عندما يعرض عليك مورّدٌ «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)، والاستدلال، وتوليد الرمز الأول.
الآثار المترتّبة:
- نموذج استدلال كبير، بلا streaming: عدّة ثوانٍ قبل أول كلمة مسموعة. مستبعَد تمامًا.
- نموذج متقدّم بـ streaming: رمز أول سريع في الأيام الجيدة، وأبطأ بكثير في السيئة. مقبول لكنه ضيّق.
- نموذج سريع بـ streaming (الفئات «الخفيفة» من Claude و GPT و Gemini): مريح.
- نموذج صغير ذو أوزان مفتوحة (open-weight) مُقدَّم على GPU الخاص بك (vLLM): ممتاز (وخاص).
قِس TTFT على حركتك الفعلية: فهو يتفاوت بحسب المزوّد والمنطقة والساعة.
تتطلّب بنية صوتية جادّة إذن:
- كل شيء بنمط streaming — ASR، LLM، TTS. لا حلقة واحدة بالنمط الدفعي.
- يُختار نموذج LLM بناءً على TTFT (زمن الوصول إلى الرمز الأول)، لا على درجة MMLU.
- يبدأ 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 مخصّص + LLM بـ streaming نحو التركيب الصوتي — المتطلّبات أعلاه جاهزةً من الصندوق. وتبقى أنت المتحكّم في:
- جذع SIP (شركتك، أرقامك).
- النماذج (النماذج المُدارة، أو BYOK، أو النماذج الخاصة) والأصوات (النسخ عبر Deepgram أو faster-whisper؛ والتركيب عبر ElevenLabs أو Cartesia أو OpenAI أو Deepgram Aura).
- المعاملات (حساسية المقاطعة، كشف نهاية الدور، عبارات الانتظار، التحويل إلى شخص بشري).
أنت لا تهيّئ سباكة الوقت الحقيقي — فتلك مهمّة المنصّة. أنت تصمّم المحادثة، وهي التحدّي الحقيقي في مجال الأعمال.