ناپایداری مدل‌های داور باعث خطای ۱۷ درصدی در تصمیمات ادغام کد شد

اگر امروز برای تایید کیفیت کدها به امتیاز یک مدل زبانی تکیه می‌کنید، احتمالاً با یک «تولیدکننده عدد تصادفی» طرف هستید، نه یک داور دقیق. یک بررسی فنی عمیق در چارچوب maf-evals — که بر پایه Microsoft Agent Framework و .NET 8 ساخته شده — فاش کرد که بسیاری از خط‌لوله‌های ارزیابی، میانگین‌های فریبنده را با معیارهای قابل‌اعتماد اشتباه می‌گیرند.

بسیاری از تیم‌های مهندسی، مدل زبانی به‌مثابه داور (LLM-as-a-judge) — شبیه به داوری که قوانین را می‌داند اما هر بار با یک حس متفاوت سوت می‌زند — را با تعیین یک حد آستانه (مثلاً رد هر پاسخی با امتیاز زیر ۷) پیاده می‌کنند و آن را به عنوان یک گیت کیفیت (Quality Gate) عرضه می‌کنند. طبق گزارش توسعه‌دهندگان این چارچوب، این رویکرد شکست می‌خورد چون «واریانس» (Variance) یا همان میزان پراکندگی داخلی داور را نادیده می‌گیرد. این مسئله در واقع تکرار همان چالشی است که در تحلیل ما درباره تمایل داوران هوش مصنوعی به دروغ گفتن با اطمینان بالا بررسی کردیم، جایی که معیارهای کیفیت توسط مدل‌های متقاعدکننده اما غیردقیق فریب داده می‌شدند. وقتی یک ورودی یکسان چندین بار داوری می‌شود، امتیازها نوسان می‌کنند؛ یعنی یک درخواست ادغام (Pull Request) ممکن است در یک اجرا سبز و در اجرای بعدی بدون هیچ تغییری قرمز شود. دلیل این اتفاق چیزی جز تصادفی بودن (Stochasticity) مدل نیست. داور لزوماً اشتباه نمی‌کند، بلکه ناپایدار است و این پایداری هرگز پیش از اعتماد به اعداد، اندازه‌گیری نشده بود.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های بازمتن اشاره کردیم، اعتماد به خروجی‌های تک‌مرحله‌ای بدون سنجش توزیع احتمالی، ریسک عملیاتی را بالا می‌برد. برای حل این مشکل، maf-evals یک سلسله‌مراتب سخت‌گیرانه برای کالیبراسیون (Calibration) معرفی می‌کند: ثبات درونی مدل باید پیش از هرگونه توافق با انسان تایید شود. اگر داوری نتواند با خودش موافقت کند — مثلاً برای یک ورودی یکبار ۵، بار دیگر ۲ و سپس ۴، دوباره ۵ و باز ۲ بدهد — مقایسه امتیاز او با برچسب انسانی، در واقع مقایسه یک نتیجه با پرتاب سکه است. شما نمی‌توانید خط‌کشی را کالیبره کنید که هر بار آن را برمی‌دارید، طولش تغییر می‌کند.

تله‌ی انحراف معیار میانگین

در یک اجرای واقعی از دستور کالیبراسیون در maf-evals (با دستور dotnet run --project src/EvalRunner -- calibrate --repeat 3)، داده‌ها نقص بحرانی در نحوه ردیابی پایداری را آشکار کردند. در این فرآیند، ۱۲ مورد برچسب‌گذاری‌شده توسط انسان، هر کدام ۳ بار داوری شدند تا ثبات مدل سنجیده شود و اولویت با بررسی ثبات درونی بود.

برای امتیاز «بازیابی» (Retrieval) — یعنی توانایی مدل در پیدا کردن درست اطلاعات، شبیه به جست‌وجوی یک سند خاص در بایگانی عظیم یک اداره — انحراف معیار میانگین عدد خیره‌کننده ۰.۲۰ بود. اما این میانگین، یک شکست سیستماتیک را پنهان می‌کرد. در حالی که اکثر موارد پایدار بودند، دو مورد خاص نوسانی شدید داشتند و امتیازات را تا سه واحد جابه‌جا می‌کردند. در یک نمونه، مدل برای ۵ بار ورودی یکسان، امتیازات ۵، ۲، ۴، ۵ و ۲ را ثبت کرد.

