פיתוח מערכות NLP: תהליכי עיבוד, מודלים ופריסה

פיתוח מערכות NLP: היכן נפגע הדיוק

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

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

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

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

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

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

מה מניב צינור עיבוד טקסט בנוי

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

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

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

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

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

אפשרויות מימוש: ענן, תשתית עצמית, היברידי

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

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

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

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

שלבי הטמעה: מביקורת נתונים ועד פריסה

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

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

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

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

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

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

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

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

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

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

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

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

במה שונה כיוונון עדין של מודל NLP מאימון מאפס?

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

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

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

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

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

ספקות טכניים: נתונים, תיוג, עומס

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

מה יקרה בעומס שיא?

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

איך מובטחת פרטיות הנתונים?

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

מי אחראי לדריפט באיכות לאחר ההפעלה?

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

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

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

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

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