בדיקת 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

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

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

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

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

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

Kotlin

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. בקטע Variants, מגדירים שתי וריאציות:

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

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