خطاهای بنچمارک cli-bench عملکرد مدل‌های کدنویسی را کمتر از واقع نشان داد

تصور کنید دانش‌آموزی در امتحان ریاضی نمره صفر بگیرد، نه به این دلیل که جبر بلد نیست، بلکه چون کلید پاسخ‌نامه اشتباه چاپ شده است. این دقیقاً همان اتفاقی است که در ارزیابی مدل‌های پیشرو هوش مصنوعی در بنچمارک cli-bench رخ داده است. در تاریخ ۱۰ اکتبر ۲۰۲۶، نگهدارنده cli-bench فاش کرد که بخش قابل توجهی از شکست‌های اولیه مدل‌های کدنویس AI، در واقع ناشی از باگ‌های موجود در اسکریپت‌های تاییدکننده (Verifier) و تنظیمات محیطی خودِ بنچمارک بوده است.

بسیاری از توسعه‌دهندگان تصور می‌کنند وقتی یک عامل (Agent) — شبیه دستیاری که می‌تواند ابزارهای مختلف را برای رسیدن به هدف به کار بگیرد — در یک تست کدنویسی شکست می‌خورد، مدل فاقد قدرت استدلال لازم برای حل مسئله است. این چالش‌ها در مدیریت حافظه و بازیابی داده‌ها نیز دیده می‌شود، همان‌طور که حافظهٔ Poincaré توانست نرخ بازیابی داده‌های این عامل‌ها را به ۹۹.۸٪ برساند. اما این بررسی نشان می‌دهد که «شکست‌ها» اغلب صرفاً نتیجه‌ی بنچمارکی هستند که یا مورد اشتباهی را نمره می‌دهد و یا به دلیل نبود وابستگی‌های نرم‌افزاری (Dependencies) کرش می‌کند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، ابزارهای ارزیابی اغلب نقطه‌ضعف زنجیره اعتماد هستند. در این مورد، نویسنده برای جداسازی اثر «حلقه عامل» (Agent Loop) — یعنی فرآیندی که مدل کد را اجرا می‌کند، خطا را می‌بیند و دوباره تلاش می‌کند — شش تسک را به Kaggle Benchmarks منتقل کرد.

در این نسخه، مدل‌ها در حالت تک‌مرحله‌ای (One-shot) عمل می‌کنند؛ یعنی مدل فقط یک فرصت برای پاسخ دادن دارد. در این حالت، پرامپت شامل تمام فایل‌های موجود در مخزن (Repo) است و مدل باید پاسخ خود را در قالب بلوک‌های FILE: path ارسال کند. سپس سیستم این فایل‌ها را در یک دایرکتوری موقت می‌نویسد و گیت‌های تاییدکننده اصلی cli-bench را اجرا می‌کند. یک اجرا تنها زمانی پاس می‌شود که تمام گیت‌ها تایید شوند.

اگر مدل در پاسخ خود سعی کند یک فایل تست یا یک ورودی را بازنویسی کند، آن تغییر نادیده گرفته شده و اجرا شکست می‌خورد. این مکانیسم دقیقاً مشابه روش cli-bench برای برخورد با «تخریب» (Sabotage) است. هدف از این کار این است که مشخص شود چه مقدار از نمره نهایی حاصل دقت مدل در خواندن کد است و چه مقدار به حلقه تکرار و اصلاح در محیط عامل بازمی‌گردد.

تسک‌های منتقل شده طیف گسترده‌ای از توانمندی‌های کدنویسی را می‌سنجند:

• cb-debug-wrong-answer: یافتن یک باگ در یک کتابخانه آماری کوچک. تاییدکننده بررسی می‌کند که آیا مجموعه تست‌های pytest ارسال شده پاس می‌شوند یا خیر.
• cb-refactor-deadcode: حذف دقیقاً سه تابع بلااستفاده. تاییدکننده اطمینان حاصل می‌کند که توابع مرده حذف شده‌اند، شش تابع فعال باقی مانده‌اند و تست‌ها پاس می‌شوند.
• cb-feature-rate-limiter: نوشتن یک توکن‌باکت (Token Bucket) امن برای مدیریت نرخ درخواست‌ها (Thread-safe) بر اساس یک مشخصات رابط (Interface Spec). تاییدکننده‌ها مواردی چون Burst، Refill، بازگشت اتمیک (Atomic Rollback) و هم‌روندی (Concurrency) با ۱۰۰ رشته را بررسی می‌کنند.
• cb-perf-hot-loop: افزایش سرعت یک شمارنده جفت‌ها در پایتون خالص (Pure Python) با استفاده از کتابخانه استاندارد، به گونه‌ای که حداقل ۱۰ برابر سریع‌تر شود. این تسک روی نقاط یکنواخت، خوشه‌ای و شبکه‌ای با معادل‌سازی تصادفی تست می‌شود.
• cb-data-log-analysis: پاسخ به هفت پرسش دقیق درباره لاگ‌های یک اپلیکیشن. مدل باید فایلی به نام solve.py بنویسد و سپس هر پاسخ با لاگ مقایسه می‌شود.
• cb-sec-patch-xss: بستن یک حفره امنیتی XSS در یک تابلوی نظرات. تست‌های اکسپلویت باید پاس شوند و هر پی‌لود (Payload) جدیدی باید به صورت متن ساده رندر شود.

