خطاهای زیرساختی؛ عامل اصلی فریب در بنچمارک‌های کدنویسی هوش مصنوعی

تصور کنید یک عامل کدنویس در یک بنچمارک امتیاز ۸۱٪ می‌گیرد، اما در واقعیت، دلیل شکست‌هایش نه فقدان منطق، بلکه پر شدن پوشه /tmp در سرور بوده است. یک سناریوی واقعی را در نظر بگیرید: یک مسابقه کدنویسی در آخر هفته روی یک سرور ارزان‌قیمت و مشترک. عامل A امتیاز ۶۲ درصد و عامل B امتیاز ۸۱ درصد می‌گیرد. شما در حال آماده کردن پست نتایج هستید که ناگهان فایل syslog را باز می‌کنید. متوجه می‌شوید که چهار مورد از شکست‌های عامل A به‌دلیل خطای "Broken pipe" هنگام اجرای git clone بوده است، یکی به‌دلیل پر شدن دیسک در مسیر /tmp و دو مورد دیگر به‌دلیل اینکه pytest یک فایل .pyc قدیمی را وارد کرده است، چون اجرای قبلی در میانه عملیات نوشتن متوقف شده بود. در این حالت، شما مدل‌ها را اندازه نگرفته‌اید؛ بلکه «آب‌وهوای سرور» را اندازه‌گیری کرده‌اید.

در ۱۶ سپتامبر ۲۰۲۶، راهنمای فنی منتشرشده در dev.to افشا کرد که محیط‌های میزبانی مشترک چگونه داده‌های عملکردی هوش مصنوعی را آلوده می‌کنند و ارزیابی‌های مدل را به چیزی تبدیل می‌کنند که نویسنده آن را «دفترچه خاطرات میزبانی» می‌نامد. اندازه‌گیری عامل‌های هوش مصنوعی روی سرورهای مشترک اغلب باعث ایجاد پدیده‌هایی چون «همسایگان پرصدا» (Noisy Neighbors)، محدودیت‌های نرخ درخواست (Rate Limits) و پیش‌گرفتن CPUها می‌شود. وقتی یک توسعه‌دهنده هر کد خروجی غیرصفر (non-zero exit code) را به‌عنوان شکست مدل ثبت می‌کند، در واقع دارد هوش را اندازه نمی‌گیرد، بلکه وضعیت لحظه‌ای سرور را ثبت می‌کند. این امر یک توهم بازاریابی ایجاد می‌کند که در آن مدل‌ها به‌گونه‌ای به نظر می‌رسند که گویی از انسان‌ها بهتر کد می‌زنند، صرفاً چون محیط تست یک «میز کار تمیز» است که اصطکاک‌های دنیای واقعی را نادیده می‌گیرد. این تضاد میان نتایج آزمایشگاهی و عملکرد واقعی، ریشه در شکاف عمیقی دارد که باعث شکست عامل‌ها در محیط‌های عملیاتی می‌شود. در رشته‌های گفتگو در فضای عمومی ادعا می‌شود که مدل‌ها در حال حاضر از اکثر توسعه‌دهندگان بهتر کد می‌زنند، اما این ادعا برای فایلی CSV که هر خروجی غیرصفر را به عنوان «شکست عامل» ثبت کرده باشد، صادق نیست.

به نقل از این گزارش، برای توقف این آلودگی داده‌ای، متدولوژی پیشنهادی ایجاب می‌کند که هر اجرای ناموفق یا ناتمام، پیش از تجمیع هرگونه امتیاز، دقیقاً در یکی از چهار دسته‌بندی (Bucket) زیر قرار گیرد:

• MODEL: عامل یک وصله (Patch) تولید کرده یا از انجام کار امتناع کرده است، محیط اجرا (Harness) سالم مانده و تست‌ها همچنان به‌دلیل نقص در منطق تسک شکست می‌خورند. این تنها دسته‌ای است که در امتیاز مهارت محاسبه می‌شود.
• HARNESS: مشکل از اجرای‌کننده (Runner)، قالب پرامپت، سیستم داور (Grader) یا پیکربندی سندباکس است. در این حالت، عامل اصلاً شانس منصفانه‌ای برای اجرا نداشته است.
• INFRA: سقوط‌های سطح سیستم شامل قطع شدن اتصال SSH، پر شدن دیسک، خطای کمبود حافظه میزبان (Host OOM)، خطاهای ۵xx ارائه‌دهنده، محدودیت‌های نرخ درخواست (Rate Limits) یا پیش‌گرفتن زمان اجرای برنامه (Wall-clock preemption). در این موارد، تسک اصلاً امتیازدهی نمی‌شود.
• FLAKY_TEST: تست‌هایی که حتی وقتی عامل غیرفعال است، در اجراهای مجدد گاهی پاس و گاهی فیل می‌شوند.

