Executar testes A/B com duas versões de um modelo

Depois de treinar um novo modelo personalizado ou o modelo do AutoML Vision Edge, é possível usar o Teste A/B para comparar o desempenho do novo modelo em condições reais com o do modelo que você já usa. Depois de confirmar que seu novo modelo é uma melhoria, ele poderá ser implantado facilmente para todos os usuários, sem a necessidade de uma atualização do app.

Nesta página, mostramos como realizar um Teste A/B para avaliar duas versões de um modelo que aciona um recurso hipotético de pesquisa visual de plantas. Nele, um modelo de rotulagem de imagens personalizado permite que os usuários usem imagens para identificar espécies de plantas.

Suponha que você acabou de publicar um novo modelo de rotulagem de plantas, plant_labeler_v2, e quer executar um experimento que o compare com seu modelo atual, chamado plant_labeler_v1. Veja nas etapas abaixo como configurar e executar o experimento e tomar medidas em relação aos resultados.

1. Possibilitar a configuração remota do seu modelo

A primeira etapa para fazer um Teste A/B nos seus modelos é configurar o app para que ele use um parâmetro do recurso Configuração remota para determinar qual modelo vai ser usado. Primeiro, defina o modelo atual do aplicativo como valor padrão desse parâmetro. Como o nome do modelo é controlado por um parâmetro de configuração remota, é possível alterar e fazer experimentos com diferentes modelos sem a necessidade de publicar atualizações do aplicativo para os usuários.

Dessa forma, ao publicar seu modelo atual com o nome plant_labeler_v1, você define, no código de inicialização do seu app, plant_labeler_v1 como valor padrão do parâmetro plant_labeler_model, conforme o exemplo a seguir:

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

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, altere o código de configuração do modelo para carregar o modelo especificado pelo parâmetro plant_labeler_model:

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

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 app usa um parâmetro da Configuração remota para determinar qual modelo carregar, é possível publicar um novo modelo e atribuir o nome dele ao parâmetro da Configuração remota para substituir o anterior. Com esse recurso, o Teste A/B atribui modelos diferentes a usuários diferentes com o objetivo de compará-los.

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

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

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 no Analytics, que você usará posteriormente como o evento de ativação do experimento. O usuário precisa acionar o evento de ativação antes de ser considerado para fazer parte do experimento. Isso garante que os usuários não sejam registrados no Teste A/B até que o dispositivo conclua o download do seu modelo de ML personalizado.

2. Determinar uma métrica de meta

A próxima etapa é decidir como mensurar o sucesso do seu modelo e verificar se o aplicativo está 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 internas, como "Receita", "Engajamento diário" e "Retenção de usuários". Na maioria dos casos elas são úteis para testar diferentes fluxos de experiência do usuário ou fazer ajustes precisos de parâmetros, mas podem não ser ideais para avaliar seu modelo e caso de uso. Nesses casos, otimize um evento personalizado no Analytics em vez de usar métricas.

Por exemplo, no recurso hipotético de pesquisa visual de plantas, suponha que você apresentou os resultados da pesquisa ao usuário na ordem de confiança do modelo em cada resultado. Observe a frequência com que os usuários abriram o primeiro resultado da pesquisa para verificar a precisão do seu modelo.

Para testar qual modelo melhor cumpriu o objetivo de maximizar cliques nos resultados principais, registre um evento personalizado sempre que um usuário tocar no primeiro item da lista.

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

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

A métrica a ser testada depende, basicamente, da maneira que o aplicativo usa seu modelo.

Neste ponto, é possível implantar o aplicativo na Play Store. O app vai continuar usando seu modelo original, mas o código da Configuração remota e do Analytics que você adicionou vai possibilitar a realização de experimentos com modelos diferentes usando apenas o Console do Firebase.

3. Executar um experimento do Teste A/B

Agora que seu aplicativo está nas mãos dos usuários e coletando dados de análise, crie um experimento do Teste A/B para avaliar o efeito do novo modelo no lugar do modelo atual.

Siga as etapas a seguir para criar o experimento:

1. Na página Eventos do Console do Firebase, verifique se você registrou os eventos relevantes do Analytics: o evento de ativação e a métrica de meta.

   É preciso que seu aplicativo registre cada evento pelo menos uma vez para que ele apareça no Console do Firebase.

2. No Console do Firebase, abra a seção Teste A/B.

3. Crie um novo experimento:

   1. Clique em Criar experimento > Configuração remota.

   2. Na seção Segmentação, siga as etapas a seguir:

      • Escolha seu aplicativo na lista.
      • Especifique quantos usuários você quer incluir no experimento.
      • Selecione o evento de ativação que você começou a registrar (neste exemplo, nondefault_model_downloaded)

   3. Na seção Metas, escolha a métrica determinada na seção anterior (neste exemplo, first_result_opened) na lista de métricas de meta e selecione as outras que você quer rastrear, como "Receita de compra" ou "Usuários sem falhas".

   4. Na seção Variantes, defina as duas a seguir:

      • Grupo de controle (criado automaticamente)
      • Rotulador de plantas experimental

      Para o grupo de controle, crie um parâmetro plant_labeler_model e defina-o como plant_labeler_v1. Os usuários atribuídos a esse grupo utilizarão o modelo antigo. Não defina o parâmetro como (no change) porque, no seu aplicativo, você está testando se está usando um valor remoto.

      Para a variante Rotulador de plantas experimental, defina o parâmetro plant_labeler_model como plant_labeler_v2 (supondo que você tenha publicado seu novo modelo com esse nome). Os usuários atribuídos a essa variante usarão o novo modelo.

   

Inicie e execute o experimento por vários dias ou mais, até que o Teste A/B selecione a variante vencedora. Poderá ser necessário expandir a experiência para mais usuários se o experimento não determinar um líder.

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

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

Na seção Teste A/B do Console do Firebase, abra a visualização de detalhes do experimento concluído. Nela, você verá o desempenho de cada variante de acordo com a métrica da meta e outras métricas secundárias selecionadas. Com essas informações, você pode optar pela distribuição da variante líder ou de outra variante.

Para distribuir uma variante a todos os usuários, clique em more_vert > Distribuir 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 app, altere o valor padrão do parâmetro plant_labeler_model para plant_labeler_v2 e atualize o modelo agrupado, caso você use um. No entanto, seus usuários já usarão o modelo mais recente, por isso, é possível enviar essa atualização como parte do aplicativo publicado sempre que for conveniente, como quando você fizer uma atualização de recursos.