בדיקת 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. בקטע אירועים בדף במסוף 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

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