Catch up on highlights from Firebase at Google I/O 2023. Learn more

Prova A/B due versioni di un modello

Dopo aver addestrato un nuovo modello personalizzato o un modello AutoML Vision Edge, puoi utilizzare A/B Testing per vedere le prestazioni del nuovo modello in condizioni reali, rispetto al modello che già utilizzi. Dopo aver confermato che il tuo nuovo modello è un miglioramento, puoi facilmente distribuire il nuovo modello a tutti i tuoi utenti, senza richiedere un aggiornamento dell'app.

Questa pagina mostra come condurre un test A/B che valuta due versioni di un modello che alimenta un'ipotetica funzione di ricerca visiva delle piante. Questa funzione utilizza un modello di etichettatura delle immagini personalizzato per aiutare gli utenti a identificare le specie vegetali dalle loro immagini.

Si supponga di aver appena pubblicato un nuovo modello di etichettatura delle piante, plant_labeler_v2 e di voler eseguire un esperimento che lo confronti con il modello corrente, denominato plant_labeler_v1 . I passaggi seguenti mostrano come impostare l'esperimento, eseguirlo e agire sui risultati.

1. Rendi il tuo modello configurabile da remoto

Il primo passaggio per il test A/B dei modelli consiste nel modificare l'app in modo che utilizzi un parametro Remote Config per determinare quale modello utilizza. Inizialmente, imposterai il valore predefinito di questo parametro in modo che sia il modello già utilizzato dalla tua app, ma poiché il nome del modello è controllato da un parametro configurabile in remoto, puoi modificare e sperimentare modelli diversi senza dover inviare gli aggiornamenti dell'app al tuo utenti ogni volta.

Pertanto, se hai pubblicato il tuo modello corrente con il nome plant_labeler_v1 , nel codice di inizializzazione dell'app, devi impostare plant_labeler_v1 come valore predefinito del parametro plant_labeler_model , come nell'esempio seguente:

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.
                  // ...
                }
            }
        });

Quindi, modifica il codice di configurazione del modello per caricare il modello specificato dal parametro 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

Ora che la tua app usa un parametro Remote Config per determinare quale modello caricare, puoi modificare il modello semplicemente pubblicando un nuovo modello e assegnandone il nome al parametro Remote Config. Questa funzionalità consente a A/B Testing di assegnare modelli diversi a utenti diversi allo scopo di confrontarli.

Prima di continuare, apporta anche la seguente aggiunta al codice di download del modello:

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);
                }
            }
        });

Il codice precedente registra un evento Analytics personalizzato che utilizzerai in seguito come esperimento evento di attivazione . Un evento di attivazione è un evento che l'utente deve attivare prima di essere considerato parte dell'esperimento. Ciò garantisce che gli utenti non vengano registrati nel test A/B fino a quando il loro dispositivo non avrà terminato il download del modello ML personalizzato.

2. Determinare una metrica obiettivo

Il passaggio successivo consiste nel decidere come misurerai il successo del tuo modello e assicurarti che la tua app raccolga i dati necessari per testare il rendimento delle diverse versioni del modello in base a quella metrica.

Il test A/B ha diverse metriche integrate, tra cui entrate, coinvolgimento quotidiano e fidelizzazione degli utenti. Queste metriche sono spesso utili per testare diversi flussi UX o per ottimizzare i parametri, ma potrebbero non avere senso per valutare il modello e il caso d'uso. In questa situazione, puoi invece provare a ottimizzare per un evento Analytics personalizzato.

Utilizzando l'ipotetica funzione di ricerca visiva delle piante come esempio, supponiamo di aver presentato i risultati della ricerca all'utente nell'ordine di confidenza del modello in ciascun risultato. Un modo per farti un'idea dell'accuratezza del tuo modello consiste nell'esaminare la frequenza con cui gli utenti hanno aperto il primo risultato di ricerca.

Per testare quale modello ha raggiunto meglio l'obiettivo di massimizzare i clic sui risultati migliori, dovresti registrare un evento personalizzato ogni volta che un utente tocca il primo elemento nell'elenco dei risultati.

Kotlin+KTX

FirebaseAnalytics.getInstance(this).logEvent("first_result_opened", null)

Java

