لماذا يفشل وكلاء الذكاء الاصطناعي في بيئة التشغيل

الوكيل الذي يعمل في العرض التقديمي ويفشل في التشغيل الفعلي ليس ضحية سوء حظ ولا نموذج قاصر. إنه نمط متكرر، ومتكرر بما يكفي لتعداده.

هذه قائمة بما نراه ينكسر حين ينتقل الوكيل من قاعة الاجتماعات إلى أناس حقيقيين. ولا واحد من الستة مشكلة في النموذج. وكلها قابلة للمنع، لكن عليك أن تقرّر منعها من البداية، لأن كل واحد منها يكلّف بعد الإطلاق خمسة أضعاف ما يكلّفه قبله.

1. السياق يتدهور

في العرض التقديمي يردّ الوكيل على ثلاث رسائل. أما في التشغيل الفعلي فتبلغ محادثة دعم واحدة أربعين رسالة، مع مرفقات، ومع عميل يغيّر الموضوع ثم يعود إليه، ومع تحويل إلى موظف بشري ثم عودة منه.

وما يحدث بعد الرسالة الخامسة عشرة أن التفصيلة المهمة — رقم الطلب الذي ذكره العميل في البداية — تُدفن تحت عشرين رسالة عن الشحن، فيبدأ النموذج في الاستدلال انطلاقًا من آخر ما قرأه بدل ما هو ذو صلة. هو لا يهلوس، بل يرتّب الأولويات ترتيبًا خاطئًا.

كيف يُمنع: لا تُرسل المحادثة كاملة. يجب أن يعمل الوكيل فوق حالة صريحة — الطلب، والعميل، والمرحلة، والقرارات المتخذة — تُحدَّث في كل دور، إضافة إلى نافذة قصيرة من الرسائل الأخيرة. أما السجل الكامل فيُحفظ للتدقيق، لا للاستدلال.

2. الأدوات تفشل ولا يستطيع الوكيل قراءة ذلك

يذهب جهد التصميم كله إلى المسار السعيد. ثم، في التشغيل، تُعيد واجهة نظام ERP رمز الخطأ 500 عند الثالثة فجرًا أثناء المعالجة الليلية، أو تردّ بـ 200 OK بجسم فارغ، أو تستغرق أربعين ثانية.

والوكيل الذي لم يُعلَّم ما تعنيه هذه الحالات يفعل أسوأ ما يمكن: يتعامل مع الخطأ باعتباره بيانات. فتتحوّل «لم أتمكن من العثور على الطلب» إلى «طلبك غير موجود»، تُقال لعميل طلبه موجود فعلًا.

كيف يُمنع: تُعيد كل أداة حالات مصنَّفة وقابلة للتمييز — موجود، غير موجود، خطأ عابر، غير مصرَّح. وللوكيل تعليمات صريحة لكل حالة، والاستجابة الصحيحة لخطأ عابر هي في الغالب الأعم إعادة المحاولة مرة واحدة ثم التصعيد إلى شخص، لا الارتجال أبدًا.

3. لا توجد حدود للإجراءات

هذا ما يقلق العملاء، وهم محقّون. فوكيل يملك صلاحية كتابة غير مقيّدة في نظام CRM يستطيع، بتعليمة واحدة أساء فهمها، أن يعدّل أربعمئة سجل.

وعادةً يُصاغ النقاش على شكل «كم من الاستقلالية نمنحه؟»، وهذا هو السؤال الخطأ. السؤال الصحيح هو: أي الإجراءات قابل للتراجع وأيها غير قابل؟ إرسال رسالة واتساب لا يمكن التراجع عنه. إنشاء مسودة طلب يمكن.

كيف يُمنع: حصر الصلاحيات في الحد الأدنى اللازم، ووضع الإجراءات غير القابلة للتراجع خلف اعتماد بشري من اليوم الأول، وفرض حدود صارمة — للمبلغ، ولعدد السجلات في التنفيذ الواحد، وللتكرار — في الشيفرة لا في التعليمات. فالحدّ المكتوب في التعليمات اقتراح. والحدّ المكتوب في الشيفرة حدّ.

