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

אחרי שמאמנים מודל מותאם אישית חדש או מודל AutoML Vision Edge, אפשר להשתמש 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/label-images-with-automl#configure-a-local-model-source
// 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/label-images-with-automl#configure-a-local-model-source
// 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 עד שהמכשיר שלהם סיימו להוריד את המודל המותאם אישית של למידת מכונה.

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

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

ב-A/B Testing יש כמה מדדים מובנים, כולל הכנסות, התעניינות יומית ושמירת משתמשים. המדדים האלה שימושיים בדרך כלל לבדיקה תהליכים שונים של חוויית המשתמש או כוונון עדין של פרמטרים, אבל ייתכן שיהיו לא הגיוניים הערכת המודל והתרחיש לדוגמה שלכם. במקרה כזה, תוכלו במקום זאת לנסות לבצע אופטימיזציה לאירוע מותאם אישית ב-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. בקטע אירועים בדף במסוף Firebase, יש לוודא שביצעת רישום של המידע הרלוונטי אירועי Analytics: אירוע ההפעלה ומדד היעד.

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

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

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

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

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

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

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

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

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

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

      בשביל הווריאנט מתייג הצמחים הניסיוני, מגדירים את הערך של פרמטר של 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 ועדכון של החבילה אם משתמשים בו. אבל המשתמשים שלך כבר משתמשים במודל העדכני ביותר, לכן אפשר לשלוח את העדכון הזה כחלק מהאפליקציה שפורסמה מתי שנוח לך, למשל, בפעם הבאה שתבצעו עדכון של תכונה.