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

Test A / B de 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 les tests A / B pour voir 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 nécessiter de mise à jour de l'application.

Cette page montre comment vous pouvez effectuer un test A / B qui évalue deux versions d'un modèle qui alimente une fonction de recherche visuelle hypothétique. Cette fonctionnalité utilise un modèle d'étiquetage d'image personnalisé pour aider les utilisateurs à identifier les espèces végétales à partir de leurs images.

Supposons que vous plant_labeler_v2 publier un nouveau modèle d'étiquetage d'usine, plant_labeler_v2 et que vous souhaitiez exécuter une expérience qui le compare avec votre modèle actuel, nommé plant_labeler_v1 . Les étapes ci-dessous montrent comment configurer le test, l'exécuter et agir sur les résultats.

1. Rendez votre modèle configurable à distance

La première étape du test A / B de vos modèles consiste à modifier votre application pour utiliser 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 comme étant le modèle que votre application utilise déjà, mais comme le nom du modèle est contrôlé par un paramètre configurable à distance, vous pouvez modifier et expérimenter différents modèles sans avoir à pousser les mises à jour de l'application sur votre utilisateurs à chaque fois.

Ainsi, si vous plant_labeler_v1 votre modèle actuel sous le nom plant_labeler_v1 , vous plant_labeler_v1 , dans le code d'initialisation de votre application, plant_labeler_v1 comme valeur par défaut du paramètre 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.
                  // ...
                }
            }
        });
 

Ensuite, modifiez 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 modifier le modèle simplement en publiant un nouveau modèle et en 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, apportez également l'ajout suivant au code de téléchargement de votre modèle:

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

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

L'étape suivante consiste à décider comment vous mesurerez 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.

Les tests A / B comportent plusieurs mesures intégrées, notamment les revenus, l'engagement quotidien et la fidélisation des utilisateurs. Ces métriques sont souvent utiles pour tester différents flux UX ou affiner les paramètres, mais peuvent ne pas avoir de sens pour évaluer votre modèle et votre cas d'utilisation. Dans ce cas, vous pouvez plutôt essayer d'optimiser pour un événement Analytics personnalisé.

En utilisant la fonction de recherche visuelle hypothétique des plantes comme exemple, supposons que vous ayez présenté les résultats de la recherche à votre utilisateur dans l'ordre de confiance du modèle dans chaque résultat. Une façon de vous faire une idée de la précision de votre modèle serait de regarder à quelle fréquence les utilisateurs ouvraient le premier résultat de recherche.

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

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 en fin de compte 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 à utiliser votre modèle d'origine, mais le code de configuration et d'analyse à distance que vous avez ajouté vous permettra d'expérimenter différents modèles en utilisant uniquement la console Firebase.

3. Exécutez une expérience de test A / B

Maintenant que votre application est entre les mains de vos utilisateurs et collecte des données analytiques, créez une expérience de test A / B qui teste l'effet de l'utilisation de votre nouveau modèle au lieu du modèle actuel.

Pour créer l'expérience:

  1. 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 mesure de l'objectif.

    Votre application doit consigner chaque événement au moins une fois avant qu'il n'apparaisse dans la console Firebase.

  2. Dans la console Firebase, ouvrez la section Test A / B.

  3. Créez une nouvelle expérience:

    1. Cliquez sur Créer une expérience> Configuration à distance .

    2. Dans la section Ciblage :

      • Choisissez votre application dans la liste
      • Spécifiez le nombre de vos utilisateurs que vous souhaitez inclure dans l'expérience
      • 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 (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 d'achat ou les utilisateurs sans plantage.

    4. Dans la section Variantes , définissez deux variantes:

      • Groupe de contrôle (créé automatiquement)
      • Étiqueteuse expérimentale

      Pour le groupe 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 de l' étiqueteuse de plantes expérimentales , 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.

    Écran de configuration du test A / B

Démarrez l'expérience et laissez-la s'exécuter pendant plusieurs jours ou plus, jusqu'à ce que A / B Testing déclare un leader. Si l'expérience ne peut pas déterminer un chef de file, vous devrez peut-être étendre l'expérience à plus d'utilisateurs .

4. Déployez la variante gagnante à tous les utilisateurs

Carte de résultat du test A / B

Une fois que le test A / B a collecté suffisamment d'informations pour déclarer un leader (dans ce cas, la variante qui a maximisé les clics sur les résultats de recherche les plus élevés), vous pouvez décider de déployer la variante gagnante (ou une autre variante) à tous vos utilisateurs.

Dans la section Test A / B de la console Firebase , ouvrez la vue détaillée de l'expérience terminée. À partir de cette vue, vous pouvez voir les performances de chaque variante en fonction de la métrique de votre objectif et des statistiques secondaires que vous avez sélectionnées. Avec ces informations, vous pouvez décider de déployer la variante principale ou une autre variante.

Pour déployer une variante à tous les utilisateurs, cliquez sur > variante sur la page des détails de l'expérience. Une fois que vous faites cela, la valeur du paramètre plant_labeler_model sera plant_labeler_v2 pour tous les utilisateurs.

Dans une future mise à jour de l' application, vous devez changer la valeur par défaut du plant_labeler_model paramètre à plant_labeler_v2 et mettre à jour le modèle fourni si vous utilisez un. Cependant, vos utilisateurs utilisent déjà le dernier modèle, vous pouvez donc transférer cette mise à jour dans le cadre de l'application publiée chaque fois que cela vous convient, par exemple lors de la prochaine mise à jour des fonctionnalités.