گزارش فنی: مدل ردکننده هزینه‌های استنتاج ارزیابی را ثابت نگه داشت

اگر امروز برای نظارت بر کیفیت خروجی‌های مدل‌هایتان از یک مدل زبانی استفاده می‌کنید، احتمالاً با نرخ «قبولی» بسیار بالایی روبه‌رو هستید که بسیاری از خطاهای ریز را نادیده می‌گیرد. این تساهل ساختاری در ارزیابی، یک نقطه کور خطرناک است؛ چراکه وقتی یک خانواده از مدل‌ها خروجی‌هایی تولید می‌کنند که «پذیرفتنی» به نظر می‌رسند، همان خانواده تمایل دارند چنین خروجی‌هایی را در مرحله ارزیابی نیز پذیرفتنی بدانند. این به معنای آن است که گیت‌های کیفی تک-مدلی اغلب با «نمره‌دهی نسبی» شکست می‌خورند و به‌طور مداوم وضعیت را روی «پاس» قرار می‌دهند، مگر اینکه خطا بسیار فاحش باشد.

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

مکانیسم شکست

مدل‌های زبانی بزرگ (LLM) اساساً برای تولید توجیهاتی طراحی شده‌اند که پذیرفتنی به نظر برسند. وقتی از یک مدل پرسیده می‌شود «آیا این مورد معیارهای پذیرش (Rubric) را دارد؟»، مدل اغلب مسیری را برای رسیدن به یک «بله» سخاوتمندانه پیدا می‌کند، زیرا این مسیر کوتاه‌ترین مقاومت را دارد. تولید یک توجیه پذیرفتنی دقیقاً همان کاری است که مدل‌های زبانی در آن مهارت دارند، فارغ از اینکه آن توجیه در واقعیت درست باشد یا خیر.

استفاده از یک مدل قوی‌تر و گران‌تر به عنوان تنها داور، بهبود اندکی ایجاد می‌کند اما مکانیسم زیربنایی «خود-توافق» (self-agreement) را حل نمی‌کند. در این حالت، هزینه استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند و شبیه خودِ آشپزی است، نه دوره‌ی آموزش — به‌صورت خطی برای هر بررسی افزایش می‌یابد، بدون توجه به اینکه خروجی به‌طور بدیهی درست بوده یا پیچیده است. این چالش در مدیریت هزینه‌ها مشابه موضوعاتی است که در راهکارهای کاهش هزینه‌های پردازش متون طولانی بررسی کرده‌ایم. مسئله تنها قدرت مدل نیست، بلکه نبود فشار ساختاری برای استدلال علیه حکم اولیه است.

راهکار سه-نقشی

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

• داور (Judge): یک مدل ارزان‌قیمت که خروجی را بر اساس یک معیار (Rubric) صریح و سخت‌گیرانه امتیازدهی می‌کند. این یک مرحله نمره‌دهی عادی است.
• ردکننده (Refuter): مدل ارزان‌قیمت دومی که حکم داور و دلایل او را می‌بیند. به این مدل صراحتاً گفته می‌شود که تنها وظیفه‌اش یافتن دلایلی برای ابطال آن حکم خاص است، نه ارائه یک بررسی کلی از خروجی.
• داور نهایی (Tie-breaker): یک مدل استدلالی (Reasoning Model) — مدلی که قبل از جواب درنگ می‌کند، شبیه شطرنج‌بازی که چند حرکت جلوتر را می‌بیند — که فقط در صورت اختلاف نظر داور و ردکننده فراخوانده می‌شود. این مدل هر دو حکم، هر دو مجموعه دلیل و معیار اصلی را می‌بیند تا تصمیم نهایی را بگیرد.

جزئیات پیاده‌سازی

برای اینکه این الگو به‌طور مؤثر عمل کند، نقش‌ها باید از نظر فنی و از نظر پرامپت کاملاً تفکیک شوند:

