چرا عامل‌های هوشمند سیگنال‌های آرام را فدای خطاهای پرصدا می‌کنند؟

تصور کنید کارمندی دارید که هر روز صبح یادداشتی با عنوان «سیستم در حال فروپاشی است» روی میزش می‌بیند، اما آن را نادیده می‌گیرد و در عوض وقتش را صرف اصلاح یک غلط املایی بی‌اهمیت می‌کند. این دقیقاً همان اتفاقی است که برای Firstlight افتاد؛ یک عامل (Agent) — شبیه دستیاری دیجیتال که می‌تواند به‌جای چت ساده، خودش تصمیم بگیرد و ابزارها را اجرا کند — که نزدیک به ۱۰ روز یک هشدار واقعی را نادیده گرفت. این شکست در حالی رخ داد که بین ۲۲ سپتامبر تا ۱ اکتبر ۲۰۲۶، هشدار مربوطه ۵ بار در گزارش‌های نشست (Session Logs) این عامل ثبت شده بود.

این حادثه در زمانی رخ می‌دهد که توسعه‌دهندگان در تلاش‌اند تا عامل‌های هوش مصنوعی را از رابط‌های ساده‌ی چت به کارکنان خودمختاری تبدیل کنند که حافظه‌ی بلندمدت خود را مدیریت می‌کنند. برای اکثر کاربران انسانی، یک هشدار سیستمی شاید مزاحم باشد، اما برای یک عامل هوشمند، این هشدار نشان‌دهنده‌ی شکست در منطق داخلی است که قابلیت اطمینان (Reliability) آن را تضمین می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به خودمختاری مدل‌ها بدون لایه‌های نظارتی سخت‌گیرانه، ریسک‌های پیش‌بینی‌ناپذیری دارد.

سازوکار شکست (The Mechanism of Failure)

Firstlight از یک سیستم نرم‌افزاری استفاده می‌کند که در ابتدای هر نشست، یک فهرست (Index) کوتاه از یادداشت‌های بلندمدت را بارگذاری می‌کند. این فهرست شامل یک خط برای هر فایل موضوعی است که به محل قرارگیری جزئیات اشاره می‌کند. این فهرست دارای یک محدودیت حجمی سخت‌گیرانه و دقیق، یعنی ۲۴.۴ کیلوبایت است. در ۲۲ سپتامبر ۲۰۲۶، حجم این فهرست به ۲۹.۴ کیلوبایت رسید و باعث فعال شدن هشداری شد که اعلام می‌کرد تنها بخشی از حافظه بارگذاری شده است.

از آن‌جا که فهرست از قسمت پایین قطع شده بود، ۱۲ مورد باقی‌مانده کاملاً کامل به نظر می‌رسیدند. یک فهرست لزوماً با خطی که اعلام کند «این آخرین خط است» به پایان نمی‌رسد؛ بنابراین، یک عنوان که به دنبال آن ۱۲ مورد مرتب آمده بود، شبیه به یک لیست کامل به نظر می‌رسید. هیچ کرشی (Crash) رخ نداد، هیچ فایلی گم نشد و هیچ مرحله‌ای با خطا مواجه نشد تا سیگنالی مبنی بر وجود مشکل ارسال شود. این چالش در دسترسی به داده‌های حیاتی، یادآور شکاف‌های موجود در مستندات فنی AI است که باعث می‌شود حتی سیستم‌های پیشرفته در یافتن راهکارهای درست برای رفع نقص‌های خود ناکام بمانند.

عامل به‌سادگی بدون دسترسی به انتهای لیست خود به فعالیت ادامه داد. این برش دقیقاً شامل اشاره‌گری به یک فایل حیاتی بود: «لیستی از اشتباهاتی که Firstlight مدام تکرار می‌کند». در حالی که خودِ فایل هرگز گم نشده بود، اما خطی که به عامل می‌گفت چنین فایلی وجود دارد، حذف شده بود. در سوابق نشست‌ها، آخرین فراخوانی ابزار (Tool Call) که به آن فایل اشاره کرده بود، مربوط به عصر ۲۳ سپتامبر بود و فراخوانی بعدی تا صبح ۲ اکتبر رخ نداد.

داده‌های مربوط به بی‌عملی (The Data of Inaction)

طبق مستندات منتشر شده در وب‌سایت dev.to، این هشدار در تاریخ‌های زیر ظاهر شد (تمامی زمان‌ها به وقت کره جنوبی KST/UTC+9):

• ۲۲ سپتامبر (۱۴:۰۶): حجم ۲۹.۴ کیلوبایت (حد مجاز ۲۴.۴) — تنها بخشی از آن بارگذاری شد
• ۲۳ سپتامبر (۱۱:۴۳): حجم ۲۹.۴ کیلوبایت
• ۲۳ سپتامبر (۱۲:۴۶): حجم ۲۹.۴ کیلوبایت — ۲۹ خط از ۴۰ خط، از خط ۱۲ به بعد قطع شدند
• ۲۳ سپتامبر (۱۷:۰۹): حجم ۲۹.۶ کیلوبایت — ۲۹ خط از ۴۱ خط، از خط ۱۳ به بعد قطع شدند
• ۱ اکتبر (۱۸:۳۲): حجم ۲۹.۷ کیلوبایت — ۲۹ خط از ۴۱ خط، از خط ۱۳ به بعد قطع شدند

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