طبق اعلام نویسنده، امتیاز واقعی مهارت باید از تقسیم تعداد موفقیت‌های MODEL بر مجموع موفقیت‌ها و شکست‌های MODEL به دست آید. تمام دسته‌های دیگر یعنی INFRA، HARNESS و FLAKY_TEST باید سانسور شوند. شما این موارد را گزارش می‌کنید، اما آن‌ها را در دسته «مدل ضعیف است» قرار نمی‌دهید. تغییر در مخرج کسر، اساس این متد است. این روش شاید خسته‌کننده به نظر برسد، اما تنها راهی است که مانع از دروغ گفتن به خودمان در تحلیل داده‌ها می‌شود. این رویکرد به ویژه برای مقابله با ناپایداری‌های ۸ تا ۲۰ درصدی در محک‌های هوش مصنوعی که نتایج را غیرقابل تکرار می‌کند، ضروری است.

برای ساخت یک مجموعه داده‌ی قابل دفاع (Defensible Holdout)، به‌جای استخراج داده‌ها از لیدربوردهای عمومی و نامیدن آن به عنوان دیتاست، راهنما پیشنهاد می‌کند یک مجموعه کوچک و منجمد (Frozen) شامل ۱۶ تسک ایجاد کنید. ۱۶ تسک برای عیب‌یابی متدولوژی کافی است، هرچند برای تعیین برنده نهایی کفایت نمی‌کند. این مجموعه باید شامل کنترل‌های خاصی باشد تا از عملکرد صحیح سیستم داور اطمینان حاصل شود:

• کنترل‌های منفی: حداقل ۴ تسک که از قبل «سبز» (پاس شده) هستند. اگر یک عامل این‌ها را با بازنویسی کدهای سالم «اصلاح» کند، این نشان‌دهنده یک باگ در سیستم داور است.
• الزام پیچیدگی: حداقل ۴ تسک که نیاز به ویرایش چندین فایل دارند. استفاده از توابع تک‌فایلی ساده، نرخ موفقیت MODEL را به‌طور کاذب بالا می‌برد.
• تأییدیه: هر تسک باید یک تست شکست‌خورده داشته باشد که در صورت نبود عامل، حتماً اجرا و فیل شود. وصله طلایی (Gold Patch)، در صورت موجود بودن، نباید در پرامپت، فایل README یا هر کامنتی که عامل می‌خواند وجود داشته باشد.
• مستندسازی: لایسنس، SHA کامیت و دلیل یک‌خطی حضور هر تسک در مجموعه ثبت شود. برای هر تسک یک شیء JSON ذخیره کنید که شامل فیلدهای id ،repo ،sha ،test_cmd ،expect_fail_without_patch ،negative_control ،multi_file و license باشد.

به‌جای یک نرخ موفقیت واحد، نویسنده استدلال می‌کند که باید تفکیکی از معیارها منتشر شود. این شامل resolved_rate (موفقیت‌های MODEL تقسیم بر تعداد واجد شرایط) در کنار infra_censor_rate (تعداد INFRA تقسیم بر تعداد برنامه‌ریزی شده)، harness_error_rate (تعداد HARNESS تقسیم بر تعداد برنامه‌ریزی شده) و flaky_rate (تعداد FLAKY_TEST تقسیم بر تعداد برنامه‌ریزی شده) است. سایر معیارهای حیاتی شامل time_to_first_green_s (تنها برای موفقیت‌های MODEL) و bytes_changed از طریق دستور git diff --stat است تا اطمینان حاصل شود که عملیات‌های بدون تغییر (no-ops) به‌عنوان پیروزی ثبت نمی‌شوند. اگر نرخ سانسور زیرساختی بالا باشد، شما با یک مقایسه مدل رو‌به‌رو نیستید، بلکه با یک گزارش خرابی سرور مواجهید. در این حالت باید توقف کنید، سرور را اصلاح کنید یا کل دسته داده‌ها را دور بریزید.

برای تضمین قابلیت حسابرسی، هر اجرا باید یک فایل «اثر انگشت» (Fingerprint) ثبت کند. این فایل باید کنترل‌های زیر را ثبت نماید:

• SHA کامیت Harness و Digest کانتینر.
• SHA مجموعه تسک‌ها در فایل JSONL.
• داده‌های زمانی: زمان شروع، پایان، منطقه زمانی و وضعیت NTP.
• اثر انگشت میزبان: خروجی uname -a ،میانگین بار سیستم (Load Average)، فضای دیسک آزاد و حافظه.
• بررسی قابلیت دسترسی به git و نقطه انتهایی (Endpoint) مدل پیش از اولین پرامپت.
• سیاست تلاش مجدد (Retry): صفر تلاش مجدد برای اعداد منتشر شده (تلاش‌های مجدد باید در پیوست گزارش بیایند).
• تنظیمات رمزگشایی (Decoding) دقیقاً همان‌طور که API بازگردانده است، نه آن‌طور که شما امیدوار بودید.

