Multi-Armed Bandits x Teste A/B: o Guia Completo

Todo mundo que roda testes o bastante esbarra na mesma frustração: enquanto o seu teste A/B ainda está rodando, metade do tráfego continua vendo a variação que, aos poucos, vai ficando claro que é a pior. Isso é o preço combinado de testar com rigor, você paga com “custo de oportunidade” para comprar uma resposta confiável. Só que existe uma família inteira de algoritmos desenhada exatamente para reduzir esse preço: os multi-armed bandits.

Bandit não é um substituto do teste A/B, é uma ferramenta com um objetivo diferente. Este guia explica o que é um bandit, como ele decide para onde mandar cada visitante, quando ele vale mais que um A/B clássico (e quando não vale), e mostra, com números de verdade calculados pelo mesmo motor estatístico que roda as calculadoras deste blog, quanto custa cada abordagem no mesmo cenário. No fim, uma tabela neutra compara o que VWO, Optimizely, Kameleoon e outras ferramentas do mercado realmente publicam sobre o tema, com fonte para cada claim.

O que é um multi-armed bandit

O nome vem de uma imagem antiga de cassino: um “bandido de um braço só” (one-armed bandit) é a máquina caça-níquel clássica, com uma alavanca. Um multi-armed bandit é o problema de decisão de alguém em frente a várias dessas máquinas ao mesmo tempo, cada uma com uma taxa de pagamento desconhecida e possivelmente diferente das outras. A cada jogada, você escolhe uma máquina, puxa a alavanca e observa o resultado. O objetivo é simples de enunciar e difícil de resolver bem: maximizar o total ganho ao longo de todas as jogadas, sabendo que quanto mais você joga numa máquina, mais aprende sobre ela, mas também abre mão de jogar nas outras.

Troque “máquina” por “variação da sua página” e “jogada” por “visitante”, e você tem o problema exato que um bandit resolve num teste online. Cada variação (A, B, C…) é um braço. Cada visitante que chega é uma jogada. A “taxa de pagamento” de cada braço é a taxa de conversão real daquela variação, que você não conhece de antemão e só vai estimando com mais precisão conforme o tráfego chega.

A diferença de postura em relação a um teste A/B é sutil, mas muda tudo o que vem depois: um teste A/B trata a fase de coleta de dados e a fase de decisão como duas etapas separadas (primeiro você junta evidência com uma divisão fixa, depois decide). Um bandit trata a coleta e a decisão como a mesma coisa, acontecendo em tempo real, jogada a jogada.

Bandit x teste A/B: a diferença central

Um teste A/B clássico é um experimento de horizonte fixo: você decide, antes de começar, a alocação de tráfego (normalmente 50/50) e o tamanho de amostra necessário, roda até chegar lá, e só então declara um vencedor. A alocação não muda um milímetro entre o primeiro visitante e o último, mesmo que no meio do caminho já esteja claro que uma variação está perdendo feio.

Um bandit realoca o tráfego continuamente. Ele começa perto de uma divisão igualitária (porque, no início, não sabe qual braço é melhor) e vai empurrando mais visitantes para o braço que parece vencer, ao mesmo tempo em que reduz, sem zerar, o tráfego para os braços que parecem perder. A cada nova conversão observada, a estimativa de cada braço é atualizada e a alocação se ajusta de novo.

Isso cria uma troca (trade-off) bem definida, e é o coração deste guia inteiro:

• O ganho do bandit: menos “custo de oportunidade” durante o próprio teste. Como o tráfego migra para o que está indo bem antes do fim, você perde menos conversões possíveis enquanto ainda está aprendendo.
• A perda do bandit: ele não produz um valor-p, nem uma significância estatística no sentido clássico, no final. A Optimizely documenta isso de forma direta: multi-armed bandits não geram significância estatística e não usam um controle ou linha de base formal; o resultado que você recebe é a melhora de desempenho sobre uma divisão igualitária, não um veredito estatístico com nível de confiança associado.

