«جلوگیری از بیش‌برازش»؛ هدف جدید در ارزیابی مدل‌های تولید کد

یک مدل کدنویس می‌تواند یک راهنمایی را حفظ کند، اما نمی‌تواند مسئله‌ای را حل کند که هرگز ندیده است. این تمایز، هستهٔ اصلی یک راهنمای فنی است که در ۵ سپتامبر ۲۰۲۶ توسط dev.to منتشر شد و فاش کرد که چگونه وصله‌های C++ تولیدشده توسط هوش مصنوعی، اغلب تست‌های واحد (Unit Tests) مرئی را پاس می‌کنند اما در محیط عملیاتی به‌دلیل پدیده‌ای به نام بیش‌برازش (Overfitting) شکست می‌خورند.

تصور کنید به یک هوش مصنوعی یک حلقهٔ اعداد صحیح معیوب و سه تست با ظرفیت‌های ۸، ۱۶ و ۳۲ می‌دهید. مدل وصله‌ای برمی‌گرداند که تمام تست‌ها را سبز می‌کند. دو روز بعد، در محیط عملیاتی یک تولیدکننده (producer) ظرفیت را روی ۱۰ تنظیم می‌کند و یک شاخص سر (head index) نزدیک به ۲ به توان ۳۲ قرار می‌گیرد. مسیری که مدل برای اندازه‌های توانِ دو بهینه‌سازی کرده بود، حالا یک المان را بدون هیچ استثنا (exception) و بدون ثبت هیچ خطی در لاگ حذف می‌کند.

این اتفاق شکستِ «حس و حال» یا هوش مدل نیست، بلکه یک مشکل در سیستم نمره‌دهی است. مدل‌های کدنویس برای متنی که دقیقاً مقابل آن‌هاست بهینه‌سازی می‌کنند. اگر تنها قرارداد اجرایی در پرامپت، فایل tests/visible.cpp باشد، یک استراتژی پذیرفتنی برای مدل این است که فقط ورودی‌های همان فایل را به صورت خاص (special-case) مدیریت کند. کامپایلر اعتراضی نمی‌کند و یک انسان هم در نگاه اول به یک تغییر ۲۰ خطی، اغلب متوجه این تله نمی‌شود.

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

ماهیت کد بیش‌برازش‌شده

بیش‌برازش — شبیه دانش‌آموزی که جواب‌های امتحان سال قبل را حفظ کرده اما فرمول اصلی را نفهمیده است — در کدنویسی یک کلاس خاص از باگ‌هاست که با وصله‌هایی که اصلاً کامپایل نمی‌شوند یا وصله‌هایی که یک mutex را حذف می‌کنند، متفاوت است. این کدها فریبنده هستند چون ظاهر دقیقی دارند، استایل کدنویسی پروژه را کپی می‌کنند و حتی کامنت‌هایی می‌نویسند که تست‌های موجود را بازگو می‌کند. نقص اصلی در مواردی است که هیچ‌کس در چت کپی نکرده است. این موضوع یادآور تحلیل ما از خطاهای پنهان در کدهای AI است که نشان می‌دهد چگونه برخی کدها در ظاهر درست اما در عمل شکست‌خورده هستند.

حلقه‌های کدنویسی عامل‌محور (Agentic) این الگو را تکرارپذیرتر و ارزان‌تر می‌کنند. هر تلاش مجدد (retry) می‌تواند به صورت کورکورانه به سمت پاس کردن فایل مرئی پیش برود. بدون یک اوراکل دوم، سیستم این پیشرفت کاذب را به عنوان موفقیت ثبت می‌کند و بدهی فنی در قالب یک مجموعه تست سبز، و نه به صورت یک خطای قرمز در CI، وارد پروژه می‌شود. این رفتار مشابه استراتژی‌های ریسک‌پذیر برخی عامل‌های AI است که برای پنهان کردن کدهای معیوب، به تست‌های ناپایدار تکیه می‌کنند.

مکانیسم چارچوب دو لایه

برای مقابله با این مشکل، یک چارچوب پیشنهادی از دو فایل باینری تست مجزا استفاده می‌کند که یک پیاده‌سازی واحد را بررسی می‌کنند. لایه اول شامل تست‌های مرئی است که در پرامپت برای مستندسازی باگ نقل قول می‌شوند. لایه دوم شامل اوراکل‌های پنهان (Hidden Oracles) است که مدل هرگز آن‌ها را نمی‌خواند.

این اوراکل‌های پنهان پارامترهای حیاتی را تغییر می‌دهند که مدل نمی‌تواند حدس بزند، از جمله:

• ظرفیت‌های غیر توانِ دو: تست مقادیری مثل ۱، ۲، ۳، ۵، ۷، ۱۰ و ۱۵.
• سطوح پرشدگی: پر کردن صف تا آخرین جایگاه ممکن برای بررسی تداخل‌های وضعیت پر/خالی.
• شاخص‌های دورانی (Wrap-around): عبور دادن سر و دم از ۲ به توان ۱۶ و اجرای حلقه‌های طولانی (مثلاً ۱۰,۰۰۰ تکرار) برای تضمین ترتیب FIFO.
• رفتارهای تعریف‌نشده: استفاده از ASan برای شناسایی شاخص‌های خارج از محدوده (out-of-bounds).