بر اساس مستندات این پروژه، این ناپایداری منجر به نرخ ۱۷ درصدی «تغییر حکم» (Verdict-flip) شد. این یعنی تقریباً از هر ۵ تصمیم ادغام در نزدیکی حد آستانه، یکی بر اساس شانس و نه کیفیت تصمیم گرفته شده است — یعنی بسته به اینکه داور در آن لحظه کدام نمونه را استخراج کرده باشد. در یک محیط CI، این وضعیت گیت کیفیت را به یک رابط کاربری زیبا تبدیل می‌کند که در پس‌زمینه، اعداد تصادفی تولید می‌کند.

گیت‌ها برای قوانین، گزارش‌ها برای داوران

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

سیستم شواهد را به دو دسته تقسیم می‌کند:

• بررسی‌های قطعی (Deterministic): شامل تطابق دقیق شناسه‌ی تکه‌ها (Chunk-ID) — یعنی مقایسه شناسه‌های بازگردانده شده با expectedChunkIds — یا مقایسه فراخوانی ابزارها. چون این‌ها غیرقابل جعل هستند و هرگز تغییر نمی‌کنند، گیت‌های اصلی هستند.
• داوران مدل زبانی: نظراتی ارائه می‌دهند که بین اجراها تغییر می‌کند. در نتیجه، جایگاه آن‌ها از «گیت» به «گزارش‌های مشورتی» تنزل می‌یابد.

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

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

تنها پس از آنکه داور آزمون ثبات درونی را پاس کرد (رسیدن به انحراف معیار ۰.۰۰، مشابه آنچه در معیارهای Groundedness و Relevance دیده شد)، با برچسب‌های انسانی مقایسه می‌شود. حتی در این مرحله، چارچوب هشدار می‌دهد که نباید به «اریبی» (Bias) به‌عنوان معیار سلامت تکیه کرد.

داده‌های کالیبراسیون برای توافق انسانی را بررسی کنید:

• بازیابی: ۷۵٪ تطابق دقیق، ۹۲٪ در محدوده ۱ واحد، MAE برابر ۰.۴۲، اریبی ۰.۴۲-، همبستگی ۰.۸۸، ۸۳٪ در باند یکسان.
• مبنی‌سازی (Groundedness): ۴۲٪ تطابق دقیق، ۶۷٪ در محدوده ۱ واحد، MAE برابر ۱.۱۷، اریبی ۰.۱۷-، همبستگی ۰.۴۴، ۷۵٪ در باند یکسان.
• ارتباط (Relevance): ۲۵٪ تطابق دقیق، ۸۳٪ در محدوده ۱ واحد، MAE برابر ۰.۹۲، اریبی ۰.۴۲-، همبستگی ۰.۷۴، ۸۳٪ در باند یکسان.

