Azure Speech Services: שילוב STT ו-Custom Speech

מדוע Azure Speech Services טועה בהקלטות חיות

המודל הכללי לזיהוי דיבור אומן על דיבור נקי של קריין, אך בעבודה הוא מקבל ארכיון של שיחות אמיתיות. ערוץ טלפוני צר-פס, דחיסה, הד מהרמקול, רעש משרד ומוזיקה בהמתנה מורידים את הבהירות עוד לפני שהאות מגיע למודל — ו-Azure Speech Services בקלט כזה מפיק מילים שגויות בביטחון במקום מקום ריק.

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

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

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

האפקט מההתאמה: דיוק, מהירות, ניתוח ארכיון

התאמת זיהוי דיבור נותנת שינוי צפוי אם המדדים נקבעים לפני תחילת העבודה. אנו מחשבים שלושה: שיעור המילים שזוהו שגוי בקבוצת ביקורת, זמן העיבוד של הארכיון שנצבר ושיעור ההקלטות שנכנסות לעבודה ללא תיקון ידני. להלן — מדדים שאנו רואים בפרויקטים לאחר התאמת Azure Speech Services ללקסיקון התחומי.

השינוי נובע לא מ'התאמה באופן כללי', אלא משני מנופים: המודל מאומן מחדש על ההקלטות שלכם, והמודל הלשוני — על מילון מונחים, ראשי תיבות ושמות. לכן האיכות עולה דווקא במקומות שבהם המודל הבסיסי טעה הכי הרבה.

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

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

מצבי Azure Speech: זרם, ארכיון, אימון מחדש של המודל

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

אימון מחדש של מודל זיהוי — אינו מצב שלישי לצד השניים, אלא שכבה מעל שניהם.

מודל תחומי עם ראשי תיבות, שמות מוצרים ולקסיקון ייחודי משרת גם את הזרם החי וגם את הארכיון, ולכן הווריאציות משתלבות במתאר אחד: Azure Speech Services מספק זרם, אצווה ומודלים מותאמים אישית דרך גישה אחת, והמעבר ביניהם אינו מחייב כתיבה מחדש של האינטגרציה.

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

כיצד נבנית ההטמעה: מפיילוט ועד מסירה

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

1. ניתוח המשימה והאודיו. מאחדים את מקורות הקול (טלפוניה, מיקרופונים, ארכיונים), רמת הרעש, מספר הדוברים והשהיה המותרת. בפלט — רשימת תרחישים שהמערכת חייבת לכסות.

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

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

4. התאמת המודל לתחום. על Azure Speech Services מאמנים מחדש את האקוסטיקה והמודל הלשוני על מונחים, ראשי תיבות ושמות שהמנוע הכללי שומע לא נכון; בנפרד מגדירים פורמט למספרים ותאריכים.

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

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

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

קונפיגורציות, מילונים ומדיניות גישה לשירות

חפצי ההתאמה נשארים במתאר של הלקוח: אנו מוסרים לא 'שירות מוגדר', אלא ערכה משוכפלת של קונפיגורציות. Azure Speech Services — שכבת בסיס, ומעליה חיים פרופילי מודלים, מילונים וכללי גישה: ניתן להרכיבם מחדש, לבדוק ולבטל ללא השתתפותנו.

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

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

מקרה בוחן: תמלול ארכיון פניות בשבוע

פנה אלינו מוקד שירות עם ארכיון פניות: כ-40,000 שעות אודיו על פני מספר שנים, חלק מההקלטות באיכות נמוכה ועם קולות חופפים.

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

עבדנו על Microsoft Azure: אספנו קורפוס של 40 שעות אודיו עם תיוג ידני, בנפרד תייגנו ישויות — מספרי הזמנות, קודי שירותים, שמות תעריפים.

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

על מדגם בדיקה נפרד, שיעור השגיאות במילים ירד מ-28% ל-11%, ובישויות מפתח — עד 4%: מספרי הזמנות ושמות שירותים מזוהים כמעט ללא תיקונים. ארכיון של 40,000 שעות עבר עיבוד בשבוע באמצעות משימות מקבילות, שיעור הקטעים שנאלצו לשלוח מחדש עקב תקלה — פחות מ-1%. החיפוש בתמלולים החל למצוא שיחות לפי אזכור השירות, ולא לפי תאריך השיחה.

במה שונה אימון מחדש של המודל מהגרסה הבסיסית?

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

ב-Azure Speech Services ההתאמה מחולקת לשתי שכבות בלתי תלויות. הלשונית נשענת על קורפוס טקסטואלי — תמלולים, מילון מונחים, רשימת ביטויים — ומתקנת את הלקסיקון: מונחים מורכבים, מקטעים, שמות.

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

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

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

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

ספקות טכניים נפוצים לפני תחילת הפרויקט

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

אודיו לא אמור לצאת מהמתאר הסגור — האם זה בר ביצוע?

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

כיצד לבדוק את איכות הזיהוי לפני ההטמעה?

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

הטרמינולוגיה התחומית משתנה — האם צריך לעשות הכל מחדש?

לא. רשימות הביטויים והמילונים מתעדכנים בנפרד מהאינטגרציה, ואימון מחדש של המודל — הליך תקנוני עם אותה בדיקה על מדגם ביקורת. אנו עובדים עם Azure Speech Services ומנועים תואמים, לכן החלפה או אימון מחדש של המודל לא שוברים את לוגיקת האפליקציה ואת תרחישי העיבוד.

נדון במשימה: מה נדרש כדי להתחיל לעבוד

כדי לדון במשימת זיהוי הדיבור באופן ענייני, כדאי לאסוף כמה דברים לשיחה. לפיהם מיד רואים אם המודל הבסיסי מספיק או שיש צורך באימון Custom Speech על הנתונים שלכם, ומתהווה היקף העבודה.

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.