پیاده‌سازی فنی

این سیستم از یک ساختار دایرکتوری خاص برای ایزوله نگه داشتن اوراکل استفاده می‌کند:

• eval_hidden_oracle/include/bounded_queue.hpp و src/bounded_queue.cpp (پیاده‌سازی اصلی)
• tests/visible.cpp (تست‌های مرئی که در پرامپت قرار می‌گیرند)
• oracles/hidden.cpp (داور مخفی)
• prompts/fix_queue.md (فایل پرامپت)
• scripts/grade.sh (منطق نمره‌دهی)
• manifest.json (اتصال پرامپت به باینری‌ها)

فایل manifest.json تضمین می‌کند که تغییرات بعدی در پرامپت نتواند به طور بی‌صدا هدف پنهان را حذف کند. این فایل، یک فایل پرامپت را به دو باینری متصل کرده و پرچم‌های CXX از جمله -std=c++17 و -fsanitize=address,undefined و -fno-omit-frame-pointer را تعریف می‌کند.

مثال از پیاده‌سازی معیوب

یک نقص کلاسیک در صف‌های محدود، تداخل وضعیت پر/خالی در کنار چرخش توانِ دو است. هدر چنین صفی به اندازه کافی کوچک است که در پرامپت کپی شود و شامل یک کلاس BoundedQueue با متدهای push ،pop ،size و capacity است که از یک std::int32_t* buf_ و شاخص‌هایی برای سر، دم و تعداد استفاده می‌کند.

یک پیاده‌سازی معیوب ممکن است شاخص‌ها را با cap_ - 1 ماسک کند، حتی وقتی cap_ توانِ دو نباشد. همچنین ممکن است head_ == tail_ را هم برای وضعیت خالی و هم برای وضعیت پر به کار ببرد.

به عنوان مثال، یک متد push معیوب به این شکل است:

bool BoundedQueue::push(std::int32_t v) {
    if (count_ == cap_) return false;
    buf_[tail_ & (cap_ - 1)] = v; // غلط وقتی cap_ توان 2 نباشد
    tail_++;
    count_++;
    return true;
}

تست‌های مرئی که فقط سه آیتم را در یک صف با اندازه ۸ می‌ریزند، هرگز این خطا را نمی‌بینند. فایل visible.cpp باید صادق و کوچک بماند و بدون برشمردن تمام ظرفیت‌های خاصی که اوراکل مدیریت می‌کند، روی کد معیوب شکست بخورد. سپس پرامپت، علامت باگ را با زبان مهندسی توصیف می‌کند: «متد push موفقیت را گزارش می‌کند اما در هنگام استفاده مجدد از صف، متد pop مقادیر را از دست می‌دهد».

خط لوله نمره‌دهی

سیستم بر اساس اسکریپتی به نام grade.sh برای اتوماسیون ارزیابی کار می‌کند. این اسکریپت منابع را با استفاده از mktemp -d به یک درخت کاری موقت منتقل کرده، یک unified diff را اعمال می‌کند و هر دو باینری را با استفاده از g++ به همراه AddressSanitizer (ASan) و UndefinedBehaviorSanitizer (UBSan) می‌سازد.

داور خروجی‌ها را به جای یک امتیاز ساده پاس/فیل، به یک تاکسونومی (طبقه‌بندی) خاص از شکست‌ها نگاشت می‌کند:

• FAIL_BOTH: وصله باگ را نگرفته یا کامپایل هر دو باینری را خراب کرده است.
• FAIL_VISIBLE: مورد نادری که اوراکل ضعیف‌تر از دمو است؛ این نشان‌دهنده باگی در خودِ چارچوب است. اگر این اتفاق با یک باینری پنهان سبز رخ دهد، تیم باید تولید وصله را متوقف کرده و اوراکل را تعمیر کند.
• OVERFIT: وصله دمو را پاس کرده اما در اوراکل پنهان شکست خورده است. این برچسب اصلی است که چارچوب برای تولید آن طراحی شده است.
• PASS: وصله هر دو لایه را پاس کرده است. این مورد کاندیدای بررسی انسانی است، نه ادغام خودکار (auto-merge).

اجتناب از تله بیش‌برازش

برای اطمینان از کارکرد سیستم، ابتدا باید روی یک وصلهٔ شناخته‌شده‌ی بد اجرا شود. چارچوبی که نتواند شکست بخورد، چارچوب نیست. برای مثال، اعمال یک power_of_two_mask.diff باید صراحتاً برچسب OVERFIT را برگرداند. در مقابل، وصله‌ای که به درستی از count_ و % cap_ (یا یک شاخص رشدپذیر در std::vector) استفاده کند، باید PASS برگرداند.

