Depois de treinar um novo modelo personalizado ou modelo do AutoML Vision Edge, você pode usar o teste A/B para ver o desempenho do novo modelo em condições reais, em comparação com o modelo que você já usa. Depois de confirmar que seu novo modelo é uma melhoria, você poderá implementá-lo facilmente para todos os seus usuários, sem precisar atualizar o aplicativo.
Esta página mostra como você pode realizar um teste A/B que avalia duas versões de um modelo que alimenta um hipotético recurso de pesquisa visual de planta. Este recurso usa um modelo de rotulagem de imagens personalizado para ajudar os usuários a identificar espécies de plantas a partir de imagens delas.
Suponha que você acabou de publicar um novo modelo de rotulagem de plantas, plant_labeler_v2 , e deseja executar um experimento que o compare com seu modelo atual, denominado plant_labeler_v1 . As etapas abaixo mostram como configurar o experimento, executá-lo e tomar medidas com base nos resultados.
1. Torne seu modelo configurável remotamente
A primeira etapa para testar seus modelos A/B é modificar seu aplicativo para usar um parâmetro do Configuração remota para determinar qual modelo ele usa. Inicialmente, você definirá o valor padrão desse parâmetro como o modelo que seu aplicativo já usa, mas como o nome do modelo é controlado por um parâmetro configurável remotamente, você pode alterar e experimentar diferentes modelos sem precisar enviar atualizações de aplicativo para seu usuários sempre.
Portanto, se você publicou seu modelo atual com o nome plant_labeler_v1 , você definiria, no código de inicialização do seu aplicativo, plant_labeler_v1 como o valor padrão do parâmetro plant_labeler_model , como no exemplo a seguir:
Rápido
let remoteConfig = RemoteConfig.remoteConfig()
let defaults = [
"plant_labeler_model": "plant_labeler_v1" as NSObject,
// ...
]
remoteConfig.setDefaults(defaults)
remoteConfig.fetchAndActivate()
Objetivo-C
FIRRemoteConfig *remoteConfig = [FIRRemoteConfig remoteConfig];
NSDictionary<NSString *, NSObject *> *defaults = @{
@"plant_labeler_model" : (NSObject *)@"plant_labeler_v1",
// ...
};
[remoteConfig setDefaults:defaults];
[remoteConfig fetchAndActivateWithCompletionHandler:nil];
Em seguida, altere o código de configuração do seu modelo para carregar o modelo especificado pelo parâmetro plant_labeler_model :
Rápido
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
Objetivo-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
Agora que seu aplicativo usa um parâmetro do Configuração remota para determinar qual modelo carregar, você pode alterar o modelo apenas publicando um novo modelo e atribuindo seu nome ao parâmetro do Configuração remota. Esse recurso permite que o teste A/B atribua modelos diferentes a usuários diferentes com a finalidade de compará-los.
Antes de continuar, faça também a seguinte adição ao código de download do seu modelo:
Rápido
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)
}
}
Objetivo-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];
}
}];
O código acima registra um evento personalizado do Analytics que você usará posteriormente como evento do seu experimento
2. Determine uma métrica de meta
A próxima etapa é decidir como você medirá o sucesso do seu modelo e garantir que seu aplicativo esteja coletando os dados necessários para testar o desempenho de diferentes versões do modelo de acordo com essa métrica.
O teste A/B tem várias métricas integradas, incluindo receita, envolvimento diário e retenção de usuários. Essas métricas costumam ser úteis para testar diferentes fluxos de UX ou ajustar parâmetros, mas podem não fazer sentido para avaliar seu modelo e caso de uso. Nessa situação, você pode tentar otimizar para um evento personalizado do Analytics.
Usando o hipotético recurso de pesquisa visual de plantas como exemplo, suponha que você apresentou os resultados da pesquisa ao usuário na ordem de confiança do modelo em cada resultado. Uma maneira de ter uma ideia da precisão do seu modelo seria observar com que frequência os usuários abriram o primeiro resultado da pesquisa.
Para testar qual modelo atingiu melhor o objetivo de maximizar os cliques nos resultados principais, você registraria um evento personalizado sempre que um usuário tocasse no primeiro item da lista de resultados.
Rápido
Analytics.logEvent("first_result_opened", parameters: nil)
Objetivo-C
[FIRAnalytics logEventWithName:@"first_result_opened" parameters:nil];
A métrica que você testa depende, em última análise, de como seu aplicativo usa seu modelo.
Neste ponto, você pode implantar seu aplicativo na App Store. Seu aplicativo continuará usando o modelo original, mas o código da Configuração remota e do Analytics que você adicionou permitirá que você experimente diferentes modelos usando apenas o Firebase Console.
3. Execute um experimento de teste A/B
Agora que seu aplicativo está nas mãos dos usuários e coletando dados analíticos, crie um experimento de teste A/B que testa o efeito do uso de seu novo modelo em vez do modelo atual.
Para criar o experimento:
Na página Eventos do console do Firebase, verifique se você está registrando os eventos relevantes do Analytics: o evento de ativação e a métrica da meta.
Seu aplicativo precisa registrar cada evento pelo menos uma vez antes que ele apareça no Console do Firebase.
No console do Firebase, abra a seção Teste A/B .
Crie um novo experimento:
Clique em Criar experimento > Configuração remota .
Na seção Segmentação :
- Escolha seu aplicativo na lista
- Especifique quantos usuários você deseja incluir na experiência
- Selecione o evento de ativação que você começou a registrar (neste exemplo, nondefault_model_downloaded )
Na seção Metas , escolha a métrica da meta determinada na seção anterior (neste exemplo, first_result_opened ) na lista de métricas da meta e selecione quaisquer métricas adicionais que você deseja acompanhar, como receita de compras ou usuários sem falhas.
Na seção Variantes , defina duas variantes:
- Grupo de controle (criado automaticamente)
- Rotulador de plantas experimentais
Para o grupo Controle , crie um parâmetro
plant_labeler_modele defina-o comoplant_labeler_v1. Os usuários atribuídos ao grupo de controle usarão o modelo antigo. (Não defina o parâmetro como(no change), pois em seu aplicativo você está testando se está usando um valor remoto.)Para a variante Experimental Plant Labeler , defina o parâmetro
plant_labeler_modelcomoplant_labeler_v2(supondo que você publicou seu novo modelo com esse nome). Os usuários atribuídos a esta variante usarão o novo modelo.
Inicie o experimento e deixe-o rodar por vários dias ou mais, até que o Teste A/B declare um líder. Se a experiência não conseguir determinar um líder, poderá ser necessário expandi-la para mais usuários .
4. Distribua a variante vencedora para todos os usuários
Depois que o teste A/B coletar informações suficientes para declarar um líder – neste caso, a variante que maximizou os cliques nos principais resultados de pesquisa – você pode decidir se deseja lançar a variante vencedora (ou outra variante) para todos os seus usuários.
Na seção Teste A/B do Firebase Console , abra a visualização de detalhes do experimento concluído. Nessa visualização, você pode ver o desempenho de cada variante de acordo com a métrica de sua meta e quaisquer métricas secundárias selecionadas. Com essas informações, você pode decidir se deseja implementar a variante principal ou outra variante.
Para implementar uma variante para todos os usuários, clique em more_vert > Implementar variante na página de detalhes do experimento. Depois de fazer isso, o valor do parâmetro plant_labeler_model será plant_labeler_v2 para todos os usuários.
Em uma atualização futura do aplicativo, você deverá alterar o valor padrão do parâmetro plant_labeler_model para plant_labeler_v2 e atualizar o modelo empacotado, se usar um. Porém, seus usuários já estão usando o modelo mais recente, então você pode enviar essa atualização como parte do aplicativo publicado sempre que for conveniente, como na próxima vez que fizer uma atualização de recurso.