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

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

MonkeyCode برای حل این مشکل، تغییری بنیادین در نحوه سنجش کیفیت هوش مصنوعی پیشنهاد می‌دهد: تبدیل نگاه ساده‌ی «درست/غلط» به یک سیستم پنج‌گانه که در آن خطای انتقال (Transport Loss)، قطع شدن پاسخ (Truncation)، امتناع مدل (Refusal)، فرمت‌های JSON غلط (Malformed JSON) و پاسخ‌های اشتباه (Wrong Answers) هر کدام به عنوان پنج حکم مجزا در نظر گرفته شوند.

بسیاری از ارزیابی‌های شبانه (Nightly Prompt Evaluations) در حال حاضر از سیستم‌های ساده‌ی تیک سبز استفاده می‌کنند. طبق گزارش‌های فنی، اگر یک پاسخ در لبه‌ی محدودیت توکن (Token) — که شبیه برش‌های یک کیک طولانی است که مدل تکه‌تکه می‌خورد — متوقف شود، انتهای یک شیء JSON ناپدید می‌شود و تحلیل‌گر (Parser) با خطا مواجه می‌گردد. در این حالت، grader این اتفاق را به عنوان یک شکست ثبت می‌کند و مقایسه‌ی بعدی با هفته‌های پیشین، این توهم را ایجاد می‌کند که هوش مدل افت کرده است. این یک خطای اندازه‌گیری است، نه خطای مدل. این چالش با این واقعیت همسو است که بسیاری از شکست‌های عامل‌های هوش مصنوعی در واقع ناشی از خطاهای JSON هستند و نه نقص در استدلال، موضوعی که اهمیت تفکیک دقیق خطاها را دوچندان می‌کند.

اعوجاج واقعیت‌های عملیاتی

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

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

این وضعیت شبیه ترازویی است که هر بار خواندن عدد را فراموش می‌کند، مقدار صفر کیلوگرم را ثبت می‌کند. هر بار که کامیون حمل بار دیر می‌رسد، ترازو اعلام قحطی می‌کند. در ارزیابی هوش مصنوعی، پاسخ گم‌شده به معنای پاسخ خالی نیست؛ بلکه سینی‌ای است که هرگز به ترازو نرسیده است. برای اصلاح این روند، توسعه‌دهندگان باید پیش از اختصاص نمره عددی، ماهیت شکست را طبقه‌بندی کنند.

تاکسونومی احکام ارزیابی

بر اساس مستندات و پیشنهاد MonkeyCode، ارزیابی‌ها باید از یک سیستم «حکم تایپ‌شده» (Typed Verdict System) برای جداسازی کیفیت محتوا از نویز عملیاتی استفاده کنند. این دسته‌بندی (Enum) شامل موارد زیر است:

• OK: پاسخ درست و با فرمت صحیح است.
• WRONG: پاسخ کامل است اما حاوی اطلاعات نادرست است.
• MALFORMED: مدل پاسخ را تمام کرده اما قرارداد JSON شکسته شده است.
• REFUSED: مدل از پاسخ به پرامپت امتناع کرده است.
• TRUNCATED: پاسخ به دلیل رسیدن به سقف توکن متوقف شده است (finish reason = 'length').
• TRANSPORT: قطع اتصال یا خطای سرور رخ داده است (مثلاً done.error وجود دارد یا finish == "error").
• UNKNOWN: دلیل توقف 'stop' نیست اما با هیچ‌یک از دسته‌های شناخته‌شده دیگر مطابقت ندارد.

تنها احکام OK و WRONG — که به عنوان مجموعه «محتوایی» (CONTENT set) تعریف می‌شوند — باید اجازه داشته باشند خط مبنای محتوای پین‌شده (Pinned Content Baseline) را تغییر دهند. با جداسازی این‌ها، نرخ محتوایی که ردیف‌های قطع‌شده را نادیده می‌گیرد، سالم‌تر از نرخ کلی پذیرش (Raw Pass Rate) به نظر می‌رسد، اما در واقع انعکاسی صادقانه‌تر از توانایی‌های استدلالی مدل است. این رویکرد دقیق، در مقابل متدهای سنتی قرار می‌گیرد؛ برای مثال در چالش Only What I Asked، مدل‌ها را در برابر وسوسه‌ی اصلاحات ناخواسته می‌سنجند تا مرز بین پاسخ درست و پاسخ «بیش از حد» مشخص شود.

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

