הגדרת בדיקות A/B למודלים של ML בייצור

בדיקות A/B של ML: היכן נשבר הפרודקשן

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

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

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

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

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

מה נותן השוואה מנוהלת של מודלים על זרם

מחזור בדיקת השערות מואץ

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

השוואת קבוצות משתמשים במקום ויכוחים

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

מדד איכות אחיד

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

שיעור הפריסות המפסידות יורד

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

פורמטי פריסה: מצב צל, קנרי, A/B מלא

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

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

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

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

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

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

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

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

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

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

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

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

מה היה בקלט

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

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

מה שינינו

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

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

מה קרה

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

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

במה בדיקות A/B של ML שונות משחרור קנרי

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

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

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

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

שאלות על נתונים, מדדים ותשתיות בדיקות

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

תוויות מגיעות בהשהיה — אפשר להאמין לבדיקה?

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

האם צריך מתאר ניסויים נפרד?

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

איך משיגים קבוצות בנות השוואה?

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

נדון במשימה: נבנה תוכנית ניסוי לזרם שלכם

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

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

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