אינטגרציה של FLAML (Microsoft) עבור AutoML מהיר

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

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

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

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

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

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

מה נותנים בחירה אוטומטית של מודלים וכיול

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

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

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

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

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

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

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

אינטגרציה של FLAML: מצבי הרצה ומתי כל אחד מתאים

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: קיצרנו את מחזור האימון והסרנו את הסריקה הידנית

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

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

מה שינו

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

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

מדידות לפני ואחרי

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

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

במה נבדלת בחירה אוטומטית מסריקה ידנית

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

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

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

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

שאלות של מהנדסים: נתונים, שחזוריות ועומס

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

האם התוצאה תהיה זהה אם מריצים את האימון מחדש?

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

הנתונים יושבים במערכות שונות: טבלאות, יומנים, טקסט

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

האם ניתן להוציא חלק מהאלגוריתמים מהחיפוש?

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

האימון לא יפיל שירותים פעילים?

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

מה קורה למודל לאחר ההטמעה?

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

נדון במשימה: כיצד להריץ בחירה אוטומטית של מודלים

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

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

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