کارشناس پشتیبان به درخواست کاربر برای بازنشانی احراز هویت دو مرحله‌ای با مراحلی پاسخ داد که اصلاً وجود خارجی ندارند. پاسخ با اعتمادبه‌نفس به نظر می‌رسید، درخواست HTTP کد 200 OK را برگرداند، تأخیر (latency) در سطح معمول بود و تمام نمودارهای نظارتی سبز باقی ماندند.

یک کارشناس پشتیبان مبتنی بر هوش مصنوعی دچار توهم (hallucination) شد و پاسخی ساخت، زیرا بررسی‌های داخلی که باید خطا را شناسایی می‌کردند، هرگز اجرا نشدند. داشبوردهایی که مهندسان به آن‌ها تکیه می‌کنند، اجرای بی‌نقصی را گزارش می‌دادند، در حالی که کارشناس بی‌صدا در حال جعل یک راهکار بود.

چرا داشبوردهای سنتی توهمات هوش مصنوعی را تشخیص نمی‌دهند

اکثر پشته‌های مشاهده‌پذیری (observability stacks)، یک عامل هوش مصنوعی را مانند هر میکروسرویس دیگری در نظر می‌گیرند: یک درخواست ورودی واحد و یک پاسخ خروجی واحد. آن‌ها وضعیت HTTP، زمان پاسخگویی و تعداد خطاها را ثبت می‌کنند. اما آن‌ها مراحل پنهان درون درخواست را ثبت نمی‌کنند – یعنی بازیابی اسناد خارجی، فراخوانی مدل‌های زبانی بزرگ، استفاده از ابزارهای کمکی و هرگونه منطق حفاظتی (guard-rail logic) که خروجی را تأیید می‌کند.

وقتی مرحله بازیابی (retrieval) نتیجه‌ای خالی برمی‌گرداند، مدل اغلب با متنی که معقول به نظر می‌رسد، «خلاء را پر می‌کند». از دید سیستم نظارتی، فراخوانی موفقیت‌آمیز بوده است، زیرا هیچ‌چیز کرش نکرد و کد وضعیت همان ۲۰۰ باقی ماند. توهم نامرئی باقی می‌ماند و تنها نشانه آن، رسیدن یک پاسخ اشتباه به کاربر است.

تبدیل یک جعبه سیاه به یک درخت خوانا

اولین قدم برای عیب‌یابی قابل اعتماد این است که از برخورد با عامل به عنوان یک فراخوانی یکپارچه (monolithic call) دست بردارید و شروع کنید به تجسم هر عملیات داخلی به عنوان یک ردیف مجزا در یک جدول ردگیری (trace table). یک اجرای معمولی به موارد زیر تقسیم می‌شود:

  • فراخوانی سطح بالای عامل
  • مرحله بازیابی که مستندات مرتبط را استخراج می‌کند
  • هر استنتاج مدل زبانی که داده‌های بازیابی‌شده را پردازش می‌کند
  • هر فراخوانی ابزار (مثلاً جستجو در پایگاه داده، درخواست API)
  • بررسی‌های حفاظتی که واقع‌گرایی یا رعایت سیاست‌ها را اعمال می‌کنند

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

باگی که از زیر دست‌ها در رفت

در آن تعامل پشتیبانیِ ناقص، ردگیری (trace) به این صورت بود:

  1. مرحله بازیابی اجرا شد اما هیچ سندی برنگرداند.
  2. مرحله بعدی با این حال ادامه یافت و یک بافت (context) خالی را به مدل منتقل کرد.
  3. مدل پاسخی تولید کرد که اطلاعات ناقص را با مراحل ساختگی پر کرد.
  4. سیستم کد 200 را برگرداند زیرا خط در خط لوله (pipeline) رخ نداد.

توهم، نقص در خودِ مدل زبانی نبود؛ بلکه نبودِ یک لایه حفاظتی (guard-rail) بین مراحل بازیابی و تولید بود. عامل حتی زمانی که چیزی برای استناد به پاسخ خود نداشت، پاسخ داد.

