Après avoir entraîné un nouveau modèle personnalisé ou AutoML Vision Edge, vous pouvez utiliser A/B Testing pour voir les performances du nouveau modèle en conditions réelles ; par rapport au modèle que vous utilisez déjà. Après avoir vérifié que votre nouveau modèle est une amélioration, vous pouvez facilement déployer le nouveau modèle pour tous vos utilisateurs, sans avoir à mettre à jour l'application.
Cette page vous explique comment effectuer un test A/B pour évaluer deux versions. d'un modèle qui alimente une fonction hypothétique de recherche visuelle de plantes. Cette fonctionnalité utilise un modèle d'ajout d'étiquettes aux images personnalisé pour aider les utilisateurs à identifier des espèces de plantes à partir d'images.
Supposons que vous veniez de publier
un nouveau modèle d'étiquetage de plantes,
plant_labeler_v2 et vous souhaitez effectuer un test afin de le comparer
avec votre modèle actuel, nommé plant_labeler_v1. Procédure à suivre
vous verrez comment configurer le test, l'exécuter et agir en fonction des résultats.
1. Rendre votre modèle configurable à distance
La première étape des tests A/B de vos modèles consiste à modifier votre application pour qu'elle utilise un paramètre Remote Config afin de déterminer le modèle qu'elle utilise. Au début, vous définira la valeur par défaut de ce paramètre comme étant le modèle utilisé par votre application l'utilise déjà, mais comme le nom du modèle est contrôlé par un configurable, vous pouvez modifier et tester différents modèles sans avoir à envoyer chaque fois des mises à jour à vos utilisateurs.
Si vous avez publié votre modèle actuel sous le nom
plant_labeler_v1, vous devez, dans le code d'initialisation de votre application, définir
plant_labeler_v1 comme valeur par défaut de
plant_labeler_model, comme dans l'exemple suivant:
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.
// ...
}
}
});
Modifiez ensuite le code de configuration de votre modèle pour charger le modèle spécifié par le paramètre 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-kit/android/label-images-with-automl#configure-a-local-model-source
// https://firebase.google.com/docs/ml-kit/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-kit/android/label-images-with-automl#configure-a-local-model-source
// https://firebase.google.com/docs/ml-kit/android/use-custom-models#configure_a_local_model
Maintenant que votre application utilise un paramètre Remote Config pour déterminer le modèle à utiliser vous pouvez le modifier, en publiant un nouveau modèle et en lui attribuant au paramètre Remote Config. Cette fonctionnalité permet à A/B Testing d'attribuer différents modèles à différents utilisateurs afin de les comparer.
Avant de continuer, ajoutez également les éléments suivants au téléchargement de votre modèle. code:
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);
}
}
});
Le code ci-dessus enregistre un événement Analytics personnalisé que vous utiliserez plus tard en tant que
l'
2. Déterminer une métrique correspondant à l'objectif
L'étape suivante consiste à décider comment vous allez mesurer le succès de votre modèle, et vous assurer que votre application collecte les données nécessaires pour tester l'efficacité différentes versions du modèle fonctionnent en fonction de cette métrique.
A/B Testing intègre plusieurs métriques quotidiennes, y compris les revenus l'engagement et la fidélisation des utilisateurs. Ces métriques sont souvent utiles pour tester différents flux d'expérience utilisateur ou des paramètres d'ajustement, mais qui n'ont peut-être pas de sens pour à évaluer votre modèle et votre cas d'utilisation. Dans ce cas, vous pouvez essayer d'optimiser pour un événement Analytics personnalisé.
En utilisant la fonction de recherche visuelle hypothétique de plantes comme exemple, supposons que les résultats de recherche présentés à l'utilisateur selon le niveau de confiance du modèle chaque résultat. Pour vous faire une idée de la justesse de votre modèle, en fonction de la fréquence à laquelle les utilisateurs ont ouvert le premier résultat de recherche.
Afin d'identifier le modèle qui a le mieux réalisé l'objectif de maximisation des clics dans les meilleurs résultats, vous consignez un événement personnalisé chaque fois qu'un utilisateur appuie sur le premier élément du résultat. liste.
Kotlin+KTX
FirebaseAnalytics.getInstance(this).logEvent("first_result_opened", null)
Java
FirebaseAnalytics.getInstance(YourActivity.this).logEvent("first_result_opened", null);
La métrique que vous testez dépend de la manière dont votre application utilise vos du modèle de ML.
À ce stade, vous pouvez déployer votre application sur le Play Store. Votre application continuera à utiliser votre modèle d'origine, Toutefois, le Remote Config et le code Analytics que vous avez ajoutés vous permettront de tester avec des modèles différents en utilisant uniquement la console Firebase.
3. Effectuer un test A/B Testing
Maintenant que votre application est entre les mains de vos utilisateurs et collecte des données analytiques, créez un test A/B Testing qui teste l'effet de l'utilisation de votre nouveau modèle au lieu du modèle actuel.
Pour créer le test:
-
Sur la page Événements, de la console Firebase, vérifiez que vous consignez bien Événements Analytics: événement d'activation et métrique d'objectif.
Votre application doit consigner chaque événement au moins une fois avant qu'il n'apparaisse dans la console Firebase.
-
Dans la console Firebase, ouvrez la section A/B Testing.
-
Créez un test :
Cliquez sur Créer un test > Remote Config.
-
Dans la section Ciblage :
- Sélectionnez votre application dans la liste
- Spécifiez le nombre d'utilisateurs à inclure dans le test
- Sélectionnez l'événement d'activation que vous avez commencé à enregistrer (dans cet exemple, nondefault_model_downloaded)
-
Dans la section Objectifs, choisissez la métrique d'objectif que vous avez déterminée dans la section précédente (first_result_opened dans cet exemple) dans la liste des métriques d'objectif, puis sélectionnez les métriques supplémentaires que vous souhaitez suivre, telles que les revenus issus des achats ou les utilisateurs sans plantage.
-
Dans la section Variantes, définissez deux variantes:
- Groupe de contrôle (créé automatiquement)
- Étiqueteur expérimental de plantes
Pour le groupe de contrôle, créez un
plant_labeler_modelet le définir surplant_labeler_v1Utilisateurs affectés au groupe de contrôle utilisent l'ancien modèle. (Ne définissez pas le paramètre sur(no change), car dans votre application, vous testez l'utilisation d'un la valeur distante.)Pour la variante Étiqueteur de plantes expérimental, définissez la valeur
plant_labeler_modelau paramètreplant_labeler_v2(en supposant que vous ayez publié votre nouveau modèle sous ce nom). Les utilisateurs affectés à cette variante utiliseront la nouvelle du modèle de ML.
Lancez le test et exécutez-le pendant plusieurs jours, jusqu'à A/B Testing déclare une variante optimale. Si le test ne parvient pas à déterminer un gagnant, vous devrez peut-être étendre le test à un plus grand nombre d'utilisateurs.
4. Déployez la variante la plus performante auprès de tous les utilisateurs.
Une fois que A/B Testing a collecté suffisamment d'informations pour déclarer un "Leader" (dans ce cas, la variante qui optimise les résultats de recherche en haut de page). clics), vous pouvez décider de déployer la variante gagnante (ou une autre variante) à tous vos utilisateurs.
Dans la section A/B Testing de la console Firebase, ouvrez les détails. du test terminé. Dans cette vue, vous pouvez voir comment chaque variante selon la métrique de votre objectif et les métriques secondaires que vous avez sélectionnées. Grâce à ces informations, vous pouvez décider de déployer la variante principale une autre variante.
Pour déployer une variante auprès de tous les utilisateurs, cliquez sur
more_vert > Déployez la variante sur la
sur la page d'informations du test. Une fois cette opération effectuée, la valeur
Le paramètre plant_labeler_model sera plant_labeler_v2
pour tous les utilisateurs.
Lors d'une prochaine mise à jour d'application, vous devrez modifier la valeur par défaut
Définissez le paramètre plant_labeler_model sur plant_labeler_v2 et mettez à jour le groupe
si vous en utilisez un. Toutefois, vos utilisateurs disposent déjà du dernier modèle.
vous pouvez intégrer cette mise à jour
dans l'application publiée à tout moment.
comme la prochaine mise à jour d'une fonctionnalité.