Cette page a été traduite par l'API Cloud Translation.

Effectuer des tests A/B sur deux versions d'un modèle

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 explique comment effectuer un test A/B qui évalue deux versions d'un modèle qui alimente une fonctionnalité de recherche visuelle de plantes hypothétique. 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. Les étapes ci-dessous vous montrent comment configurer le test, l'exécuter et prendre des mesures en fonction des résultats.

1. Rendre votre modèle configurable à distance

La première étape des tests A/B sur vos modèles consiste à modifier votre application pour utiliser un Remote Config pour déterminer le modèle qu'il 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:

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 les 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/label-images-with-automl#configure-a-local-model-source
// 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/label-images-with-automl#configure-a-local-model-source
// 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 le modifier simplement en publiant un nouveau modèle et en lui attribuant son nom 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:

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 comme événement d'activation de votre test. Un événement d'activation est un événement l'utilisateur doit déclencher le test avant que celui-ci ne soit considéré comme faisant partie du test. Ce garantit que les utilisateurs ne seront pas enregistrés dans votre test A/B tant que leur appareil n'aura pas ont fini de télécharger leur modèle de ML personnalisé.

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 disponible et collecte des données analytiques, créez un test A/B Testing qui évalue l'effet de l'utilisation de votre nouveau 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:
1. Cliquez sur Créer un test > Remote Config.
2. 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).
3. 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.
4. 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 paramètre plant_labeler_model et définissez-le sur plant_labeler_v1. Utilisateurs 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_model au paramètre plant_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 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 > Déployer la variante 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 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. 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é.