קול בזמן אמת או batch — סוכן AI טלפוני אינו chatbot

כשספק מציע «סוכן 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 וייצור הטוקן הראשון.

השלכות מעשיות:

• GPT-4 Turbo ב-non-streaming: ~2,000 ms לייצור תגובה של 200 טוקנים. מחוץ למשחק לחלוטין.
• GPT-4o streaming: ~400 ms לטוקן הראשון ביום טוב, ~800 ms ביום רע. קביל אבל מתוח.
• Claude Haiku streaming: ~250 ms לטוקן הראשון. נוח.
• Llama 3 8B על vLLM: ~150 ms לטוקן הראשון. מצוין — ופרטי.

ארכיטקטורת קול רצינית מחייבת לכן:

1. הכל ב-streaming — ASR, LLM, TTS. אף חוליה אחת ב-batch.
2. מודל LLM נבחר לפי TTFT (time to first token), לא לפי ציון MMLU.
3. 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 ייעודי + cascaded LLM streaming — מכסה את כל הצרכים האלה כברירת מחדל. אתם נשארים אדוני:

• הtrunk SIP (הספק שלכם, המספרים שלכם).
• המודלים (BYOK או מודלים פרטיים).
• הפרמטרים (זמן השהייה יעד, אגרסיביות barge-in, fallback לקול אנושי).

את ה-plumbing של זמן האמת אתם לא מגדירים — זה עבודת הפלטפורמה. אתם מעצבים את השיחה, שזה הנושא העסקי האמיתי.