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à. Une fois que vous avez 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 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'étiquetage d'image personnalisé pour aider les utilisateurs à identifier les espèces des images d'eux.
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épart, vous définirez 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 à pousser des mises à jour d'application à vos utilisateurs à chaque fois.
Par conséquent, si vous avez publié votre modèle actuel sous le nom plant_labeler_v1, vous devez définir 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];
Modifiez ensuite 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-kit/ios/label-images-with-automl#configure-a-local-model-source
// https://firebase.google.com/docs/ml-kit/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-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 dans le but de les comparer.
Avant de continuer, ajoutez également les éléments suivants au téléchargement de votre modèle. code:
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 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 optimiser 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.
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 de la manière dont votre application utilise vos du modèle de ML.
À ce stade, vous pouvez déployer votre application sur l'App 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 apparaisse dans le 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, sélectionnez la métrique correspondant à l'objectif que vous avez déterminé la section précédente (dans cet exemple, first_result_opened) ; dans la liste des métriques d'objectif, puis sélectionnez les métriques supplémentaires que vous que vous souhaitez suivre, comme les revenus issus des achats ou les utilisateurs n'ayant pas subi de 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 permet pas d'identifier la variante optimale, vous devrez peut-être étendez le test à plus 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 les performances de chaque variante en fonction de votre métrique d'objectif et des 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 du 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é.