Em outras palavras: A/B otimiza para aprender com rigor; bandit otimiza para ganhar durante o aprendizado. Nenhuma das duas é “melhor” de forma absoluta, elas resolvem problemas diferentes, e escolher a errada para o seu caso custa caro dos dois lados: rodar A/B quando o custo da variação perdedora é alto desperdiça conversão à toa; rodar bandit quando você precisa defender uma decisão formalmente te deixa sem o número que sustenta a defesa.

Como funciona na prática: exploração x explotação

O nome técnico para a troca que todo bandit resolve é exploration/exploitation trade-off (exploração x explotação). Explorar é gastar tráfego em braços sobre os quais você ainda tem pouca certeza, na esperança de descobrir que um deles é, na verdade, o melhor. Explotar é concentrar tráfego no braço que, com a informação disponível até agora, parece o melhor.

Um algoritmo que só explora nunca converge, ele fica jogando às cegas para sempre e desperdiça conversão testando braços ruins indefinidamente. Um algoritmo que só explota (sempre escolhe o braço que parece melhor com base nos primeiros dados) corre o risco de travar cedo demais numa escolha errada, porque os primeiros dados de qualquer braço são ruidosos: um braço genuinamente melhor pode parecer pior nas primeiras dezenas de visitantes, só por acaso, e um algoritmo puramente guloso nunca lhe daria uma segunda chance depois disso. Os três algoritmos clássicos resolvem esse equilíbrio de formas diferentes.

Epsilon-greedy: o mais simples de explicar

O epsilon-greedy reserva uma fatia fixa e pequena de tráfego, chamada epsilon (ε, por exemplo 10%), para exploração pura e aleatória entre todos os braços, e manda o resto (1-ε) sempre para o braço que parece melhor no momento. É fácil de implementar e de explicar, mas tem um defeito estrutural: ele explora do mesmo jeito o tempo todo, gastando os mesmos 10% em braços claramente ruins depois de milhares de visitantes quanto gastava no primeiro dia, quando a incerteza era genuína. Variações do método (como o epsilon decrescente, que reduz ε aos poucos) tentam corrigir isso à mão, mas continuam sendo um ajuste manual, não uma resposta automática à incerteza real de cada braço.

UCB (Upper Confidence Bound): otimismo diante da incerteza

O UCB troca a exploração aleatória por uma regra mais elegante: para cada braço, ele calcula a taxa de conversão estimada mais um bônus de otimismo, proporcional à incerteza sobre aquele braço (quanto menos dados, maior o bônus), e escolhe sempre o braço com o maior valor combinado. Um braço pouco testado ganha um “benefício da dúvida” automático que o torna atrativo mesmo com uma taxa estimada mediana, o que empurra exploração exatamente para onde falta informação, sem precisar de um parâmetro fixo como o ε. Conforme mais dados chegam, o bônus de cada braço encolhe e a escolha converge naturalmente para o de fato melhor.

Thompson Sampling: o padrão de produção bayesiano

O Thompson Sampling é o algoritmo que mais aparece em produção quando a base é bayesiana, exatamente o terreno onde a Donnu já opera. A ideia, explicada sem fórmula: para cada braço, você mantém uma distribuição de probabilidade (o “quão provável é cada taxa de conversão possível daquele braço”, dado o que já foi observado, tipicamente uma distribuição Beta quando a métrica é uma taxa de conversão). A cada novo visitante, o algoritmo sorteia um valor aleatório da distribuição de cada braço e manda o visitante para o braço que sorteou o maior valor. Depois, atualiza a distribuição daquele braço com o resultado observado (converteu ou não), deixando a curva mais estreita e mais precisa.

O truque é que essa amostragem aleatória já embute o equilíbrio certo entre explorar e explotar, sem precisar de nenhum parâmetro manual como o ε do epsilon-greedy. Um braço com poucos dados tem uma distribuição larga (muita incerteza), então às vezes o sorteio tira um valor bem alto dele mesmo que a média pareça mediana, e ele acaba recebendo tráfego de exploração de forma orgânica. Um braço com muitos dados e uma taxa claramente ruim tem uma distribuição estreita e baixa, então quase nunca sorteia um valor alto o bastante para ser escolhido, o que reduz o tráfego que vai para ele sem zerá-lo de vez.

