الصوت في الوقت الحقيقي مقابل الدفعي — agent هاتفي بالذكاء الاصطناعي ليس chatbot

عندما يعرض عليك مورّدٌ «agent هاتفيًّا بالذكاء الاصطناعي»، اطرح عليه سؤالًا واحدًا: «ما زمن الاستجابة الشامل لديك بين نهاية كلام المستخدم وبداية الرد؟»

إذا تجاوز الجواب 1.5 ثانية، فهو ليس agent هاتفيًّا. إنّه chatbot أُلصِق بمقدّمته وحدة ASR / TTS.

قاعدة الـ 800 مللي ثانية

يتحمّل الإنسان على الهاتف الصمت بعد سؤاله. لكن لهذا الصمت عتبة: فوق 800 مللي ثانية، يشعر الطرف الآخر بأنّ الخط «تجمّد». عند 1500 مللي ثانية، يقول المتّصل «ألو؟». وعند 3000 مللي ثانية، يُنهي المكالمة ظنًّا منه بوجود مشكلة في الخط.

الهدف من agent صوتي جادّ إذن هو: أقل من 800 مللي ثانية بين نهاية الكلام وأول بايت مسموع من الرد.

فلنحلّل ذلك.

ميزانية الوقت بالتفصيل

[user speech]──▶[ASR streaming]──▶[LLM]──▶[TTS streaming]──▶[audio out]
      ~150ms          ~80ms        ~?       ~250ms             ~50ms

من أصل نحو 800 مللي ثانية متاحة، تستهلك ASR + TTS + النقل نحو 270 مللي ثانية تقريبًا. وهذا يترك 530 مللي ثانية لـ LLM — بما في ذلك زمن التعبئة المسبقة (prefill)، والاستدلال، وتوليد الرمز الأول.

الآثار المترتّبة:

• GPT-4 Turbo بلا streaming: نحو 2000 مللي ثانية لتوليد رد من 200 رمز. مستبعَد تمامًا.
• GPT-4o بـ streaming: نحو 400 مللي ثانية حتى الرمز الأول في الأيام الجيدة، ونحو 800 مللي ثانية في السيئة. مقبول لكنه ضيّق.
• Claude Haiku بـ streaming: نحو 250 مللي ثانية حتى الرمز الأول. مريح.
• Llama 3 8B مُقدَّم عبر vLLM: نحو 150 مللي ثانية حتى الرمز الأول. ممتاز (وخاص).

تتطلّب بنية صوتية جادّة إذن:

1. كل شيء بنمط streaming — ASR، LLM، TTS. لا حلقة واحدة بالنمط الدفعي.
2. يُختار نموذج LLM بناءً على TTFT (زمن الوصول إلى الرمز الأول)، لا على درجة MMLU.
3. يبدأ TTS بالنطق عند أول رمز مُستقبَل، لا بعد اكتمال الرد بالكامل.

المقاطعة (barge-in)

في القناة النصية، ينتظر المستخدم انتهاء الـ bot. أمّا على الهاتف، فهو يقاطع. ثلاث مرات من أصل خمس، في المحادثات الطبيعية.

الـ agent الصوتي الذي لا يتحمّل مقاطعته يبدو «آليًّا» — إذ يواصل الكلام بينما يحاول المستخدم مقاطعته. وهذا لا يُطاق، ويشير فورًا إلى bot سيّئ الصنع.

تتطلّب المقاطعة (barge-in) التقنية:

• توقّف TTS فورًا عندما يكتشف ASR إشارةً صوتية صادرة من المستخدم.
• تجاهُل LLM للإكمال الجاري (دون تذمّر).
• تفريغ مخزن الصوت الصادر فورًا (وإلا سُمِع نصف مقطع لفظي متبقٍّ).
• إشارة سجل المحادثة إلى أنّ الرد لم يُسمَع كاملًا — تفاديًا لتكراره سهوًا.

إنّه تفصيل تقني يغيّر كل شيء في إحساس التفاعل.

التعامل مع عدم اليقين

على الهاتف، يخطئ ASR بانتظام. فحيث يتلقى chatbot النصي دائمًا النص الدقيق الذي كتبه المستخدم، يتلقى الـ agent الصوتي نسخةً منقولة كثيرًا ما تكون غير كاملة.

استراتيجيات ناجعة:

• طلب التأكيد على العناصر عالية الأثر (رقم الملف، المبلغ، اسم عائلة غير مألوف). لا بشكل منهجي — فذلك يصبح لا يُحتمَل.
• عدم الثقة العمياء بـ LLM عندما يكون ASR غامضًا. إذا كانت العبارة المُستقبَلة «أريد إلغاء عقدي» بدرجة ثقة منخفضة، فمن الأفضل السؤال «هل تقصد إلغاء عقدك؟» بدلًا من إطلاق إجراء الإلغاء.
• قطع الانحرافات — الـ agent الذي ينحرف عن النص ينبغي إعادته بواسطة عقدة condition / operator، لا بمطالبة «يُفترض أن تكون كافية».

الهاتف كذلك عبارة عن حزمة تقنية

إلى جانب الذكاء الاصطناعي، يتطلّب agent هاتفي:

• جذع SIP من شركة اتصالات (Twilio، Voxbone، OVH، Sewan…).
• بوابة وسائط (LiveKit-SIP، FreeSWITCH، Asterisk) تتحدّث SIP من جهة الشركة و WebRTC من جهة المنصّة.
• ناسخ صامد أمام الضوضاء واللهجات والأصوات المتداخلة.
• مُركِّب ينطق أسماء العلم والأرقام والتواريخ نطقًا صحيحًا.

لا شيء من هذه العناصر تافه. وكلها تتفاعل معًا.

ما تتكفّل به betool

تغطّي البنية الصوتية لـ betool — LiveKit + LiveKit-SIP + worker مخصّص + streaming متتالٍ لـ LLM — المتطلّبات أعلاه جاهزةً من الصندوق. وتبقى أنت المتحكّم في:

• جذع SIP (شركتك، أرقامك).
• النماذج (BYOK أو النماذج الخاصة).
• المعاملات (زمن الاستجابة المستهدف، حدّة المقاطعة، التراجع إلى صوت بشري).

أنت لا تهيّئ سباكة الوقت الحقيقي — فتلك مهمّة المنصّة. أنت تصمّم المحادثة، وهي التحدّي الحقيقي في مجال الأعمال.