מפתח שניגש לבעיית Speech to Text בעברית מגלה שזה לא העתק של STT באנגלית עם החלפת מודל. יש שכבות לשוניות, אקוסטיות וארכיטקטוניות שמשנות את התמונה. המדריך הזה עוטף את הצד הטכני: איך מודל Hebrew STT בנוי, מה API מחזיר, איך משלבים את זה במוצר, ומתי נכון לקנות במקום לבנות.
איך STT עובד - שתי שכבות
מודל Speech-to-Text מודרני מורכב משתי שכבות עיקריות, שתפקידן שונה:
מודל אקוסטי - רשת נוירונים (לרוב Transformer או Conformer) שמקבלת ספקטרוגרם של אודיו ומוציאה הסתברויות לפונמות או יחידות תווים. זו השכבה ש"שומעת" את הצליל.
מודל שפה - מודל סטטיסטי או רשת נוירונים שמקבלת רצף יחידות מהמודל האקוסטי ומחזירה את רצף המילים הסביר ביותר. זו השכבה ש"מבינה" שהצליל "אבל" כנראה מתחיל בה'-וי"ו עם תנועה - "הבעל", לא "אבל" - בהקשר ספציפי.
בעברית ההפרדה הזו חשובה במיוחד, כי המודל הלשוני נושא חלק גדול מהעבודה - הוא צריך להתמודד עם מורפולוגיה עשירה, חוסר ניקוד, וסדר מילים גמיש.
למה Hebrew STT שונה מ-English STT
לפני שמתכננים אינטגרציה, שווה להבין מה שונה - כדי לדעת מה לבדוק.
מודל אקוסטי
באנגלית - 44 פונמות יחסית נפרדות, סדר מילים נוקשה שמסייע לפענוח. בעברית - פונמות פחות, אבל קומבינטוריקה מורפולוגית עשירה. מודל אקוסטי שעבד טוב באנגלית לא יתפקד אופטימלית בעברית בלי אימון מחדש.
מודל שפה
ההבדל הגדול. עברית כתובה רוב הזמן בלי ניקוד - מה שאומר שהמודל הלשוני צריך לבחור בין כמה אפשרויות פונולוגיות לכל מילה. "ספר" יכולה להיות sefer (book) או sapar (barber) - וההקשר מכריע. מודל לשון שאומן על אנגלית אין לו את ה-prior הזה.
Tokenization
זה הופך לבעיה מעשית באינטגרציה. Tokenization של עברית במודלים כמו BPE לא תמיד עובד יעיל - אותיות סופיות (ם, ן, ץ, ף, ך), כתיב מלא וחסר, וצורות מורפולוגיות יוצרים tokenization מפוצל. מודל ייעודי מטפל בזה ברמת ה-tokenizer.
Real-time vs batch
ההבדל בין streaming STT (כל מילה מתפענחת תוך פחות משנייה) לבין batch STT (כל הקובץ מעובד יחד בסוף). באנגלית streaming מאוד נפוץ; בעברית ה-tradeoff שונה - streaming גרוע יותר בהקשר ארוך, וזה משפיע יותר על דיוק בעברית בגלל סדר המילים הגמיש. רוב המוקדים שלא צריכים real-time אמיתי - עדיף שיעבדו ב-batch.
מה API טוב צריך להחזיר
נניח שאתם מתחברים ל-API של STT. מה התגובה הסטנדרטית צריכה לכלול?
{
"transcript": "שלום, מדבר דני מ-Nivision, אפשר לדבר על quick check?",
"language": "he",
"duration_seconds": 4.2,
"words": [
{"word": "שלום", "start": 0.12, "end": 0.45, "confidence": 0.98, "speaker": 0},
{"word": "מדבר", "start": 0.78, "end": 1.05, "confidence": 0.95, "speaker": 0},
{"word": "דני", "start": 1.05, "end": 1.32, "confidence": 0.91, "speaker": 0},
{"word": "מ", "start": 1.32, "end": 1.40, "confidence": 0.97, "speaker": 0},
{"word": "Nivision", "start": 1.40, "end": 1.95, "confidence": 0.88, "speaker": 0},
{"word": "אפשר", "start": 2.30, "end": 2.65, "confidence": 0.96, "speaker": 0},
{"word": "לדבר", "start": 2.65, "end": 2.98, "confidence": 0.94, "speaker": 0},
{"word": "על", "start": 2.98, "end": 3.12, "confidence": 0.99, "speaker": 0},
{"word": "quick", "start": 3.12, "end": 3.45, "confidence": 0.85, "speaker": 0},
{"word": "check", "start": 3.45, "end": 3.78, "confidence": 0.87, "speaker": 0}
],
"speakers": [
{"id": 0, "label": "agent", "total_duration": 4.2}
]
}
המבנה הזה מאפשר לבנות מעליו כל יישום מורד-זרם: סיכום, סיווג, חיפוש, התראות.
שדות קריטיים
- word-level timestamps - חיוניים לחיפוש מבוסס-זמן וגלגול חזרה לאודיו.
- confidence per word - לסינון מילים שהמודל לא בטוח בהן (חיוני ל-QA אוטומטי).
- speaker id - גם בהקלטות mono. בלי הפרדת דוברים, התמלול שווה הרבה פחות.
- language detection - שיהיה ברור איזה חלקים בעברית ואיזה באנגלית (חשוב לטיפול נכון בשפה מעורבת).
ארכיטקטורה לדוגמה: שילוב STT במוצר
נניח שאתם בונים מוצר SaaS שכולל ניתוח שיחות. הנה איך הצינור נראה ברמה גבוהה:
[ספק טלפוניה: Voipe / Origami]
│
▼
Webhook על שיחה שהסתיימה
│
▼
[Queue: SQS / Pub/Sub / Kafka]
│
▼
[Worker שמושך את ההקלטה]
│
▼
[Hebrew STT API] ◄──── מנוע תמלול בעברית
│
▼
[Speaker Diarization]
│
▼
[Storage: S3 + Postgres/Mongo]
│
├─────► [LLM Summarization (GPT/Claude)]
│
├─────► [Classification engine]
│
├─────► [Search index: Elastic/OpenSearch]
│
└─────► [CRM sync: Salesforce/HubSpot/Pipedrive]
│
▼
[Dashboard / Alerts]
הדבר החשוב כאן: ה-STT הוא רק אחת התחנות. כדי לבנות מוצר שלם צריך לכתוב את כל השאר - queue, workers, storage, LLM integration, classification, search, CRM connectors, dashboard. עבור רוב הצוותים, build the whole stack לא משתלם.
מה ה-tradeoffs של real-time vs batch
| מאפיין | Streaming (real-time) | Batch (post-call) |
|---|---|---|
| Latency | פחות משנייה | דקות עד שעה |
| דיוק | פחות גבוה (אין הקשר עתידי) | גבוה (כל ההקשר זמין) |
| עלות חישוב | גבוהה (חיבור פתוח) | נמוכה (עיבוד אצווה) |
| מקרי שימוש | קוקפיט נציג, suggestions בזמן שיחה | תמלול מלא, סיכום, ניתוח, QA |
| מתאים למוקד? | רק אם באמת צריכים live coaching | כן, ברוב המקרים |
ב-Nivision החלטנו על batch (post-call) לרוב המקרים, וזה לא ויתור - זה החלטה. רוב מה שמוקד באמת עושה עם תמלילים זה ניתוח, סיכום ו-QA - שלא דורשים שיהוי של פחות משנייה. וההפרש בדיוק שווה.
Build vs Buy: השיקול בפועל
נניח שיש לכם צוות R&D טוב. למה לא לבנות לבד?
מה אתם תצטרכו לבנות:
- מודל STT לעברית, או אינטגרציה ל-Whisper/Google + תהליך fine-tuning משלכם
- מודל לדיאריזציה
- מודל לשפה מעורבת עברית-אנגלית
- pipeline ל-batch processing בקנה מידה
- שכבת LLM לסיכומים וניתוח
- אינטגרציות לטלפוניה הישראלית (Voipe, Origami)
- אינטגרציות ל-CRM
- דשבורד והתראות
- צוות תחזוקה מתמשך
מה זה עולה בפועל:
- 3-4 אנשי AI/ML למשך 12-18 חודשים לבניית הליבה (לא תיתכן זרימה תפעולית מלאה לפני)
- עוד 2-3 אנשי backend לאינטגרציות
- עלות compute שוטפת
- תחזוקה: מודלים מתיישנים, ספקי טלפוניה משנים API
מתי build נכון: אם הליבה של המוצר שלכם היא ה-STT עצמו, או אם אתם מוכרים את הטכנולוגיה ל-third parties. אחרת - הוא לא משתלם, ולא יוצא משם מהר.
Nivision מספקת את כל הסטאק מהמדף עם מנוע STT שאומן על עברית, פלוס סיכומים, סיווגים, דשבורד ואינטגרציות. עבור צוות שצריך להתמקד במוצר העיקרי שלו - זה ה-buy שמשחרר את ה-R&D לבעיות אחרות.
נקודות אבטחה לאינטגרציה
כשמשלבים STT במוצר, יש כמה נקודות אבטחה שלא לפספס:
- DPA - חתימה על Data Processing Agreement עם ספק ה-STT.
- PII redaction - אופציה למחיקת ת"ז, מספרי כרטיס אשראי, מספרי טלפון מהתמליל.
- Encryption at rest + in transit - TLS לכל קריאת API, AES-256 לאחסון.
- Audit logs - מי ניגש לאיזה תמליל ומתי.
- Data residency - איפה השרתים. עבור לקוחות אירופאים - חובה ב-EU.
זה רלוונטי בין אם בונים לבד ובין אם משלבים ספק. פירטנו לעומק במאמר נפרד.
שאלות נפוצות
מה עדיף - Whisper open-source שאני מאמן בעצמי, או API מסחרי?
תלוי בסקייל ובדיוק שנדרשים. Whisper-base / small עובד OK על podcasts בעברית, אבל על שיחות 8kHz הדיוק שלו לא מספיק לסביבה ייצורית. fine-tuning של Whisper-large על דאטה עברי טלפוני אפשרי, אבל דורש דאטה מתויג גדול (אלפי שעות) וצוות שיודע לתחזק את האימון. עבור רוב הצוותים - API מסחרי משתלם יותר.
האם יש Hebrew STT שמחזיר גם רגש (sentiment)?
כן. ספקים מתקדמים מחזירים אינדיקציה לרגש ברמת המקטע - כעס, סיפוק, ניטראלי. ב-Nivision זה נעשה בשכבת ה-LLM מעל התמלול, כי הקשר נוסף משפר את הדיוק לעומת מודל acoustic-only.
יש streaming Hebrew STT שעובד טוב?
יש כמה ספקים שמציעים streaming, אבל הדיוק לרוב נמוך ב-3-7 נקודות לעומת batch על אותה שיחה. אם הצורך באמת הוא live coaching - יש פתרונות. אם הצורך הוא post-call - batch נכון יותר.
מה הדרך הכי מהירה להתחיל POC?
לקחת 50-100 קבצי שיחות אמיתיות, להריץ דרך ה-API של 2-3 ספקים, ולהשוות דיוק על מילים שחשובות לכם (שמות, סכומים, ת"ז). זה ייתן תמונה מציאותית תוך שבוע.
האם יש WebRTC native לזה?
ספקים תומכים ב-WebRTC ובפרוטוקולי SIP. ברוב המוקדים הישראליים הטלפוניה מבוססת SIP, ויש webhooks סטנדרטיים מ-Voipe ו-Origami שמאפשרים לקבל את ההקלטה מיד אחרי השיחה.
רוצים לדבר Pythonית?
Nivision מספקת API ל-Hebrew STT + סיכומים, סיווגים והתראות, עם תיעוד טכני מלא ו-SDK ל-Python ו-Node. הצוות הטכני שלנו ישמח להראות לכם את ה-API על שיחות אמיתיות מהמוצר שלכם.
קבעו פגישה קצרה - 30 דקות, מסביר טכני, אנחנו רצים על קוד אמיתי ולא על שקפים. או השאירו פרטים ונחזור אליכם תוך יום עסקים.
תקבלו תובנות על בינת שיחות
כתיבה מעשית על ביצועי מוקד, בקרת איכות ואימון - ישר לתיבה שלכם.
