פיתוח פתרונות רשתות עצביות בהתאמה אישית מקצה לקצה

מדוע פתרונות מבוססי רשתות נוירונים אינם מגיעים לסביבת הייצור

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

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

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

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

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

אפקטים מדידים: זמן עיבוד, שיעור שגיאות, זמן השבתה

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

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

זמן עיבוד הפנייה

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

שיעור ההחלטות ללא בדיקה ידנית

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

סוג השגיאה שנמנעה

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

עמידות בתקלות ובעומס יתר

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

פריקת עומס מהמומחים במשימות אחידות

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

דרכי הטמעה: מודל מוכן, כיוונון עדין, פיתוח עצמי

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

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

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

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

שלבי העבודה: ביקורת נתונים, תרשים, כיול, בדיקה

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

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

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

ארטיפקטים של הפרויקט: תרשימים, קונפיגורציות, נהלים

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

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

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

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

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

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

מה שינינו

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

מה השתנה

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

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

במה נבדלים פתרונות מבוססי רשתות נוירונים מאוטומציה רגילה

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

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

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

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

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

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

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

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

מה עושים אם אין מספיק נתונים לאימון?

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

כיצד נבדקת האיכות לפני המסירה?

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

מה כוללת התמיכה במודל לאחר ההרצה?

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

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

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

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

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

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