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

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.
      // ...
    }
}

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:

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/use-custom-models#configure_a_local_model

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/use-custom-models#configure_a_local_model

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

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

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)
        }
    }

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, שתשתמשו בו בהמשך כאירוע ההפעלה של הניסוי. אירוע הפעלה הוא אירוע שהמשתמש צריך להפעיל כדי להיחשב כחלק מהניסוי. כך תוכלו לוודא שהמשתמשים לא יתועדו בבדיקת ה-A/B עד שההורדה של מודל ה-ML המותאם אישית למכשיר שלהם תסתיים.

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

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

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

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

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

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

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, מגדירים שתי וריאציות:

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

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