בדיקת 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 בקוד האפליקציה, כמו בדוגמה הבאה:

Kotlin+KTX

val remoteConfig = FirebaseRemoteConfig.getInstance()

val remoteConfigDefaults = HashMap<String, Any>()
remoteConfigDefaults["plant_labeler_model"] = "plant_labeler_v1"
Tasks.await(remoteConfig.setDefaultsAsync(remoteConfigDefaults))

remoteConfig.fetchAndActivate().addOnSuccessListener { success ->
    if (success) {
      // Okay to get remote values.
      // ...
    }
}

Java

final FirebaseRemoteConfig remoteConfig = FirebaseRemoteConfig.getInstance();

Map<String, Object> remoteConfigDefaults = new HashMap<>();
remoteConfigDefaults.put("plant_labeler_model", "plant_labeler_v1");
Tasks.await(remoteConfig.setDefaultsAsync(remoteConfigDefaults));

remoteConfig.fetchAndActivate().addOnSuccessListener(
        new OnSuccessListener<Boolean>() {
            @Override
            public void onSuccess(Boolean success) {
                if (success) {
                  // Okay to get remote values.
                  // ...
                }
            }
        });

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

Kotlin+KTX

val rcValue = remoteConfig.getValue("plant_labeler_model")
val remoteModelName = rcValue.asString()

// ...

val remoteModel = FirebaseRemoteModel.Builder(remoteModelName)
        .enableModelUpdates(true)
        .setInitialDownloadConditions(initialConditions)
        .setUpdatesDownloadConditions(updateConditions)
        .build()
FirebaseModelManager.getInstance().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

Java

FirebaseRemoteConfigValue rcValue = remoteConfig.getValue("plant_labeler_model");
String remoteModelName = rcValue.asString();

// ...

FirebaseRemoteModel remoteModel = new FirebaseRemoteModel.Builder(remoteModelName)
        .enableModelUpdates(true)
        .setInitialDownloadConditions(initialConditions)
        .setUpdatesDownloadConditions(updateConditions)
        .build();
FirebaseModelManager.getInstance().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 להקצות מודלים שונים למשתמשים שונים לצורך השוואה ביניהם.

לפני שממשיכים, צריך גם להוסיף את הקוד הבא לקובץ של הורדת המודל:

Kotlin+KTX

FirebaseModelManager.getInstance().downloadRemoteModelIfNeeded(remoteModel)
    .addOnSuccessListener {
        // If the model downloaded was specified by a remote parameter, log an
        // event, which will be our experiment's activation event.
        if (rcValue.source == FirebaseRemoteConfig.VALUE_SOURCE_REMOTE) {
            FirebaseAnalytics.getInstance(this).logEvent("nondefault_model_downloaded", null)
        }
    }

Java

FirebaseModelManager.getInstance().downloadRemoteModelIfNeeded(remoteModel)
        .addOnSuccessListener(new OnSuccessListener<Void>() {
            @Override
            public void onSuccess(Void aVoid) {
                // If the model downloaded was specified by a remote parameter, log an
                // event, which will be our experiment's activation event.
                if (rcValue.getSource() == FirebaseRemoteConfig.VALUE_SOURCE_REMOTE) {
                    FirebaseAnalytics.getInstance(YourActivity.this)
                            .logEvent("nondefault_model_downloaded", null);
                }
            }
        });

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

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

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

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

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

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

Kotlin+KTX

FirebaseAnalytics.getInstance(this).logEvent("first_result_opened", null)

Java

FirebaseAnalytics.getInstance(YourActivity.this).logEvent("first_result_opened", null);

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

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

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

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

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

    מסך הגדרת בדיקת A/B

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

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

כרטיס התוצאות של בדיקת A/B

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

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

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

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