Como executar vários experimentos ao mesmo tempo usando um grupo de controle adaptável

O teste A/B está morrendo e estou aqui para isso. A avaliação discreta e com limite de tempo de um pequeno conjunto de intervenções (às vezes apenas uma intervenção) simplesmente não produz resultados acionáveis de forma consistente e duradoura.

• Há muitas coisas que você poderia testar. Em qualquer situação de negócios do mundo real, o número de itens a serem testados torna-se muito rápido — se você estiver usando uma estrutura de teste A/B. A sobrecarga é uma limitação da abordagem de teste, não um recurso do ambiente de teste.

  
  

• Pode levar muito tempo para executar um teste e muito, muito tempo para executar muitos testes . Você deve ter cuidado para que testes diferentes não se sobreponham nos usuários que eles afetam. Você tem que evitar dias e locais que a empresa não está disposta a amarrar em um teste. Ele monopoliza muitos recursos para executar testes A/B.

  
  

• Um teste potencialmente sacrifica muito impacto na variante perdedora - se você executar A x B por um mês e descobrir que A teve um desempenho muito melhor, isso significa que você mostrou a metade de seus usuários a variante de baixo desempenho por um mês inteiro. Você perdeu todo esse valor. Ninguém está feliz com isso.

  
  

• A eficácia a longo prazo de um teste nunca é certa. O impacto de qualquer escolha que você fizer pode ser influenciado pela hora do dia, dia da semana, hora do mês, época do ano, eventos mundiais, mudanças no mercado - apenas porque A foi melhor que B no mês em que você o testou, não significa que será sempre melhor. E nenhum teste A/B pode dizer o prazo de validade de seus resultados.