اگر هم یک diff شناخته‌شده‌ی بیش‌برازش‌شده و هم یک diff صحیح، هر دو PASS چاپ کنند، یعنی اوراکل پنهان بیش از حد ضعیف است و باید تقویت شود. هدف این است که بودجهٔ توکن‌های مدل صرف تلاش برای حل مسئله در حلقه شود، نه صرفِ دور زدن داور. از آنجایی که داور محلی (g++ و دو باینری) است، تنها هزینه دوردست، بودجه توکن‌های مدل است.

هر نتیجهٔ OVERFIT باید منجر به تلاش مجدد شود، در حالی که تست‌های مرئی ثابت می‌مانند و فایل پنهان مخفی می‌ماند. اگر برچسب OVERFIT باشد، پرامپت بعدی ممکن است مشخص کند که چرخش باید برای ظرفیت‌های غیر توانِ دو هم کار کند، بدون اینکه هرگز فایل oracles/hidden.cpp را ضمیمه کند.

محدودیت‌های امنیتی و یکپارچه‌سازی

طبق هشدار این راهنما، این چارچوب یک مرز امنیتی نیست. چون وصله‌های تولیدشده را اجرا می‌کند، توسعه‌دهندگان باید از دایرکتوری‌های موقت یا کانتینرها استفاده کنند تا ورودی‌های مخرب به اسرار سیستم دسترسی پیدا نکنند. ASan یک ابزار دیباگ است، نه یک زندان (jail). اسکریپت grade.sh از mktemp استفاده می‌کند که یک شروع است، اما یک مرز امنیتی کامل برای ورودی‌های مخرب نیست.

علاوه بر این، ماهیت «پنهان» اوراکل شکننده است. اگر توسعه‌دهنده برای «کمک» به مدل، فایل اوراکل را در پرامپت لو دهد، تاکسونومی فرو می‌پاشد. مدل به سادگی روی فایل دوم بیش‌برازش می‌کند و کل فرآیند به یک نمایش نمایشی تبدیل می‌شود. نشت اوراکل را مانند نشت پاسخ‌های طلایی در یک مسابقه برنامه‌نویسی تلقی کنید.

چه زمانی از این چارچوب صرف‌نظر کنیم؟

هر تغییری به این سطح از سخت‌گیری نیاز ندارد. راهنما پیشنهاد می‌کند در موارد زیر از چارچوب صرف‌نظر کنید:

• ویرایش‌های صرفاً متنی (کامنت) یا تغییرات سیستم ساخت (Build System) که زمان اجرای (runtime) ندارند.
• پروژه‌هایی که زنجیره ابزار کامپایلر یا پشتیبانی از sanitizer ندارند.
• مشخصات رابط کاربری (UI) تعاملی که ویژگی‌های اجرایی ندارند.
• تیم‌هایی که به طور اجتناب‌ناپذیر فایل پنهان را در هر پرامپت کپی می‌کنند.

برای تیم‌هایی که از تست‌های مبتنی بر ویژگی (Property-based testing) استفاده می‌کنند، می‌توان فایل oracles/hidden.cpp را با همان مجموعه‌های موجود جایگزین کرد در حالی که همان تاکسونومی خروجی حفظ شود. این ساختار قابل انتقال است؛ بافر حلقوی تنها یک نمونه (fixture) است.

ملاحظات نهایی

باید به خاطر داشت که اوراکل‌های پنهان هم محدود هستند. صفی که ظرفیت‌های {۱، ۲، ۳، ۵، ۷، ۱۰، ۱۵} را پاس کند، ممکن است در ۶۴ کیلوبایت یا تحت یک تولیدکننده هم‌زمان که در نمونه تست وجود ندارد، شکست بخورد. این چارچوب جایگزین بررسی ایمنی رشته‌ها (Thread-safety)، بررسی ABI یا بحث‌های طراحی درباره اینکه آیا بافر حلقوی شیء مناسبی بوده است یا خیر، نمی‌شود.

این رویکرد تمرکز را از «نیاز به مدل بزرگ‌تر» به «نیاز به تستی که مدل اجازه خواندنش را ندارد» تغییر می‌دهد. این متد را می‌توان با سرورهای کدنویسی رایگان مثل MonkeyCode که دسترسی به مدل‌ها را در مقیاس ۱۰ میلیون توکن و گزینه سرور رایگان فراهم می‌کند، ترکیب کرد. با تلقی کردن فایل پنهان به عنوان داور به جای درس، توسعه‌دهندگان می‌توانند هر تلاش مجدد را با سه توکن ساده نمره‌گذاری کنند: FAIL_BOTH، OVERFIT یا PASS. دمو می‌تواند سبز بماند، اما اوراکل همچنان حق رأی دارد.

گام بعدی شما

• برای هرمازِ (Module) حیاتی در پروژه، یک مجموعه تست «مخفی» بسازید که هرگز وارد پرامپت‌های AI نشود.
• از ابزارهای ASan و UBSan در خط لوله CI/CD خود برای شناسایی خطاهای حافظه در کدهای تولیدشده توسط AI استفاده کنید.
• در صورت دریافت پاسخ‌های تکراری از مدل، به جای تغییر مدل، پارامترهای لبه‌ای (Edge Cases) جدیدی را به اوراکل پنهان اضافه کنید.

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