Eseguire test A/B di due versioni di un modello

Dopo aver addestrato un nuovo modello personalizzato, puoi utilizzare A/B Testing per vedere le prestazioni del nuovo modello in condizioni reali, rispetto al modello che utilizzi già. Dopo aver verificato che il nuovo modello è un miglioramento, puoi implementarlo facilmente per tutti gli utenti, senza richiedere un aggiornamento dell'app.

Questa pagina mostra come eseguire un test A/B che valuta due versioni di un modello che supporta una funzionalità dei risultati di ricerca visiva di piante ipotetica. Questa funzionalità utilizza un modello di etichettatura delle immagini personalizzato per aiutare gli utenti a identificare le specie vegetali dalle loro immagini.

Supponiamo che tu abbia appena pubblicato un nuovo modello di etichettatura delle piante, plant_labeler_v2 e che tu voglia eseguire un esperimento che lo confronti con il tuo modello attuale, denominato plant_labeler_v1. I passaggi riportati di seguito mostrano come configurare l'esperimento, eseguirlo e intervenire in base ai risultati.

1. Rendere il modello configurabile da remoto

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

Pertanto, se hai pubblicato il modello attuale 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:

let remoteConfig = RemoteConfig.remoteConfig()
let defaults = [
    "plant_labeler_model": "plant_labeler_v1" as NSObject,
    // ...
]
remoteConfig.setDefaults(defaults)
remoteConfig.fetchAndActivate()

FIRRemoteConfig *remoteConfig = [FIRRemoteConfig remoteConfig];
NSDictionary<NSString *, NSObject *> *defaults = @{
  @"plant_labeler_model" : (NSObject *)@"plant_labeler_v1",
  // ...
};
[remoteConfig setDefaults:defaults];
[remoteConfig fetchAndActivateWithCompletionHandler:nil];

Quindi, modifica il codice di configurazione del modello per caricare il modello specificato dal parametro plant_labeler_model:

let rcValue = remoteConfig.configValue(forKey: "plant_labeler_model")
guard let remoteModelName = rcValue.stringValue else { return }

// ...

let remoteModel = RemoteModel(
    name: remoteModelName,
    allowsModelUpdates: true,
    initialConditions: initialConditions,
    updateConditions: updateConditions
)
ModelManager.modelManager().register(remoteModel)

// Optionally configure a local model:
// https://firebase.google.com/docs/ml/ios/use-custom-models#configure_a_local_model

FIRRemoteConfigValue *rcValue = [remoteConfig configValueForKey:@"plant_labeler_model"];
NSString *remoteModelName = [rcValue stringValue];

// ...

FIRRemoteModel *remoteModel = [[FIRRemoteModel alloc] initWithName:remoteModelName
                                                allowsModelUpdates:YES
                                                 initialConditions:initialConditions
                                                  updateConditions:updateConditions];
[[FIRModelManager modelManager] registerRemoteModel:remoteModel];

// Optionally configure a local model:
// https://firebase.google.com/docs/ml/android/use-custom-models#configure_a_local_model

Ora che la tua app utilizza un parametro Remote Config per determinare quale modello caricare, puoi cambiare il modello semplicemente pubblicandone uno nuovo e assegnando il relativo nome al parametro Remote Config. Questa funzionalità consente a A/B Testing di assegnare modelli diversi a utenti diversi per confrontarli.

Prima di continuare, aggiungi anche quanto segue al codice di download del modello:

NotificationCenter.default.addObserver(
    forName: .firebaseMLModelDownloadDidSucceed,
    object: nil,
    queue: nil
) { [weak self] notification in
    guard let _ = self,
        let userInfo = notification.userInfo,
        let model = userInfo[ModelDownloadUserInfoKey.remoteModel.rawValue]
            as? RemoteModel,
        model.name == remoteModelName
        else { return }
    // If the model downloaded was specified by a remote parameter, log an
    // event, which will be our experiment's activation event.
    if rcValue.source == .remote {
        Analytics.logEvent("nondefault_model_downloaded", parameters: nil)
    }
}

__weak typeof(self) weakSelf = self;

[NSNotificationCenter.defaultCenter
    addObserverForName:FIRModelDownloadDidSucceedNotification
                object:nil
                 queue:nil
            usingBlock:^(NSNotification *_Nonnull note) {
              if (weakSelf == nil | note.userInfo == nil) {
                return;
              }

              FIRRemoteModel *model = note.userInfo[FIRModelDownloadUserInfoKeyRemoteModel];
              if ([model.name isEqualToString:remoteModelName] &&
                  rcValue.source == FIRRemoteConfigSourceRemote) {
                // If the model downloaded was specified by a remote parameter, log an
                // event, which will be our experiment's activation event.
                [FIRAnalytics logEventWithName:@"nondefault_model_downloaded" parameters:nil];
              }
            }];