برای خودکارسازی این فرآیند، یک طبقه‌بندی‌کننده مبتنی بر Regex در پایتون ارائه شده است که لاگ‌ها را برای شناسایی الگوهایی مانند "Broken pipe" ،"Connection reset by peer" ،"No space left on device" ،"Killed" ،"Out of memory" ،"HTTP 429" ،"HTTP 5xx" ،"deadline exceeded" یا "Could not resolve host" اسکن می‌کند تا شکست‌های INFRA را به‌طور خودکار علامت‌گذاری کند. شکست‌های HARNESS نیز با الگوهایی مانند "ModuleNotFoundError: No module named 'harness'" یا "ERROR: file not found: pytest" شناسایی می‌شوند.

با این حال، نویسنده هشدار می‌دهد که Regex ابزاری کلی است و توسعه‌دهندگان باید ردیف‌های مرزی را به‌صورت دستی بررسی کنند. برای مثال، مدلی که عبارت "Connection reset by peer" را داخل یک fixture چاپ می‌کند، ممکن است شبیه به INFRA به نظر برسد. اگر دو برچسب برای یک مورد قابل اعمال باشد، اولین شکست را بر اساس ترتیب زمانی انتخاب کنید. یک خطای OOM قبل از اینکه مدل پاسخی برگرداند، یک خطای INFRA است، نه MODEL.

تیم‌های مارکتینگ عاشق یک درصد واحد و یک برنده قطعی هستند، اما گزارش‌های علمی نیازمند مخرجی هستند که قابل دفاع باشد. هرگاه ارائه‌دهنده‌ای امتیازی را بدون افشای SHA مجموعه تست، قوانین انتخاب تسک، تفاوت eligible_n در مقابل scheduled_n ،سیاست تلاش مجدد (که برای اعداد اصلی باید صفر باشد) و نرخ‌های سانسور اعلام می‌کند، باید آن را به‌عنوان «متن تبلیغاتی» دید، نه «اندازه‌گیری فنی».

این تغییر رویکرد، میدان را از لیدربوردهای تزیینی به سمت چارچوب‌های حسابرسی‌پذیر می‌برد و مرز بین توانایی استدلال عامل و توانایی اجرای زیرساخت را روشن می‌کند. برای پیاده‌سازی این روش، با اجرای یک «پروب» شروع کنید: یک وصله خالی را روی تستی که می‌دانید قرمز (شکست‌خورده) است اجرا کنید. اگر تست پاس شد، سیستم داوری شما خراب است و هیچ عدد دیگری در گزارش شما اهمیتی ندارد.

در عمل، برای تمرین این روش نیازی به کلاسترهای پیچیده نیست. شما فقط به لاگ‌ها، یک مجموعه منجمد و سروری نیاز دارید که بتواند یک دسته اجرا را به پایان برساند. MonkeyCode دسترسی رایگان به مدل‌ها و گزینه سرور رایگان را برای کمک به عیب‌یابی این طبقه‌بندی فراهم می‌کند. اگر سرور رایگان پرسرصدا باشد، نتیجه صادقانه یک infra_censor_rate بالا و عدم امکان رتبه‌بندی است.

البته این رویکرد محدودیت‌هایی دارد. چهار دسته (Bucket) کلی هستند؛ برای مثال، یک پین اشتباه در تست با یک برنامه‌ریز (Planner) گیج متفاوت است. شما می‌توانید بعداً زیربرچسب‌ها اضافه کنید، اما این کار را تا زمانی که ترکیب خطاهای SSH با امتیازات مهارت را متوقف نکرده‌اید، انجام ندهید. اگر به SLAهای تولیدی نیاز دارید، اگر نمی‌توانید مجموعه تست را منجمد کنید، اگر تست‌های شما به شبکه زنده متصل می‌شوند یا اگر هدف شما صرفاً یک پست برای لانچ محصول است، از این روش استفاده نکنید. همچنین عامل‌هایی را که پرامپت‌ها، تایم‌اوت‌ها یا روزهای متفاوتی را دیده‌اند، بدون افشای این موارد با هم مقایسه نکنید. مهم‌تر از همه، اگر قصد بررسی Diffها را ندارید، این روش را رها کنید. برچسب‌ها بدون بررسی Diffها، صرفاً یک لباس مبدل دیگر هستند.

پیش از آنکه عددی را نقل کنید، یک لاگ شکست را باز کنید. نام دسته (Bucket) را روی کاغذ بنویسید. اگر در نوشتن آن تردید کردید، یعنی آن عدد هنوز آماده انتشار نیست.

گام بعدی شما

• لاگ‌های شکست مدل‌های خود را باز کنید و بررسی کنید چند درصد آن‌ها به‌دلیل خطاهای سیستم (مثل HTTP 429 یا OOM) بوده‌اند.
• یک مجموعه تست کوچک (Holdout set) شامل کنترل‌های منفی بسازید تا از صحت عملکرد Grader مطمئن شوید.
• در گزارش‌های فنی خود، نرخ سانسور زیرساختی (Infra-censor rate) را به‌عنوان یک معیار شفافیت اضافه کنید.

اما تأثیر این نویزها بر مدل‌های استدلالی (Reasoning Models) که زمان استنتاج بیشتری می‌برند حتی پیچیده‌تر است — به تحلیل ما درباره‌ی مدل‌های استدلالی مراجعه کنید.