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 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 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:

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/android/label-images-with-automl#configure-a-local-model-source
// 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/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:

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'événement d'activation du 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 propose plusieurs métriques intégrées, y compris les revenus, l'engagement quotidien et la rétention 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 précision de votre modèle, vous pouvez examiner 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 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 plant_labeler_model et le définir 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 Outil expérimental de libellé de plantes, définissez le paramètre plant_labeler_model sur 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 laissez-le s'exécuter pendant plusieurs jours, jusqu'à ce que A/B Testing déclare un leader. 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 la vue d'informations 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 ou 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 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é.