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 évaluer les performances du nouveau modèle dans des conditions réelles, par rapport au modèle que vous utilisez déjà. Après avoir confirmé que votre nouveau modèle est une amélioration, vous pouvez facilement déployer le nouveau modèle pour tous vos utilisateurs, sans nécessiter de mise à jour de l'application.

Cette page montre comment vous pourriez effectuer un test A/B qui évalue deux versions d'un modèle qui alimente une fonction de recherche visuelle d'usine 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 venez de publier un nouveau modèle d'étiquetage des plantes, plant_labeler_v2 et vous voulez exécuter une expérience qu'il 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 de configuration à distance afin de déterminer le modèle qu'elle utilise. Initialement, 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 à envoyer les mises à jour utilisateurs à chaque fois.

Donc, si vous avez publié votre modèle actuel sous le nom plant_labeler_v1 , vous le feriez dans votre code d'initialisation de l' application, jeu plant_labeler_v1 comme la valeur par défaut du plant_labeler_model paramètre, 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 votre code de configuration du modèle pour charger le modèle spécifié par le plant_labeler_model paramètre:

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 capacité permet à l'A/B Testing d'attribuer différents modèles à différents utilisateurs dans le but de les comparer.

Avant de continuer, ajoutez également l'ajout suivant à votre code de téléchargement de 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 de ML personnalisé.

2. Déterminer une métrique d'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 les performances des différentes versions du modèle en fonction de cette métrique.

Les tests A/B intègrent plusieurs métriques, 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 cette situation, vous pouvez plutôt essayer d'optimiser un événement Analytics personnalisé.

En utilisant la fonction de recherche visuelle de plantes hypothétique 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 d'avoir une idée de la précision de votre modèle serait de regarder à quelle fréquence les utilisateurs ont ouvert le premier résultat de recherche.

Pour tester quel modèle atteint le mieux l'objectif de maximiser les meilleurs clics sur les résultats, vous enregistrez un événement personnalisé chaque fois qu'un utilisateur touche le premier élément de la liste des 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 Remote Config and Analytics 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 d'analyse, 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 Events page de la console Firebase, vérifiez que vous connectez les événements Analytics pertinents: l'événement d'activation et métriques de but.

    Votre application doit enregistrer 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 un nouveau test :

    1. Cliquez sur Créer expérience> Remote Config.

    2. Dans la section Ciblage:

      • Choisissez votre application dans la liste
      • Indiquez le nombre d'utilisateurs que vous souhaitez inclure dans le test
      • Sélectionnez l'événement d'activation vous commencé à enregistrer (dans cet exemple, nondefault_model_downloaded)
    3. Dans la section Objectifs, choisissez l'objectif métrique que vous avez déterminé dans la section précédente (dans cet exemple, first_result_opened) dans la liste des mesures de but, et sélectionnez les mesures supplémentaires que vous souhaitez suivre, comme les revenus d'achat ou les utilisateurs sans accident.

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

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

      Pour le groupe de contrôle, créez un plant_labeler_model paramètre et réglez - le sur plant_labeler_v1 . Les utilisateurs affectés au groupe de contrôle utiliseront l'ancien modèle. (Ne pas régler le paramètre (no change) de (no change) , puisque dans votre application, vous testez que vous utilisez une valeur à distance.)

      Pour l'installation expérimentale variante étiqueteuse, réglez le plant_labeler_model paramètre à plant_labeler_v2 ( en supposant que vous avez publié votre nouveau modèle sous ce nom). Les utilisateurs affectés à cette variante utiliseront le nouveau modèle.

    Écran de configuration des tests A/B

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

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

Carte de résultat des tests A/B

Une fois que l'A/B Testing a collecté suffisamment d'informations pour déclarer un leader (dans ce cas, la variante qui a maximisé les meilleurs clics dans les résultats de recherche), 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 votre métrique d'objectif et des métriques 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 > Déploiement variante sur la page des détails de l'expérience. Une fois que vous le faites, la valeur du plant_labeler_model paramètre 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. Vos utilisateurs utilisent déjà le dernier modèle, cependant, vous pouvez donc envoyer 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.