FirebaseAnalytics.getInstance(YourActivity.this).logEvent("first_result_opened", null);

La metrica per la quale esegui il test dipende in definitiva da come la tua app utilizza il tuo modello.

A questo punto, puoi distribuire la tua app sul Play Store. La tua app continuerà a utilizzare il tuo modello originale, ma il codice Remote Config e Analytics che hai aggiunto ti consentirà di sperimentare modelli diversi utilizzando solo la console Firebase.

3. Eseguire un esperimento di test A/B

Ora che l'app è nelle mani degli utenti e sta raccogliendo dati analitici, crea un esperimento di test A/B che verifica l'effetto dell'utilizzo del nuovo modello anziché del modello corrente.

Per creare l'esperimento:

  1. Nella pagina Eventi della console Firebase, verifica di aver registrato gli eventi Analytics rilevanti: l'evento di attivazione e la metrica dell'obiettivo.

    La tua app deve registrare ogni evento almeno una volta prima che appaia nella console Firebase.

  2. Nella console Firebase, apri la sezione Test A/B .

  3. Crea un nuovo esperimento:

    1. Fare clic su Crea esperimento > Configurazione remota .

    2. Nella sezione Targeting :

      • Scegli la tua app dall'elenco
      • Specifica quanti dei tuoi utenti vuoi includere nell'esperimento
      • Seleziona l'evento di attivazione che hai iniziato a registrare (in questo esempio, nondefault_model_downloaded )
    3. Nella sezione Obiettivi , scegli la metrica dell'obiettivo che hai determinato nella sezione precedente (in questo esempio, first_result_opened ) dall'elenco delle metriche dell'obiettivo e seleziona le metriche aggiuntive che desideri monitorare, come le entrate degli acquisti o gli utenti senza arresti anomali.

    4. Nella sezione Varianti , definisci due varianti:

      • Gruppo di controllo (creato automaticamente)
      • Etichettatrice sperimentale per piante

      Per il gruppo di controllo , creare un parametro plant_labeler_model e impostarlo su plant_labeler_v1 . Gli utenti assegnati al gruppo di controllo utilizzeranno il vecchio modello. (Non impostare il parametro su (no change) , poiché nella tua app stai verificando che stai utilizzando un valore remoto.)

      Per la variante Experimental plant labeler, imposta il parametro plant_labeler_model su plant_labeler_v2 (supponendo che tu abbia pubblicato il tuo nuovo modello con quel nome). Gli utenti assegnati a questa variante utilizzeranno il nuovo modello.

    Schermata di configurazione del test A/B

Avvia l'esperimento e lascialo funzionare per diversi giorni o più, fino a quando A/B Testing non dichiara un leader. Se l'esperimento non riesce a determinare un leader, potrebbe essere necessario espandere l'esperimento a più utenti .

4. Distribuisci la variante vincente a tutti gli utenti

Scheda dei risultati del test A/B

Dopo che A/B Testing ha raccolto informazioni sufficienti per dichiarare un leader, in questo caso, la variante che ha massimizzato i clic sui risultati di ricerca principali, puoi decidere se distribuire la variante vincente (o un'altra variante) a tutti i tuoi utenti.

Nella sezione Test A/B della console Firebase , apri la visualizzazione dei dettagli dell'esperimento completato. Da questa visualizzazione, puoi vedere il rendimento di ciascuna variante in base alla metrica dell'obiettivo e alle metriche secondarie che hai selezionato. Con queste informazioni, puoi decidere se implementare la variante principale o un'altra variante.

Per distribuire una variante a tutti gli utenti, fai clic su > Implementa variante nella pagina dei dettagli dell'esperimento. Dopo averlo fatto, il valore del parametro plant_labeler_model sarà plant_labeler_v2 per tutti gli utenti.

In un futuro aggiornamento dell'app, dovresti modificare il valore predefinito del parametro plant_labeler_model in plant_labeler_v2 e aggiornare il modello in bundle se ne usi uno. Tuttavia, i tuoi utenti stanno già utilizzando il modello più recente, quindi puoi eseguire il push di questo aggiornamento come parte dell'app pubblicata ogni volta che è conveniente, ad esempio la prossima volta che esegui un aggiornamento delle funzionalità.