כשספק מציע «סוכן AI טלפוני», שאלו אותו שאלה אחת: «מהו זמן ההשהייה end-to-end מרגע שהמשתמש מפסיק לדבר ועד שמתחילה התגובה?»
אם התשובה עולה על 1.5 שנייה — זה לא סוכן טלפוני. זה chatbot עם מודול ASR / TTS מודבק לפניו.
כלל ה-800 ms
אדם בטלפון סובל שתיקה לאחר שאלתו. אבל לשתיקה יש גבול: מעבר ל-800 ms, הצד השני נראה «קפוא». ב-1,500 ms, המשתמש אומר «הלו?». ב-3,000 ms הוא כבר מנתק וחושב על תקלת קו.
המטרה של כל סוכן קולי רציני: פחות מ-800 ms בין סוף הדיבור לתחילת התגובה הנשמעת.
נפרק את זה.
תקציב הזמן בפירוט
[parole user]──▶[ASR streaming]──▶[LLM]──▶[TTS streaming]──▶[audio out]
~150ms ~80ms ~? ~250ms ~50ms
מתוך ~800 ms הזמינים, כ-270 ms הולכים ל-ASR + TTS + העברה. נשארים 530 ms ל-LLM — כולל prefill, thinking וייצור הטוקן הראשון.
השלכות מעשיות:
- מודל reasoning גדול, ב-non-streaming: כמה שניות לפני המילה הנשמעת הראשונה. מחוץ למשחק.
- מודל high-end ב-streaming: טוקן ראשון מהיר ביום טוב, הרבה פחות ביום רע. קביל אבל מתוח.
- מודל מהיר ב-streaming (הסדרות ה«קלות» של Claude, GPT ו-Gemini): נוח.
- מודל open-weight קטן המוגש על ה-GPU שלכם (vLLM): מצוין — ופרטי.
מדדו את ה-TTFT על התעבורה שלכם: הוא משתנה לפי הספק, האזור והשעה.
ארכיטקטורת קול רצינית מחייבת לכן:
- הכל ב-streaming — ASR, LLM, TTS. אף חוליה אחת ב-batch.
- מודל LLM נבחר לפי TTFT (time to first token), לא לפי ציון MMLU.
- TTS מתחיל לדבר מהטוקן הראשון שהתקבל, לא עם סיום התגובה המלאה.
ה-barge-in
בערוץ כתוב, המשתמש ממתין שהבוט יסיים. בטלפון — הוא מפריע. שלוש מתוך חמש פעמים בשיחות טבעיות.
סוכן קולי שאינו יודע להיות מופרע נשמע «רובוטי לגמרי» — הוא ממשיך לגלגל את המשפט בזמן שהמשתמש מנסה להפריע. זה בלתי-נסבל ומסגיר מיד שמדברים עם מכונה גרועה.
barge-in טכני מחייב:
- TTS מפסיק מיד כאשר ASR מזהה אות קולי מהמשתמש.
- LLM זונח את ההשלמה הנוכחית ללא היסוס.
- ה-buffer האודיו היוצא מנוקה מיידית (אחרת שומעים הברה-חצי שיורית).
- היסטוריית השיחה מציינת שהתגובה לא נשמעה במלואה — כדי שלא לחזור עליה בטעות.
פרט טכני אחד שמשנה את כל החוויה.
ניהול אי-ודאות
בטלפון, ASR טועה לא מעט. בעוד שחלון צ'אט תמיד מקבל את הטקסט המדויק שהמשתמש הקליד, הסוכן הקולי מקבל תמלול שכיח שיהיה בלתי-מושלם.
אסטרטגיות שעובדות:
- בקשת אישור על רכיבים בעלי השלכות משמעותיות (מספר תיק, סכום, שם משפחה יוצא דופן). לא באופן שיטתי — אחרת זה מייגע.
- אל תסמכו עיוורונית על ה-LLM כשה-ASR אמביגואלי. אם המשפט שהתקבל הוא «אני רוצה לבטל את החוזה שלי» עם ציון ביטחון נמוך, עדיף לשאול «התכוונת לבטל את החוזה?» מאשר להפעיל את הליך הביטול.
- גזרו סטיות בשורש — סוכן שחורג מהסקריפט חייב להיות מוחזר על ידי צומת condition או מפעיל, לא על ידי פרומפט שאמור «להספיק».
הטלפון הוא גם stack
מעבר ל-AI, סוכן טלפוני דורש:
- trunk SIP אצל ספק (Twilio, Voxbone, OVH, Sewan…).
- media gateway (LiveKit-SIP, FreeSWITCH, Asterisk) שמדברת SIP בצד הספק ו-WebRTC בצד הפלטפורמה.
- מתמלל עמיד לרעש, מבטאים וחפיפות קוליות.
- מסנתז שמבטא כהלכה שמות פרטיים, מספרים ותאריכים.
אף אחד מהרכיבים הללו אינו פשוט. כולם מקיימים אינטראקציה ביניהם.
מה betool מטפלת בו
ארכיטקטורת הקול של betool — LiveKit + LiveKit-SIP + worker ייעודי + LLM ב-streaming אל סינתזת הדיבור — מכסה את כל הצרכים האלה כברירת מחדל. אתם נשארים אדוני:
- הtrunk SIP (הספק שלכם, המספרים שלכם).
- המודלים (מודלים מנוהלים, BYOK או מודלים פרטיים) והקולות (תמלול Deepgram או faster-whisper; סינתזה ElevenLabs, Cartesia, OpenAI או Deepgram Aura).
- הפרמטרים (רגישות ה-barge-in, זיהוי סוף תור, משפטי המתנה, העברה לנציג אנושי).
את ה-plumbing של זמן האמת אתם לא מגדירים — זה עבודת הפלטפורמה. אתם מעצבים את השיחה, שזה הנושא העסקי האמיתי.