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

לאחר שתכשיר דגם מותאם אישית חדש או דגם AutoML Vision Edge, תוכל להשתמש ב-A/B Testing כדי לראות עד כמה הדגם החדש מתפקד בתנאים אמיתיים, בהשוואה לדגם שבו אתה כבר משתמש. לאחר שתאשר שהדגם החדש שלך הוא שיפור, תוכל להפיץ את הדגם החדש בקלות לכל המשתמשים שלך, מבלי לדרוש עדכון אפליקציה.

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

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

1. הפוך את הדגם שלך לניתן להגדרה מרחוק

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

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

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

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

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

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

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

Kotlin+KTX

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

Java

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

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

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

3. הפעל ניסוי A/B Testing

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

כדי ליצור את הניסוי:

  1. בדף האירועים של מסוף Firebase, ודא שאתה רושם את אירועי Analytics הרלוונטיים: אירוע ההפעלה ומדד היעד.

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

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

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

    1. לחץ על צור ניסוי > תצורה מרחוק .

    2. בקטע מיקוד :

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

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

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

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

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