اگر امروز بر اساس داشبوردهای سبز رنگ به کیفیت مدل خود اعتماد می‌کنید، احتمالاً در تلهٔ «پس‌روی‌های خاموش» افتاده‌اید. بسیاری از مدل‌ها به‌جای حل مسئله، یاد گرفته‌اند پاسخ‌های مرجع را تقلید کنند تا نمرات بالایی بگیرند. در حالی که یک داور می‌تواند رشته طلایی را بخواند، اما در این حالت دیگر در حال ارزیابی رفتار مدل نیست؛ بلکه هم‌پوشانی برچسب‌ها به ارزان‌ترین راه برای پاس شدن تبدیل می‌شود.
برای متوقف کردن این دسته خاص از شکست‌ها — جایی که مدل داور به‌جای عملکرد واقعی در تسک، به هم‌پوشانی برچسب‌ها پاداش می‌دهد — شرکت MonkeyCode در ۸ اکتبر ۲۰۲۶ یک پیشنهاد فنی منتشر کرد که جزئیات یک «هارنس ارزیابی کور» (Blinded Evaluation Harness) را شرح می‌دهد. این سازوکار مانع از آن می‌شود که مدل‌های هوش مصنوعی صرفاً با تکرار کلید پاسخ، آزمون‌ها را پاس کنند.
بسیاری از ارزیابی‌های پرامپت در تله‌ای می‌افتند که در آن پرامپتِ داور، «رشته طلایی» مورد انتظار را در کنار خروجی کاندید قرار می‌دهد. وقتی داور پاسخ را می‌بیند، اغلب به کاندید پاداش می‌دهد چون متن را با پاسخ مرجع مطابقت داده است، حتی اگر مدل دیگر از دستورالعمل‌های اصلی (Rubric) پیروی نکرده باشد. این وضعیت یک داشبورد «سبز» ایجاد می‌کند که افت کیفیت واقعی را پنهان می‌کند و این افت‌ها تنها بعداً در قالب شکایت‌های کاربران آشکار می‌شوند. پس‌روی‌های خاموش در دل یک نمره پایدار پنهان می‌مانند، زیرا داور به‌جای ارضای دستورالعمل، به پژواک‌های برچسب پاداش می‌دهد.
تصور کنید در یک امتحان کتاب‌باز، مراقب پاسخ‌ها را در گوش دانش‌آموز زمزمه کند؛ دانش‌آموز با تکرار آن زمزمه نمره کامل می‌گیرد، اما این نمره توانایی او را نمی‌سنجد، بلکه دسترسی‌اش به پاسخ را اندازه می‌گیرد. در ارزیابی‌های هوش مصنوعی، این اتفاق به عنوان «هم‌پوشانی برچسب» (Label Overlap) شناخته می‌شود و باعث می‌شود ارزان‌ترین راه برای پاس شدن، کپی لغوی باشد نه رفتار صحیح.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی نشت داده‌ها در مجموعه‌های آموزشی اشاره کردیم، تکرار الگوها به‌جای استدلال، بزرگ‌ترین تهدید برای اعتبار بنچمارک‌هاست. این موضوع باعث می‌شود افت کیفیت مدل در داشبوردها پنهان بماند و تنها زمانی آشکار شود که کاربران نهایی از خروجی‌ها شکایت کنند.
معماری دو مسیره
برای حل این مشکل، سیستم MonkeyCode هر مورد آزمون را به دو مسیر مجزا تقسیم می‌کند. این دو مسیر به پرسش‌های متفاوتی پاسخ می‌دهند و هر مجموعه‌ای که این دو را در یک مقدار بولی (Boolean) واحد ادغام کند، باعث می‌شود مشخص نشود که دقیقاً کدام پرسش با شکست مواجه شده است:
- مسیر دقیق (Exact Lane): این مسیر دسترسی کامل به رشته طلایی دارد. تنها هدف آن انجام یک مقایسه کانونی (Canonical Comparison) پس از نرمال‌سازی است تا ببیند آیا خروجی دقیقاً با متن مورد انتظار مطابقت دارد یا خیر.
- مسیر کور (Blinded Lane): این مسیر تسک، نام متغیر (Invariant)، دستورالعمل (Rubric) و خروجی کاندید را می‌بیند، اما دسترسی به رشته طلایی برای آن اکیداً ممنوع است.
برای اطمینان از اینکه رشته طلایی از طریق بازنویسی کد (Refactor) دوباره وارد سیستم نشود، یک «محافظ نشت» (Leak Guard) تعبیه شده است. این محافظ اگر متن نرمال‌شدهٔ پاسخ مرجع در هر جای پرامپت داور ظاهر شود، کل پرامپت را رد می‌کند. این کار مانع از آن می‌شود که یک بازنویسی کد، برچسب را به‌طور پنهانی به دید داور بازگرداند.
مدیریت اختلافات
در این رویکرد، به‌جای میانگین‌گیری از این دو مسیر برای رسیدن به یک درصد واحد، «اختلاف» (Disagreement) به عنوان سیگنال اصلی در نظر گرفته می‌شود. اختلاف نباید در قالب یک درصد دوستانه میانگین‌گیری و حذف شود:
- پذیرش در مسیر دقیق / شکست در مسیر کور: اگر تطابق دقیق پاس شود اما داور کور شکست بخورد، خروجی ممکن است یک کپی لغوی باشد که دستورالعمل را نقض کرده است. برای مثال، اگر کاندیدی قبلاً یک پاسخ رد ساختاریافته (Structured Refusal) برمی‌گرداند، اما پس از ویرایش پرامپت، جمله طلایی را برگرداند ولی شرط «رد کردن» را حذف کند، تطابق دقیق سبز می‌ماند در حالی که دستورالعمل کور شکست می‌خورد.
- شکست در مسیر دقیق / پذیرش در مسیر کور: اگر تطابق دقیق شکست بخورد اما داور کور پاس شود، احتمالاً رشته طلایی بیش از حد محدود است یا داور به‌جای بررسی متغیر، روی لحن (Tone) امتیاز داده است.
در هر دو حالت، هارنس از انتشار نمره نهایی مجموعه خودداری می‌کند. این اجبار باعث می‌شود توسعه‌دهنده متوقف شود، ردیف مربوطه را بررسی کند و پیش از انتشار نمره کلی، مورد آزمون یا کاندید را اصلاح کند. این روش شکست‌هایی را شکار می‌کند که در غیر این صورت ساکت می‌ماندند، زیرا اگر فقط بیت نهایی پاس شدن ذخیره شود، داشبورد می‌تواند سالم به نظر برسد.
تضمین پوشش و پیاده‌سازی
این سیستم همچنین از «سبزهای کاذب» جلوگیری می‌کند و حضور متغیرهای خاصی مانند فرمت (Format)، رد درخواست (Refusal) و آرگومان‌های ابزار (Tool Arguments) را الزامی می‌کند. هارنس زمانی که یک متغیر الزامی هیچ مورد آزمونی نداشته باشد، از انتشار نمره مجموعه خودداری می‌کند؛ زیرا آزمونی که غایب است، آزمونی پاس‌شده نیست.
پوشش در اینجا به عنوان «حالت‌های شکست اعلام‌شده» تعریف می‌شود، نه صرفاً تعداد کل پرامپت‌ها. اجرای آزمونی که فقط فرمت را پوشش می‌دهد، می‌تواند نرخ تطابق دقیق بالایی گزارش کند، در حالی که رفتار «رد درخواست» بدون حتی یک ردیف قرمز، دچار پس‌روی شده باشد. نگه داشتن نمره تا زمان حضور هر متغیر الزامی، نویسنده را مجبور می‌کند پیش از جشن گرفتن نمره کلی، موارد آزمون را اضافه کند.
بر اساس پیشنهاد MonkeyCode، گردش کار باید از ترتیب سخت‌گیرانه‌ای پیروی کند:
۱. نوشتن متغیر (Invariant) در فایل مورد آزمون پیش از رشته طلایی، تا دستورالعمل مستقل از کلید پاسخ وجود داشته باشد.
۲. تولید خروجی کاندید از طریق تابع فراخوانی (Callable) و ذخیره هش خروجی.
۳. ساخت پرامپت کور بر اساس تسک، دستورالعمل و خروجی.
۴. اجرای محافظ نشت، فراخوانی داور و ثبت هر دو مقدار بولی بدون میانگین‌گیری در حلقه موارد.
تنها پس از حضور تمام متغیرهای الزامی است که تابع مجموعه می‌تواند اختلاف را با آستانه سیاست (Policy Threshold) مقایسه کند تا تصمیم بگیرد آیا نمره می‌تواند منتشر شود یا خیر.
محدودیت‌های پیاده‌سازی
این رویکرد تفکیکی جهانی نیست. این روش برای نوشتارهای باز (Open-ended)، نقدهای طراحی یا خلاصه‌سازی‌هایی که رشته کانونی واحدی ندارند، مناسب نیست. در این موارد، اجبار به مسیر تطابق دقیق باعث ایجاد شکست‌های کاذب می‌شود، زیرا مسیر دقیق به دلایلی شکست می‌خورد که لزوماً پس‌روی (Regression) نیستند.
برای حفظ یکپارچگی، این پیشنهاد توصیه می‌کند که پرامپت داور ثابت (Pin) شده و هش آن ثبت شود. توسعه‌دهندگان هرگز نباید مدل داور را در همان تغییری که مدل کاندید را عوض می‌کنند، تغییر دهند، زیرا این کار نتایج را مسموم می‌کند. همچنین لازم نیست داور و کاندید از یک ارائه‌دهنده (Vendor) باشند.
برای تیم‌هایی که دستورالعمل مکتوب (Rubric) ندارند، این سیستم بی‌اثر است، زیرا یک داور کور بدون قوانین، صرفاً در میانه اجرا استانداردهای خود را اختراع می‌کند. علاوه بر این، نویسنده اشاره می‌کند که این اسکریپت جایگزینی برای ردپاهای بازرسی انسانی (Human Audit Trails) در زمینه‌های حساس مانند هوش مصنوعی پزشکی، حقوقی یا مالی نیست. اگر هدف صرفاً تأیید برابری با یک پاسخ پنهان است، مسیر دقیق کافی است و نیازی به مدل زبانی کور نیست.
زیرساخت و دسترسی
برای کاهش موانع ورود، MonkeyCode دسترسی رایگان به مدل‌ها را برای اشغال تابع فراخوانی کاندید فراهم کرده است. این کار نیاز به ذخیره کلیدهای API پولی در پیکربندی هارنس را از بین می‌برد. علاوه بر این، سرور رایگان آن‌ها می‌تواند این اسکریپت‌ها را در یک زمان‌بندی (Schedule) میزبانی کند تا ساعت ارزیابی به لپ‌تاپ محلی توسعه‌دهنده وابسته نباشد.
این ادعاهای دسترسی، حقایقی هستند که توسط اپراتور ارائه شده‌اند و بنچمارک‌های اندازه‌گیری شده یا وعده‌های ظرفیت دائمی نیستند. هیچ‌کدام از این گزینه‌ها جایگزینی برای پرامپت داور ثابت، فایل مورد آزمون منجمد یا قانون اختلاف نیستند.
با تبدیل اختلاف بین دو مسیر به نتیجه‌ای که بیشترین اهمیت را دارد، توسعه‌دهندگان می‌توانند پس‌روی‌های خاموشی را شکار کنند که در حالت عادی با یک تیک سبز ساده پوشانده می‌شدند. عادت عملی ساده است: پرامپت داور را در تابعی بسازید که نمی‌تواند فیلد رشته طلایی را ببیند، سپس اجازه دهید اختلاف، مانع از انتشار نمره مجموعه شود.
گام بعدی شما
- پرامپت‌های داور خود را بررسی کنید و رشته‌های طلایی را از دید داور کور کنید.
- برای هر قابلیت حیاتی مدل، حداقل یک مورد آزمون (Invariant) تعریف کنید تا از پوشش کامل مطمئن شوید.
- به‌جای تکیه بر درصد کلی پاس شدن، روی موارد «اختلاف» بین تطابق دقیق و داوری معنایی تمرکز کنید.
اما چالش‌های استقرار این مدل‌ها در محیط‌های عملیاتی حتی پیچیده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی هزینه استنتاج مراجعه کنید.
گفتگو