«قرنطینهٔ امتیازات»؛ راهکاری برای جلوگیری از تشخیص اشتباه رگرسیون

تصور کنید یک مهندس نرم‌افزار متوجه افت امتیاز در خروجی‌های مدل خود می‌شود و ساعت‌ها وقت صرف تغییر پرامپت می‌کند، در حالی که مشکل اصلاً از متن پرامپت نیست. این یک تلهٔ رایج در توسعه است؛ جایی که تغییرات زیرساختی مدل را به اشتباه به عنوان رگرسیونِ کیفیت در پرامپت تفسیر می‌کنیم. تفاوت در امتیاز (Score Delta) لزوماً دلیلی بر تغییر در پرامپت نیست، به‌ویژه زمانی که مهر مدل (Model Stamp) یا نسخه سرور تغییر کرده باشد.

طبق یک پیشنهاد فنی در ۱۰ اکتبر ۲۰۲۶ از سوی MonkeyCode، بسیاری از تیم‌ها در ردیابی کیفیت هوش مصنوعی دچار شکست می‌شوند؛ زیرا مسیرهای رایگان مدل را جایگزینی مستقیم برای نسخه‌های قبلی می‌بینند. وقتی یک مهندس شاهد تغییر در میانگین امتیازات است، ممکن است در واقع با یک مدل ضعیف‌تر یا یک توکن‌ساز (Tokenizer) — شبیه به دستگاه خردکنی که کلمات را به تکه‌های کوچک‌تر تبدیل می‌کند تا مدل بفهمد — روبرو باشد، نه یک رگرسیون واقعی در پرامپت.

این مشکل زمانی تشدید می‌شود که تیم‌ها به محیط‌های تست شبانه متکی هستند که از نقاط انتهایی (Endpoints) جایگزین‌پذیر استفاده می‌کنند. در این شرایط، متغیرها بدون اینکه حتی یک خط از پرامپت تغییر کند، با هم ترکیب می‌شوند. اکثر تیم‌ها ابزار ارزیابی (Fixture) و داور (Grader) را ثابت نگه می‌دارند، اما نام دقیق مدلی که پاسخ را تولید کرده ثبت نمی‌کنند. این موضوع یک نقطه کور ایجاد می‌کند؛ جایی که اثر انگشت (Hash) فایل‌های تست ثابت می‌ماند، اما نقطه انتهایی به‌طور خاموش به مجموعه وزن‌های متفاوتی متصل می‌شود. این عدم قطعیت در داده‌های تست، ما را به یاد چالش‌های ثبت دقیق عملکرد می‌اندازد که در تحلیل ما درباره تفاوت لاگ‌های توهمی و رسیدهای واقعی در ارزیابی AI به تفصیل بررسی شده است.

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

زمینه رگرسیون‌های خاموش

جایگزینی مسیرهای مدل اغلب ارزان است و در جریان نگهداری روتین سرور، توقف سهمیه‌ها یا بررسی حوادث رخ می‌دهد. بدون یک شناسه هویتی، سه علت متمایز — رگرسیون واقعی پرامپت، مدل ضعیف‌تر، یا تغییر در تصویر سرور که توکن‌سازی را تغییر داده — همگی در قالب یک عدد واحد ظاهر می‌شوند. این وضعیت باعث می‌شود مهندس مسئول، هیچ ردپایی (Stack Trace) برای عیب‌یابی شکست نداشته باشد.

بر اساس مستندات MonkeyCode، بررسی‌های فعلی در بسیاری از خط لوله‌ها (Pipelines)، ابزار ارزیابی، داور و جایگاه مورد تست (Case Slot) را پیش از اعتماد به تفاضل (Diff) تثبیت می‌کنند. در حالی که این تثبیت‌ها مانع از آن می‌شوند که یک دستورالعمل متغیر، تاریخچه را بازنویسی کند، اما نام مدلی که پاسخ را تولید کرده ثبت نمی‌کنند. فیلد گمشده، شناسه مدل (Model Stamp) است که باید در کنار اثر انگشت فایل ذخیره شود، نه اینکه از روی امتیاز استنتاج شود.

خطر نمودارهای تخت

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

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

سازوکار مرحله «قرنطینه»

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

• مانیفست مورد (Case Manifest): فهرستی از ورودی‌های طلایی و خروجی‌های مورد انتظار. این بخش شامل یک اثر انگشت محتوایی است که روی بایت‌های فایل کانونی محاسبه شده است. این کار تضمین می‌کند که یک ویرایش پنهان در فیلدهای مورد انتظار، پشت پوشش تعویض مدل مخفی نشود.
• آداپتور کاندید (Candidate Adapter): مؤلفه‌ای که پاسخ را به همراه شناسه مدل (Model Stamp) و نسخه سرور گزارش‌شده توسط میزبان برمی‌گرداند.
• مرحله قرنطینه (Quarantine Step): یک گیت منطقی که دلتای امتیاز را تنها زمانی محاسبه می‌کند که اثر انگشت مانیفست، شناسه مدل و نسخه سرور، همگی با ردیف خط مبنا (Baseline) مطابقت داشته باشند.

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

