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

Après avoir entraîné un nouveau modèle personnalisé ou un modèle AutoML Vision Edge, vous pouvez utiliser A/B Testing pour évaluer les performances du nouveau modèle dans des 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 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 venez de publier un nouveau modèle d'étiquetage des plantes, plant_labeler_v2, et que vous souhaitiez exécuter un test le comparant à 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 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 vers 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:

Kotlin

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

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 à 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 dans le but de les comparer.

Avant de continuer, ajoutez également le code suivant à votre code de téléchargement du modèle:

Kotlin

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 comme événement d'activation de votre test. Un événement d'activation est un événement que l'utilisateur doit déclencher avant d'être considéré comme participant au test. Cela garantit que les utilisateurs ne seront pas enregistrés dans votre test A/B tant que leur appareil n'aura pas terminé de télécharger leur modèle ML Kit personnalisé.

2. Déterminer une métrique d'objectif

L'étape suivante consiste à décider comment 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 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 affiner des paramètres, mais elles peuvent ne pas avoir 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é.

Prenons l'exemple de la fonctionnalité de recherche visuelle de plantes hypothétique. Supposons que vous présentiez à l'utilisateur les résultats de recherche dans l'ordre de la confiance du modèle dans 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.

Pour tester quel modèle a le mieux atteint l'objectif de maximiser les clics sur les premiers résultats, vous devez consigner un événement personnalisé chaque fois qu'un utilisateur appuie sur le premier élément de la liste de résultats.

Kotlin

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 en définitive de la façon dont votre application utilise votre modèle.

À ce stade, vous pouvez déployer votre application sur le Play Store. Votre application continuera d'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 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 les événements Analytics pertinents: l'événement d'activation et la 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:
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 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).
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)
  - Outil expérimental d'étiquetage des plantes
  Pour le groupe de contrôle, créez un paramètre plant_labeler_model et définissez-le sur plant_labeler_v1. Les utilisateurs affectés au groupe de contrôle 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 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 le nouveau modèle.

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 parvient pas à déterminer un gagnant, vous devrez peut-être étendre le test à un plus grand nombre 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 les premiers résultats 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 des 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 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 utilisent déjà le dernier modèle. Vous pouvez donc appliquer cette mise à jour dans l'application publiée à tout moment, par exemple lors de votre prochaine mise à jour de fonctionnalités.