Il codice riportato sopra registra un evento Analytics personalizzato che utilizzerai in un secondo momento come evento di attivazione dell'esperimento. Un evento di attivazione è un evento che l'utente deve attivare prima di essere considerato parte dell'esperimento. In questo modo, gli utenti non verranno registrati nel test A/B finché il dispositivo non avrà terminato il download del modello ML personalizzato.

2. Determinare una metrica dell'obiettivo

Il passaggio successivo consiste nel decidere come misurare il successo del modello e assicurarsi che l'app raccolga i dati necessari per testare le prestazioni delle diverse versioni del modello in base a questa metrica.

A/B Testing dispone di diverse metriche integrate, tra cui entrate, coinvolgimento giornaliero e fidelizzazione degli utenti. Queste metriche sono spesso utili per testare diversi flussi UX o per perfezionare i parametri, ma potrebbero non essere adatte per valutare il modello e il caso d'uso. In questo caso, puoi provare a ottimizzare per un evento Analytics personalizzato.

Utilizzando come esempio la funzionalità ipotetica di ricerca visiva di piante, supponiamo che tu abbia presentato i risultati di ricerca all'utente in base all'ordine di confidenza del modello in ogni risultato. Un modo per farti un'idea dell'accuratezza del modello è osservare la frequenza con cui gli utenti hanno aperto il primo risultato di ricerca.

Per verificare quale modello ha raggiunto meglio l'obiettivo di massimizzare i clic sul primo risultato, registra un evento personalizzato ogni volta che un utente tocca il primo elemento nell'elenco dei risultati.

Analytics.logEvent("first_result_opened", parameters: nil)

[FIRAnalytics logEventWithName:@"first_result_opened" parameters:nil];

La metrica che testi dipende in definitiva da come la tua app utilizza il tuo modello.

A questo punto, puoi eseguire il deployment della tua app sull'App Store. La tua app continuerà a utilizzare il 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 A/B Testing

Ora che la tua app è nelle mani degli utenti e raccoglie dati e analisi, crea un esperimento A/B Testing che testa l'effetto dell'utilizzo del nuovo modello anziché di quello attuale.

Per creare l'esperimento:

1. Nella pagina Eventi della console Firebase, verifica di registrare gli eventi Analytics pertinenti: l'evento di attivazione e la metrica obiettivo.

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

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

3. Crea un nuovo esperimento:

   1. Fai clic su Crea esperimento > Remote Config.

   2. Nella sezione Targeting:

      • Scegli la tua app dall'elenco.
      • Specifica quanti utenti vuoi includere nell'esperimento.
      • Seleziona l'evento di attivazione di cui hai iniziato la registrazione (in questo esempio, nondefault_model_downloaded)

   3. Nella sezione Obiettivi, scegli la metrica obiettivo che hai determinato nella sezione precedente (in questo esempio, first_result_opened) dall'elenco delle metriche obiettivo e seleziona eventuali altre metriche che vuoi monitorare, ad esempio le entrate generate dagli acquisti o gli utenti senza arresti anomali.

   4. Nella sezione Varianti, definisci due varianti:

      • Gruppo di controllo (creato automaticamente)
      • Etichettatore sperimentale di piante

      Per il gruppo di controllo, crea un parametro plant_labeler_model e impostalo su plant_labeler_v1. Gli utenti assegnati al gruppo di controllo utilizzeranno il modello precedente. Non impostare il parametro su (no change), poiché nella tua app stai testando l'utilizzo di un valore remoto.

      Per la variante Etichettatore sperimentale di piante, imposta il parametro plant_labeler_model su plant_labeler_v2 (supponendo che tu abbia pubblicato il nuovo modello con questo nome). Gli utenti assegnati a questa variante utilizzeranno il nuovo modello.

   

Avvia l'esperimento e lascialo in esecuzione per diversi giorni o più, finché A/B Testing non dichiara un leader. Se l'esperimento non riesce a determinare un leader, potresti dover estendere l'esperimento a più utenti.

4. Implementa la variante vincente per tutti gli utenti

Dopo che A/B Testing ha raccolto informazioni sufficienti per dichiarare un leader, in questo caso la variante che ha massimizzato i clic sul primo risultato di ricerca, puoi decidere se implementare la variante vincente (o un'altra variante) per tutti gli utenti.

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

Per implementare una variante per tutti gli utenti, fai clic su more_vert > Distribuisci variante nella pagina dei dettagli dell'esperimento. Una volta fatto, il valore del parametro plant_labeler_model sarà plant_labeler_v2 per tutti gli utenti.

In un futuro aggiornamento dell'app, devi modificare il valore predefinito del parametro plant_labeler_model in plant_labeler_v2 e aggiornare il modello in bundle, se ne utilizzi uno. Tuttavia, i tuoi utenti utilizzano già l'ultimo modello, quindi puoi eseguire il push di questo aggiornamento nell'ambito dell'app pubblicata quando preferisci, ad esempio quando esegui un aggiornamento delle funzionalità.