لایه‌های حفاظتی ساده برای متوقف کردن توهمات

دو تغییر ملموس مشکل را از بین برد:

  • لغو در صورت بازیابی خالی – اگر ذخیره‌ساز اسناد چیزی برنگرداند، عامل باید به جای رفتن به مرحله تولید، با عبارت «نتوانستم اطلاعات مورد نیاز شما را پیدا کنم» پاسخ دهد.
  • بررسی استناد (Grounding check) – پس از اینکه مدل پاسخی تولید کرد، تأیید کنید که هر ادعای واقعی در محتوای بازیابی‌شده وجود دارد. اگر این بررسی با شکست مواجه شد، پاسخ را رد کرده و به پاسخ «نمی‌توانم پاسخ دهم» بازگردید.

یک گردش کار عملی برای عیب‌یابی سریع‌تر

  1. هر فراخوانی داخلی را ردگیری کنید – عامل را مجهز کنید تا هر مرحله بازیابی، استنتاج مدل و استفاده از ابزار، یک ردیف در یک گزارش (log) دائمی بنویسد.
  2. اجراهای ناموفق را حفظ کنید – ردگیری کامل هر تعاملی را که کاربر آن را اشتباه گزارش می‌دهد، ذخیره کنید. حذف آن‌ها برای صرفه‌جویی در فضای ذخیره‌سازی، داده‌های مورد نیاز برای یافتن عقب‌گردها (regressions) را پنهان می‌کند.
  3. اجراها را با اطلاعات نسخه برچسب‌گذاری کنید – شناسه نسخه و وضعیت هرگونه پرچم ویژگی (feature-flag) را در هر ردیف ردگیری بگنجانید. این کار به شما اجازه می‌دهد یک باگ جدید را با تغییرات اخیر کد مرتبط کنید.
  4. کیفیت را بسنجید، نه فقط سرعت را – معیارهایی اضافه کنید که میزان پیروی پاسخ از دستورالعمل و استناد آن به محتوای بازیابی‌شده را اندازه‌گیری کنند. اگر پاسخ‌ها اشتباه باشند، نرخ پردازش بالا (high throughput) ارزش چندانی ندارد.
  5. شکست‌ها را روزانه بررسی کنید – یک بررسی کوتاه و منظم از شکست‌های ذخیره‌شده اغلب الگوهایی را (مثلاً نوع خاصی از پرس‌وجو که همیشه بازیابی‌های خالی برمی‌گرداند) قبل از اینکه کاربران زیادی را تحت تأثیر قرار دهند، آشکار می‌کند.

تیم‌ها با تبدیل وضعیت «سبز» به «تأییدشده»، می‌توانند توهمات را زودتر شناسایی کنند و تجربه کاربری را قابل اعتماد نگه دارند.

هزینه نادیده گرفتن شکست‌های داخلی

وقتی داشبوردها فقط موفقیت را در لایه HTTP گزارش می‌دهند، سازمان‌ها عواملی را مستقر می‌کنند که قابل اعتماد به نظر می‌رسند اما مرتباً راهنمایی‌های نادرستی ارائه می‌دهند.

آنچه در ادامه باید زیر نظر داشت

تا زمانی که این موارد به امری عادی تبدیل نشوند، ایمن‌ترین رویکرد این است که با هر عملیات داخلی به‌گونه‌ای برخورد شود که قابل مشاهده (observable) باشد و در صورت نبود شواهد، بلافاصله با خطا مواجه شویم (fail fast).

نکته کلیدی: یک داشبورد سبز به شما می‌گوید که زیرساخت‌ها به‌درستی کار می‌کنند؛ اما تضمینی نمی‌دهد که پاسخ درست است. با ردیابی هر فرایند بازیابی، فراخوانی مدل و بررسی‌های حفاظتی (guard-rail)، شما توهمات پنهان را به خطاهای قابل مشاهده‌ای تبدیل می‌کنید که می‌توان پیش از رسیدن به کاربر، آن‌ها را اصلاح کرد.