После обучения новой пользовательской модели вы можете использовать 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/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/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 Store. Ваше приложение продолжит использовать вашу исходную модель, но добавленный вами код Remote Config и аналитики позволит вам экспериментировать с различными моделями, используя только консоль Firebase .
3. Проведите A/B Testing .
Теперь, когда ваше приложение находится в руках пользователей и собирает аналитические данные, создайте эксперимент A/B Testing , который проверит эффект использования вашей новой модели вместо текущей.
Для проведения эксперимента:
На странице «События» в консоли Firebase убедитесь, что вы регистрируете соответствующие события Analytics: событие активации и метрику цели.
Вашему приложению необходимо регистрировать каждое событие как минимум один раз, прежде чем оно отобразится в консоли Firebase .
В консоли Firebase откройте раздел A/B Testing .
Создайте новый эксперимент:
Нажмите «Создать эксперимент» > Remote Config .
В разделе «Целевое наведение» :
- Выберите приложение из списка
- Укажите, сколько пользователей вы хотите включить в эксперимент.
- Выберите событие активации, которое вы начали регистрировать (в этом примере — nondefault_model_downloaded ).
В разделе «Цели» выберите из списка целевых показателей целевую метрику, определенную в предыдущем разделе (в этом примере — first_result_opened ), и выберите любые дополнительные метрики, которые вы хотите отслеживать, например, доход от покупок или количество пользователей без сбоев.
В разделе «Варианты» определите два варианта:
- Контрольная группа (создается автоматически)
- Экспериментальный этикетировщик растений
Для контрольной группы создайте параметр
plant_labeler_modelи установите для него значениеplant_labeler_v1. Пользователи, назначенные в контрольную группу, будут использовать старую модель. (Не устанавливайте параметр в значение(no change), поскольку в вашем приложении вы проверяете использование удаленного значения.)Для экспериментального варианта маркировки растений установите параметр
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 и обновить встроенную модель, если вы её используете. Однако ваши пользователи уже используют последнюю версию модели, поэтому вы можете распространить это обновление в рамках опубликованного приложения в любое удобное для вас время, например, при следующем обновлении функционала.