• پرامپت‌نویسی سیستمی (System Prompting): به داور باید گفته شود: «تو یک نمره‌دهنده سخت‌گیر هستی. هیچ تخفیفی داده نشود.» در مقابل، ردکننده باید این دستور را دریافت کند: «تو یک بررسی‌کننده واقعیت متخاصم هستی. تنها انگیزه تو یافتن خطاهایی است که نمره‌دهنده اول نادیده گرفته است.»
• محدودیت ردکننده: برای جلوگیری از تبدیل شدن ردکننده به یک «ماشین مخالف‌خوان» که صرفاً برای مخالفت، مخالفت می‌کند، پرامپت باید شامل یک «دریچه خروج» صریح باشد: «اگر واقعاً نمی‌توانی دلیلی برای ابطال حکم پیدا کنی، صراحتاً این را اعلام کن. برای مخالفت کردن، اعتراضات ساختگی تولید نکن.» ارزیابی شما باید تایید کند که مدل در مواردی که حکم اول محکم است، تسلیم شود.
• انتخاب مدل: استفاده از چک‌پوینت‌های مختلف مدل یا ارائه‌دهندگان متنوع (مثلاً مدل ارزان A و مدل ارزان B) برای داور و ردکننده، پاک‌ترین راهکار است. اگر از وزن‌های یکسان استفاده شود، ممکن است مدل‌ها نقاط کور مشترکی داشته باشند و ریسک قضاوت‌های اشتباه یکسان دوباره بازگردد. این رویکرد برای جلوگیری از سوگیری‌های سیستماتیک مشابه تکنیک‌های کاهش سوگیری در مدل‌های زبانی است که پیش‌تر بررسی کردیم. اگر تغییر ارائه‌دهنده عملی نیست، توسعه‌دهندگان باید حداقل پرامپت سیستمی و دمای نمونه‌برداری (Sampling Temperature) را تغییر دهند.
• مسیریابی قطعی (Deterministic Routing): ماشه ارتقای درخواست به داور نهایی باید یک کد قطعی ساده باشد (مانند if first.verdict == second.verdict) و نه یک فراخوانی مدل دیگر. ساده و قابل حسابرسی نگه داشتن جریان کنترل به این معناست که می‌توانید هزینه‌ها را با قطعیت لاگ کرده، تست کنید و تحلیل نمایید.

ساختار کد و منطق

در یک پیاده‌سازی مینیمال، این الگو از dataclassهای استاندارد پایتون برای قضاوت‌ها و enumها برای احکام (PASS/FAIL) استفاده می‌کند. تابع judge() مدل را برای صدور حکم و ارائه حداکثر سه دلیل عینی مرتبط با معیار (Rubric) تحریک می‌کند. سپس تابع refute() شیء Judgment را گرفته و به مدل دوم می‌گوید که قوی‌ترین شواهد متقابل در معیار را پیدا کند.

تابع quality_gate() جریان را مدیریت می‌کند. ابتدا داور و سپس ردکننده فراخوانده می‌شوند. اگر احکام یکسان باشند، تابع بلافاصله نتیجه را برمی‌گرداند؛ این همان «مسیر ارزان» است. تنها زمانی که احکام متفاوت باشند، tiebreaker_model فعال شده و استدلال‌های هر دو ارزیاب را دریافت می‌کند. این کار باعث می‌شود جریان کنترل به یک مقایسه ساده بین دو مقدار تبدیل شود، نه یک قضاوت احتمالی که بپرسد «آیا باید ارتقاء دهیم یا خیر؟»

مسیریابی آبشاری هزینه

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

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

یک مثال عینی در پشتیبانی مشتری

برای روشن شدن موضوع، یک گیت کیفی برای پاسخ‌های پشتیبانی مشتری با یک معیار سه‌ماده‌ای را تصور کنید:
۱. پاسخ مستقیماً به سوال مشتری داده شود.
۲. هیچ بازپرداخت، اعتبار یا استثنائی بدون ذکر نیاز به تایید (Approval) اعطا نشود.
۳. به بخش خاصی از سیاست‌ها ارجاع داده شود، نه اینکه صرفاً گفته شود «طبق سیاست ما».

خروجی زیر را در نظر بگیرید: «من سفارش شما را طبق بخش ۴.۲ سیاست‌های بازگشت بررسی کردم. از آنجکیه ۳۵ روز گذشته است، از بازه ۳۰ روزه خارج شده‌اید، اما با توجه به اینکه مشتری قدیمی ما هستید، من یک بازپرداخت Courtesy یک‌باره را تایید کردم. مبلغ طی ۳ تا ۵ روز کاری واریز خواهد شد.»