Essa é também a razão de o Thompson Sampling se encaixar tão bem num produto que já é bayesiano por padrão: a distribuição de crença sobre cada braço é exatamente o mesmo tipo de objeto que um motor bayesiano de teste A/B já calcula para responder “qual a probabilidade de B ser melhor que A”. Bandit e teste A/B bayesiano compartilham a mesma matemática de fundo; a diferença está no que você faz com ela: decidir tráfego em tempo real, ou reportar uma probabilidade no fim.

Quando usar bandit em vez de A/B (e quando não usar)

A pergunta certa não é “qual é melhor”, é “o que essa decisão específica precisa”. Bandit tende a valer mais quando:

• O custo de mostrar a variação perdedora é alto e imediato. Testar preços, por exemplo: cada visitante que vê o preço “errado” é uma venda potencialmente perdida agora, não só um dado estatístico. Um bandit reduz essa sangria mais rápido que um A/B 50/50 fixo.
• O tráfego é altíssimo e a decisão é de otimização contínua, não um marco único. Uma manchete de home page com milhões de visitas por dia, ou um algoritmo de recomendação que precisa se adaptar sem parar, se encaixa melhor num bandit rodando continuamente do que numa sequência de testes A/B encerrados um a um.
• Você tem muitos candidatos (A/B/n com dezenas de variações) e não pode dar tráfego igual para todos. Um bandit já aloca menos tráfego para os braços fracos desde cedo, o que evita queimar amostra em variações claramente piores.

A/B clássico continua sendo a escolha certa quando:

• Você precisa de uma resposta que aguenta ser defendida formalmente. Uma decisão de produto ou de negócio que vai ser citada num relatório, apresentada a um investidor ou usada para justificar um investimento maior geralmente exige um número com nível de confiança, não “melhorou sobre uma divisão igualitária”.
• A mudança precisa durar e ser analisada por segmento depois. Se você quer saber como a variação performou em mobile x desktop, por canal de aquisição, ou por coorte, precisa de dados coletados sob uma alocação estável e comparável, exatamente o que um bandit, ao mudar a alocação o tempo todo, dificulta.
• A decisão é binária e definitiva: trocar de fornecedor de checkout, redesenhar o fluxo de cadastro, ou qualquer mudança onde reverter é caro. Você quer um veredito claro de “isso funciona, sim ou não”, não uma otimização contínua.

O trade-off que ninguém esconde

Vale repetir com todas as letras, porque é a parte que o marketing de “otimização automática” tende a suavizar: um bandit não produz um vencedor declarado com 95% de confiança da mesma forma que um teste A/B. A documentação da própria Optimizely é direta sobre isso, multi-armed bandit optimizations não geram significância estatística; o algoritmo otimiza o total de conversões realocando tráfego para a variação que está performando melhor no momento, sem analisar formalmente por que uma variação supera a outra, e sem usar um controle ou linha de base no sentido do A/B clássico.

Isso não é um defeito de implementação que algum fornecedor vai corrigir num próximo release, é a natureza do problema que o bandit resolve. Bandit é uma ferramenta de otimização (maximizar o resultado acumulado durante o período de teste); A/B é uma ferramenta de inferência causal (estimar, com uma margem de erro conhecida, se uma mudança específica causa uma melhora específica). São perguntas diferentes, e um bom bandit responde bem à primeira sem responder à segunda.

Na prática, isso importa no momento em que você precisa defender a decisão. “A variação B converteu 30% mais e recebeu a maior parte do tráfego ao longo do teste” é uma frase legítima para um bandit, mas não carrega o mesmo peso de “B converteu 30% mais, com valor-p de 0,003 e intervalo de confiança de 95% entre +0,5 e +2,5 pontos percentuais”, a frase que um teste A/B devidamente dimensionado permite dizer. Se a sua cultura de decisão exige o segundo tipo de frase (para um conselho, um investidor, ou só para o próprio time de produto dormir tranquilo), o bandit sozinho não entrega isso, mesmo que ele tenha, de fato, entregue mais conversão durante o processo.

Um exemplo numérico trabalhado