برای پیاده‌سازی این سیستم، تحلیل‌گر ابتدا یک مانیفست از موارد طلایی (Golden Cases) را می‌خواند و هر پاسخ ذخیره شده را پیش از ایجاد هرگونه نمره عددی، طبقه‌بندی می‌کند. این ترتیب حیاتی است زیرا اختصاص نمره بدون تعیین کلاس، منجر به مقایسه‌های غلط در آینده می‌شود.

• ساختار مورد (Case Structure): هر مورد شامل یک case_id (شناسه مورد)، یک prompt (پرامپت) و یک دیکشنری expect حاوی مقادیر JSON مورد انتظار است.
• منطق طبقه‌بندی (Classification Logic): تابع classify ابتدا پرچم finish را بررسی می‌کند. اگر finish == "length" باشد، حکم TRUNCATED صادر می‌شود؛ اگر finish == "refusal" باشد، حکم REFUSED ثبت می‌گردد. تنها در صورتی که finish == "stop" باشد، تحلیل‌گر برای پارس کردن JSON تلاش می‌کند.
• اعتبارسنجی JSON: اگر تابع json.loads() خطای JSONDecodeError بدهد یا نتیجه یک دیکشنری نباشد، حکم MALFORMED صادر می‌شود. اگر خروجی یک دیکشنری باشد اما مقادیر آن با دیکشنری expect همخوانی نداشته باشد، حکم WRONG ثبت می‌شود.
• یکپارچگی مانیفست (Manifest Integrity): سیستم از یک هش manifest_sha256 از موارد (که بر اساس کلیدها مرتب شده‌اند) استفاده می‌کند تا مقادیر JSON مورد انتظار را به آن اجرا (Run) متصل کند. این کار تضمین می‌کند که یک ویرایش بی‌صدا در یک مورد طلایی، به اشتباه به عنوان تغییر در مدل تلقی نشود.

ایجاد حفاظ‌های داده‌ای

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

به طور مشخص، تابع کمکی content_diff_allowed تفاضل را تحت دو شرط سرکوب می‌کند:
۱. اگر کمتر از هشت مورد داوری شده باشند (آستانه min_judged).
۲. اگر احکام غیرمحتوایی (ردیف‌های مسدود شده) بیش از یک‌پنجم کل اجرا باشند (blocked * 5 <= len(rows)).

این سازوکار تضمین می‌کند که جهش ناگهانی در قطع اتصال سرورها، به شکل افت فاجعه‌بار در دقت مدل دیده نشود. در این گردش‌کار، ذخیره هر پاسخ خام — شامل متن خام، پرچم توقف و شناسه مورد — در کنار شناسه مورد برای بازپخش (Replay) ضروری است. این امر به بازبین اجازه می‌دهد بدون اجرای مجدد مدل (که باعث ورود نمونه جدید به شواهد می‌شود)، کلاس خطا را تایید کند. این سطح از سخت‌گیری در اندازه‌گیری، جایگزینی برای رویکردهای غیردقیق است، مشابه آنچه در چارچوب Four-Leaf Tree برای جایگزینی «حسِ خوب» با متدهای مهندسی‌شده در کدنویسی AI دنبال می‌شود.

تثبیت تاکسونومی

برای اطمینان از اینکه خودِ تحلیل‌گر دچار نقص نشود، توصیه می‌شود تاکسونومی با مجموعه‌ای ثابت از پاسخ‌ها (Fixtures) که هرگز فرآیند تست را ترک نمی‌کنند، قفل شود. یک تست سه خطی — شامل یک پاسخ قطع‌شده، یک امتناع و یک پاسخ غلط — می‌تواند ثابت کند که بازنویسی کدِ تحلیل‌گر، به طور تصادفی خطای length را در دسته wrong ادغام نکرده است.

به عنوان مثال، یک تست باید تایید کند که پاسخی با finish="length" حتماً TRUNCATED باشد، در حالی که پاسخی با finish="stop" اما با مقدار اولویت (Priority) غلط، WRONG باشد. پس از سبز شدن این تست، Runner شبانه می‌تواند مدل را با همان تابع classify پین‌شده فراخوانی کند.

توسعه‌دهندگان باید این تست‌های تاکسونومی را در یک محیط مجازی پاک (Clean Virtual Environment) اجرا کنند و پیش از اتصال هر کلاینتی، تنها Test Runner (مانند pytest) را نصب نمایند. یک Wrapper دور توابع summarize و diff_content باید در صورتی که هش مانیفست قابل محاسبه نباشد یا هش‌ها با هم متفاوت باشند، از شروع عملیات خودداری کند.