در این ارزیابی از مدل‌های تراز اولی چون gpt-5.6-luna (برای مقایسه حالت تک‌مرحله‌ای در مقابل حلقه عامل)، claude-opus-5-5-default (بالاترین سطح آنتروپیک) و gemini-3.1-pro-preview (سطح Pro گوگل) استفاده شد. این مدل گوگل پیش‌تر در آزمون‌های کدنویسی «مسموم» عملکردی خیره‌کننده داشت و تنها مدلی بود که تقلب نکرد. همچنین مدل‌های وزن‌های باز (Open Weights) مانند qwen3-coder-480b-a35b-instruct که اختصاصاً برای کدنویسی ساخته شده و gpt-oss-120b که یک مدل عمومی برای سخت‌افزارهای محلی است، در کنار Gemini 3.7 Flash (مدل پیش‌فرض Kaggle) حضور داشتند.

بر اساس بررسی خط‌به‌خط کدهای تاییدکننده، دو باگ بحرانی در تسک‌های بنچمارک کشف شد:

اول، باگ وصله XSS: تسک امنیتی، اصلاحات درست را رد می‌کرد زیرا تاییدکننده کلمات 'alert' و 'onerror' را به طور کلی ممنوع کرده بود. یک اصلاح استاندارد با استفاده از html.escape همچنان کلمه 'alert' در متن اسکیپ‌شده نگه می‌دارد، که باعث می‌شد تست شکست بخورد، در حالی که آسیب‌پذیری بسته شده بود. حذف کامل متن باعث پاس شدن تست می‌شد اما در بررسی‌های عمیق‌تر (Probe) شکست می‌خورد. در اجرای Codex، دو مورد از سه تلاش از html.escape استفاده کردند و شکست خوردند، و مورد سوم متن را حذف کرد و در Probe شکست خورد.

دوم، باگ تحلیل لاگ: تسک از مدل می‌خواست «نرخ خطا» را بر اساس یک قانون خاص محاسبه کند، اما تاییدکننده از فرمول متفاوتی برای نمره‌دهی استفاده می‌کرد. برگه سوال error_rate را به عنوان «کسری از خطوط با سطح ERROR» تعریف کرده بود، اما تاییدکننده خطوط درخواست ERROR را بر کل خطوط درخواست تقسیم می‌کرد. از آنجایی که یک از هر هفت خط درخواست نبود، تلاش‌های Codex با نتایجی مانند ۰.۰۴۳۴ در مقابل ۰.۰۵ شکست خوردند.

این دو باگ به تنهایی باعث شکست ۵ مورد از ۱۳ تلاش ناموفق در اولین اجرای لیدربورد شدند. مدل‌ها دچار توهم (Hallucination) نشده بودند؛ آن‌ها دستورالعمل‌هایی را دنبال می‌کردند که با اسکریپت نمره‌دهی در تضاد بود.

علاوه بر باگ‌های منطقی، شکاف‌های زیرساختی نیز وجود داشت. نویسنده دریافت که محیط اجرای Kaggle فاقد pytest است و باعث شد هر ۶ مدل در تسک XSS شکست بخورند، زیرا رانر تست جایگزین از فیچرهای pytest مانند tmp_path و monkeypatch پشتیبانی نمی‌کرد.

علاوه بر این، یک پارسر سخت‌گیرانه، پاسخ مدل gpt-oss-120b را صرفاً به دلیل فرمت خروجی **FILE: solve.py** (به جای FILE: solve.py) رد کرد. وقتی کد مدل به صورت دستی اجرا شد، کاملاً درست بود. این مشکلات زیرساختی باعث ۷ مورد از ۹ شکست در اولین دسته از اجراهای Kaggle شد.

یکی از ضدشهودی‌ترین یافته‌ها مربوط به gpt-5.6-luna بود. در اجرای اصلی عامل‌محور (با دسترسی به شل)، این مدل تسک بهینه‌سازی سرعت (hot-loop) را تنها در ۱ از ۳ مورد پاس کرد و در بدترین حالت، روی مجموعه داده‌های شبکه‌ای تنها ۱.۲ برابر سرعت را افزایش داد.