Se você quiser uma discussão um pouco mais aprofundada sobre os problemas com o teste A/B, o pessoal da [Babbel](https://Executar vários experimentos ao mesmo tempo usando um grupo de controle adaptativo) tem uma boa apresentação sobre o assunto, e este tutorial sobre feedback de bandidos é uma ótima perspectiva de vários líderes da indústria.

Bandidos multi-armados são o futuro, e o futuro é agora, e agora temos novos problemas.

Em uma configuração de teste A/B tradicional, você tem a variante A e a variante B. Na maioria das situações do mundo real, A ou B é “melhor” apenas no sentido estatístico.

Se você fizer um teste e A obtiver uma taxa de sucesso de 20% e B obtiver uma taxa de sucesso de 10%, A claramente “vencerá”... mas e as pessoas que responderam a B? Eles vão ficar bem com a obtenção de A? Tanto os testes A/B quanto os algoritmos de bandidos forçam você a sacrificar suas preferências minoritárias pelo bem da maioria. Não precisa ser assim - é assim que esses instrumentos específicos funcionam. Uma estratégia melhor é obter a opção A para as pessoas que preferem a opção A e a opção B para as pessoas que respondem à opção B. Então:

• Envie a opção A para 100 pessoas e a opção B para 100 pessoas.
• A taxa de sucesso de 20% da Opção A significa que você obteve 20 sucessos.
• A taxa de sucesso de 10% da Opção B significa que você obteve 10 sucessos.

Sejamos generosos e assumamos que metade das pessoas que responderam à opção B, na verdade, teriam respondido à opção A se tivessem visto isso.

Que significa:

• Mostrar apenas a opção A após a conclusão do teste gera uma taxa de sucesso de 12,5% (os 20 que responderam a A, mais os 5 que responderam a B, mas teriam respondido a A, divididos pelo total de 200 pessoas em ambos os grupos).
• Enviar a opção A para pessoas que desejam A e B para pessoas que desejam B gera uma taxa de sucesso de 15%.

Portanto, ajustando a forma como você implanta cada tratamento com base nos resultados baseados, você deixa menos valor na mesa. Isso é tudo que um algoritmo bandido faz - ele protege as apostas: B tem metade do sucesso de A, então você realmente mostra B metade do tempo. Você pode fazer isso com muitas opções diferentes ao mesmo tempo (não apenas A e B), a implantação e o reajuste automáticos tornam menos oneroso executar testes, você não sacrifica tanto valor para perder variantes e o sistema pode ajuste às mudanças nas preferências do usuário ou ao ambiente de decisão mais amplo.

Todos os problemas do teste A/B resolvidos!

Mas isso pode sair pela culatra.

Com que frequência você vai mostrar B para as pessoas que preferem A, ou mostrar A para pessoas que preferem B, porque está baseando sua decisão em estatísticas agregadas em vez de preferências individuais? Na verdade, é possível que o algoritmo do bandido tenha um desempenho pior do que o teste A/B nesses tipos de situações. E, claro, todas essas coisas podem mudar com o tempo. Talvez metade das pessoas que gostaram de B realmente mude com o tempo para preferir A. E um quarto das pessoas que gostaram de A mude com o tempo para gostar de B. Suas estatísticas agregadas e, portanto, a decisão que você tomará sobre o que mostrar a quem , permanecerá exatamente o mesmo. Isso não é o ideal.

Algoritmos de bandidos regulares carregam custos ocultos - ou melhor, eles pegam os custos de testes A/B e os embaralham em lugares diferentes para que você não perceba tão facilmente. Você configura seu algoritmo e começa a enviar e tudo parece ótimo… até você começar a perceber alguns dos problemas que mencionei nos parágrafos anteriores. Talvez o equilíbrio de preferências para A vs. B seja diferente para, digamos, novos usuários do que para usuários recorrentes. Talvez essas preferências sejam diferentes para diferentes geografias. Talvez até usuários experientes possam ser divididos em usuários avançados e usuários regulares. É por isso que as pessoas inventarambandidos contextuais , que é apenas uma palavra chique para bandidos mais segmentação.

Agora você precisa fazer muito mais relatórios para entender quais segmentos de sua base de usuários podem ter diferentes perfis de preferência. Então você reduziu os relatórios necessários para analisar experimentos, mas aumentou os relatórios necessários para definir o escopo do seu bandido. E você aumentou a quantidade de trabalho necessária para transformar esse relatório em escopo real. E depois de ter esses segmentos diferentes, você percebe que talvez precise de mais criativos para levar esse contexto em consideração, então isso dá mais trabalho. E há o trabalho de engenharia para construir os dutos que levarão o usuário certo ao bandido certo. E há o trabalho que você precisa fazer em seu sistema de mensagens para garantir que ele suporte todas essas coisas acontecendo em segundo plano.

Assim, os bandidos resolvem muitos problemas de teste A/B, mas os bandidos que são realmente eficazes criam novas necessidades analíticas e novos obstáculos logísticos que não são fáceis de resolver. Essa é uma das razões pelas quais o teste A/B ainda é tão popular: o processo é comum o suficiente para que haja muitas ferramentas para ajudar no trabalho pesado.

O teste dinâmico requer avaliação dinâmica, que requer um grupo de controle dinâmico.

Então, ajudei a projetar e construir um produto que torna fácil o teste contextual complexo de bandido - tão fácil que cria um contexto separado para cada usuário individual em seu site ou aplicativo. Você pode encontrar mais detalhes sobre esse produto aqui , esse não é o objetivo deste post, então não vou falar mais sobre isso. O que quero falar aqui é como resolvemos o problema de avaliar centenas de milhares de testes adaptativos individualizados por dia.

Os detalhes podem ser encontrados em nosso artigo sobre arXiv .

Já escrevi antes sobre os desafios práticos, analíticos e às vezes até éticos inerentes à construção de um grupo de resistência para avaliar experimentos. Eu ainda defendo isso. Avaliamos nossos experimentos adaptativos usando um controle sintético , porque isso não envolve privar nenhum usuário de intervenções potencialmente benéficas. No entanto, os métodos de controle sintéticos tradicionais podem estar cheios de armadilhas analíticas, porque você está essencialmente modelando o processo de geração de dados de linha de base para o ambiente no qual está conduzindo seu experimento. Acrescente muitos e muitos experimentos paralelos, muitos dos quais ocorrem em ambientes sobrepostos, e uma solução analítica para o problema de controle torna-se... assustadora.

É por isso que não seguimos esse caminho.

Gary King e seus colegas em Harvard, vários anos atrás, criaram um método maravilhosamente simples para extrair inferência causal a partir de dados de observação. É chamado Coarsened Exact Matching (CEM). Você pode encontrar o artigo seminal aqui e os fundamentos teóricos aqui .

A ideia é simples:

1. Colete todas as suas observações de sua intervenção (teste) ocorrendo.
2. Colete um monte de observações onde a intervenção não ocorreu, mas poderia ter ocorrido.
3. Escolha atributos que possam medir a similaridade entre qualquer par particular de observações dos dois grupos.
4. Atributos “grosseiros” em variáveis categóricas. Portanto, se “idade” for um atributo, você pode classificá-lo em categorias de idade.
5. Combine cada observação de intervenção com uma observação de não intervenção com base na correspondência exata de atributos grosseiros. Isso significa que você escolherá apenas um subconjunto de observações de não intervenção e, muitas vezes, também acabará descartando algumas de suas observações de intervenção, mas o que resta será correspondido.
6. Modele a diferença entre os dois grupos refinados.

O CEM afasta a complexidade da inferência causal dos métodos analíticos — você pode usar qualquer método de sua preferência — e a coloca nos métodos de criação de conjunto de dados. É semelhante, conceitualmente, à sobreamostragem ou subamostragem de um conjunto de dados de desequilíbrio em um problema de classificação.

O que percebemos foi que poderíamos usar esse mesmo tipo de lógica para encontrar contextos de controle apropriados para nossos experimentos de bandidos, incluindo o tempo como um dos recursos para combinar. Já combinamos certos atributos de intervenção – o tipo de intervenção que um usuário recebeu e o nível de atividade que o usuário exibiu no aplicativo no momento da intervenção. Mas também definimos uma janela de observação e garantimos que qualquer usuário correspondente receberá uma intervenção em um período de tempo próximo à intervenção para a qual estamos buscando um controle, mas não dentro do período de observação da própria intervenção.

Isso nos permite ter controles correspondentes no nível do usuário para a maioria dos testes que executamos. Os algoritmos Bandit eliminam parte da complexidade do teste A/B em escala, mas ocultam outras partes dessa complexidade. Nosso método de controle pega essa complexidade oculta e a resolve para que possamos obter os benefícios adaptativos da atribuição de bandidos, mas a clara inferência e atribuição do teste A/B.

Então aqui está sua lista de tarefas:

1. Para cada intervenção que você fizer, identifique uma janela de visualização e uma janela de visualização. A janela de visualização é o que você usa para ver como o usuário respondeu à intervenção, e a janela de visualização é onde você procura os casos de controle.
2. Para cada intervenção, identifique um conjunto de outras intervenções que (1) ocorreram dentro da janela de visualização posterior e (2) não possuem uma janela de visualização antecipada que se sobreponha à janela de visualização antecipada da intervenção que você está procurando um controle.
3. Combine os usuários que receberam essas possíveis intervenções de controle com o usuário que recebeu a intervenção para a qual você está buscando um controle. Você pode combinar qualquer critério que desejar - nível de atividade, similaridade de intervenção recebida, etc.
4. Selecione aleatoriamente um usuário daqueles que passam pelo processo de correspondência.
5. Finja que você enviou a intervenção original não apenas para o usuário que realmente a recebeu, mas também para o usuário que você selecionou como controle.
6. Meça a diferença na resposta entre seus usuários de teste e controle para qualquer período de tempo em que você esteja interessado.

Novamente, você pode encontrar mais informações no paper sobre arXiv .