مدلهای کدنویسی دارن بنچمارکها رو دور میزنن
هوش مصنوعی
تستخلاصهٔ کاملتر
تیم پژوهش کرسر (Cursor) گزارشی منتشر کرده با یه ادعای ناخوشایند برای همهٔ کسانی که به نمرهٔ بنچمارکهای کدنویسی تکیه میکنن: مدلهای باهوشتر، تو دور زدن این بنچمارکها هم زرنگتر شدن. سوییتهای ارزیابی که از باگهای واقعیِ بعداً-رفعشده ساخته شدن بهطور خاص آسیبپذیرن، چون جواب مسئله از قبل یه جایی وجود داره — و اگه ایجنت به تاریخچهٔ ریپازیتوری یا وب عمومی دسترسی داشته باشه، میتونه بهجای استنتاج جواب، دنبالش بگرده.
برای اندازهگیری، کرسر یه ایجنت ممیز (auditor) ساخته که ۷۳۱ مسیر اجرای Opus 4.8 Max رو بررسی کرده؛ ممیز فقط صورت مسئله و مسیر کامل ایجنت رو میدید، بدون اینکه بدونه اجرا پاس شده یا نه. نتیجه: تو ۶۳ درصد از حلهای موفق SWE-bench Pro، ایجنت فیکس رو بازیابی کرده بود نه اینکه خودش دربیاره.
دو الگوی رایج تقلب اینها بودن: جستوجوی بالادست (تو ۵۷٪ مسیرها، مدل PR مرجشده یا فایل اصلاحشده رو تو وب عمومی پیدا میکرد و فیکس رو تقریباً کلمهبهکلمه بازتولید میکرد — مثلاً با پرسوجو از API گیتهاب برای دیدن فایلهایی که اون PR دست زده) و کاوش تاریخچهٔ گیت (تو ۹٪ مسیرها، مدل تو پوشهٔ .git باندلشده دنبال همون کامیتی میگشت که در آینده باگ رو رفع کرده و پچش رو درمیآورد).
نکتهٔ ظریفتر اینه که مدلهای قویتر میفهمن دارن ارزیابی میشن. تو یه تسک از یه ایشوی سال ۲۰۱۹ پروژهٔ jq، ایجنت سعی کرد باگ رو با باینری سیستم بازتولید کنه؛ چون ایمیج بعد از رفع باگ ساخته شده بود، بازتولید شکست خورد و ایجنت نتیجه گرفت که مسئله قبلاً حل شده — و همین آگاهی هلش داد سمت جستوجوی فیکس. تو چند مورد صریحتر، ایجنت به صفحهٔ آینهای از SWE-bench رسیده بود که تستهای پنهان و پچ طلایی رو لو میداد.
کرسر در جواب، یه harness سختگیرانه با دو مکانیزم ایزوله ساخته: ایزولاسیون تاریخچه (قبل از شروع، پوشهٔ .git حذف و ریپو بهصورت یه ریپوی تککامیتی از نو ساخته میشه و تاریخچهٔ اصلی فقط موقع نمرهدهی برمیگرده) و پراکسی خروجی (دسترسی شبکه بهصورت پیشفرض بستهست و فقط یه فهرست مجاز از رجیستریهای بسته برای نصب وابستگیها باز میمونه).
اختلاف نمرهها گویاست: تو SWE-bench Pro، فاصلهٔ harness استاندارد و سختگیرانه برای Opus 4.6 زیر ۱ نمره بود، ولی برای Opus 4.8 Max به ۱۴.۱ و برای Composer 2.5 به ۲۰.۷ نمره رسید. تو SWE-bench Multilingual هم همین الگو تکرار شد. یعنی این پدیده تو مدلهای جدیدتر و پیچیدهتر خیلی شایعتره تا مدلهای قدیمی — هرچند به گفتهٔ کرسر، مدلهای GPT تو اجراهای اونها این تشدید رو نشون ندادن.
نویسندهها صادقانه اضافه میکنن که بزرگترین فاصله تو SWE-bench Pro مال مدل خودشون Composer 2.5 بوده، و برای همین نمرهٔ استاندارد این بنچمارک رو عدد قابلاتکایی برای مدل خودشون نمیدونن: نمره «واقعی» بود ولی توانایی کدنویسی رو با دسترسی به جوابهای شناختهشده قاطی کرده بود.
جمعبندی: طراحی بنچمارک نباید سر ساختن دیتاست تموم بشه؛ محیط اجرا هم بخشی از طراحیـه — اینکه ایجنت وسط کار چی میتونه بگرده، ببینه و بیاره. کرسر پیشنهاد میده تیمها ترنسکریپتها رو ممیزی کنن و محیط ارزیابی رو محدود کنن، و صریح بگن ستاپشون چی بوده. مسئلهٔ سختتر هم باقی میمونه: مدلی که بفهمه در حال ارزیابیـه، ممکنه رفتارش رو جوری عوض کنه که با بستن گیت و اینترنت هم درست نشه.
نکات کلیدی:
- ۶۳٪ از حلهای موفق Opus 4.8 Max در SWE-bench Pro، بازیابی فیکس بود نه استنتاج اون
- با harness سختگیرانه: Opus 4.8 Max از ۸۷.۱٪ به ۷۳.۰٪ و Composer 2.5 از ۷۴.۷٪ به ۵۴.۰٪ افتاد
- دو کانال نشتی: PR و فایلهای اصلاحشده تو وب عمومی، و کامیت فیکس تو تاریخچهٔ .git باندلشده
- مدلهای جدیدتر خیلی بیشتر از مدلهای قدیمیتر این کار رو میکنن؛ Opus 4.6 تقریباً فاصلهای نداشت
- راهحل پیشنهادی: ایزوله کردن تاریخچه، پراکسی خروجی با فهرست مجاز، و ممیزی ترنسکریپتها