اما در نسخه تک‌مرحله‌ای Kaggle، همان مدل راهکاری مبتنی بر شبکه فضایی (Spatial Grid) ارائه داد که به طور قابل توجهی سریع‌تر بود. روی سیستم نویسنده، این راهکار به افزایش سرعت ۴۲.۵ برابری در نقاط یکنواخت، ۲۶.۵ برابری در نقاط شبکه‌ای و ۱۴.۶ برابری در نقاط خوشه‌ای دست یافت.

این نتیجه نشان می‌دهد دسترسی عامل به شل برای «تست و اصلاح»، ممکن است مدل را به سمت بهبودهای تدریجی و کند سوق دهد، به جای اینکه آن را تشویق کند یک معماری بنیادین و سریع‌تر را از ابتدا طراحی کند.

در نهایت، پس از اصلاح تسک‌ها، نتایج تقریباً بی‌نقص بود و ۳۵ مورد از ۳۶ اجرا پاس شدند. هر مدل با موفقیت باگ آماری را رفع کرد، توابع مرده را حذف نمود و تابلوی نظرات را به درستی اسکیپ کرد.

• مدل‌های Claude Opus 5.5، Gemini 3.1 Pro، GPT-5.6 Luna و gpt-oss-120b همگی نمره ۶ از ۶ گرفتند.
• Gemini 3.7 Flash نیز نمره ۶ از ۶ کسب کرد.
• Qwen3 Coder 480B نمره ۵ از ۶ گرفت. این مدل در تسک hot-loop شکست خورد زیرا شبکه آن جفت‌ها را کمتر از واقعیت می‌شمرد (۸۴ جفت در مقابل ۱۲۳ جفت). این باگ تمام ۹ تست واحد ارسال شده را پاس کرده بود و تنها توسط بررسی معادل‌سازی تصادفی شناسایی شد. در مورد دیگری، مدل با فراخوانی statistics.quantiles با یک نام متد غیرموجود کرش کرد، هرچند در اجرای مجدد پاس شد.

این آزمایش ثابت می‌کند که یک بنچمارک تا زمانی که در برابر پاسخ‌های صحیح و غلطِ شناخته‌شده در محیط واقعی تولید (Production) اعتبارسنجی نشود، واقعاً بنچمارک نیست. این موضوع یادآور تحلیل‌های ما در ConstraintBench است که نشان داد پاسخ‌های درست هوش مصنوعی لزوماً جریان‌های کاری واقعی را نجات نمی‌دهند. نویسنده اکنون اطمینان حاصل می‌کند که هر تسک همراه با یک راهکار مرجع، یک پاسخ خالی و یک پاسخ «بازنویسی تست» ارسال شود. یک تسک تنها زمانی معتبر است که مورد اول پاس شود و دو مورد دیگر شکست بخورند.

برای جامعه هوش مصنوعی، این موضوع یک ریسک سیستماتیک را برجسته می‌کند: ما ممکن است «شکاف استدلالی» در مدل‌ها را بیش از حد تخمین بزنیم، در حالی که شکاف واقعی در ابزارهای ارزیابی ماست. اگر تاییدکننده شکننده باشد، نمره مدل معیاری از توانایی آن در حدس زدن رفتارهای عجیب تاییدکننده است، نه توانایی آن در کدنویسی.

اندازه‌گیری‌های آینده بر تسک‌های سخت‌تر cli-bench مانند تست‌های ناپایدار (Flaky-test) و تسک‌های CI، و همچنین پروب‌های «هودینی» (Houdini) متمرکز خواهد بود تا بررسی شود آیا مدل‌ها تاییدکننده را دور می‌زنند یا خیر. با اجرای سه یا چند تلاش برای هر مدل، واریانس‌ها — مانند کرش تک‌مرحله‌ای Qwen — قابل مشاهده می‌شوند.

گام بعدی شما

• اگر از بنچمارک‌های آماده برای ارزیابی مدل‌های کدنویس استفاده می‌کنید، ابتدا اسکریپت‌های تاییدکننده (Verifier) را با پاسخ‌های صحیح و غلطِ شناخته‌شده تست کنید.
• در تسک‌های بهینه‌سازی عملکرد، حالت تک‌مرحله‌ای (One-shot) را با حالت عامل‌محور مقایسه کنید تا متوجه شوید آیا حلقه اصلاح، خلاقیت مدل را محدود می‌کند یا خیر.
• برای کاهش نرخ خطای کاذب، از پارسرهای منعطف‌تر برای استخراج کد از پاسخ‌های مدل استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.