4. لا توجد مجموعة تقييم

هذا أكثر الأعطال شيوعًا وأغلاها ثمنًا، لأنه يجعل بقية الأعطال غير مرئية.

فبلا مجموعة حالات حقيقية تُقاس عليها، لا سبيل لمعرفة ما إذا كان تعديل التعليمات يوم الثلاثاء قد حسّن النظام أم أضعفه. يجرّب أحدهم أربعة أمثلة يدويًا، فتبدو أفضل، فيُطلَق التعديل، وبعد أسبوعين تصل شكوى عن حالة كانت تعمل من قبل.

كيف يُمنع: من ثلاثين إلى مئة حالة حقيقية مأخوذة من عمل العميل، مكتوبة إلى جانب كل منها الإجابة الصحيحة، تعمل تلقائيًا عند كل تغيير. هذا يكفي للبدء. وتفصيل ذلك في الـ evals لوكلاء الذكاء الاصطناعي.

5. الجودة تتراجع دون أن ينكسر شيء

الأنظمة التقليدية تفشل بصوت عالٍ: يُرفع استثناء، ويرى أحدهم التنبيه. أما الوكيل فيفشل بصمت. يواصل الرد، ويواصل الظهور بمظهر المعقول، وتنزلق حصة الحالات التي يصيب فيها من 82% إلى 71% خلال شهرين.

والأسباب متعددة وكلها اعتيادية: المزوّد يحدّث النموذج من تحتك، وكتالوج العميل يتغيّر، ويبدأ وصول نوع جديد من الاستفسارات لم يكن موجودًا حين بُني النظام.

كيف يُمنع: مقياس جودة يعمل على حركة حقيقية — لا على مجموعة التقييم — وتنبيه حين ينزل عن الحد المتفق عليه. وبدون ذلك، أول من يلاحظ أن الوكيل ساء هو عميل.

6. حالة مشتركة بين الخطوات

هذا لا يظهر إلا حين يكتب أكثر من وكيل أو أكثر من خطوة في الشيء نفسه. خطوة تحدّث حالة الطلب، وأخرى كانت قد قرأت القيمة السابقة فتتصرف بناءً على معلومة قديمة. في نظام حتمي تكتشف هذا في أول اختبار حِمل. أما هنا، ولأن كل تنفيذ يسلك مسارًا مختلفًا، فيظهر تعارض التزامن مرة واحدة كل ثلاثمئة تنفيذ.

كيف يُمنع: كاتب واحد لكل كيان، وعمليات مُتكافئة التنفيذ — آمنة التكرار دون مضاعفة الأثر — ومفتاح تكافؤ لكل تنفيذ. إجراء ممل، وهو ما يمنع إدخال الطلب مرتين.

النمط الذي يجمع الستة

لا واحد من هذه الأعطال يخص الذكاء الاصطناعي. إنها أعطال أي نظام موزّع يعمل مقابل واجهات طرف ثالث، تفاقمها خاصيتان يضيفهما الوكلاء: المخرجات ليست حتمية، والنظام يفشل بشكل معقول بدل أن يفشل بصوت عالٍ.

وهذا يغيّر شيئًا واحدًا بالضبط في بناء البرمجيات، لكنه يغيّره تغييرًا كاملًا: لا يمكنك اعتبار غياب الأخطاء دليلًا على أن الأمور تعمل. عليك أن تقيس الجودة بصورة نشطة ومستمرة، على حالات ذات معنى. والوكيل بلا قياس ليس وكيلًا يعمل — بل وكيلًا لم تعثر بعد على أعطاله.

وهو أيضًا، بصراحة، الفرق بين عرض تقديمي يُبهر قاعة، ونظام لا يزال يعمل في شهره الثامن عشر.