بنچمارک FrontierCode 2.0 شرکت Cognition؛ مدل‌های هوش مصنوعی در نیمی از وظایف واقعی برنامهنویسی شکست میخورند

شرکت Cognition، سازنده دستیار هوشمند Devin، از بنچمارک جدیدی به نام FrontierCode 2.0 رونمایی کرده است؛ ابزاری ارزیابی که پولریکوئستهای حاصل از درخواستهای تعمداً مبهم و ناکامل را میسنجد. سیستم نمرهدهی این بنچمارک فراتر از دستورات اولیه پرامپت میرود و انتظارات واقعی مدیران مخزن کد مانند رعایت الگوهای پروژه، مدیریت حالتهای خاص، پاکسازی درست منابع، نگارش آزمونهای مناسب و حفظ پایداری رابطهای برنامه‌نویسی (API) را ملاک سنجش قرار می‌دهد.

در این ارزیابی، مدل Opus 5.5 با کسب امتیاز ۴۵ درصد در رتبه نخست قرار گرفت؛ نتیجهای که نشان می‌دهد هیچکدام از مدل‌های بررسیشده نتوانستهاند حتی به نیمی از امتیاز ممکن دست پیدا کنند. این جدول ردهبندی تفاوتهای چشمگیری با ارزیابیهای پیشین کدنویسی دارد؛ بهطور مثال مدل‌های Muse Wonder 1.0 و Gemini 4 Argon که در بنچمارک DeepSWE v1.1 عملکرد درخشانی داشتند، در جدول FrontierCode به میانه ردهبندی سقوط کردهاند.

ورود عنصر قضاوت مهندسی به معیارهای ارزیابی

بسیاری از بنچمارک‌های کدنویسی، مشخصات دقیق و جزییات فنی را در اختیار ایجنت‌ها می‌گذارند و سپس ارزیابی می‌کنند که آیا کد خروجی با این الزامات همخوانی دارد یا خیر. در مقابل، بنچمارک FrontierCode شرح مسائلی غیررسمی و مبهم را به مدل ارائه می‌دهد و تصمیمات مهندسی گستردهتری را میسنجد که برای ایجاد یک پچ قابل ادغام در کد اصلی ضروری هستند. در این آزمون، علاوه بر صحت کارکرد کد، کیفیت معماری و جامعیت پیادهسازی نیز نقشی محوری ایفا می‌کنند.

ایجنت برنامهنویسی در مواجهه با این درخواستها، باید محدودیتها و نکاتی را بهدرستی استنباط کند که یک مهندس باتجربه بهطور طبیعی از دل مخزن کد درک میکند؛ مواردی مانند:

• استفاده مجدد از ساختارها و لایه‌های موجود به‌جای ایجاد کدهای تکراری و زائد
• پیروی دقیق از استانداردهای نامگذاری، معماری و سبک آزموننویسی همان پروژه
• برطرف کردن تمام موارد مرتبط با همان باگ در سایر بخش‌های کد
• پشتیبانی از همان نوع داده‌های ورودی که توابع مجاور پردازش می‌کنند
• حفظ تعهدات پاکسازی منابع و عدم تغییر در رابطهای عمومی برنامه‌نویسی
• نوشتن تستهایی که با بازگشت احتمالی باگ در آینده بلافاصله ناموفق شوند

ابهام در درخواستها؛ عامل دگرگونی جدول ردهبندی

شرکت Cognition مدل‌ها را بر اساس هزینه پردازش و سطح توانمندی در جدول آنلاین خود دستهبندی کرده است. نتایج بهدستآمده در FrontierCode 2.0 به شرح زیر است:

بررسی این نتایج نشان می‌دهد که حتی ارزان‌ترین مدل‌های اختصاصی تجاری توانستهاند امتیازی بالاتر از ۲۰ درصد کسب کنند؛ درحالیکه گروه‌های متنباز به امتیازهای ۱۷ درصد و ۳ درصد بسنده کردهاند. این فاصله عملکردی، بسیار عمیق‌تر از رتبهبندیهایی است که معمولاً در ارزیابیهای سنتی با سبک SWE-Bench با تعریف دقیق صورت مسئله مشاهده میشد.

معیارهای سختگیرانهتر و دامنه تغییرات گستردهتر

نسخه دوم FrontierCode تنوع مخازن کد را گسترش داده، دستهبندیهایی چون وصلههای امنیتی و بهینهسازی عملکرد را اضافه کرده و شرایط سختگیرانهتری را برای صحت و طراحی کد اعمال نموده است. در مقایسه با نسخه ۱٫۱، کدهای مبنا ۲۵ درصد حجیمتر شدهاند و راهکارهای مرجع بهطور میانگین ۶۷ درصد فایل‌های بیشتر و ۸۹ درصد سطرهای بیشتری را دستخوش تغییر می‌کنند.

الزامات کلیدی مرتبط با جامعیت پیادهسازی در این نسخه، سه برابر بیشتر از نسخه ۱٫۱ تکرار شدهاند. این بازرسیها مواردی مانند برطرف ساختن ریشهای یک نقص در تمام بخش‌ها با وجود اشاره به تنها یک مورد در صورت مسئله، یا تعمیم قابلیت‌های جدید به انواع ورودیهایی که توابع همجوار پشتیبانی می‌کنند را در بر می‌گیرند.

یک ژنراتور رهاشده شکاف واقعی را آشکار می‌کند

یکی از نمونه چالش‌های این بنچمارک از کتابخانه جاوااسکریپتی Mock Service Worker گرفته شده که برای شبیهسازی درخواستهای شبکه کاربرد دارد. گزارش این مسئله حاکی از آن بود که تابع resetHandlers() نمی‌تواند کدهای مبتنی بر ژنراتور را مجدداً راه‌اندازی کند.

