Une fois que vous avez entraîné un nouveau modèle personnalisé, vous pouvez utiliser A/B Testing pour voir ses performances en conditions réelles, par rapport au modèle que vous utilisez déjà. Après avoir confirmé que votre nouveau modèle est une amélioration, vous pouvez facilement le déployer auprès de tous vos utilisateurs, sans avoir à mettre à jour l'application.
Cette page explique comment effectuer un test A/B qui évalue deux versions d'un modèle qui alimente une fonctionnalité hypothétique de recherche visuelle de plantes. Cette fonctionnalité utilise un modèle personnalisé de libellisation d'images pour aider les utilisateurs à identifier les espèces de plantes à partir de leurs images.
Supposons que vous venez de publier un nouveau modèle de libellisation de plantes, plant_labeler_v2, et que vous souhaitez exécuter un test qui le compare à votre modèle actuel, nommé plant_labeler_v1. Les étapes ci-dessous montrent 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 pour tester vos modèles A/B consiste à modifier votre application afin qu'elle utilise un Remote Config paramètre pour déterminer le modèle à utiliser. Au départ, vous définissez la valeur par défaut de ce paramètre sur le modèle que votre application utilise déjà. Toutefois, comme le nom du modèle est contrôlé par un paramètre configurable à distance, vous pouvez modifier et tester différents modèles sans avoir à envoyer de mises à jour d'application à vos utilisateurs à chaque fois.
Ainsi, si vous avez publié votre modèle actuel sous le nom plant_labeler_v1, vous définissez plant_labeler_v1 comme valeur par défaut du paramètre plant_labeler_model dans le code d'initialisation de votre application, comme dans l'exemple suivant :
Swift
let remoteConfig = RemoteConfig.remoteConfig()
let defaults = [
"plant_labeler_model": "plant_labeler_v1" as NSObject,
// ...
]
remoteConfig.setDefaults(defaults)
remoteConfig.fetchAndActivate()
Objective-C
FIRRemoteConfig *remoteConfig = [FIRRemoteConfig remoteConfig];
NSDictionary<NSString *, NSObject *> *defaults = @{
@"plant_labeler_model" : (NSObject *)@"plant_labeler_v1",
// ...
};
[remoteConfig setDefaults:defaults];
[remoteConfig fetchAndActivateWithCompletionHandler:nil];
Ensuite, modifiez le code de configuration de votre modèle pour charger le modèle spécifié par le paramètre plant_labeler_model :
Swift
let rcValue = remoteConfig.configValue(forKey: "plant_labeler_model")
guard let remoteModelName = rcValue.stringValue else { return }
// ...
let remoteModel = RemoteModel(
name: remoteModelName,
allowsModelUpdates: true,
initialConditions: initialConditions,
updateConditions: updateConditions
)
ModelManager.modelManager().register(remoteModel)
// Optionally configure a local model:
// https://firebase.google.com/docs/ml/ios/use-custom-models#configure_a_local_model
Objective-C
FIRRemoteConfigValue *rcValue = [remoteConfig configValueForKey:@"plant_labeler_model"];
NSString *remoteModelName = [rcValue stringValue];
// ...
FIRRemoteModel *remoteModel = [[FIRRemoteModel alloc] initWithName:remoteModelName
allowsModelUpdates:YES
initialConditions:initialConditions
updateConditions:updateConditions];
[[FIRModelManager modelManager] registerRemoteModel:remoteModel];
// Optionally configure a local model:
// https://firebase.google.com/docs/ml/android/use-custom-models#configure_a_local_model
Maintenant que votre application utilise un paramètre Remote Config pour déterminer le modèle à charger, vous pouvez modifier le modèle en publiant simplement un nouveau modèle et en attribuant son nom au paramètre Remote Config. Cette fonctionnalité permet aux 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 code de téléchargement de votre modèle :
Swift
NotificationCenter.default.addObserver(
forName: .firebaseMLModelDownloadDidSucceed,
object: nil,
queue: nil
) { [weak self] notification in
guard let _ = self,
let userInfo = notification.userInfo,
let model = userInfo[ModelDownloadUserInfoKey.remoteModel.rawValue]
as? RemoteModel,
model.name == remoteModelName
else { return }
// If the model downloaded was specified by a remote parameter, log an
// event, which will be our experiment's activation event.
if rcValue.source == .remote {
Analytics.logEvent("nondefault_model_downloaded", parameters: nil)
}
}
Objective-C
__weak typeof(self) weakSelf = self;
[NSNotificationCenter.defaultCenter
addObserverForName:FIRModelDownloadDidSucceedNotification
object:nil
queue:nil
usingBlock:^(NSNotification *_Nonnull note) {
if (weakSelf == nil | note.userInfo == nil) {
return;
}
FIRRemoteModel *model = note.userInfo[FIRModelDownloadUserInfoKeyRemoteModel];
if ([model.name isEqualToString:remoteModelName] &&
rcValue.source == FIRRemoteConfigSourceRemote) {
// If the model downloaded was specified by a remote parameter, log an
// event, which will be our experiment's activation event.
[FIRAnalytics logEventWithName:@"nondefault_model_downloaded" parameters:nil];
}
}];
Le code ci-dessus enregistre un événement Analytics personnalisé que vous utiliserez ultérieurement comme votre
événement d'
2. Déterminer une métrique d'objectif
L'étape suivante consiste à déterminer 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 les performances des différentes versions du modèle en fonction de cette métrique.
A/B Testing comporte plusieurs métriques intégrées, y compris les revenus, l'engagement quotidien et la fidélisation des utilisateurs. Ces métriques sont souvent utiles pour tester différents flux d'expérience utilisateur ou affiner les paramètres, mais elles ne sont peut-être pas pertinentes pour évaluer votre modèle et votre cas d'utilisation. Dans ce cas, vous pouvez essayer d'optimiser un événement Analytics personnalisé.
En utilisant la fonctionnalité hypothétique de recherche visuelle de plantes comme exemple, supposons que vous présentiez les résultats de recherche à votre utilisateur dans l'ordre de la confiance du modèle dans chaque résultat. Vous pouvez vous faire une idée de la précision de votre modèle en examinant la fréquence à laquelle les utilisateurs ont ouvert le premier résultat de recherche.
Pour tester le modèle qui a le mieux atteint l'objectif de maximisation des clics sur le premier résultat, vous enregistrez un événement personnalisé chaque fois qu'un utilisateur appuie sur le premier élément de la liste de résultats.
Swift
Analytics.logEvent("first_result_opened", parameters: nil)
Objective-C
[FIRAnalytics logEventWithName:@"first_result_opened" parameters:nil];
La métrique que vous testez dépend en fin de compte de la façon dont votre application utilise votre modèle.
À ce stade, vous pouvez déployer votre application sur l'App Store. Votre application continuera à utiliser votre modèle d'origine, mais le code Remote Config et Analytics que vous avez ajouté vous permettra de tester différents modèles à l'aide de la console Firebase.
3. Exécuter une expérience A/B Testing
Maintenant que votre application est entre les mains de vos utilisateurs et qu'elle collecte des données Analytics, créez une expérience 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 enregistrez les événements Analytics pertinents : l'événement d'activation et la métrique d'objectif.
Votre application doit enregistrer chaque événement au moins une fois avant qu'il n'apparaisse dans la Firebase console.
-
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 :
- Choisissez votre application dans la liste.
- Spécifiez le nombre d'utilisateurs que vous souhaitez 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 (dans cet exemple, first_result_opened) dans la liste des métriques d'objectif, puis sélectionnez toutes les métriques supplémentaires que vous souhaitez suivre, telles que les revenus générés par les achats ou les utilisateurs sans plantage.
-
Dans la section Variantes, définissez deux variantes :
- Groupe témoin (créé automatiquement)
- Libellisation expérimentale des plantes
Pour le groupe témoin, créez un
plant_labeler_modelparamètre et définissez-le surplant_labeler_v1. Les utilisateurs attribués au groupe témoin utiliseront l'ancien modèle. (Ne définissez pas le paramètre sur(no change), car dans votre application, vous testez que vous utilisez une valeur à distance.)Pour la variante Libellisation expérimentale des plantes, définissez le paramètre
plant_labeler_modelsurplant_labeler_v2(en supposant que vous avez publié votre nouveau modèle sous ce nom). Les utilisateurs attribués à cette variante utiliseront le nouveau modèle.
Démarrez le test et laissez-le s'exécuter pendant plusieurs jours ou plus, jusqu'à ce que A/B Testing déclare un leader. Si le test ne peut pas déterminer de leader, vous devrez peut-être l'étendre à davantage d'utilisateurs.
4. Déployer la variante gagnante 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 a maximisé les clics sur le premier résultat de recherche) , vous pouvez décider de déployer la variante gagnante (ou une autre variante) auprès de tous vos utilisateurs.
Dans la section A/B Testing de la console Firebase, ouvrez la vue détaillée du test terminé. Dans cette vue, vous pouvez voir les performances de chaque variante en fonction de votre métrique d'objectif et de toutes les métriques secondaires que vous avez sélectionnées. Grâce à ces informations, vous pouvez décider de déployer la variante principale ou une autre variante.
Pour déployer une variante auprès de tous les utilisateurs, cliquez sur
more_vert > Déployer la variante sur la page de détails du test. Une fois que vous avez effectué cette opération, la valeur du paramètre plant_labeler_model sera plant_labeler_v2 pour tous les utilisateurs.
Lors d'une future mise à jour de l'application, vous devez remplacer la valeur par défaut du paramètre plant_labeler_model par plant_labeler_v2 et mettre à jour le modèle groupé si vous en utilisez un. Vos utilisateurs utilisent déjà le dernier modèle. Vous pouvez donc envoyer cette mise à jour dans le cadre de l'application publiée quand vous le souhaitez, par exemple lors de la prochaine mise à jour d'une fonctionnalité.