אימון XGBoost, LightGBM, CatBoost על נתונים טבלאיים

אימון מודל על נתונים טבלאיים: היכן האיכות הולכת לאיבוד

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

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

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

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

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

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

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

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

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

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

דרכי בנייה: צינור אצווה, זרימה והיברידי

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

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

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

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

אימון מודל: שלבי עבודת הנדסה מהנתונים ועד למסירה

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

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

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

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

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

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

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

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

מה שינו

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

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

מה קרה

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

במה שונה אימון מחדש לפי לוח זמנים מעדכון על זרימה

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

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

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

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

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

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

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

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

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

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

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

התשובה הנכונה מגיעה באיחור — האם זה שובר את האימון?

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

מי תומך בפתרון אחרי ההפעלה?

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

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

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

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

מה מבהירים בשלב הזה:

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

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