Para sair da teoria, vamos usar o mesmo motor estatístico que roda as calculadoras deste blog e comparar, com números concretos, o que um teste A/B fixo custa em oportunidade perdida frente a um bandit adaptativo, no mesmo cenário.

O cenário: uma página com 10.000 visitantes por semana, taxa de conversão atual de 5%, e uma variação B que, na realidade (embora você não saiba disso de antemão), converte 6,5%, o mesmo lift de 30% relativo usado como exemplo no guia de significância estatística deste blog. Você quer detectar um efeito mínimo de 10% relativo, com 95% de confiança e 80% de poder, o padrão de mercado.

Rode esses números na calculadora abaixo (ela já está com esse cenário preenchido) e confira o tamanho de amostra e a duração:

Taxa de conversão atual%Efeito mínimo detectávelrelativo (%)absoluto (pp)Confiança909599%Poder8090%Visitantes por semana (total)Testebilateralunilateral

-Visitantes por variação

-Total (2 variações)

-Duração estimada

Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.

O motor de amostra deste blog (o mesmo de src/lib/stats.ts, sem alterações na matemática congelada) devolve 31.234 visitantes por variação, 62.468 no total, rodando por 44 dias com esse tráfego semanal.

O custo do A/B fixo 50/50

Durante os 44 dias inteiros, metade do tráfego (31.234 visitantes) continua vendo a variação A, mesmo que, bem antes do fim, os dados já estejam apontando para B. Fazendo a conta de conversões esperadas nesse desenho:

• Conversões esperadas de A: 31.234 × 5% ≈ 1.562.
• Conversões esperadas de B: 31.234 × 6,5% ≈ 2.030.
• Total esperado com A/B fixo: ≈ 3.592 conversões nos 62.468 visitantes.

Agora, o teto teórico: se todo o tráfego, desde o primeiro visitante, tivesse ido para B (a variação de fato melhor, num cenário hipotético onde você já soubesse disso com certeza absoluta), o resultado seria:

• 62.468 × 6,5% ≈ 4.060 conversões.

A diferença, ≈ 468 conversões, é o “custo de oportunidade” que o desenho 50/50 fixo paga por sua própria disciplina: ele mantém metade do tráfego na variação inferior do início ao fim, porque a alocação foi decidida antes de qualquer dado chegar e não muda até o teste acabar. É exatamente esse custo que um bandit tenta reduzir.

Uma alocação adaptativa no mesmo cenário

Para ilustrar a lógica (não para simular com exatidão nenhum motor comercial específico, já que a curva real depende do algoritmo, do prior escolhido e da variância observada), vamos dividir os mesmos 44 dias e os mesmos 62.468 visitantes em três fases, com a alocação para B subindo conforme a evidência se acumula:

Fase	Dias	Visitantes (aprox.)	Alocação para B	Alocação para A
1: ainda incerto	1 a 11	~15.617	50%	50%
2: evidência começa a aparecer	12 a 26	~21.296	65%	35%
3: evidência forte, mas nunca 100%	27 a 44	~25.555	80%	20%

Somando as duas variações ao longo das três fases: A recebe cerca de 20.374 visitantes e B cerca de 42.095. As conversões esperadas ficam assim:

• A: 20.374 × 5% ≈ 1.019 conversões.
• B: 42.095 × 6,5% ≈ 2.736 conversões.
• Total ilustrativo com bandit adaptativo: ≈ 3.755 conversões.

Comparando os três números lado a lado, com o mesmo tráfego total:

O ponto central deste exemplo não é o número exato (que muda com o algoritmo, o prior e a taxa real de conversão), é a forma do resultado: um bandit bem configurado fica sistematicamente entre o A/B fixo e o teto teórico, nunca alcançando o teto porque nenhum bandit sério para de explorar por completo (isso seria apostar tudo numa leitura que ainda pode estar errada), mas também nunca ficando tão atrás quanto uma divisão 50/50 mantida do início ao fim. E, como visto acima, ele entrega esse ganho sem produzir, ao final, um valor-p ou uma significância no sentido clássico.

Tabela comparativa: A/B clássico x bandit x bandit contextual