مدیریت «ناحیه خاکستری»

یکی از دشوارترین دسته‌ها، JSONهای ناقصی هستند که پس از یک سیگنال stop تمیز رخ می‌دهند. در این حالت، مدل تصور کرده که کار را تمام کرده است اما همچنان فرمت درخواستی را شکسته است.

رویکرد MonkeyCode این مورد را به جای wrong در دسته malformed قرار می‌دهد. این تفکیک حیاتی است زیرا به توسعه‌دهندگان اجازه می‌دهد بفهمند چه زمانی یک پرامپت نیاز به سخت‌گیرانه‌تر شدن دارد تا فرمت بهتری تحمیل شود، و این موضوع را از دانش واقعی مدل درباره حقایق جدا می‌کند. در مقابل، امتناع (Refusal) به عنوان یک نتیجه‌ی سیاست‌گذاری (Policy Outcome) در نظر گرفته می‌شود نه یک فیلد غلط؛ ادغام آن در نرخ محتوایی، به طور ناعادلانه‌ای پاسخی را که رد شده است، جریمه می‌کند.

محدودیت‌های این الگو

این روش به طور خاص برای قراردادهای محدود JSON طراحی شده است. برای مثال، موردی در تیکت‌های پشتیبانی که انتظار priority: p2 و queue: billing دارد، ساختار کافی برای نمایش این تفکیک را فراهم می‌کند. با این حال، این الگو برای موارد زیر مناسب نیست:

• جستارهای باز (Open-ended essays) یا مشاوره‌های حقوقی.
• هر موردی که در آن نمره جزئی (Partial Credit) یک نیاز واقعی در محصول باشد.
• تغییرات متنی آزاد (Free-text drift) که ممکن است توسط انسان پذیرفته شود اما سیستم آن را wrong علامت بزند.

علاوه بر این، این سیستم به این شرط وابسته است که ارائه‌دهنده (Provider) پرچم finish reason را برگرداند. بسیاری از کلاینت‌ها هرگز این پرچم را ارسال نمی‌کنند. اگر finish مفقود باشد، سیستم نمی‌تواند صادقانه قطع شدن را از متن ناقص تفکیک کند و باید ردیف را به جای حدس زدن، به عنوان unknown برچسب بزند.

برای کاربرانی که از حساب‌های MonkeyCode استفاده می‌کنند، نویسنده پیشنهاد می‌دهد برای این کارهای شبانه تکراری از مدل‌ها و سرورهای رایگان استفاده کنند. با این حال، این دسترسی باید به عنوان یک تسهیلات در نظر گرفته شود، نه به عنوان یک معیار کیفیت اندازه‌گیری شده برای عملکرد مدل. یک مسیر مدل رایگان می‌تواند دفعات قطع شدن پاسخ‌ها را تغییر دهد بدون اینکه پاسخ‌هایی که واقعاً تمام شده‌اند تغییر کنند؛ به همین دلیل است که سهم ردیف‌های مسدود شده باید دروازه‌ای برای تفاضل محتوایی باشد.

این تغییر در رویکرد، فرض بنیادی بنچ‌مارک‌های هوش مصنوعی را عوض می‌کند. این صنعت را از مدل ساده‌ی «قبول/رد» به سمت یک مدل تشخیصی می‌برد که در آن زیرساخت و هوش روی دو محور مجزا اندازه‌گیری می‌شوند. مقایسه‌ای که ارزش نگه داشتن دارد، قرار دادن نرخ محتوایی در کنار تعداد هر کلاس، برای یک مانیفست پین‌شده، روی یک Endpoint پین‌شده است.

گام بعدی شما

• در سیستم‌های ارزیابی خود، پرچم finish_reason را از API استخراج کرده و آن را از صحت محتوا تفکیک کنید.
• یک مجموعه تست ثابت (Fixture) برای اعتبارسنجی تحلیل‌گر خود بسازید تا مطمئن شوید دسته‌بندی خطاها در به‌روزرسانی‌های کد تغییر نمی‌کند.
• نرخ «محتوای خالص» را جایگزین نرخ «پذیرش کلی» کنید تا اثر نوسانات سرور بر تحلیل کیفیت مدل حذف شود.

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