اگر امروز بر اساس گزارش‌های هفتگی، پایداری مدل خود را تایید می‌کنید، احتمالاً فریب یک عدد کاذب را می‌خورید. حقیقت این است که نرخ شکست در تلاش اول ممکن است بدون هیچ ردی، در حال افزایش باشد. این اتفاق زمانی رخ می‌دهد که یک سیستم ارزیابی، موفقیت در تلاش دوم یا سوم را به عنوان موفقیت مدل ثبت کند. در واقع، موفقیت در تلاش مجدد یک رویداد مربوط به لایه انتقال داده است، نه دلیلی بر بهبود توانایی مدل.
وقتی یک سیستم ارزیابی (Evaluation Harness) فقط پاسخ نهایی موفق را نگه می‌دارد، شکست‌های اولیه محو می‌شوند و گزارش نهایی به جای سنجش «قابلیت»، «شانس» را اندازه‌گیری می‌کند. این وضعیت دقیقاً شبیه تفاوت بین یک دفترچه آزمایشگاهی است که تمام تیتراسیون‌ها را با جزئیات ثبت می‌کند و تخته‌سیاهی که بعد از هر اشتباه، پاک می‌شود تا فقط جواب درست بعد از پر کردن مجدد بشر را نشان دهد.
طبق گزارش‌های فنی، این نشت اندازه‌گیری اغلب به‌صورت خاموش رخ می‌دهد. توسعه‌دهندگان ممکن است تنظیمات (Fixtures) خود را ثابت نگه دارند، اما اگر کتابخانه کلاینت یک اتصال قطع‌شده (Dropped Socket) را به‌طور خودکار تکرار کند و فقط بدنه نهایی را برگرداند، معیار کیفیت فاسد می‌شود. نتیجه این است که یک «بعدازظهر پر نویز» در شبکه، در گزارش نهایی شبیه به افزایش عملکرد مدل به نظر می‌رسد. به همین دلیل، سیاست تلاش مجدد باید در لایه کلاینت باشد و مالکیت امتیاز در لایه ارزیابی؛ این دو تصمیم نباید از یک متغیر مشترک استفاده کنند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی استانداردهای تست مدل‌های زبانی اشاره کردیم، تضاد بنیادینی بین رفتار کلاینت و رفتار اندازه‌گیری وجود دارد. تلاش مجدد برای کلاینتی که می‌خواهد «در دسترس بودن» (Availability) را در زمان قطع شدن سوکت تضمین کند، رفتاری درست است. اما برای سیستمی که می‌خواهد «کیفیت» را بسنجد، این رفتار اشتباه است؛ زیرا بازیابی خطا، جایگزین ردیفی می‌شود که باید شکست را ثبت می‌کرد.
مکانیزم دفتر ثبت تلاش‌ها
برای حل این مشکل، سیستمی به نام دفتر ثبت تلاش‌ها (Attempt Ledger) پیشنهاد شده است که این دو دغدغه را از هم جدا می‌کند. این دفتر تلاش دوم را ممنوع نمی‌کند و هر قطع اتصال را شکست محتوایی نمی‌داند، بلکه اجازه نمی‌دهد تلاش دوم جایگاه (Slot) تلاش اول را که پیش‌تر به دست آورده بود، اشغال کند. این رویکرد در واقع تکامل یافته‌ی ایده‌ی ثبت خروجی‌ها در قالب Snapshotهاست که برای مقابله با خطاهای نامشخص در ارزیابی‌ها پیشنهاد شده بود.
در این روش، به جای یک جایگاه واحد برای نتیجه، هر تعامل به عنوان یک ردیف تغییرناپذیر (Immutable Row) ثبت می‌شود. گردش کار پیش از فراخوانی مدل با یک شناسه مورد (Case Identifier)، هشِ داده‌های ورودی (Fixture Hash) و شماره تلاش (Ordinal) یک شروع می‌شود. هر پاسخ، حتی اگر خطای شبکه یا زمان‌بندی باشد، ردیفی را اضافه می‌کند که نوع خطا (Fault Class) و شماره تلاش را نام می‌برد.
هر پاسخ در این سیستم به کلاس‌های خطای مشخصی تقسیم می‌شود:
- NONE: تولید موفق که قابل امتیازدهی است.
- TRANSPORT: شکست در سطح شبکه.
- TIMEOUT: درخواستی که از حد زمانی مجاز فراتر رفته است.
انجماد تلاش اول
قانون اصلی این دفتر، «منجمد کردن» اولین نتیجه امتیازدهی شده است. یک ردیف محتوایی یک‌بار امتیاز می‌گیرد و سپس منجمد می‌شود تا اگر در تلاش‌های بعدی پاس شد، در کنار ردیف اول ذخیره شود اما امتیاز نهایی را تغییر ندهد. تابع امتیازدهی فقط ردیف شماره یک را می‌خواند (زمانی که آن ردیف محتوای امتیازدهی شده باشد) و هر موفقیت بعدی را برای آن مورد نادیده می‌گیرد.
این رویکرد یک تفکیک حیاتی در گزارش‌دهی ایجاد می‌کند. در دسترس بودن در یک سری داده مجزا می‌ماند و کیفیت محتوا بر اساس اولین تولیدی که داور امتیاز داده است سنجیده می‌شود. ردیف‌های مربوط به خطا و زمان‌بندی از میانگین کیفیت حذف می‌شوند، زیرا «نبودِ پاسخ» با «پاسخ اشتباه» متفاوت است. موفقیت‌های بعدی پس از یک Timeout برای تشخیص خطا ذخیره می‌شوند، اما هرگز وارد میانگین کیفیت نمی‌شوند.
اگر هر مورد نیاز به تلاش دوم داشته باشد، میانگین «آخرین موفقیت» (Last Success Mean) همچنان خوب به نظر می‌رسد، در حالی که میانگین دفتر ثبت تلاش‌ها خالی می‌ماند. این شکاف، سیگنال واقعی پس‌روی (Regression) است: افزایش در دسترس بودن در کنار غیبت یا انجماد کیفیت، بدون اینکه بازنویسی خاموشی بین این دو سری داده رخ دهد.
شناسایی پس‌روی‌های خاموش
این تفکیک، سیگنال «پس‌روی خاموش» را آشکار می‌کند. در یک سیستم ساده، تفاوت هفتگی (Weekly Diff) ممکن است پایداری را گزارش کند چون میانگین آخرین موفقیت‌ها تغییر نکرده است. اما دفتر ثبت تلاش‌ها حقیقت را می‌گوید: در دسترس بودن در حال افزایش است، اما نرخ شکست در تلاش اول نیز بالا رفته است.
اگر تعداد «ترفیع‌های رد شده» (Refused Promotions) — یعنی تلاش‌های مجددی که می‌توانستند امتیاز را بهبود ببخشند — افزایش یابد در حالی که میانگین تلاش اول ثابت است، ثابت می‌شود که تلاش‌های مجدد در حال «روابط عمومی» برای پرامپتی هستند که در واقع بهبود نیافته است. این همان پس‌روی خاموشی است که این دفتر برای شکار آن ساخته شده است و ردیفی باقی می‌گذارد که می‌توانید هفته بعد آن را با داده‌های جدید مقایسه (Diff) کنید. این حساسیت در ارزیابی، مشابه بررسی تله‌های راهنمای کاذب در عامل‌های کدنویسی است که در آن مدل‌ها به جای تکیه بر استدلال، تسلیم اشارات غلط می‌شوند.
حفاظ‌های پیاده‌سازی
برای توسعه‌دهندگانی که این سیستم را در پایتون ۳.۱۱+ (با استفاده از Generics داخلی) پیاده می‌کنند، منطق برنامه باید با دقت قرار گیرد. شماره تلاش (Ordinal) باید داخل حلقه تکرار افزایش یابد، نه بعد از اینکه حلقه یک بازمانده را برگرداند. اگر افزایش شماره تلاش دیر اتفاق بیفتد، دفتر ثبت تلاش‌ها صادقانه یک دروغ را ذخیره می‌کند و تست‌های واحد (Unit Tests) با وجود نشت داده، سبز می‌مانند.
علاوه بر این، کلاس‌های خطا باید از نوع استثنا (Exception Type) استخراج شوند، نه از طریق جستجوی متنی در بدنه پیام. متن پیام‌ها در نسخه‌های مختلف کلاینت تغییر می‌کنند، اما استثناهای تایپ‌شده کلیدهای پایداری برای سری‌های در دسترس بودن هستند.
برای تایید این منطق، می‌توان از اسکریپت‌های پیشنهادی استفاده کرد که تلاش‌ها را ثبت و خطاها را طبقه‌بندی می‌کنند. اجرای pytest روی داده‌های ثابت، صحت قانون امتیازدهی را ثابت می‌کند اما مسیری که در آن یک Runner میزبانی‌شده Timeout می‌دهد و SDK تلاش مجدد می‌کند را نمی‌سنجد. هر اجرای آزمایشی (Dry Run) که نتواند لاگ شماره تلاش‌های خود را نشان دهد، حتی اگر پاسخ نهایی روی صفحه تمیز باشد، دلیلی بر صحت سیستم نیست.
محدودیت‌ها و ریسک‌ها
این رویکرد یک راهکار ایمنی جامع نیست و در دو سناریوی خاص شکست می‌خورد:
۱. وقتی کلاینت استثنای اول را می‌بلعد و یک شیء پاسخ واحد بدون شمارش تلاش‌ها برمی‌گرداند.
۲. وقتی خودِ داور (Grader) دوباره مدل را فراخوانی می‌کند، زیرا این فراخوانی پنهان هرگز شماره‌ای از دفتر ثبت دریافت نمی‌کند.
تیم‌هایی که نمی‌توانند ردیف‌های خام تلاش‌ها را نگه دارند، نباید از این امتیازدهی استفاده کنند، زیرا امتیاز منجمد شده بعد از پایان کار قابل حسابرسی (Audit) نیست. همچنین، این طرح برای ارزیابی‌های پزشکی، حقوقی یا ایمنی نیست و امتیاز منجمد اول جایگزینی برای تحلیل کامل مخاطرات (Hazard Analysis) نمی‌شود.
به همین ترتیب، کسانی که به دنبال توافق‌نامه‌های سطح خدمات (SLA) قراردادی هستند، نباید گیت انتشار خود را روی سرورهای رایگان قرار دهند. در اینجا هدف بنچمارک مدل‌های نام‌برده نیست و از هیچ مدلی نام برده نشده است. نمونه‌ها امتیاز عددی ذخیره می‌کنند تا جریان کنترل مشخص باشد؛ تنها پس از تست قانون شماره تلاش، داور خود را جایگزین کنید، در غیر این صورت داور جدید نشت داده‌ای را که قصد شکارش را داشتید، پنهان خواهد کرد.
پلتفرم MonkeyCode که دسترسی رایگان به مدل‌ها و سرور فراهم می‌کند، اشاره دارد که ظرفیت‌های مشترک باعث افزایش احتمال Timeout و وسوسه برای استفاده از تلاش‌های خودکار می‌شود. این محیط برای تمرین کلاینت مناسب است، اما برای انتشار یک لیدربورد مقایسه‌ای، جای مناسبی نیست. پیش از وابستگی کارهای شبانه به این گزینه‌ها، شرایط فعلی را بررسی کنید، زیرا این پیش‌نویس مدت‌زمان یا ظرفیت خاصی را تضمین نمی‌کند. برای بهینه‌سازی هزینه‌ها در چنین محیط‌هایی، می‌توان از راهکارهای طبقه‌بندی‌کننده محلی جهت جلوگیری از اتلاف بودجه در فراخوانی‌های تکراری استفاده کرد.
اگر یادداشتی ثبت می‌کند که کدام Endpoint پاسخ داده است، آن را روی ردیف تلاش ذخیره کنید و ستون کیفیت را عددی نگه دارید. کاربران می‌توانند هنگام بررسی یک Timeout، یادداشت را پیوست کنند بدون اینکه میانگین منجمد شده بازنویسی شود.
با ردیابی سه عدد مجزا — میانگین محتوای تلاش اول، نرخ خطای در دسترس بودن و تعداد ترفیع‌های رد شده — تیم‌ها راه‌حلی می‌یابند تا دیگر یک اتصال پایدار را با یک مدل پایدار اشتباه نگیرند.
گام بعدی شما
- بررسی کنید آیا کتابخانه‌های کلاینت شما (SDKs) تلاش‌های مجدد را به‌طور پنهان انجام می‌دهند و نتایج شکست اولیه را حذف می‌کنند یا خیر.
- پیاده‌سازی یک لایه ثبت (Logging) برای هر درخواست که شامل شماره تلاش (Attempt Ordinal) و نوع خطا (Fault Class) باشد.
- تفکیک داشبوردهای «در دسترس بودن» از «کیفیت محتوا» برای شناسایی پس‌روی‌های خاموش در مدل‌ها.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو