أجاب وكيل الدعم على طلب مستخدم لإعادة تعيين المصادقة الثنائية بخطوات لا وجود لها ببساطة. بدا الرد واثقاً، وأعادت طلب HTTP الرمز 200 OK، وكان زمن الاستجابة طبيعياً وظلت جميع مخططات المراقبة باللون الأخضر.
قام وكيل دعم مدعوم بالذكاء الاصطناعي بتقديم إجابة "هلوسة" (hallucinated) لأن عمليات التحقق الداخلية التي كان ينبغي أن تكتشف الخطأ لم تعمل أبداً. أبلغت لوحات البيانات التي يعتمد عليها المهندسون عن تشغيل مثالي، بينما قام الوكيل بتلفيق حل بصمت.
لماذا تغفل لوحات البيانات التقليدية عن هلوسات الذكاء الاصطناعي
تتعامل معظم حزم المراقبة (observability stacks) مع وكيل الذكاء الاصطناعي كأي خدمة مصغرة (microservice) أخرى: طلب وارد واحد واستجابة صادرة واحدة. فهي تسجل حالة HTTP، ووقت الاستجابة، وعدد الأخطاء. لكنها لا تسجل الخطوات المخفية داخل الطلب – مثل استرجاع المستندات الخارجية، أو استدعاءات النماذج اللغوية الكبيرة، أو استخدام الأدوات المساعدة، أو أي منطق للحواجز الوقائية (guard-rail logic) الذي يتحقق من صحة المخرجات.
عندما تعيد خطوة الاسترجاع نتيجة فارغة، غالباً ما يقوم النموذج بـ "ملء الفجوة" بنص يبدو منطقياً. ومن وجهة نظر نظام المراقبة، نجح الاستدعاء لأن شيئاً لم يتعطل وظل رمز الحالة 200. تظل الهلوسة غير مرئية، والعرض الوحيد هو وصول إجابة خاطئة إلى المستخدم.
تحويل الصندوق الأسود إلى شجرة قابلة للقراءة
الخطوة الأولى لتصحيح الأخطاء (debugging) بشكل موثوق هي التوقف عن معاملة الوكيل كاستدعاء متجانس (monolithic call) والبدء في تصور كل عملية داخلية كصف مستقل في جدول تتبع (trace table). ينقسم التشغيل النموذجي إلى:
- استدعاء الوكيل في المستوى الأعلى
- خطوة الاسترجاع التي تسحب الوثائق ذات الصلة
- كل استنتاج للنموذج اللغوي (inference) يعالج البيانات المسترجعة
- كل استدعاء لأداة (مثل البحث في قاعدة البيانات، أو طلب API)
- فحوصات الحواجز الوقائية التي تفرض الواقعية أو الامتثال للسياسات
يسجل كل صف الطابع الزمني، وعلامة النجاح، والبيانات (payload) التي مرت عبر تلك الخطوة. ومع هذا الهيكل، يصبح التنفيذ عبارة عن شجرة يمكن فحصها سطراً بسطر بدلاً من التخمين بناءً على المخرجات النهائية.
الخطأ الذي تسلل
في تفاعل الدعم الخاطئ، بدا التتبع كالتالي:
- الاسترجاع تم تشغيله ولكنه لم يعيد أي مستندات.
- استمرت الخطوة التالية على أي حال، حيث مررت سياقاً فارغاً إلى النموذج.
- قام النموذج بإنشاء إجابة ملأت المعلومات المفقودة بخطوات مخترعة.
- أعاد النظام الرمز 200 لأن خط الإنتاج (pipeline) لم يواجه أي استثناء.
لم تكن الهلوسة خللاً في النموذج اللغوي نفسه؛ بل كانت نقصاً في الحواجز الوقائية بين مرحلتي الاسترجاع والتوليد. لقد أجاب الوكيل حتى عندما لم يكن لديه أي شيء يستند إليه في رده.
حواجز وقائية بسيطة توقف الهلوسات
أدى تغييران ملموسان إلى القضاء على المشكلة:
- الإلغاء عند الاسترجاع الفارغ – إذا لم يعيد مخزن المستندات أي شيء، يجب على الوكيل الرد بـ "لم أتمكن من العثور على المعلومات التي تحتاجها" بدلاً من المضي قدماً في عملية التوليد.
- فحص الاستناد (Grounding check) – بعد أن ينتج النموذج رداً، تحقق من أن كل ادعاء واقعي يظهر في المحتوى المسترجع. إذا فشل الفحص، ارفض الإجابة وانتقل إلى رد "لا يمكن الإجابة".
سير عمل عملي لتصحيح الأخطاء بشكل أسرع
- تتبع كل استدعاء داخلي – قم بتجهيز الوكيل بحيث يكتب كل استرجاع، واستنتاج للنموذج، واستخدام للأداة صفاً في سجل دائم.
- الحفاظ على عمليات التشغيل الفاشلة – قم بتخزين التتبع الكامل لأي تفاعل يبلغ المستخدم عن خطئه. إن حذفها لتوفير مساحة التخزين يخفي البيانات اللازمة للعثور على التراجعات (regressions).
- وسم عمليات التشغيل بمعلومات الإصدار – قم بتضمين معرف الإصدار وأي حالة لعلم الميزات (feature-flag) في كل صف تتبع. يتيح لك ذلك ربط خطأ جديد بتغيير حديث في الكود.
- قياس الجودة، وليس السرعة فقط – أضف مقاييس تقيس مدى التزام الإجابة بالتعليمات ومدى استنادها إلى المحتوى المسترجع. إن الإنتاجية العالية لا تعني الكثير إذا كانت الإجابات خاطئة.
- مراجعة الإخفاقات يومياً – غالباً ما تكشف المراجعة القصيرة والمنتظمة للإخفاقات المخزنة عن أنماط (مثل نوع معين من الاستعلامات يعيد استرجاعات فارغة باستمرار) قبل أن تؤثر على العديد من المستخدمين.
من خلال تحويل الحالة من "خضراء" إلى "موثقة"، يمكن للفرق اكتشاف الهلوسات مبكراً والحفاظ على موثوقية تجربة المستخدم.
تكلفة تجاهل الإخفاقات الداخلية
عندما تكتفي لوحات البيانات بالإبلاغ عن النجاح عند طبقة HTTP، تقوم المؤسسات بنشر وكلاء يبدون موثوقين ولكنهم يقدمون توجيهات غير صحيحة بانتظام.
ما يجب مراقبته لاحقاً
إلى أن تصبح هذه الممارسات شائعة، فإن النهج الأكثر أماناً هو التعامل مع كل عملية داخلية على أنها قابلة للمراقبة، والاعتماد على مبدأ "الفشل السريع" عند غياب الأدلة.
الخلاصة: لوحة التحكم الخضراء تخبرك بأن العمليات الأساسية تعمل، لكنها لا تضمن صحة الإجابة. فمن خلال تتبع كل عملية استرجاع، واستدعاء للنموذج، وفحص لضوابط الحماية، فإنك تحول الهلوسات الخفية إلى إخفاقات مرئية يمكن إصلاحها قبل أن تصل إلى المستخدم.