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:
Veloce
let remoteConfig = RemoteConfig.remoteConfig()
let defaults = [
"plant_labeler_model": "plant_labeler_v1" as NSObject,
// ...
]
remoteConfig.setDefaults(defaults)
remoteConfig.fetchAndActivate()
Obiettivo-C
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
:
Veloce
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/label-images-with-automl#configure-a-local-model-source
// https://firebase.google.com/docs/ml/ios/use-custom-models#configure_a_local_model
Obiettivo-C
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/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:
Veloce
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)
}
}
Obiettivo-C
__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 precedente registra un evento Analytics personalizzato che utilizzerai in seguito come esperimento
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.
Veloce
Analytics.logEvent("first_result_opened", parameters: nil)
Obiettivo-C
[FIRAnalytics logEventWithName:@"first_result_opened" parameters:nil];
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 nell'App 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:
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.
Nella console Firebase, apri la sezione Test A/B .
Crea un nuovo esperimento:
Fare clic su Crea esperimento > Configurazione remota .
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 )
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.
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 suplant_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
suplant_labeler_v2
(supponendo che tu abbia pubblicato il tuo nuovo modello con quel nome). Gli utenti assegnati a questa variante utilizzeranno il nuovo modello.
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

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 more_vert > 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à.