Hebrew Call Analysis: מדריך למפתחים שבונים AI

צוות R&D ישראלי שמקבל את המשימה "תבנו לנו ניתוח שיחות בעברית" בדרך כלל לא יודע שהוא נכנס לפרויקט של 12+ חודשים. הצינור עצמו לא מסובך מבחינה אדריכלית — אבל כל חוליה בו נשברת אחרת בעברית מאשר באנגלית. המדריך הזה פורש את הצינור המלא, מציין איפה זה נשבר, מציג קונטרקט JSON טיפוסי, ונותן מסגרת מסודרת להחלטת build-vs-buy.

מהו pipeline טיפוסי של Hebrew call analysis?

הצינור הסטנדרטי בנוי משישה שלבים. כל אחד מהם הוא מודל או רכיב נפרד, וכל אחד מהם דורש החלטה.

1. קליטת אודיו — קובץ, stream או webhook ממערכת טלפוניה.
2. Pre-processing — נורמליזציה, הפחתת רעש, פיצול ערוצים.
3. Speech-to-Text — תמלול לטקסט עם חותמות זמן.
4. Diarization — הפרדת דוברים (מי אמר מה).
5. Text-level NLP — NER, סיווג, סנטימנט, חילוץ פעולות.
6. Output structuring — בניית JSON תקני שזורם ל-CRM, BI או דשבורד.

נראה פשוט. בעברית, חמשת השלבים האחרונים מציבים אתגרים שונים מאוד מאשר באנגלית.

למה כל שלב קשה יותר בעברית?

זה לב הבעיה. אם אתם בונים, חשוב להבין למה כל שלב נשבר.

שלב	מה האתגר בעברית	למה זה משפיע
Speech-to-Text	מורפולוגיה עשירה, ניקוד נדיר, code-switching לאנגלית	מודלים גנריים מפספסים 8–15% מילים יותר מאנגלית
Diarization	דוברים עם דיאלקטים שונים, רעש רקע ישראלי טיפוסי	מבלבל בין הנציג ללקוח, פוגע בכל הניתוח
NER	שמות עברית, שמות מקומות לא סטנדרטיים, שמות מוצרים מעורבים	חילוץ פגום של ישויות קריטיות
Sentiment	סלנג, אירוניה, השפעות שפה אם	מודלים מאומני אנגלית מתפספסים על ניואנסים
סיווג	מעט dataset מתויג בעברית	overfitting או דיוק נמוך

זו הסיבה שצוות שמנסה לעטוף Whisper out-of-the-box רואה דיוק של 75% במקרה הטוב, וצוות שמשקיע במודל מאומן על דאטה ישראלית מגיע ל-92%+.

כלל אצבע: בעברית, איכות התמלול היא תקרת הזכוכית של כל הצינור. אם ה-STT לא טוב — הסנטימנט, ה-NER והסיווג כולם יקרסו.

איך נראה output JSON טיפוסי?

הקונטרקט בין מנוע הניתוח לבין שאר המערכת חייב להיות יציב. דוגמה מינימליסטית של פלט מובנה לשיחה אחת:

{
  "call_id": "c_8a91f2",
  "duration_sec": 412,
  "language": "he",
  "speakers": [
    { "id": "agent", "label": "נציג" },
    { "id": "customer", "label": "לקוח" }
  ],
  "transcript": [
    { "speaker": "agent", "start": 0.0, "end": 4.2, "text": "שלום, מדבר דניאל מ-Nivision, איך אפשר לעזור?" },
    { "speaker": "customer", "start": 4.5, "end": 9.1, "text": "שלום, יש לי בעיה עם החיוב החודשי..." }
  ],
  "summary": "לקוח דיווח על חיוב כפול בחודש מאי. הנציג זיהה את הטעות והבטיח זיכוי תוך 3 ימי עסקים.",
  "topics": ["חיוב", "זיכוי", "תהליך גביה"],
  "sentiment": {
    "overall": "neutral",
    "trajectory": [
      { "t": 0, "score": 0.1 },
      { "t": 60, "score": -0.4 },
      { "t": 300, "score": 0.3 }
    ]
  },
  "entities": [
    { "type": "amount", "value": "189 ש\"ח", "speaker": "customer" },
    { "type": "month", "value": "מאי" }
  ],
  "action_items": [
    { "owner": "agent", "text": "לבצע זיכוי על סך 189 ש\"ח", "due": "2026-06-09" }
  ],
  "qa_score": 87,
  "compliance": {
    "disclosure_given": true,
    "recording_announced": true
  }
}

הקונטרקט הזה צריך להיות יציב — כל שינוי שובר אינטגרציות במורד הזרם. כלל אצבע: עוטפים שדות אופציונליים, לעולם לא מסירים שדות חובה. תוספות חיוביות תמיד יותר טוב מ-breaking changes.

אילו אירועים (events) המערכת צריכה לפלוט?

מעבר ל-output הסופי, מערכת טובה פולטת אירועים בזמן אמת:

• call.received — שיחה נכנסה ל-pipeline.
• transcription.started — תחילת תמלול.
• transcription.completed — תמלול גמור, זמין ל-NLP.
• escalation.detected — לקוח עבר רף סיכון (איום ביטול, אזכור רגולטור).
• compliance.violation — חוסר עמידה בדיסקלוסר רגולטורי.
• analysis.completed — output מלא זמין.

האירועים האלה הם מה שמאפשר התראות בזמן אמת, סנכרון ל-CRM, ואינטגרציה ל-Slack — ולכן הם לא פחות חשובים מה-output הסופי.

Build vs Buy: מסגרת החלטה

זו השאלה הקשה. בואו נשים אותה על השולחן בלי לקשט.

מתי משתלם לבנות?

• דאטה ייחודי מאוד — אם השיחות שלכם בסקטור שאף ספק לא מכסה (לדוגמה, מסחר כיוונים סופר־ספציפי).
• צוות R&D עם ניסיון ב-NLP — לפחות 2–3 מהנדסים בכירים שעבדו על STT/NLP.
• תקציב לטווח ארוך — צוות של 4–6 מהנדסים במשך 18+ חודשים, כולל שותפויות אקדמיות.
• דרישות compliance ייחודיות — שמחייבות שליטה מלאה במודלים.

מתי משתלם לקנות?

• תקרת זכוכית של 90%+ דיוק — שאלת הזמן עד שמודל ייעודי מנצח את הסקלת ה-in-house.
• חוסר ב-AI ML engineers בעברית — אין הרבה בשוק, והם יקרים.
• time-to-value קצר — צריך תוצאות תוך רבעון, לא תוך שנתיים.
• דרישת אינטגרציות רחבה — Voipe, Origami, Zoom, Teams, Salesforce, HubSpot, Pipedrive, Monday, Slack — כל אחת מחייבת תחזוקה.

ברוב המקרים, גם צוותי R&D חזקים בוחרים לקנות את שכבת ה-STT וה-NLP הבסיסית ולבנות מעליה לוגיקה ייחודית. זה אלגנטי יותר מבנייה מלאה. Nivision מספקת שכבת Hebrew Speech-to-Text וConversation Intelligence כ-API שצוותי R&D בונים מעליו.

שיקולי scale ו-latency

מערכת ניתוח שיחות אסינכרונית היא קלה. real-time היא משחק אחר. נקודות כשל טיפוסיות בקנה מידה:

• STT batch vs streaming — streaming יקר יותר ודרוש להתראות תוך-שיחה (live coaching). להתראות post-call (תוך דקות מסיום השיחה - מה ש-Nivision מספקת) batch מספיק.
• GPU vs CPU inference — STT דורש GPU בנפח גבוה; NLP יכול לרוץ על CPU.
• Queue management — אלפי שיחות במקביל דורשות תור עמיד עם retry policies.
• Audio storage — קבצי הקלטה גדולים; cold storage חיוני אחרי 30–90 יום.
• GDPR & data retention — מחיקה אוטומטית של נתוני לקוח שביקש זאת.

צוות שלא מטפל בארבעת אלה בארכיטקטורה הראשונית מגלה אותם בפרודקשן, וזה הרבה יותר יקר.

שאלות נפוצות

האם Whisper מספיק לעברית?

Whisper הוא נקודת התחלה סבירה אבל לא מספיק לפרודקשן B2B. הדיוק שלו על עברית עסקית טהורה הוא בערך 78–84% (תלוי גרסה), ועל code-switching ומונחי מוצר הוא יורד משמעותית. ראו למה תמלול עברית קשה יותר מאנגלית.

מה ההבדל בין diarization ל-speaker identification?

Diarization מפריד "מי דיבר מתי" בלי לדעת מי. Speaker identification ממפה לזהויות ספציפיות (נציג ספציפי, לקוח רשום). רוב מערכות ה-CI משתמשות בדיאריזציה ומחברות לזהות דרך metadata של המרכזיה.

איך מתמודדים עם code-switching עברית-אנגלית?

זה תחום מאתגר. הגישה הטובה ביותר היום היא מודל STT שאומן ספציפית על code-switching ישראלי טיפוסי — לא לעבור בין מודלים על־פי שפה.

האם זה רץ on-prem או רק בענן?

תלוי בספק. רוב הספקים מציעים cloud-first, חלק מציעים VPC מבודד, וקומץ מציעים מנוע STT שרץ on-prem עם NLP בענן. ב-Nivision יש אפשרויות מותאמות לדרישות אבטחת מידע ישראליות.

מה כדאי לבדוק ב-POC?

שלושה דברים: דיוק WER על שיחות אמיתיות שלכם (לא דמו של הספק), זמן end-to-end מסיום שיחה עד output, ויציבות הקונטרקט (האם השדות עקביים בין שיחות וקריאות?).

רוצים לראות איך זה עובד אצלכם?

Nivision היא פלטפורמת AI ישראלית לתמלול, סיכום וניתוח שיחות בעברית. הפלטפורמה מתאימה לצוותי מכירות, מוקדי שירות וארגונים שרוצים להפוך שיחות טלפון לתמלול מדויק, סיכומי שיחה ותובנות פעולה אוטומטיות. לצוותי R&D יש API מתועד ו-SDK שמתחברים ישירות לצינור הקיים.

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