وكيل صوتي بالذكاء الاصطناعي كذب على العملاء وخلط بين المتصلين — والمطوّر وجد السبب في بنية الكود لا في الـ prompt

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

ثلاثة إخفاقات رئيسية للوكيل

خلال الأشهر الأولى في بيئة الإنتاج، أخطأ الوكيل الصوتي أكثر من مرة.

الحادثة الأولى: أبلغ الوكيل عميلًا بأن «المسؤول أليكسي» سيعاود الاتصال به خلال ساعة. لم يكن هناك أي أليكسي؛ فقد ولّد الوكيل هذا الاسم من سياق المكالمات السابقة بعد أن مزج بين أجزاء من حوارات مختلفة. انتظر العميل طويلًا ثم كتب شكوى.

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

• ناداه باسم المتصل السابق بدلًا من اسمه
• تذكّر تفاصيل طلب شخص آخر واقترح «مواصلة إتمامه»
• أكّد اتفاقات غير موجودة من جلسات سابقة
• اعتذر عن «تأخير» لم يحدث، لأنه خلط بين المكالمة الحالية والسابقة

أما الحالة الثالثة فكانت الأطول من حيث مدة اكتشافها. فطوال شهر كامل، كان الوكيل يقدّم تحويلًا عاديًا للنص إلى كلام (TTS) ويعرّف نفسه للعملاء على أنه «صوت مستنسخ». لم يعمل الاستنساخ بسبب خطأ في الإعدادات، لكن النظام لم يُطلق أي استثناء، بل تراجع بصمت إلى التحويل القياسي.

لماذا لا يعالج الـ prompt المشكلة

أول ردّ فعل بديهي هو إضافة عبارات إلى الـ prompt مثل «لا تخترع أسماء» و«لا تتذكر المتصلين السابقين» و«تحقق دائمًا من وجود ملف صوتي». جرّب المؤلف ذلك، ويشرح لماذا لا ينجح هذا الأسلوب بصورة منهجية.

لا يفرّق النموذج اللغوي بين المنع الوارد في الـ prompt والبيانات الموجودة في سياق الجلسة. فإذا وصل سجلّ المكالمة السابقة فعليًا إلى نافذة السياق، فسيستخدمه النموذج. ولا يمكن بتعليمة نصية منع شيء موجود أصلًا في الذاكرة.

«الـ prompt مجرد توصية، وليس حاجزًا معماريًا. الحاجز يجب أن يكون في الكود.»

يكمن الحل في عزل الحالة على مستوى البنية التحتية: إعادة تهيئة صارمة للسياق بين المكالمات، والتحقق من وجود الملف الصوتي قبل بدء المكالمة (لا أثناءها)، وفحص صريح لكل معلومة قبل نطقها.

المنظومة الروسية وخصوصياتها

يعمل المؤلف بالكامل على أدوات محلية: نموذج لغوي (LLM) روسي، ومزوّد روسي لخدمة TTS، واتصالات هاتفية عبر مشغّل محلي. ويفرض ذلك قيودًا خاصة.

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

الخلاصات العملية من تجربة الأشهر الثلاثة:

• تحقق من توافر جميع الموارد (الصوت، الملف، الجلسة) قبل بدء العملية، لا أثناءها
• سجّل في السجلات الاستجابات «الناجحة» وليس الأخطاء فقط: التراجع الصامت أخطر من الانهيار الصريح
• اعزل حالة الوكيل بين الجلسات على مستوى الكود، لا على مستوى الـ prompt
• اختبر المخرج الصوتي، لا السجل النصي وحده: فالصوت التركيبي والصوت المستنسخ يختلفان في الوقع

ماذا يعني ذلك

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

معظم «السلوك الغريب» للوكيل الصوتي ليس هلوسة من النموذج، بل ثغرات معمارية في الكود المحيط به. وإصلاح ذلك ممكن، لكن لا يتم بالـ prompt.