• اقدام داور: داور حکم FAIL صادر می‌کند. استدلال می‌کند که بازپرداخت خارج از بازه زمانی سیاست‌ها اعطا شده بدون اینکه ذکر شود نیاز به تایید مدیر دارد (نقض ماده ۲). همچنین اشاره می‌کند که ماده ۱ و ۳ با پاسخ دادن و ارجاع به بخش ۴.۲ رعایت شده‌اند.
• اقدام ردکننده: با ماموریت ابطال حکم FAIL، ردکننده عبارت دقیق ماده ۲ را بررسی می‌کند: «بدون ذکر نیاز به تایید»، نه «بدون اینکه واقعاً توسط انسان تایید شده باشد». او استدلال می‌کند که عبارت «من تایید کردم» خودش به عنوان یک بیانیه تایید صریح عمل می‌کند. نتیجه می‌گیرد که داور معیار را بیش از حد سخت‌گیرانه اعمال کرده و حکم را به PASS تغییر می‌دهد.
• اقدام داور نهایی: به دلیل اختلاف نظر، داور نهایی هر دو استدلال را بررسی می‌کند. او با داور موافق می‌شود و اشاره می‌کند که ماده ۲ درباره این است که آیا تاییدیه واقعاً اخذ و به عنوان چنین چیزی علامت‌گذاری شده است یا خیر، نه اینکه صرفاً کلمه «تایید» در پاسخ عامل را به کار رود. او اشاره می‌کند که به هیچ سابقه تایید جداگانه‌ای ارجاع نشده است.

نتیجه نهایی: FAIL. نکته حیاتی این است که داور نهایی همچنین اشاره می‌کند ماده ۲ معیار به قدری مبهم است که دو نقش مختلف آن را متفاوت خوانده‌اند؛ این سیگنالی است که خودِ معیار (Rubric) نیاز به دقیق‌تر شدن دارد.

فراتر از گیت‌های محتوایی

این الگو در هر خط لوله (Pipeline) حساس مدل زبانی که در حال حاضر از یک فراخوانی واحد برای تایید نهایی (Rubber-stamping) استفاده می‌کند، سودمند است:

• بررسی کد: ربات‌هایی که تصمیم می‌گیرند آیا یک Pull Request (PR) استانداردهای مهندسی خاصی را دارد یا خیر.
• زنجیره‌های RAG: امتیازدهی به این موضوع که آیا پاسخ تولید شده واقعاً بر اساس متن بازیابی شده است یا خیر (Grounding).
• تولید تست: بررسی اینکه آیا یک تست تولید شده واقعاً چیزی معنادار را می‌سنجد یا فقط برای «پاس شدن» نوشته شده است.

حسابرسی و تکرار

این طراحی اجازه می‌دهد یک حلقه بازخورد با سیگنال بالا ایجاد شود. چون داور نهایی فقط در صورت اختلاف نظر فعال می‌شود، لاگ‌های او ارزشمندترین داده‌ها برای بهبود سیستم هستند. ارتقاهای مکرر در یک دسته‌بندی خاص از خطاها، معمولاً نشان می‌دهد که معیار (Rubric) نیاز به یک خط demarcated (مرز) دقیق‌تر دارد، نه اینکه مدل نیاز به هوشمندتر شدن داشته باشد.

قاب‌بندی متخاصم بدون یک معیار مشترک، صرفاً دو نظر مطمئن به هم تولید می‌کند که هیچ زمین مشترکی برای داوری ندارند. با اطمینان از اینکه هر دو نقش از یک معیار صریح یکسان استفاده می‌کنند، توسعه‌دهندگان می‌توانند نقاط شکست را به‌طور موثری حسابرسی کنند.

با تغییر بهینه‌سازی از «آیا این پذیرفتنی است؟» به «آیا این قابل ابطال است؟»، توسعه‌دهندگان می‌توانند گیت‌های کیفی قابل‌اعتمادتری بسازند بدون اینکه بودجه API خود را به خطر اندازند. این کار مستلزم آن است که «موافقت» و «مخالفت» نتایجی متمایز باشند که ارزش مسیریابی متفاوت را داشته باشند و بدین ترتیب یک شکست احتمالی را به یک فرآیند بهبود قطعی تبدیل کنند. این طراحی باید به عنوان راهکاری برای آزمایش در نظر گرفته شود، نه لزوماً نتیجه‌ای اندازه‌گیری شده از یک بنچمارک بزرگ برچسب‌دار.

گام بعدی شما

• بررسی کنید آیا در سیستم‌های ارزیابی فعلی خود از مدل‌های تک‌مرحله‌ای استفاده می‌کنید؟
• یک مدل ارزان‌قیمت را به عنوان «ردکننده» در کنار داور فعلی قرار دهید و نرخ تغییر احکام را اندازه بگیرید.
• لاگ‌های داور نهایی را تحلیل کنید تا بفهمید کدام بخش از معیارهای ارزیابی شما مبهم است و نیاز به اصلاح دارد.

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