בדיקת A/B של שתי גרסאות של מודל

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

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

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

1. הגדרת המודל מרחוק

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

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

let remoteConfig = RemoteConfig.remoteConfig()
let defaults = [
    "plant_labeler_model": "plant_labeler_v1" as NSObject,
    // ...
]
remoteConfig.setDefaults(defaults)
remoteConfig.fetchAndActivate()

FIRRemoteConfig *remoteConfig = [FIRRemoteConfig remoteConfig];
NSDictionary<NSString *, NSObject *> *defaults = @{
  @"plant_labeler_model" : (NSObject *)@"plant_labeler_v1",
  // ...
};
[remoteConfig setDefaults:defaults];
[remoteConfig fetchAndActivateWithCompletionHandler:nil];

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

let rcValue = remoteConfig.configValue(forKey: "plant_labeler_model")
guard let remoteModelName = rcValue.stringValue else { return }

// ...

let remoteModel = RemoteModel(
    name: remoteModelName,
    allowsModelUpdates: true,
    initialConditions: initialConditions,
    updateConditions: updateConditions
)
ModelManager.modelManager().register(remoteModel)

// Optionally configure a local model:
// https://firebase.google.com/docs/ml/ios/use-custom-models#configure_a_local_model

FIRRemoteConfigValue *rcValue = [remoteConfig configValueForKey:@"plant_labeler_model"];
NSString *remoteModelName = [rcValue stringValue];

// ...

FIRRemoteModel *remoteModel = [[FIRRemoteModel alloc] initWithName:remoteModelName
                                                allowsModelUpdates:YES
                                                 initialConditions:initialConditions
                                                  updateConditions:updateConditions];
[[FIRModelManager modelManager] registerRemoteModel:remoteModel];

// Optionally configure a local model:
// https://firebase.google.com/docs/ml/android/use-custom-models#configure_a_local_model

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

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

NotificationCenter.default.addObserver(
    forName: .firebaseMLModelDownloadDidSucceed,
    object: nil,
    queue: nil
) { [weak self] notification in
    guard let _ = self,
        let userInfo = notification.userInfo,
        let model = userInfo[ModelDownloadUserInfoKey.remoteModel.rawValue]
            as? RemoteModel,
        model.name == remoteModelName
        else { return }
    // If the model downloaded was specified by a remote parameter, log an
    // event, which will be our experiment's activation event.
    if rcValue.source == .remote {
        Analytics.logEvent("nondefault_model_downloaded", parameters: nil)
    }
}

__weak typeof(self) weakSelf = self;

[NSNotificationCenter.defaultCenter
    addObserverForName:FIRModelDownloadDidSucceedNotification
                object:nil
                 queue:nil
            usingBlock:^(NSNotification *_Nonnull note) {
              if (weakSelf == nil | note.userInfo == nil) {
                return;
              }

              FIRRemoteModel *model = note.userInfo[FIRModelDownloadUserInfoKeyRemoteModel];
              if ([model.name isEqualToString:remoteModelName] &&
                  rcValue.source == FIRRemoteConfigSourceRemote) {
                // If the model downloaded was specified by a remote parameter, log an
                // event, which will be our experiment's activation event.
                [FIRAnalytics logEventWithName:@"nondefault_model_downloaded" parameters:nil];
              }
            }];

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

2. קביעת מדד יעד

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

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

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

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

Analytics.logEvent("first_result_opened", parameters: nil)

[FIRAnalytics logEventWithName:@"first_result_opened" parameters:nil];

המדד שאתם בודקים תלוי בסופו של דבר באופן השימוש של האפליקציה במודל.

בשלב הזה, אפשר לפרוס את האפליקציה ב-App Store. האפליקציה תמשיך להשתמש במודל המקורי, אבל הקוד של Remote Config ו-Analytics שהוספתם יאפשר לכם להתנסות במודלים שונים באמצעות מסוף Firebase בלבד.

3. הפעלת ניסוי A/B Testing

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

כדי ליצור את הניסוי:

1. בדף Events (אירועים) במסוף Firebase, מוודאים שאתם מתעדים את האירועים הרלוונטיים ב-Analytics: אירוע ההפעלה ומדד היעד.

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

2. במסוף Firebase, פותחים את הקטע A/B Testing.

3. כדי ליצור ניסוי חדש:

   1. לוחצים על יצירת ניסוי > Remote Config.

   2. בקטע טירגוט:

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

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

   4. בקטע Variants, מגדירים שתי וריאציות:

      • קבוצת בקרה (נוצרת באופן אוטומטי)
      • סיווג צמחים ניסיוני

      בקבוצת הבקרה Control group, יוצרים פרמטר plant_labeler_model ומגדירים אותו לערך plant_labeler_v1. משתמשים שמשויכים לקבוצת הבקרה ישתמשו במודל הישן. (אל תגדירו את הפרמטר כ-(no change), כי באפליקציה אתם בודקים שאתם משתמשים בערך מרוחק).

      בווריאנט Experimental plant labeler, מגדירים את הפרמטר plant_labeler_model לערך plant_labeler_v2 (בהנחה שפרסמתם את המודל החדש בשם הזה). משתמשים שמשויכים לווריאנט הזה ישתמשו במודל החדש.

   

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

4. מפעילים את הווריאנט המנצח לכל המשתמשים

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

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

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

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