پیاده‌سازی فنی و منطق

این سیستم از یک بررسی مبتنی بر پایتون برای اجرای این قوانین استفاده می‌کند. شناسه مدل به عنوان یک رشته متنی مبهم (Opaque String) از پاسخ میزبان کپی می‌شود، نه یک نام مستعار که توسط توسعه‌دهنده انتخاب شده باشد. اگر میزبان برای یک نام تجاری یکسان، رشته متفاوتی برگرداند، قرنطینه آن را به عنوان یک «شماره سری» (Lot Number) جدید در نظر می‌گیرد.

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

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

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

جزئیات الزامات سیستم

• ساختار مانیفست: استفاده از JSON که هر مورد شامل ورودی مدل و یک «پوش» (Envelope) مورد انتظار برای داور است که تنها پس از بازگشت پاسخ مدل دیده می‌شود. جدا نگه داشتن داده‌های طلایی از پرامپت یک کنترل مجزا است. مثال: { "suite": "envelope-v3", "cases": [ { "id": "refund-status", "input": {"ticket": "T-1842", "ask": "status"}, "expected": {"tool": "lookup_ticket", "args": {"id": "T-1842"}} } ] }.
• رکورد خط مبنا: ذخیره وضعیت موفقیت به صورت عدد صحیح برای ساده‌سازی تفریق. مثال: { "manifest_hash": "recorded-sha256", "model_stamp": "host-reported-id", "server_revision": "image-digest", "passed": 1 }.
• وضعیت‌های خروجی: کد ۰ برای تطابق کامل و چاپ دلتا، و کد ۲ برای فعال شدن قرنطینه. کد ۲ باید به عنوان یک هشدار (Page) برای مهندس ارسال شود، در حالی که خطاهای عملیاتی مانند نبود فایل ورودی باید جداگانه مدیریت شوند تا مهندسان به نادیده گرفتن هشدارها عادت نکنند.
• نسخه سرور: این فیلد حیاتی است زیرا یک Digest جدید از تصویر سرور می‌تواند توکن‌سازی، زمان انتظار (Timeout) یا طرح ابزار (Tool Schema) را تغییر دهد، در حالی که نام مدل ثابت بماند. این فیلد تضمین می‌کند که این دسته از تغییرات به عنوان ویرایش پرامپت masquerade نکنند.
• مدیریت ناشناخته‌ها: شناسه‌های حذف‌شده باید «unknown» بمانند. ناشناخته بودن به معنای شکست در قرنطینه است، نه یک پیش‌فرض خاموش که وانمود کند مدل دیروز هنوز متصل است.

مدیریت موارد خاص و محدودیت‌ها

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

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

نقش نظارت انسانی

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

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

افشا: این مقاله به عنوان بخشی از فعالیت‌های تبلیغاتی محصول MonkeyCode تهیه شده است. MonkeyCode توسط اپراتور به عنوان یک پروژه متن‌باز توصیف شده است که دسترسی رایگان به مدل‌ها و گزینه سرور رایگان ارائه می‌دهد. این ادعاهای در دسترس بودن اهمیت دارند زیرا آداپتور کاندید به میزبانی نیاز دارد که برای اجرای شبانه به اندازه کافی ارزان باشد. جزئیات مربوط به سهمیه توکن‌ها، شناسه‌های مدل، سخت‌افزار و مدت زمان پیشنهادها به دلیل نبود مستندات اولیه در این پیش‌نویس ذکر نشده است.

گام بعدی شما

• بررسی کنید آیا در سیستم‌های تست خود، شناسه دقیق نسخه مدل (Model Stamp) را ذخیره می‌کنید یا فقط به نام تجاری مدل اکتفا کرده‌اید.
• پیاده‌سازی یک لایه «قرنطینه» که در صورت تغییر نسخه سرور یا مدل، از محاسبه دلتای امتیاز جلوگیری کرده و هشدار انسانی صادر کند.
• ایجاد یک مانیفست با اثر انگشت (Hash) برای ورودی‌ها و خروجی‌های طلایی جهت جلوگیری از تغییرات پنهان در داده‌های تست.

اما تأثیر این تغییرات بر هزینه استنتاج در مقیاس بالا حتی پیچیده‌تر است — به تحلیل ما درباره بهینه‌سازی هزینه‌های GPU مراجعه کنید.