הגדרת אימון מחדש אוטומטי של מודל מסחר ב-LightGBM

למה מודל מסחר מתדרדר בלי אימון מחדש אוטומטי

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

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

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

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

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

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

האפקט של עדכון שוטף של מודל המסחר

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

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

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

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

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

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

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

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

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

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

מה לקחת בחשבון בבחירה

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

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

כיצד אנו בונים אימון מחדש אוטומטי

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

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

תצורות, סכימות ונהלים במסירה

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

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

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

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

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

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

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

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

מה שינו

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

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

מטריקות לפני ואחרי

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

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

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

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

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

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

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

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

מה מהנדסים בדרך כלל מבררים לפני ההתחלה

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

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

כמה נתונים נדרשים בקלט?

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

כיצד מופרדות הסביבות?

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

מה אם האיכות ירדה לאחר אימון מחדש?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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

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