تصور کنید مدیر محصولی هستید که با تکیه بر نمرات درخشان یک بنچمارک، مدل عامل خود را ارتقا میدهد، اما هفته بعد متوجه میشود نرخ خطاهای بحرانی در محیط عملیاتی بهشدت بالا رفته است. مشکل اینجاست که مدلهای «بهتر» لزوماً خطاهایی تولید نمیکنند که انسانها بتوانند آنها را شکار کنند.
به نقل از مقالهای که در ۱۳ اوت ۲۰۲۶ در dev.to منتشر شد، یک ریسک عملیاتی جدی وجود دارد: شکاف میان صحت خام یک مدل و توانایی ناظر انسانی در شناسایی اشتباهات خاص آن. این شکاف دقیقاً همان جایی است که حوادث تولیدی (Production Incidents) رخ میدهند. در بسیاری از تیمها، روند کار به این صورت است که مدیر تیم لینکی به یک مدل جدید با هزینه کمتر و اعداد ارزیابی خیرهکننده میفرستد و در کمتر از یک ساعت، عامل (Agent) — شبیه به کارمندی که دستورات را اجرا میکند اما گاهی در جزئیات اشتباه میکند — به مدل جدید متصل میشود. اما این دو پرسش که «آیا مدل بهتر است؟» و «آیا انسان متوجه اشتباه آن میشود؟» اغلب پاسخهای متفاوتی دارند و بیشتر از آنچه تیمها انتظار دارند، از یکدیگر فاصله میگیرند.
مالکیت و بازگشتپذیری
پیش از هر ارزیابی، تیم باید مسئولان را مشخص کند. مالک تصمیم معمولاً کسی است که صف تأییدیهها را مدیریت میکند — اغلب مدیر محصول یا طراح — در کنار مهندسی که هنگام انحراف رفتار عامل، مسئول پشتیبانی است.
بسیاری از تیمها تعویض مدل را یک تغییر ساده در تنظیمات میبینند که بهراحتی قابل بازگشت است. اما هزینه واقعی، «کالیبراسیون مجدد» غرایز انسانی است. ناظران ماهها وقت صرف میکنند تا حالتهای شکست مدل فعلی را یاد بگیرند. آنها از طریق هر پیشنویس بازگردانده شده و هر اصلاحیه یادداشتشده، آموزش دیدهاند که در نقاط خاصی از متن به دنبال خطا بگردند. وقتی مدل جدید انواع متفاوتی از خطا را معرفی میکند، پنجره بازگشتپذیری بسته میشود؛ زیرا شما فقط کد را برنمیگردانید، بلکه باید انسانها را دوباره آموزش دهید. بازگرداندن یک تنظیمات چند دقیقه زمان میبرد، اما بازآموزی یک تیم انسانی هفتهها طول میکشد. این چالشها نشان میدهد که چرا در استقرار مدلها، اولویتبندی پایداری بر کیفیت خام میتواند ریسک حوادث عملیاتی را بهشدت کاهش دهد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، اعتماد کالیبرهشده بین انسان و ماشین، حساسترین بخش سیستمهای عاملمحور است.
دروازه قابلیت شناسایی توسط ناظر
برای جلوگیری از حوادث، نویسنده یک «دروازه» سه مرحلهای را پیشنهاد میکند که باید پیش از استقرار هر مدل اجرا شود. این یک پیشنهاد طراحی با ساختاری عینی است که هدف آن اجرا و انتشار نتایج با اعداد واقعی هر تیم است. این سیستم تمرکز را از مدل بهتنهایی به «سیستم مدل-به-plus-ناظر» منتقل میکند. این رویکرد در واقع تکاملیافتهی پروتکلهای بازپخش در برابر بنچمارکهاست که تضمین میکند مدل در محیط واقعی پایدار باقی بماند.
بخش اول: بسته بازپخش (Replay Pack)
تیمها بهجای پرامپتهای فرضی، باید از لاگهای تصمیمات عامل خود برای استخراج خروجیهای واقعی که قبلاً توسط انسان رد، بازنویسی یا بازگردانده شدهاند، استفاده کنند. اگر تیمی لاگ تصمیمات ندارد، اولین مشکل همین است، زیرا بدون آن چیزی برای ارزیابی وجود ندارد. این موارد رد شده باید به دستههای رفتاری تقسیم شوند:
- تجاوز از محدوده (Scope creep): عامل روی مواردی اثر گذاشته که از او خواسته نشده بود.
- اختراع پذیرفتنی (Plausible invention): ساختن جزئیات با اعتمادبهنفس برای پر کردن شکافهای موجود در یک مشخصات فنی (Spec).
- فراموشی محدودیتها (Constraint amnesia): فراموش کردن یک قانون محلی، یک وضعیت خطا، یا یک محدودیت دسترسیپذیری که در ابتدای جلسه ذکر شده بود.
- شکافهای بدون علامت: خروجیهایی که کامل به نظر میرسند اما حفرهای دارند که ناظر باید بهتنهایی و بدون راهنما آن را پیدا کند.
تیمها باید برای هر دسته، تعدادی مورد بازپخش با استفاده از پرامپتها، کانتکست و دسترسی به ابزارهای کاملاً یکسان بسازند. اجرای حدود ۲۰ مورد از این کیسهای واقعی روی مدل فعلی و مدل کاندید، روندهای رفتاری را آشکار میکند. بررسی کمتر از ۲۰ مورد، تقریباً هیچ اطلاعات مفیدی به تیم نمیدهد.
بخش دوم: کارت امتیاز قابلیت شناسایی
این کارت بهجای صیقلخوردگی خروجی، تعامل بین خطا و شناسایی انسانی را میسنجد. سیگنالهای کلیدی عبارتند از:
- نمایش استدلال: آیا ناظر میبیند عامل چه چیزی خوانده و چرا این کار را کرده است؟ استدلال نامرئی قابل حسابرسی نیست.
- قابلیت تشخیص خطا: آیا یک ناظر خسته میتواند اشتباه را در کمتر از یک دقیقه پیدا کند؟ خطاهای زیاد اما مشهود، بهتر از خطاهای نادر اما پنهان هستند.
- بار بازنویسی: تعداد ویرایشهای لازم برای هر تأیید. تعداد ویرایشها در هر تأیید، نشاندهنده روند واقعی کیفیت است.
- وفاداری به محدوده اعلامشده: آیا عامل در چارچوب درخواست مانده است؟ نقض محدوده، اعتماد کالیبرهشده را نابود میکند.
- گزارش شکافهای خودکار: آیا مدل حدسها و حذفیات خود را علامتگذاری میکند؟ یک حفره بدون علامت، بهطور کامل از مرحله بازبینی عبور میکند.
قابلیت تشخیص خطا حیاتیترین معیار است. مدلی که در لیدربوردهای عمومی نمره بالاتری میگیرد اما خطاهایی تولید میکند که برای انسان سختتر قابل شناسایی است، در واقع یک «تنزل کیفیت» برای سیستمهای انسان-در-حلقه (Human-in-the-loop) محسوب میشود. لیدربوردها مدل را در انزوا ارزیابی میکنند؛ اما این کارت امتیاز، سیستمی را میسنجد که شما واقعاً اجرا میکنید. این متدولوژی شباهت زیادی به سازوکارهای ممیزی رفتاری دارد که برای جلوگیری از ادغامهای کورکورانه کد در مدلهای برنامهنویسی به کار میرود.
بخش سوم: معیارهای توقف پیشتعیینشده
برای جلوگیری از مذاکره با نتایج پس از مشاهده، تیمها باید معیارهای توقف (Abort Criteria) را از پیش تعیین کنند. راهنما پیشنهاد میکند به این محرکهای خاص متعهد شوید:
- توقف در صورت هرگونه پسرفت در موارد فراموشی محدودیتها: ناظران تقریباً هرگز این دسته را نمیگیرند و آسیب بهصورت خاموش انباشته میشود.
- توقف در صورت کاهش گزارش شکافهای خودکار: این مورد حتی اگر کیفیت کلی تکمیل خروجی بالا رفته باشد، اعمال میشود.
- گسترش نمونه در صورت تغییر خوشهها: اگر چندین مورد در یک دسته بهطور همزمان از «پاس» به «فیل» تغییر کنند، این یک تغییر رفتاری است، نه یک نوسان ساده.
- بازگشت فوری اگر ناظران بگویند «دیگر نمیدانم باید دنبال چه بگردم»: این جمله یعنی مدل ذهنی ناظر در حال فروپاشی است و پنجره بازگشتپذیری در حال بسته شدن است.
در تمام این بازه زمانی، مدل قبلی باید تنها با یک تغییر در فلگ تنظیمات (Config Flag) در دسترس باشد. بازگشت (Rollback) باید یک کلید ساده باشد، نه جستوجو در تاریخچه نسخهها.
اجرا و ریسکهای نادیده گرفته شده
برای تیمهای بدون بودجه، استفاده از MonkeyCode پیشنهاد شده است که دسترسی رایگان به مدلها و امکان میزبانی یک سیستم بازپخش سبک را فراهم میکند؛ سیستمی که شامل یک اسکریپت، یک جدول نتایج و یک صف بازبینی انسانی است. از آنجایی که لایههای رایگان ممکن است محدودیتهای مستندی داشته باشند یا حذف شوند، این سیستم باید به صورت «یکبار مصرف» طراحی شود. دارایی ماندگار، خودِ «بسته بازپخش» است که باید در مخزن کنترلشده تیم باشد.
دو بررسی فراموششده اما ضروری برای تکمیل این دروازه وجود دارد:
- سناریوهای دسترسیپذیری (a11y): گنجاندن حداقل دو مورد که معیارهای پذیرش آنها الزامات دسترسیپذیری باشد؛ مانند ترتیب فوکوس کیبورد، پیامهای خطای اعلامشده یا کنتراست کافی در استایلهای تولید شده. مدلها اغلب در این محدودیتهای ضمنی بیشتر از عملکردهای صریح پسرفت میکنند.
- هزینه خواندن برای ناظر: حتی اگر صحت یکسان باشد، تغییر در سبک خروجی — مانند استدلالهای طولانیتر، لحن متفاوت یا بخشبندی مجدد — عادتهای اسکن سریع متن را میشکند. این بار بازآموزی باید به عنوان یک هزینه امتیازدهی شده در دروازه در نظر گرفته شود.
چه زمانی از این دروازه صرفنظر کنیم؟
این رویکرد سختگیرانه در سه حالت خاص لازم نیست:
۱. عدم وجود لاگ شکست: شما نمیتوانید بر اساس تاریخی که هرگز ثبت نکردهاید امتیازدهی کنید؛ ابتدا سیستم ثبت در حلقه بازبینی را راهاندازی کنید.
۲. تعویض مدل در درخواستهای تکمرحلهای: برای فراخوانیهای بدون وضعیت (Stateless) که عادتی برای ناظر ایجاد نمیکند یا کانتکست پایدار ندارد، این حجم از بررسی زیاد است. چند مورد سخت را بررسی کنید و پیش بروید.
۳. اتکای کامل به بنچمارکها: اگر تیم قصد دارد بر اساس اسکرینشاتهای بنچمارک تصمیم بگیرد، آنها در حال توصیف مدل هستند، نه سیستم. تنها چیزی که واقعاً عرضه میشود، سیستم است.
اطلاعیه انتشار بعدی نیز با همان ترتیب همیشگی خواهد رسید: اعداد خیرهکننده، قیمت پایین و یک درخواست ادغام (Pull Request) مشتاقانه. تیمهایی که این وضعیت را بهخوبی مدیریت میکنند، کسانی هستند که میتوانند با دلیل و مدرک پاسخ دهند که آیا اشتباهات جدید از آن نوعی هستند که انسانهای آنها بتوانند شکار کنند یا خیر.
گام بعدی شما
- لاگهای رد شده (Rejected Logs) ماه گذشته را استخراج کرده و آنها را به چهار دسته «تجاوز از محدوده»، «اختراع»، «فراموشی» و «شکاف پنهان» تقسیم کنید.
- یک «بسته بازپخش» شامل ۲۰ مورد واقعی بسازید و مدل جدید را با مدل فعلی روی این موارد مقایسه کنید.
- معیارهای توقف (Abort Criteria) را پیش از اجرای تستها مکتوب کنید تا تحت تأثیر اعداد جذاب بنچمارکها قرار نگیرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو