یک سیگنال «موفق» در خط لوله‌ای که بدون نظارت انسان اجرا می‌شود، اغلب یک دروغ است. در حالی که یک عملیات ممکن است از نظر فنی به نتیجه برسد، اما هزینه پنهانِ تکرارهای متعدد می‌تواند سیستمی را بپوشاند که در سکوت به سمت یک قطعی کامل پیش می‌رود.
به گزارش وب‌سایت dev.to در ۲ سپتامبر ۲۰۲۶، مهندسان به یک نقطه کور حیاتی در نظارت بر عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیاری که برای انجام یک کار، چندین بار شکست می‌خورد اما در نهایت فقط نتیجه نهایی را گزارش می‌کند — اشاره کرده‌اند. اکثر داشبوردها، یک تکرار موفق را دقیقاً مشابه موفقیتی در اولین تلاش می‌بینند. این «جذب» شکست، نویز را برای اپراتور انسانی حذف می‌کند اما سیگنال‌های حیاتی سلامت سیستم را پاک می‌کند. این پدیده در واقع تکرار همان الگوی شکست‌های خاموشی است که در پشت چراغ‌های سبز مانیتورینگ پنهان می‌مانند و تشخیص آن‌ها را دشوار می‌کنند.
توهم موفقیت
این جذبِ خطا، دقیقاً همان هدفی است که برای مکانیزم تکرار (Retry) تعریف شده است. خطاهای گذرا واقعی هستند و بیدار کردن یک انسان برای یک اختلال چهار ثانیه‌ای که خودبه‌خود حل می‌شود، بدتر از خودِ آن اختلال است. تکرار، وظیفه‌اش را انجام می‌دهد، اما این کار را در سکوت می‌کند.
از آنجا که موفقیت نهایی، شکست‌های قبلی را می‌بلعد و هیچ ردی از آن‌ها باقی نمی‌گذارد، گزارش نهایی فارغ از میزان دشواری مسیر، یکسان می‌ماند. برای یک اجرای بی‌نقص و یک اجرای که سه بار شکست خورده و در نهایت موفق شده، از یک کلمه، یک رنگ و یک جایگاه در گزارش روزانه استفاده می‌شود.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی پایداری سیستم‌های عامل‌محور اشاره کردیم، نبودِ دید به لایه‌های زیرین منجر به تصمیمات غلط می‌شود. تصور کنید در روز اول، هیچ‌کدام از اجراها نیاز به تلاش دوم ندارند. در روز چهلم، این عدد به ۱۲ درصد می‌رسد و در روز نودم، نیمی از اجراها برای موفقیت به تکرار نیاز دارند. چون خروجی نهایی همچنان «سبز» است، این زوال تا زمانی که تلاش دوم هم شکست بخورد و یک کرش ناگهانی و به‌ظاهر تصادفی رخ دهد، نامرئی می‌ماند. در واقع، سیستم هفته‌ها بود که شکست خود را در کانالی فریاد می‌زد که هرگز ساخته نشده بود. این وضعیت می‌تواند به سرعت به بحران‌های عملیاتی تبدیل شود، مشابه آنچه در تجربه Arc Ops برای جلوگیری از فروپاشی سیستم بر اثر بودجه‌بندی نادرست تلاش‌های تکراری مشاهده شد.
شکاف «ریتم»
وقتی یک انسان کاری را انجام می‌دهد، متوجه یک توقف چهار ثانیه‌ای یا یک تردید کوتاه می‌شود. این یک سیگنال است که از طریق حس «ریتم» اپراتور منتقل می‌شود.
یک عامل بدون نظارت، چنین شهودی ندارد؛ او حسی از ریتم ندارد و انتظار کشیدن برایش آزاردهنده نیست. او با صبوری تا ابد تکرار می‌کند و تنها زمانی خبر بد می‌دهد که آخرین تلاشش هم تمام شده باشد. این اولین چیزی است که با حذف انسان از چرخه (Human-out-of-the-loop)، از دست می‌رود.
راهکار فنی
برای حل این مشکل، نویسنده در dev.to پیشنهاد می‌کند که «نتیجه» از «تلاش» تفکیک شود. به‌جای یک بیت ساده‌ی موفق/ناموفق، تیم‌ها باید موارد زیر را پیاده کنند:
- ردیابی تعداد تلاش‌ها: تعداد دفعات اجرا را به‌عنوان یک مقدار مجزا در رکورد هر عملیات ثبت کنید. این عدد باید در کنار وضعیت موفقیت باشد، نه ادغام‌شده در آن.
- نظارت بر روند: میانگین تعداد تلاش‌ها را به‌عنوان یک معیار کند-متغیر رصد کنید، نه به‌عنوان یک هشدار صفر و یکی.
- تغییر واژگان: به‌جای پرسیدن «آیا کار کرد؟»، بپرسید «انجام این کار چقدر سخت بود؟»
این تغییر، خط پایه عملیاتی را عوض می‌کند. یک اجرای تک‌موردی که دو تلاش نیاز داشته، یک حادثه نیست؛ اما هفته‌ای که در آن میانگین تلاش‌ها از ۱.۰ به ۱.۴ می‌رسد، سیگنالی است که استحقاق یک ساعت زمان مهندسی را دارد. این روند هرگز به‌تنهایی یک خط قرمز در داشبورد ایجاد نمی‌کند، اما جهت حرکت سیستم را فاش می‌کند. در غیر این صورت، ریسک وقوع خطاهای زنجیره‌ای افزایش می‌یابد، درست مانند زمانی که یک اشتباه در شمارش توکن‌ها منجر به حلقه تکرار و توقف کل سیستم شد.
برای کسانی که هوش مصنوعی را در محیط تولید (Production) مدیریت می‌کنند، این بدان معناست که استانداردهای فعلی داشبوردهای «سبز»، ناکافی هستند. ما سیستم‌هایی می‌سازیم که از نظر فنی هر چه خواسته‌ایم را انجام می‌دهند، در حالی که هم‌زمان در پس‌زمینه، در حال آماده‌سازی یک قطعی بزرگ هستند.
توسعه‌دهندگان باید اکنون لایه‌های ثبت لاگ (Logging) خود را بازبینی کنند تا مطمئن شوند تعداد تکرارها به‌عنوان معیارهای درجه اول نمایش داده می‌شوند. هدف این است که «تردید» ماشین را پیش از آنکه سیستم قرمز شود، شناسایی کنیم.
گام بعدی شما
- داشبوردهای نظارتی خود را بررسی کنید و ستونی برای
attempt_countبه گزارش‌های موفق اضافه کنید. - یک هشدار (Alert) برای افزایش میانگین تلاش‌ها در بازه ۷ روزه تعریف کنید، حتی اگر نرخ موفقیت ۱۰۰٪ باشد.
- در جلسات بازبینی فنی، به‌جای بررسی نرخ خطا، «تلاش میانگین برای موفقیت» را به عنوان شاخص سلامت (Health Metric) معرفی کنید.
اما داستان سخت‌افزاری این تحول و تأثیر تأخیرهای میلی‌ثانیه‌ای بر هزینه استنتاج حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی بهینه‌سازی GPUها مراجعه کنید.
گفتگو