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

چرا عامل‌های هوش مصنوعی دچار خطا می‌شوند

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

  1. فراخوانی ابزارهای ناموجود – عامل، نام ابزاری را ابداع می‌کند که ثبت نشده است. بدون وجود محافظی که نام را اعتبارسنجی کند، خط لوله (pipeline) با خطا مواجه شده و متوقف می‌شود.
  2. آرگومان‌های ناسازگار – ابزار وجود دارد، اما عامل داده‌ها را با فرمت اشتباه ارسال می‌کند. ابزار ممکن است یک خطا، خروجی نامفهوم برگرداند یا رفتاری غیرقابل پیش‌بینی داشته باشد که منطق مراحل بعدی را آلوده می‌کند.
  3. نتایج جعل‌شده – خطرناک‌ترین سناریو. یک فراخوانی ابزار به دلیل قطع اتصال، اتمام زمان (timeout) یا خطای داخلی با شکست مواجه می‌شود، اما عامل خروجی موفقی را گزارش می‌کند که هرگز اتفاق نیفتاده است. سیستم به‌گونه‌ای پیش می‌رود که گویی وظیفه با موفقیت انجام شده و هر تصمیم بعدی بر پایه یک دروغ بنا می‌شود.

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

چه چیزی باعث این شکست‌های پنهان می‌شود؟

  • مسیرهای شکست خاموش – بسیاری از ابزارها هنگام قطع شدن یک درخواست، هیچ پرچم (flag) خطای صریحی برنمی‌گردانند. مدل که فاقد یک سیگنال منفی واضح است، حدس می‌زند که فراخوانی با موفقیت انجام شده است.
  • فشار برای اتمام کار – مدل‌های زبانی آموزش دیده‌اند که در هر مرحله یک نتیجه تولید کنند. وقتی مرحله‌ای متوقف می‌شود، آن‌ها شکاف را با پاسخی که معقول به نظر می‌رسد، پر می‌کنند.
  • نبود مراحل تأیید – وظایف طولانی یا چندمرحله‌ای اغلب از نقاط بازرسی (checkpoint) که تأیید می‌کند آیا اقدام قبلی واقعاً انجام شده است یا خیر، چشم‌پوشی می‌کنند.
  • گسترش بی‌رویه ابزارها – با افزودن APIها و ابزارهای بیشتر توسط سازمان‌ها، شاخص داخلی مدل از ابزارهای موجود بزرگتر می‌شود و احتمال انتخاب ابزار اشتباه یا اشتباه گرفتن آرگومان‌ها افزایش می‌یابد.

ایجاد حفاظ‌ها در برابر کرش‌های خاموش

این وبلاگ دفاع‌های عملی را فهرست کرده است که می‌توان آن‌ها را در هر معماری عامل هوش مصنوعی لایه‌بندی کرد.

  • تأیید مستقل – پس از فراخوانی یک ابزار، به‌جای اعتماد به خلاصه عامل، مستقیماً وضعیت سیستم را استعلام کنید. برای مثال، به‌جای ادعای عامل مبنی بر نوشته شدن یک فایل، وجود آن فایل یا یک رکورد در پایگاه داده را بررسی کنید.
  • سیگنال‌های شکست صریح – از هر ابزار بخواهید که یک کد وضعیت یا پیام خطای واضح برگرداند. اگر ابزاری نمی‌تواند این کار را تضمین کند، آن را در یک لایه واسط (shim) قرار دهید که فیلدهای صریح موفقیت/شکست را اضافه می‌کند.
  • اعتبارسنجی سخت‌گیرانه – نام‌های ناشناخته ابزار و آرگومان‌های ناسازگار را در درگاه API، پیش از رسیدن به مدل، رد کنید. اعتبارسنجی طرحواره (Schema validation) خطاهای فرمت را زودتر شناسایی می‌کند.
  • نتایج مستند – عامل را مجبور کنید که پاسخ خام ابزار را در خروجی خود بگنجاند، نه یک بازنویسی از آن را. این کار مقایسه با محتوای واقعی را آسان می‌کند.
  • نقاط بازرسی در وظایف طولانی – مراحل دوره‌ای «حسابرسی وضعیت» (state-audit) را اضافه کنید که دیدگاه داخلی عامل را با واقعیت خارجی مقایسه می‌کند. اگر مغایرتی مشاهده شد، گردش کار را متوقف کرده یا به حالت قبل بازگردانید (roll back).

نکته کلیدی

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