Critério	A/B clássico	Bandit (simples)	Bandit contextual
Alocação de tráfego	Fixa (ex.: 50/50) do início ao fim	Muda ao longo do tempo, conforme a evidência	Muda por visitante, conforme o contexto dele
Produz significância estatística formal	Sim, valor-p e intervalo de confiança	Não, no sentido clássico (Optimizely é explícita sobre isso)	Não, no sentido clássico
Melhor para	Decisões que precisam ser defendidas e documentadas	Otimização contínua, custo alto de mostrar a variação perdedora	O “vencedor” muda por perfil (dispositivo, canal, comportamento)
Análise por segmento depois do teste	Direta, a alocação foi estável	Difícil, a alocação já mudou sozinha durante o teste	É o próprio objetivo do método
Exige mais dado/infraestrutura	Não, é o desenho mais simples	Um pouco mais (atualização contínua)	Bem mais (modelo por atributo de contexto, dados em tempo real)
Risco de decisão errada	Baixo, se dimensionado e rodado corretamente	Baixo custo de oportunidade, mas sem prova formal de causa	O mesmo do bandit simples, mais a complexidade de manter vários modelos

Nenhuma linha dessa tabela é “sempre a melhor”. Ela existe para você escolher com base no que a sua decisão específica exige, e não pelo que soa mais moderno.

Ferramentas que oferecem bandits (visão neutra)

Boa parte do mercado de teste A/B já oferece algum sabor de bandit, geralmente como um recurso ao lado do A/B clássico, não como substituto dele. Vale olhar o que cada fornecedor publica sobre a própria abordagem, com a devida ressalva de que specs de produto mudam e o melhor lugar para confirmar detalhes é sempre a documentação oficial mais recente.

• VWO (SmartStats). A VWO documenta seu SmartStats como um motor bayesiano, com um prior não informativo (todas as taxas de conversão possíveis começam igualmente prováveis) que vai sendo atualizado conforme os dados chegam, permitindo monitorar o teste continuamente sem a penalidade estatística de um desenho frequentista fixo. A própria VWO, em seu help center oficial, afirma que a técnica reduz o tempo de teste pela metade frente ao desenho tradicional. Vale o hedge de sempre: números de redução de tempo divulgados por um fornecedor sobre o próprio produto merecem ser lidos como o melhor cenário da empresa, não como uma média garantida para qualquer conta.
• Optimizely (multi-armed bandit e contextual bandit). A Optimizely documenta os dois formatos separadamente. O bandit simples busca a única variação de melhor desempenho para todo mundo; o bandit contextual, que a empresa descreve como parte da sua camada de IA (Opal), personaliza a escolha por atributos do visitante, como dispositivo, localização ou histórico de comportamento. Como já citado, a documentação da Optimizely é clara ao afirmar que otimizações de bandit não geram significância estatística nem usam um controle formal, ao contrário do produto de experimentação clássica da mesma empresa.
• Kameleoon (CUPED). A Kameleoon não vende bandit como diferencial central, vende CUPED (Controlled Experiment Using Pre-Experiment Data), uma técnica de redução de variância baseada no método de variáveis de controle: ela usa dados de antes do experimento como covariável para reduzir o ruído da métrica medida, sem precisar de mais tráfego. A própria Kameleoon relata redução de até 60% no tamanho de amostra necessário com a técnica bem aplicada. CUPED e bandit resolvem problemas diferentes (CUPED acelera um A/B clássico que continua produzindo significância; bandit troca a significância formal por otimização contínua), e vale não confundir os dois quando estiver comparando fornecedores.
• Spotify Engineering (separação entre personalização e experimentação). Em janeiro de 2026, a Spotify publicou no seu blog de engenharia uma descrição de como a empresa separa deliberadamente a pilha técnica que faz personalização, que inclui bandits contextuais, da pilha que faz experimentação formal. O artigo ilustra um bandit contextual escolhendo entre variações de um botão de checkout com base em atributos do visitante (como carrinho, idade e localização), em vez de rodar um A/B tradicional para achar “o” botão vencedor único. E reforça o ponto central deste guia: um algoritmo de recomendação que só otimiza para engajamento imediato, sugerindo sempre músicas já conhecidas, melhora as métricas de curto prazo mas pode reduzir a descoberta de conteúdo novo e prejudicar a satisfação de longo prazo. O ponto que mais importa para este guia: mesmo tendo bandits rodando em produção, a Spotify ainda avalia esses sistemas através de testes A/B formais comparando versões deles, exatamente a divisão de trabalho que este artigo defende, otimização contínua de um lado, veredito formal do outro.

