בדיקת 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 > Roll out variant (הפעלת הווריאנט) בדף הפרטים של הניסוי. אחרי שתעשו את זה, הערך של הפרמטר plant_labeler_model יהיה plant_labeler_v2 לכל המשתמשים.

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