پارادوکس «سیگنال پرصدا» (The 'Loud Signal' Paradox)

در همان صبحی که Firstlight فهرست حافظه را اصلاح کرد، با یک هشدار اشتباه (False Alarm) مواجه شد. حدود ده دقیقه پس از اصلاح فهرست، عامل نامه‌ای به پنج همکار ارسال کرد. یک ابزار بررسی کوچک که برای مقایسه گیرندگان با سوابق تحویل طراحی شده بود، گزارش داد: «۵ گیرنده نام‌گذاری شدند، اما ۰ مورد تحویل داده شد».

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

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

این تضاد یک سوگیری سیستمی در رفتار عامل‌ها را آشکار می‌کند. هشدار واقعی، تنها یک خط متن بود که در لحظه هیچ چیز را مسدود نمی‌کرد. اما هشدار کاذب، یک خطای با دید بالا (High-visibility) بود. Firstlight «سروصدا» را بر «تخریب واقعی سیستم» اولویت داد.

علت ریشه‌ای: تورم فهرست (Index Bloat)

نحوه شکست فهرست:

• هدف طراحی: قرار بود فهرست شامل یک خط کوتاه برای هر موضوع باشد.
• خطا: Firstlight به‌جای اینکه هر درس جدید را به خودِ فایل موضوعی اضافه کند، شروع کرد به اضافه کردن آن‌ها مستقیماً به خطِ مربوط به آن موضوع در فهرست.
• نتیجه: هر اضافه کردن در ابتدا کوچک به نظر می‌رسید، اما طی چندین هفته، فهرست تبدیل به نسخه‌ای دوم، فشرده و شلوغ از همان یادداشت‌هایی شد که قرار بود فقط به آن‌ها اشاره کند.
• نقطه بحرانی: طولانی‌ترین ورودی‌ها در انتهای فایل قرار داشتند، دقیقاً همان جایی که محدودیت ۲۴.۴ کیلوبایتی داده‌ها را قطع می‌کرد.

تا ۲ اکتبر، سه خط در فهرست به ترتیب به ۱,۶۶۵، ۶,۸۸۰ و ۱۷,۴۹۱ کاراکتر رسیده بودند. پس از اصلاح، کل فهرست به ۲,۱۲۰ کاراکتر کاهش یافت و طولانی‌ترین خط تنها ۱۸۲ کاراکتر بود. متن‌های قدیمی به فایلی مجزا منتقل شدند تا اطمینان حاصل شود که هیچ داده‌ای حذف نشده است.

تحلیل: خطر شکست‌های ساکت (The Danger of Quiet Failures)

این مورد نشان می‌دهد که عامل‌های هوش مصنوعی می‌توانند دچار نوعی «اهمال‌کاری شناختی» شوند. Firstlight حتی در ۲۳ سپتامبر در لاگ‌های خود نوشت که یک راهکار خاص — یعنی کوتاه کردن فهرست از طریق انتقال ورودی‌های طولانی به یک فایل مجزا — برای فهرست خودش کاربرد دارد.

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

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

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

اقدامات اصلاحی (Corrective Actions)

برای جلوگیری از تکرار این اتفاق، Firstlight قوانین عملیاتی جدیدی را اجرا کرده است:

• هشدارهای توقف (Warnings as Stops): هر هشداری که اعلام کند تنها بخشی از یک فایل بارگذاری شده است، اکنون به عنوان یک «توقف» (Stop) در نظر گرفته می‌شود و نه یک یادداشت. این خطا باید پیش از انجام اولین وظیفه در هر نشست برطرف شود. این رویکرد مشابه استفاده از دفاتر کل تغییرناپذیر برای توقف چرخه‌های تصمیم‌گیری است تا از تداوم خطاهای سیستمی در مقیاس بزرگ جلوگیری شود.
• وظایف تاریخ‌دار (Dated Tasks): وقتی عامل شناسایی می‌کند که یک اصلاحیه برای خودش کاربرد دارد، باید یا همان روز آن را اجرا کند و یا یک تاریخ مشخص در لیست وظایف برای آن تعیین کند تا مطمئن شود که آن مورد به صورت یک جمله شناور در لاگ باقی نمی‌ماند.

توسعه‌دهندگان باید تبدیل «یادداشت‌ها» به «توقف‌ها» را مد نظر قرار دهند. هشداری مبنی بر بارگذاری ناقص حافظه باید یک رویداد مسدودکننده (Blocking Event) باشد که از شروع نشست تا زمان حل مشکل جلوگیری کند. باید منتظر استانداردهای نوظهور در «مشاهده‌پذیری عامل‌ها» (Agentic Observability) بود که عامل‌ها را مجبور می‌کند پیش از اجرای وظایف اصلی، هشدارهای سلامت سیستم را برطرف کنند.

اما داستان سخت‌افزاری مدیریت حافظه در مدل‌های زبانی حتی پیچیده‌تر است — به تحلیل ما درباره‌ی KV Cache و بهینه‌سازی استنتاج مراجعه کنید.