Ferramenta	Abordagem divulgada	O que fica de fora sem confirmação direta
VWO	Bayesiano (SmartStats), prior não informativo, teste sequencial	Redução de tempo “pela metade” é número divulgado pela própria empresa
Optimizely	MAB simples e contextual (via Opal), documentação explícita de que não gera significância	Detalhes do algoritmo exato de bandit usado internamente
Kameleoon	CUPED (redução de variância, não bandit em si)	Se a empresa oferece bandit nativo além de CUPED, confira a documentação atual
Spotify Engineering	Bandits contextuais em produção (personalização), avaliados por A/B formal à parte	Detalhes de implementação são internos, o artigo público é de alto nível

A Donnu A/B se posiciona nesse mapa como uma ferramenta bayesiana nativa: o mesmo motor que já calcula “qual a probabilidade de B ser melhor que A” para um teste clássico é a base matemática de que um bandit como o Thompson Sampling precisa. Hoje o produto foca em teste A/B com leitura bayesiana honesta; bandit é a extensão natural desse motor, não um recurso genérico colado por cima.

Faça Isso Automático na Donnu

Você acabou de ver os dois lados reais dessa escolha: um teste A/B clássico entrega um veredito que aguenta ser defendido, com valor-p, intervalo de confiança e uma alocação estável fácil de analisar depois por segmento, ao custo de manter tráfego na variação perdedora até o fim. Um bandit reduz esse custo de oportunidade realocando tráfego em tempo real, ao custo de não entregar, ao final, uma significância estatística formal. Nenhuma ferramenta te livra de escolher: você ainda precisa decidir se a sua situação pede rigor de inferência causal ou otimização contínua, e a resposta muda de teste para teste.

A Donnu já roda hoje sobre um motor bayesiano nativo, exatamente a base matemática que sustenta os dois mundos: o mesmo cálculo de “qual a probabilidade de B ser melhor que A” que declara um vencedor honesto num A/B também é o que alimenta um bandit como o Thompson Sampling quando a decisão pede otimização contínua em vez de um veredito único. Você não precisa escolher a ferramenta certa às cegas, a Donnu já parte da estatística que os dois cenários exigem.

Leia também o que é teste A/B e como funciona, significância estatística explicada com a fórmula por trás, o problema do peeking e por que parar cedo estraga um teste, e a peça-irmã deste guia, bandit contextual explicado, para quando o “vencedor” muda de acordo com quem está olhando.

Comece um teste grátis de 14 dias e rode o seu próximo experimento sobre uma base estatística que já é bayesiana por padrão.

Referências

• Optimizely. Run a multi-armed bandit (MAB) optimization in Feature Experimentation e Multi-armed bandit (glossário). docs.developers.optimizely.com e optimizely.com/optimization-glossary/multi-armed-bandit.
• Optimizely. Run Contextual Multi-Armed Bandit optimizations. docs.developers.optimizely.com.
• VWO. Enhanced SmartStats, Bayesian powered sequential testing engine. vwo.com/why-us/technology/statistics.
• Kameleoon. What we learned from running 200+ experiments on CUPED. kameleoon.com/blog/cuped.
• Spotify Engineering. Why We Use Separate Tech Stacks for Personalization and Experimentation (janeiro de 2026). engineering.atspotify.com.
• Russo, D. J., Van Roy, B., Kazerouni, A., Osband, I. & Wen, Z. A Tutorial on Thompson Sampling. Foundations and Trends in Machine Learning, 2018. arxiv.org/abs/1707.02038.
• Auer, P., Cesa-Bianchi, N. & Fischer, P. Finite-time Analysis of the Multiarmed Bandit Problem (o artigo que formaliza o UCB). Machine Learning, 47, 235-256, 2002.