مدل Opus 5.5 برای بازگرداندن این رفتار، ارجاع به ژنراتور قبلی را حذف می‌کند تا درخواست بعدی بتواند یک نمونه تازه بسازد. اما این روش باعث می‌شود ژنراتور رهاشده همچنان باز بماند و در نتیجه، دستورات پاکسازی منابع که در بلوک finally نوشته شدهاند هرگز اجرا نشوند.

function* () {
  try {
    yield 'first'
    return 'rest'
  } finally {
    cleanup() // skipped if the generator is abandoned
  }
}

زبان جاوااسکریپت پس از قطع ارتباط با یک ژنراتور، تابع return() را بهطور خودکار صدا نمیزند. یک ریست اصولی باید پیش از جایگزینی، تکرارکننده قبلی را صراحتاً ببندد یا پاکسازی معادل آن را اجرا کند. پچ ارائهشده توسط مدل، هرچند مشکل ظاهری را حل میکند، اما چرخه حیات استاندارد این کتابخانه را نقض مینماید.

تلاش استدلالی بیشتر؛ چاقوی دولبه برای دامنه تغییرات کد

شرکت Cognition همچنین گزارش داده که تنظیمات استدلالی بالاتر گاهی اوقات به کاهش امتیاز مدل‌ها میانجامد؛ چراکه مدل‌ها کدهای بیشتری مینویسند و فایل‌های بیشتری را تغییر می‌دهند. پچهای بزرگ‌تر احتمال ایجاد تغییرات ناخواسته، ناسازگاری در بخش‌های دیگر پروژه و بازطراحیهای غیرضروری را بهشدت افزایش می‌دهند.

یکی از وظایف مربوط به PostHog Android SDK این ریسک را بهخوبی نمایان می‌کند. مدل GPT-6 Astra در حالت استدلال پایین، یک اصلاحیه کوچک و دقیق برای رفع یک خطای همزمانی ارائه می‌دهد. اما در بالاترین سطح استدلال، این مدل یک کلاس عمومی از رابط برنامه‌نویسی را بهکل حذف میکند؛ اقدامی که اگرچه خطای همزمانی را از بین میبرد، اما کدهای وابسته در نرم‌افزارهای توسعهدهندگان را با خطایی فاحش و ناسازگاری روبهرو می‌سازد.

نحوه انتخاب ایجنت مناسب بر اساس این نتایج

تیم‌هایی که در پی انتخاب ایجنت‌های خودکار برای ثبت پولریکوئست هستند، می‌توانند از FrontierCode در کنار بنچمارک‌های مبتنی بر الزامات صریح استفاده کنند. این نتایج به تصمیمگیریهای عملی زیر کمک شایانی می‌کنند:

• سنجش متناسب با جریان کاری واقعی: ارزیابی FrontierCode زمانی بیشترین کاربرد را دارد که ایجنت‌ها گزارش‌های غیررسمی دریافت می‌کنند و دسترسی اندکی به توضیحات تکمیلی دارند.
• مقایسه هزینه با کیفیت کار: مدل GPT-6.1 Sol با ثبت امتیاز ۳۹ درصد و هزینه ۱٫۰۳ دلار به ازای هر وظیفه، بالاترین بهرهوری اقتصادی را از خود نشان داده است.
• تنظیم دقیق سطح استدلال: صرف توان پردازشی بیشتر می‌تواند حجم کد و دامنه دستکاریها را بیمورد افزایش دهد؛ بنابراین تیم‌ها باید سطوح مختلف استدلال را روی مخازن اختصاصی خود بیازمایند.
• مهار ریسکهای ناسازگاری کد: دستورالعملهای ورودی به ایجنت و فرایندهای بازبینی کد باید بهطور ویژه از رابطهای عمومی، فرایندهای مهاجرت داده و الگوهای پاکسازی منابع محافظت کنند.
• آزمون محلی پیش از بهکارگیری مدل‌های متنباز: مدل‌های متنباز موجود در این بنچمارک فاصله زیادی با سیستم‌های اختصاصی دارند و پیش از سپردن وظایف مستقل به آنها، نیازمند آزمونهای اختصاصی روی کدهای پروژه هستند.

طراحی چالش‌ها توسط مدیران پروژه‌ها و اهمیت بافت مخزن

شرکت Cognition اعلام کرده که هر یک از چالش‌های این بنچمارک توسط مدیران و نگهدارندگان اصلی همان مخزن طراحی شده و آمادهسازی هر کدام بیش از ۴۰ ساعت زمان برده است. در ۸۰ درصد موارد، راهکار مرجع این بنچمارک با پولریکوئست اصلی و اولیه پروژه متفاوت بوده است. همچنین در جریان این بررسیهای دقیق، یک آسیبپذیری امنیتی ناشناخته نیز کشف و به توسعهدهندگان پروژه گزارش شد.

از آنجا که خود شرکت Cognition هم بنچمارک و هم لیدربورد را تولید کرده است، انجام آزمونهای داخلی پیش از تصمیمگیری نهایی برای خرید و استقرار ایجنت‌ها امری ضروری به شمار می‌آید. تیم‌های مهندسی باید وظایفی نمونه از کدهای اختصاصی خود بسازند، بار بازبینی کدهای تولیدی و نرخ بازگشت باگها را اندازهگیری کنند و نتایج FrontierCode را تنها بهعنوان یک شاخص راهنما در فرآیند ارزیابی خود مدنظر قرار دهند.