Catch up on everthing we announced at this year's Firebase Summit. Learn more

Teste A / B duas versões de um modelo

Depois de treinar um novo modelo personalizado ou modelo AutoML Vision Edge, você pode usar o teste A / B para ver o desempenho do novo modelo em condições do mundo real, em comparação com o modelo que você já usa. Depois de confirmar que seu novo modelo é uma melhoria, você pode implementar facilmente o novo modelo para todos os seus usuários, sem exigir uma atualização do aplicativo.

Esta página mostra como você pode conduzir um teste A / B que avalia duas versões de um modelo que alimenta um recurso de pesquisa visual de planta hipotético. Este recurso usa um modelo de rotulagem de imagem personalizado para ajudar os usuários a identificar espécies de plantas a partir de imagens delas.

Suponha que você acaba de publicar um novo modelo de rotulagem planta, plant_labeler_v2 e você deseja executar um experimento que compara com o modelo atual, com o nome plant_labeler_v1 . As etapas abaixo mostram como configurar o experimento, executá-lo e agir de acordo com os resultados.

1. Torne seu modelo configurável remotamente

A primeira etapa para o teste A / B de seus modelos é 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 deste parâmetro para ser 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 ter que enviar atualizações de aplicativo para o seu usuários o tempo todo.

Então, se você publicou seu modelo atual sob o nome plant_labeler_v1 , você faria, em seu código de inicialização de aplicativos, conjunto plant_labeler_v1 como o valor padrão do plant_labeler_model parâmetro, como no exemplo a seguir:

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

Em seguida, alterar o código de configuração do modelo para carregar o modelo especificado pela plant_labeler_model parâmetro:

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

Agora que seu aplicativo usa um parâmetro de 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 de Configuração remota. Esse recurso permite que o Teste A / B atribua modelos diferentes a usuários diferentes com o objetivo de compará-los.

Antes de continuar, faça também a seguinte adição ao código de download do modelo:

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

O código acima registra um evento personalizado do Analytics que você usará posteriormente como seu experimento evento de ativação . Um evento de ativação é um evento que o usuário deve acionar antes de ser considerado parte do experimento. Isso garante que os usuários não sejam registrados em seu teste A / B até que o dispositivo conclua o download do modelo de ML personalizado.

2. Determine uma métrica de meta

A próxima etapa é decidir como você medirá o sucesso de 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ário. Essas métricas geralmente são úteis para testar diferentes fluxos de UX ou parâmetros de ajuste fino, 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 recurso de pesquisa visual de planta hipotética como exemplo, suponha que você apresentou os resultados da pesquisa ao seu 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 observando a frequência com que os usuários abriram o primeiro resultado da pesquisa.

Para testar qual modelo atingiu melhor a meta de maximizar os cliques de resultados principais, você registraria um evento personalizado sempre que um usuário tocasse no primeiro item da lista de resultados.

Kotlin + KTX

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

Java

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

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 Play Store. Seu aplicativo continuará a usar o modelo original, mas o código do Remote config e do Analytics que você adicionou permitirá que você experimente diferentes modelos usando apenas o console do Firebase.

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 de usar seu novo modelo em vez do modelo atual.

Para criar o experimento:

  1. Na Eventos página do console Firebase, verifique se está registrando os eventos do Google Analytics relevantes: o evento de ativação e métricas objetivo.

    Seu aplicativo precisa registrar cada evento pelo menos uma vez antes de aparecer no console do Firebase.

  2. No console Firebase, abra a seção A / B Testing.

  3. Crie um novo experimento:

    1. Clique em Criar experiência> remoto de configuração.

    2. Na seção Segmentação:

      • Escolha seu aplicativo na lista
      • Especifique quantos usuários deseja incluir no experimento
      • Selecione o evento de ativação que você começou login (neste exemplo, nondefault_model_downloaded)
    3. Na seção Metas, escolha a métrica do objectivo determinado na seção anterior (neste exemplo, first_result_opened) da lista de métricas de objetivo e selecione as métricas adicionais que você deseja acompanhar, como receita de compra ou usuários sem acidente.

    4. Na seção Variantes, definir duas variantes:

      • Grupo de controle (criado automaticamente)
      • Marcador de planta experimental

      Para o grupo de controle, criar um plant_labeler_model parâmetro e defini-lo para plant_labeler_v1 . Os usuários atribuídos ao grupo de controle usarão o modelo antigo. (Não defina o parâmetro para (no change) , já que em seu aplicativo, você está testando se você está usando um valor remoto.)

      Para o Experimental variante planta labeler, defina o plant_labeler_model parâmetro para plant_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.

    Tela de configuração de teste A / B

Inicie o experimento e deixe-o funcionar por vários dias ou mais, até que o Teste A / B declare um líder. Se a experiência não pode determinar um líder, pode ser necessário alargar a experiência a mais usuários .

4. Lance a variante vencedora para todos os usuários

Cartão de resultado de teste A / B

Depois que o Teste A / B coletou informações suficientes para declarar um líder - neste caso, a variante que maximizou os cliques nos principais resultados da pesquisa - você pode decidir se deseja distribuir a variante vencedora (ou outra variante) para todos os seus usuários.

Na seção A / B Testing da consola Firebase , abra a exibição de detalhes da experiência concluída. Nessa visualização, você pode ver o desempenho de cada variante de acordo com sua métrica de meta e quaisquer métricas secundárias que você selecionou. Com essas informações, você pode decidir se deseja lançar a variante principal ou outra variante.

Para a implantação de uma variante para todos os usuários, clique em > Roll out variante na página de detalhes do experimento. Uma vez que você fizer isso, o valor da plant_labeler_model parâmetro será plant_labeler_v2 para todos os usuários.

Em uma atualização futura aplicativo, você deve alterar o valor padrão do plant_labeler_model parâmetro para plant_labeler_v2 e atualizar o modelo de pacote, se você usar um. Seus usuários já estão usando o modelo mais recente, portanto, você pode enviar essa atualização como parte do aplicativo publicado sempre que for conveniente, como na próxima atualização de um recurso.