در مورد امتیازات مبنی‌سازی — یعنی اینکه پاسخ مدل چقدر بر اساس مستندات است و چقدر از خودش ساخته — اریبی تقریباً صفر بود (۰.۱۷-). در حالت عادی، این عدد نشان‌دهنده یک مدل کالیبره شده است. اما در واقعیت، داور در دو جهت مخالف خراب بود: مدل تمام توهمات (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — را دقیقاً با امتیاز ۳.۰ می‌سنجید، اما هم‌زمان پاسخ‌های درست را به دلیل کمی خارج از موضوع بودن، جریمه می‌کرد. این خطاها در مجموع یکدیگر را خنثی کرده و اریبی را سالم نشان می‌دادند.

تیم با تمرکز بر میانگین مطلق خطا (MAE) ۱.۱۷ و توافق باند ۷۵٪ به‌جای اریبی، متوجه شد که توهمات در نقطه ۳.۰ خوشه‌بندی شده‌اند. این بینش داده‌محور باعث شد کفِ مسدودکننده از ۳.۰ به ۳.۵ تغییر کند. در کف قدیمی، هر توهمی به‌عنوان یک هشدار ساده رد می‌شد؛ اما با بالا بردن کف، توهمات مسدود شدند و توافق در محدوده از ۵۰٪ به ۷۵٪ رسید.

پیاده‌سازی محدوده امتیاز (Score Band)

برای جذب نوسانات ذاتی داوران، maf-evals به‌جای یک آستانه، از دو آستانه استفاده می‌کند: یک «کف» (Floor) برای مسدود کردن و یک «هدف» (Target) برای هشدار. فضای بین این دو، نوسانات را جذب می‌کند.

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

public GateOutcome ApplyScore(JudgeScore score, ScoreBand band) {
    if (score.Value < band.Floor) return GateOutcome.Block($"{score.Name} {score.Value:F1} < floor {band.Floor:F1}");
    if (score.Value < band.Target) return GateOutcome.Warn($"{score.Name} {score.Value:F1} < target {band.Target:F1}");
    return GateOutcome.Pass();
}

برای مبنی‌سازی، محدوده کالیبره شده روی new ScoreBand(Floor: 3.5, Target: 4.0) تنظیم شد. این تضمین می‌کند توهماتی که در نقطه ۳.۰ متمرکز بودند، زیر کف قرار گرفته و باعث BLOCK شوند.

حفظ کالیبراسیون

کالیبراسیون یک اتفاق یک‌باره نیست. این چارچوب الزام می‌کند که در موارد زیر، مجموعه کالیبراسیون دوباره اجرا شود:

۱. تعویض مدل داور (مثلاً انتقال از GPT-4o به نسخه‌ای جدید).
۲. به‌روزرسانی راهنمای برچسب‌گذاری.
۳. تغییر در حد آستانه.

این ضرورت به این دلیل است که امتیازات مدل‌های مختلف قابل مقایسه نیستند؛ عدد «۳» در GPT-4o با عدد «۳» در مدل آینده، دو مقدار متفاوت با یک برچسب یکسان هستند. تعویض داور بدون تغییر آستانه‌ها، عملاً کالیبراسیون را دور می‌اندازد و تیم را به حالت «انتخاب اعداد بر اساس حس» برمی‌گرداند.

علاوه بر این، مجموعه کالیبراسیون با ۱۲ مورد مهندسی‌شده طراحی شده تا سه امتیاز بازیابی، مبنی‌سازی و ارتباط را از هم تفکیک کند. این کار مانع از آن می‌شود که داور با ادغام همه این‌ها در یک حس کلی از «کیفیت»، نمره بالایی بگیرد بدون اینکه واقعاً دقیق باشد. اگر موارد تست نتوانند حالت‌های شکست را ایزوله کنند، کالیبراسیون هیچ چیزی را اثبات نمی‌کند. این تفکیک دقیق از اهمیت بالایی برخوردار است، زیرا همان‌طور که پیش‌تر اشاره کردیم، ادغام اعتبارسنجی و اصلاح کد در AI می‌تواند مسیر بازرسی فنی را به‌طور کامل نابود کند.

این تغییر در رویکرد، ارزیابی هوش مصنوعی را از «حدس زدن اعداد» به یک فرآیند مهندسی منضبط تبدیل می‌کند. با نگاه به داور مدل زبانی به‌عنوان ابزاری که نیاز به چک کردن مداوم با مرجع دارد، تیم‌ها می‌توانند از تکیه بر تولیدکننده‌های عدد تصادفی دست بردارند. پیاده‌سازی کامل سه لایه — شامل گاردریل‌ها، گیت‌های PR، داوری مسیر (Trajectory Judging) و مجموعه ایمنی متخاصم (Adversarial Safety Suite) — در آدرس github.com/sauravbhattacharya001/maf-evals در دسترس است.

گام بعدی شما

• اگر از LLM-as-a-judge استفاده می‌کنید، هر ورودی را ۳ بار تکرار کنید تا نرخ تغییر حکم (Verdict-flip) را بسنجید.
• گیت‌های مسدودکننده (Blocking) را فقط برای بررسی‌های قطعی (Deterministic) نگه دارید و داوران را به نقش مشورتی منتقل کنید.
• برای هر مدل داور جدید، یک مجموعه کالیبراسیون مجزا با تمرکز بر MAE به‌جای Bias ایجاد کنید.

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