אחרי שאתם מארגנים מודל מותאם אישית חדש או מודל 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 מותאם אישית, שבו תשתמשו מאוחר יותר בתור
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 כדי לבדוק את ההשפעה של השימוש במודל החדש במקום במודל הנוכחי.
כדי ליצור את הניסוי:
-
בדף Events במסוף Firebase, מוודאים שהאירועים הרלוונטיים ב-Analytics מתועדים ביומן: אירוע ההפעלה ומדד היעד.
האפליקציה צריכה לתעד כל אירוע לפחות פעם אחת לפני שהוא יופיע במסוף Firebase.
-
במסוף Firebase, פותחים את הקטע A/B Testing.
-
יוצרים ניסוי חדש:
לוחצים על יצירת ניסוי > Remote Config.
-
בקטע טירגוט:
- בוחרים את האפליקציה מהרשימה.
- מציינים כמה מהמשתמשים רוצים לכלול בניסוי
- בוחרים את אירוע ההפעלה שהתחלתם לתעד (בדוגמה הזו, nondefault_model_downloaded)
-
בקטע יעדים, בוחרים את מדד היעד שציינתם בקטע הקודם (בדוגמה הזו, first_result_opened) מרשימת מדדי היעד, ובוחרים מדדים נוספים שאחריהם אתם רוצים לעקוב, כמו הכנסות מרכישות או משתמשים ללא קריסות.
-
בקטע Variants, מגדירים שתי וריאציות:
- קבוצת בקרה (נוצרת באופן אוטומטי)
- ניסוי לסימון צמחים
לקבוצת הבקרה, יוצרים פרמטר
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
ולעדכן את המודל המצורף, אם אתם משתמשים בו. עם זאת, המשתמשים שלכם כבר משתמשים בגרסת העדכון האחרונה, כך שתוכלו לדחוף את העדכון הזה כחלק מהאפליקציה שפורסמה מתי שנוח לכם, למשל בפעם הבאה שתבצעו עדכון תכונות.