Eseguire test A/B di due versioni di un modello

Dopo aver addestrato un nuovo modello personalizzato, puoi utilizzare A/B Testing per verificare il rendimento del nuovo modello in condizioni reali, rispetto al modello che utilizzi già. Dopo aver confermato 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 di immagini personalizzato per aiutare gli utenti a identificare le specie di piante dalle immagini.

Supponiamo che tu abbia appena pubblicato un nuovo modello di etichettatura di piante, plant_labeler_v2, e che tu voglia eseguire un esperimento per confrontarlo con il modello attuale, denominato plant_labeler_v1. I passaggi che seguono mostrano come configurare l'esperimento, eseguirlo e intervenire sui risultati.

1. Rendere il modello configurabile da remoto

Il primo passo per eseguire i test A/B dei modelli è modificare l'app in modo che utilizzi un Remote Config parametro per determinare il modello da utilizzare. Inizialmente, imposterai il valore predefinito di questo parametro sul modello già utilizzato dall'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 imposterai 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];

Poi, 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 l'app utilizza un Remote Config parametro per determinare il modello da caricare, puoi modificare il modello semplicemente pubblicandone uno nuovo e assegnandogli 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, 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 loro dispositivo non avrà completato il download del modello di ML personalizzato.

2. Determinare una metrica obiettivo

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

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

Utilizzando come esempio la funzionalità dei risultati di ricerca visiva di piante ipotetica, supponiamo che tu abbia presentato i risultati di ricerca all'utente in base al livello di attendibilità del modello in ogni risultato. Un modo per farti un'idea dell'accuratezza del modello è esaminare 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 risultato principale, devi registrare 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 l'app utilizza il modello.

A questo punto, puoi eseguire il deployment dell'app nell'App Store. L'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 l'app è nelle mani degli utenti e raccoglie dati e analisi, crea un esperimento A/B Testing che verifichi 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.

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

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 l'app dall'elenco
      • Specifica il numero di utenti da 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 obiettivo che hai determinato nella sezione precedente (in questo esempio, first_result_opened) dall'elenco delle metriche obiettivo e seleziona eventuali metriche aggiuntive di cui vuoi tenere traccia, ad esempio le entrate da acquisti o gli utenti senza arresti anomali.

   4. Nella sezione Varianti, definisci due varianti:

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

      Per il gruppo di controllo, crea un plant_labeler_model parametro 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é nell'app stai verificando di utilizzare un valore remoto.)

      Per la variante Etichettatore di piante sperimentale, 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, potrebbe essere necessario espandere l'esperimento a un numero maggiore di utenti.

4. Implementare 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 risultato di ricerca principale, 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 dei dettagli dell'esperimento completato. In questa visualizzazione puoi vedere il rendimento di ogni variante in base alla metrica 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 > Implementa 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, gli utenti utilizzano già il modello più recente, quindi puoi inviare questo aggiornamento come parte dell'app pubblicata quando ti è più comodo, ad esempio quando esegui un aggiornamento delle funzionalità.