הגדרת Azure Neural TTS: קולות, SSML, סינתזה בזרימה

למה Azure Neural TTS נשמע כמו רובוט במשפטים חיים

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

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

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

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

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

מה נותנת סינתזת דיבור מכווננת: טון, קצב, טבעיות

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

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

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

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

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

דרכי סינתזת דיבור: השוואת מצבים ומגבלות

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

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

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

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

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

איך מתבצעת התאמת Neural TTS לתרחיש שלכם

כיול סינתזה הוא לא בחירת קול מהקטלוג. Neural TTS נשמע יציב במשפטים ניטרליים ונשבר על מספרים ארוכים, ראשי תיבות, לטינית ושמות — ואלה בדיוק מה שנכנס לרפליקות הכי часто. לכן מתחילים בביקורת של מה שהמערכת תבטא במציאות, ולא בדוגמאות הדגמה.

1. ביקורת תרחישי הקראה. מייצאים טקסטים אמיתיים: רפליקות דיאלוג, מספרי הזמנות, כתובות, יחידות מידה, מונחים. מסמנים סוגי משפטים שנשמעים לא נכון — זו מפת העבודה.
2. התאמת קול וסגנון. משווים מועמדים על אותם משפטים מהמדגם שלכם, ולא על דוגמאות ייחוס של הספק: מקשיבים למקרים הגרועים, לא לטובים.
3. מילון הגייה. מגדירים כללים לראשי תיבות, תאריכים, מספרים, טלפונים ושמות: היכן לקרוא באותיות, היכן בהברות, היכן להחליף הטעמה.
4. סימון SSML. מגדירים הפסקות, קצב, אינטונציה של שאלה וקביעה, החלפת קול בתוך רפליקה — במקום שבו המשמעות חשובה יותר מיציבות הצליל.
5. סינתזה בזרימה. מפצלים את התשובה לקטעים ומוציאים את הראשון לשמע, בלי להמתין לסוף הטקסט: הבוט הקולי מתחיל לדבר מיד, ולא אחרי יצירה מלאה.
6. בדיקת הקראה על משפטים אמיתיים. מריצים מדגם ייחוס, מקשיבים ומקבעים מערך רגרסיה — אחרי כל תיקון במילון הוא נבדק מחדש.
7. מסירת ההגדרות. מוסרים מילונים, תבניות סימון, מדריך קולות ומערך בדיקות: הצוות שלכם מוסיף משפטים חדשים בלי לבנות הכול מחדש.

פרופילי קולות, כללי הגייה ותקנות

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

• סטים של קולות לתרחישים. לכל ערוץ — טלפוניה, הקראת וידאו, התראות קצרות — מקובעים קריין, קצב וסגנון; החלפת קול בערוץ אחד לא פוגעת באחרים.
• מילוני הגיית מונחים. מותגים, ראשי תיבות, מק"טים ויחידות מידה הוצאו מהקוד לקובץ נפרד: תיקון הגייה לא דורש בנייה מחדש של האפליקציה.
• כללי נרמול טקסט. מתואר איך מספרים, תאריכים, לטינית ומקפים הופכים למחרוזת מבוטאת, — כדי שמק"ט «A-1024» לא ייקרא כחיסור.
• סכמת חיבור הסינתזה. לאן פונה שירות-צרכן, איך מועברים מפתחות, היכן הצליל נשמר בבאפר ומה קורה בעת ניתוק קשר או עיכוב בתשובה.
• תקנון הפעלה. מגבלות על נפח תווים, סדר רוטציה של מפתחות, התנהגות בעת דרדור שירות ואחראי על שינויים בהרכב הקולות.
• סט משפטי ייחוס. שלושה-ארבעה עשרות הקלטות עם תוצאה צפויה: אחרי תיקון במילון או בקול, ההרצה מראה מה בדיוק השתנה.

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

מקרה בוחן: איך הסרנו קטיעות ואינטונציה רובוטית

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

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

מה שינינו

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

אחרי השיפור, הקטיעות בזרימה — 0.4% לעומת 12%, שאלות חוזרות — 4%, זמן עד לצליל הראשון — 0.3–0.4 שניות. פניות לתמיכה בנוגע לאיכות ההקראה הצטמצמו פי שלושה, והדיאלוג התחיל להשיב בקצב השיחה, ולא אחרי הפסקה.

במה סינתזה בזרימה שונה מסינתזה באצווה

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

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

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

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

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

שאלות ששואלים לפני כיול הסינתזה

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

מה יקרה לסינתזה שכבר מכווננת בעת מיגרציה?

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

היכן תושמע ההקראה — בכל המכשירים?

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

מי מכין את הטקסטים להקראה?

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

מי אחראי להגיית שמות ומונחים?

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

נדון במשימת סינתזת הדיבור עבור המוצר שלכם

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

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

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