Teste A/B de LLM: como testar prompts e modelos em produção
Teste A/B de LLM: como testar prompts e modelos com usuários reais, medir aceitação, custo e latência, e evitar os erros do juiz LLM.
📚 Este artigo faz parte do guia Personalização com IA e Teste A/B: como funcionam juntos.
Um teste A/B de LLM é um experimento controlado em que usuários reais são sorteados entre duas versões do comportamento de IA dentro do produto (outro prompt, outro modelo, outra temperatura, com ou sem RAG) para medir o efeito causal disso no que eles fazem. A avaliação offline, com conjunto de perguntas e LLM como juiz, filtra candidatos; só o teste online diz se a mudança melhora a tarefa do usuário, e ele traz três armadilhas próprias: saída não determinística, métricas por mensagem com sorteio por usuário e custo por requisição que muda entre as variantes. Este guia faz parte do guia de personalização com IA e teste A/B e cobre a divisão de trabalho entre offline e online, os vieses medidos do juiz LLM, a tabela de métricas e guardrails, a simulação que mostra por que o intervalo ingênuo erra, um exemplo trabalhado de prompt atual contra prompt novo com as duas calculadoras embutidas, e a conta de custo que decide se o vencedor se paga.
O que muda quando a variante é um comportamento de IA
A estatística é a mesma de qualquer teste A/B: dois grupos equivalentes por sorteio, uma métrica primária declarada antes, um tamanho de amostra calculado para um efeito mínimo e uma leitura com intervalo de confiança. O que muda é a natureza da variante e o tipo de dano que ela pode causar.
Numa página, a variante é um texto ou um layout fixo, igual para todos que caem no grupo. Numa funcionalidade de LLM, a variante é uma configuração que gera saídas diferentes a cada chamada. Isso tem quatro consequências práticas:
- A mesma entrada produz saídas diferentes. A documentação da API de mensagens da Anthropic, consultada em setembro de 2026, diz que mesmo com temperatura 0,0 os resultados não serão totalmente determinísticos (a mesma página marca o parâmetro como descontinuado: modelos lançados depois do Claude Opus 4.6 só aceitam o valor 1,0). A variância da métrica tem uma fonte a mais, que não existe num botão.
- A variante tem custo variável. Um prompt com mais instruções ou com trechos recuperados de uma base consome mais tokens de entrada, e cada requisição passa a custar mais. Isso nunca acontece quando você muda a cor de um CTA.
- A variante pode falhar de formas novas. Recusar uma tarefa legítima, inventar um fato, demorar demais para começar a responder, estourar o limite de requisições do fornecedor.
- A variante pode mudar sem você mexer nela. Um alias de modelo que aponta para a versão mais recente, ou uma mudança na infraestrutura de serviço, pode alterar o comportamento no meio do teste.
A diferença para a peça sobre variantes geradas por IA é importante: lá a IA escreve variações de uma página e o teste é um teste de página comum. Aqui a IA é a própria funcionalidade testada, e a variação é o comportamento dela.
Avaliação offline x experimento online: quem decide o quê
A avaliação offline roda a configuração candidata sobre um conjunto fixo de entradas e mede a qualidade das saídas, com rótulo humano ou com outro modelo julgando. O experimento online expõe usuários reais e mede o que eles fazem. As duas são necessárias, e cada uma responde uma pergunta diferente.
O texto de Widad Machmouchi e Somit Gupta, da plataforma de experimentação da Microsoft, publicado em setembro de 2023, põe a fronteira de forma direta: a avaliação offline é adequada para o início do desenvolvimento de uma funcionalidade, mas não consegue avaliar como mudanças de modelo beneficiam ou degradam a experiência do usuário em produção. O mesmo texto descreve os desenhos de experimento que recomenda no lançamento da funcionalidade e depois dele.
| Pergunta | Offline (conjunto + juiz) | Sombra | Teste A/B online |
|---|---|---|---|
| A resposta está correta e no tom certo? | Sim, sobre as perguntas do conjunto | Parcialmente, sem reação do usuário | Indiretamente, pelo comportamento |
| Quanto custa e quanto demora? | Estimativa em ambiente de teste | Sim, com tráfego real | Sim, com tráfego real |
| O usuário aceita, aplica ou regenera? | Não | Não | Sim |
| O usuário volta a usar a função? | Não | Não | Sim |
| A mudança causa o efeito observado? | Não | Não | Sim, por causa do sorteio |
| Custo de errar | Baixo | Baixo | Alto, usuários expostos |
O conjunto de avaliação tem um limite estrutural que nenhum juiz resolve: ele é fixo, e os usuários não são. As perguntas que chegam em produção mudam com a época, o público e o próprio produto, e o conjunto envelhece em silêncio. Por isso o fluxo saudável usa o offline para cortar de dez candidatos para dois e deixa o teste online decidir entre os dois.
O juiz LLM e os vieses que já foram medidos
Usar outro modelo para dar nota às respostas é barato e escala, e existe evidência de que ele concorda bastante com pessoas. O trabalho de Zheng e coautores, “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (2023), relata que juízes fortes como o GPT-4 alcançaram mais de 80 por cento de concordância com preferências humanas, o mesmo nível de concordância entre humanos. O mesmo artigo mede três vieses que tornam o juiz perigoso como métrica primária sem calibração:
- Viés de posição. Os autores geraram pares de respostas parecidas e inverteram a ordem. Com o prompt padrão, o GPT-4 manteve o veredito em 65,0 por cento dos casos, o GPT-3.5 em 46,2 por cento e o Claude-v1 em 23,8 por cento; o Claude-v1 favoreceu a primeira posição em 75,0 por cento dos casos.
- Viés de verbosidade. Num ataque de “lista repetitiva”, em que uma resposta foi alongada com itens reescritos sem informação nova, o juiz preferiu a versão inflada em 91,3 por cento dos 23 casos com Claude-v1 e com GPT-3.5, e em 8,7 por cento com GPT-4.
- Viés de autopromoção. Comparado a humanos, o GPT-4 deu a si mesmo uma taxa de vitória 10 por cento maior e o Claude-v1, 25 por cento maior. Os autores ressalvam que, com poucos dados e diferenças pequenas, o estudo não consegue determinar se o viés existe de fato.
O próprio artigo sugere mitigações simples: chamar o juiz duas vezes com a ordem invertida e só declarar vitória quando a mesma resposta vence nas duas, e fornecer uma resposta de referência em perguntas de matemática, o que reduziu as falhas do GPT-4 de 14 em 20 para 3 em 20 no teste dos autores. A regra operacional que sai daí é: o juiz LLM é um instrumento de medição, e instrumento se calibra. Separe uma amostra de respostas, rotule com pessoas, meça a concordância do juiz nessa amostra e só então use a nota dele, e mesmo assim como filtro ou métrica secundária. Tratar a nota do juiz como métrica substituta do valor para o usuário exige a mesma validação que qualquer substituta.
Métricas de um teste A/B de LLM: sucesso, uso e guardrails próprios
A métrica primária deve estar ligada ao valor da tarefa e ser medida por usuário, a unidade sorteada. O texto da Microsoft descreve, entre as métricas de uma funcionalidade de LLM, um funil que vai da oportunidade de sugerir até a resposta aceita e mantida pelo usuário, e acrescenta famílias que não existem num teste de página: consumo de tokens, respostas truncadas, erros 429 de sobrecarga, tempo até o primeiro token medido em vários percentis, respostas filtradas por conteúdo e retenção.
| Métrica | Tipo | Unidade natural | Armadilha |
|---|---|---|---|
| Sucesso da tarefa (concluiu o que foi fazer) | Primária | Usuário | Definir “sucesso” depois de ver o dado |
| Usuário aceitou uma resposta sem regenerar | Primária ou secundária | Usuário | Mudar a janela de medição no meio do teste |
| Taxa de aceitação por resposta (copiou, aplicou) | Secundária | Mensagem | É métrica de razão: exige método delta |
| Taxa de “regenerar” e de reformulação | Secundária, sinal de insatisfação | Mensagem | Uma variante mais lenta reduz regeneração por cansaço, não por qualidade |
| Polegar para cima ou para baixo | Secundária | Mensagem | Só uma fração responde e não é sorteada; quem responde é diferente de quem não responde |
| Retenção na função (voltou na semana seguinte) | Primária de longo prazo | Usuário | Precisa de janela longa; efeito novidade infla as primeiras semanas |
| Tokens e custo por requisição | Guardrail | Requisição | Comparar médias por requisição quando uma variante gera mais requisições por usuário |
| Latência (p95 do tempo até o primeiro token) | Guardrail | Requisição | Olhar a média esconde a cauda; use métricas de quantil |
| Taxa de erro, timeout e 429 | Guardrail | Requisição | Cota compartilhada entre variantes cria interferência |
| Taxa de recusa de tarefa legítima | Guardrail | Mensagem | Precisa de classificação consistente nas duas variantes |
| Incidentes de segurança (conteúdo filtrado, vazamento) | Guardrail com limite zero ou quase | Evento | Evento raro: o teste raramente tem poder, então exige revisão fora da estatística |
Três observações sobre essa tabela. A primeira é que aceitação sem regenerar é uma boa primária por usuário porque junta dois sinais (o usuário usou a resposta e não precisou pedir outra) sem depender de ninguém clicar num polegar. A segunda é que o polegar não é métrica primária: quem responde é autosselecionado, e uma variante pode mudar quem responde sem mudar a qualidade. A terceira é que os guardrails de LLM têm limite declarado antes, como qualquer métrica de guardrail, e custo é guardrail, não detalhe de faturamento.
De onde vem a variância extra num teste de LLM
A variância de um teste de LLM tem quatro fontes que um teste de página não tem ou tem em escala muito menor. Duas afetam o desenho do sorteio, duas afetam a leitura.
Sortear por usuário, não por requisição
A primeira decisão de desenho é a unidade de sorteio. Sortear cada requisição de forma independente parece aumentar a amostra, e é justamente essa a armadilha: o mesmo usuário recebe a variante A na primeira mensagem, a B na segunda e a A de novo na terceira, dentro da mesma conversa.
Sortear por usuário resolve a contaminação e cria um custo estatístico: todas as mensagens de um usuário estão correlacionadas (um usuário que gosta da função aceita muitas respostas, um que não gosta aceita poucas). A atribuição tem que ser determinística por identificador de usuário, exatamente como num teste A/B server-side, para o mesmo usuário cair sempre no mesmo braço em qualquer servidor.
Métrica por mensagem com sorteio por usuário: o intervalo ingênuo erra
Quando a métrica é “taxa de aceitação por resposta” e a unidade sorteada é o usuário, a métrica vira uma razão de duas somas por usuário (respostas aceitas sobre respostas geradas). Tratar cada mensagem como observação independente subestima o erro padrão, e o tamanho do erro cresce com o número de mensagens por usuário. A correção é o método delta, explicado em métricas de razão.
Para medir o tamanho do problema em funcionalidades de LLM, rodamos uma simulação feita para este guia (gerador pseudoaleatório com semente fixa): 2.000 testes A/A, sem nenhuma diferença real entre os braços, com 2.000 usuários por braço, número de requisições por usuário variando de forma assimétrica e propensão de aceitar variando entre usuários. Em cada teste, a diferença na taxa de aceitação por mensagem foi testada a 95 por cento de duas formas.
| Cenário simulado | Requisições por usuário (média) | Erro padrão do método delta dividido pelo ingênuo | Falso positivo com intervalo ingênuo | Falso positivo com método delta |
|---|---|---|---|---|
| Função de uso ocasional | cerca de 3,7 | 1,28 | 12,10% | 4,55% |
| Chat de uso intenso | cerca de 20 | 2,83 | 49,15% | 4,50% |
O nível nominal é 5 por cento. Com o método delta, as duas simulações ficam perto disso. Com o intervalo ingênuo, a função de uso ocasional já mais que dobra a taxa de alarme falso, e o chat de uso intenso declara vencedor em quase metade dos testes em que nada mudou. É por isso que um painel de LLM que mostra “aceitação por mensagem com significância” sem dizer como calculou o erro padrão merece desconfiança imediata.
Novidade, cache compartilhado e versões que mudam sozinhas
Efeito novidade. Um comportamento de IA novo pode atrair curiosidade: o usuário testa mais, regenera para ver o que acontece, aceita por entusiasmo. O efeito novidade faz as primeiras semanas exagerarem o ganho ou a perda. Rode semanas cheias, olhe o efeito por semana de exposição e desconfie de um ganho que só existe na primeira.
Interferência por recurso compartilhado. Se as duas variantes usam o mesmo cache de respostas, um usuário do braço B pode receber uma resposta gerada pelo prompt A e armazenada. Se usam a mesma cota de requisições do fornecedor, uma variante que consome mais pode provocar erros 429 na outra. As duas situações violam a premissa de que o tratamento de um usuário não afeta o resultado de outro, tema de interferência entre variações. A solução é chavear o cache pela variante e monitorar erros por braço.
Versão do modelo que muda no meio do teste. A página de identificadores de modelo da Anthropic, consultada em setembro de 2026, explica que em modelos anteriores à geração 4.6 os aliases sem data da API apontam para o snapshot datado mais recente daquela versão, enquanto cada identificador é uma versão fixada. A mesma página avisa que, mesmo com identificador e pesos inalterados, mudanças na infraestrutura de serviço (roteamento, classificadores de segurança, lógica de amostragem) podem produzir pequenas diferenças de comportamento observável. A regra prática vale para qualquer fornecedor: fixe a versão do modelo nas duas variantes, registre essa versão na configuração do experimento e anote qualquer mudança conhecida do fornecedor durante a janela.
Exemplo trabalhado: prompt atual x prompt novo
Um SaaS de e-commerce tem uma função que escreve a descrição de um produto a partir de atributos cadastrados. O lojista pode aceitar o texto, editar ou regenerar. O time escreveu um prompt novo com mais instruções de estilo e exemplos recuperados das descrições que os lojistas mais aprovaram. O prompt novo passou na avaliação offline e num experimento sombra, sem aumento de erro. A pergunta que resta é a do teste online.
Declaração antes de rodar:
- Unidade de sorteio: lojista (usuário), atribuição determinística por identificador.
- Métrica primária: proporção de usuários que aceitaram pelo menos uma descrição sem regenerar durante o teste.
- Taxa base histórica: 30 por cento.
- Efeito mínimo que justifica o custo do prompt novo: mais 5 por cento relativo.
- Guardrails: custo por mil requisições, p95 do tempo até o primeiro token, taxa de erro e taxa de recusa, com limites escritos.
- Versão do modelo: fixada e idêntica nos dois braços.
Quantos usuários e quantos dias
Coloque na calculadora abaixo taxa atual de 30, efeito mínimo de 5 relativo, confiança 95, poder 80, 10.000 visitantes por semana (aqui, usuários novos que entram no teste por semana) e teste bilateral:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Ela devolve 14.856 usuários por variação, 29.712 no total e 21 dias. Três semanas cheias é uma boa notícia neste caso, porque a janela dá espaço para ver se um eventual efeito novidade da primeira semana se sustenta nas seguintes.
O resultado
Depois de 21 dias, os números da simulação feita para este guia (gerador com semente fixa, com um efeito verdadeiro pequeno embutido no prompt novo) foram:
- Controle (prompt atual): 14.962 usuários, 4.371 aceitaram uma descrição sem regenerar.
- Variante (prompt novo): 15.038 usuários, 4.584 aceitaram.
Antes de ler o efeito, confira a divisão: 14.962 contra 15.038 numa divisão configurada de 50 por 50 dá qui-quadrado de 0,1925 e valor-p de 0,6608 no teste de divisão desigual de tráfego (SRM), ou seja, sem sinal de problema no sorteio. Agora cole os números na calculadora de significância:
Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.
A tela mostra taxa de 29,21% no controle e 30,48% na variante, melhora relativa de +4,3%, valor-p de 0,0163, IC 95% da diferença de +0,2% a +2,3% (pp) e o veredito “Vencedora com significância”, com B vencendo. Os valores exatos por trás da tela são diferença de 1,2688 ponto percentual, intervalo de 0,2333 a 2,3043 pontos e z de 2,4012.
A métrica por mensagem conta outra história
No mesmo teste, a taxa de aceitação por mensagem foi de 11,84 por cento no controle (6.587 aceitas em 55.643 requisições) e de 12,07 por cento na variante (6.834 em 56.638), diferença de +0,23 ponto. Com o método delta, o intervalo vai de −0,26 a +0,72 ponto e o valor-p é 0,3623: sem conclusão. O cálculo ingênuo daria intervalo de −0,15 a +0,61 ponto, cerca de 23 por cento mais estreito do que deveria. A leitura correta é que a métrica secundária por mensagem não tem poder para confirmar nem para desmentir a primária, e que a decisão continua ancorada na métrica por usuário declarada antes.
O custo entra na decisão: quanto custa cada usuário adicional
O prompt novo usa mais tokens. Os valores abaixo são ilustrativos, escolhidos para a conta ficar clara, e não correspondem ao preço de nenhum fornecedor específico: US$ 3,00 por milhão de tokens de entrada e US$ 15,00 por milhão de tokens de saída.
| Item | Prompt atual | Prompt novo | Diferença |
|---|---|---|---|
| Tokens de entrada por requisição | 1.200 | 2.000 | +66,7% |
| Tokens de saída por requisição | 300 | 320 | +6,7% |
| Custo por mil requisições | US$ 8,10 | US$ 10,80 | +US$ 2,70 (+33,3%) |
| Requisições por usuário no teste | 3,72 | 3,77 | n/d |
| Custo extra por 10.000 usuários | n/d | US$ 101,69 | n/d |
O custo extra por 10.000 usuários é 3,7663 requisições por usuário do braço novo vezes US$ 0,0027 de diferença por requisição vezes 10.000. O ganho, na mesma base de 10.000 usuários, é a diferença na métrica primária: 126,9 usuários adicionais que aceitam uma descrição sem regenerar, pela estimativa central. Dividindo um pelo outro, e fazendo o mesmo nos dois limites do intervalo:
| Leitura do efeito | Usuários adicionais por 10.000 | Custo por usuário adicional |
|---|---|---|
| Limite inferior do IC (+0,23 pp) | 23,3 | US$ 4,36 |
| Estimativa central (+1,27 pp) | 126,9 | US$ 0,80 |
| Limite superior do IC (+2,30 pp) | 230,4 | US$ 0,44 |
A decisão agora é de negócio, e tem forma clara. Se um lojista adicional que adota a função vale mais que US$ 4,36 (por exemplo, pelo efeito em retenção do plano), o prompt novo se paga até no pior cenário plausível. Se vale entre US$ 0,80 e US$ 4,36, ele se paga na estimativa central, mas com risco real. Se vale menos que US$ 0,80, não se paga nem na estimativa central. A mesma conta vale, com números maiores, para trocar de modelo: um modelo maior costuma mudar a coluna de custo muito mais que um prompt.
Checklist de lançamento de um teste A/B de LLM
- Filtrar offline antes. Conjunto de avaliação atualizado, juiz com concordância medida contra rótulo humano, avaliação com ordem invertida quando o juiz compara pares.
- Rodar modo escuro ou sombra quando a mudança afeta capacidade. Troca de modelo e prompts muito mais longos mudam custo, latência e taxa de erro antes de mudar qualquer comportamento.
- Sortear por usuário, com atribuição determinística. O mesmo usuário recebe sempre a mesma variante, em qualquer servidor e em qualquer conversa.
- Declarar a métrica primária por usuário e a janela. Por escrito, num plano de análise pré-registrado, antes do primeiro dado.
- Declarar guardrails com limite. Custo por mil requisições, p95 do tempo até o primeiro token, erro e 429 por braço, recusa, incidentes de segurança.
- Fixar a versão do modelo e registrar a configuração inteira. Identificador do modelo, prompt versionado, temperatura, parâmetros de recuperação e chave de cache por variante.
- Calcular amostra e duração em semanas cheias. Use a calculadora de tamanho de amostra e arredonde para cima em semanas.
- Checar SRM antes de ler o efeito. A verificação de SRM roda em segundos.
- Ler métricas por mensagem com o método delta. Nunca com o intervalo binomial por mensagem.
- Fechar a decisão com a conta de custo sobre o intervalo inteiro. E, se a função é central no produto, manter um holdout de longo prazo para medir retenção depois do lançamento.
Erros comuns
| Erro | Por que engana | Correção |
|---|---|---|
| Usar a nota do juiz LLM como métrica primária sem calibração humana | O juiz tem viés de posição e de verbosidade medidos, e pode premiar a resposta mais longa em vez da mais útil | Juiz como filtro offline; primária baseada em comportamento do usuário |
| Sortear por requisição | Mistura variantes na mesma conversa e infla a amostra aparente | Sorteio determinístico por usuário |
| Olhar só o polegar | Quem responde é autosselecionado e raro | Aceitação, regeneração e sucesso da tarefa como sinais principais |
| Esquecer custo e latência | Um vencedor de aceitação pode ser mais caro e mais lento que o ganho vale | Guardrails declarados e conta de custo sobre o IC |
| Não fixar a versão do modelo | Alias aponta para versão nova no meio da janela | Identificador fixo e registrado na configuração |
| Ignorar mudança do fornecedor durante o teste | Infraestrutura de serviço pode mudar o comportamento sem mudar o identificador | Anotar a janela, comparar efeito por semana, repetir se necessário |
| Ler aceitação por mensagem com intervalo ingênuo | Na simulação deste guia, até 49,15% de falsos positivos | Método delta |
| Declarar vitória na primeira semana | A novidade pode inflar o uso inicial | Semanas cheias e efeito por semana de exposição |
| Compartilhar cache entre as variantes | O braço B recebe respostas do prompt A | Chave de cache inclui a variante |
Faça isso automático na Donnu
O ponto em que um teste A/B de LLM costuma quebrar não é a estatística, é o registro. Três semanas depois, ninguém lembra qual versão do modelo estava fixada, qual era a métrica primária declarada e se o limite de custo foi escrito antes ou depois de ver o resultado. Sem esse registro, a conta de custo sobre o intervalo vira discussão de opinião.
Sendo direto sobre o que a Donnu A/B é hoje: uma ferramenta de teste A/B client-side para páginas web. O sorteio de um prompt ou de um modelo acontece no seu backend, então a atribuição da variante de IA em si é trabalho do seu servidor ou de uma plataforma de feature flags de servidor, como explicado em feature flags x teste A/B. O que a Donnu faz nesse fluxo é o que ela faz em qualquer experimento: registra a configuração do experimento no momento em que ele é criado, com a métrica primária declarada, e mantém o histórico por experimento. E testes da camada visível da função (onde o botão de IA aparece, como a sugestão é apresentada, qual chamada convida a usar) são exatamente o caso de uso do snippet.
Para a parte numérica, as calculadoras deste guia são gratuitas: a calculadora de tamanho de amostra para planejar a janela e a calculadora de significância para ler a métrica primária por usuário. Se quiser ver a Donnu em testes de página, comece um teste grátis de 14 dias.
Referências
- Machmouchi, W. e Gupta, S. How to Evaluate LLMs: A Complete Metric Framework. Microsoft Research, plataforma de experimentação (ExP), 27 de setembro de 2023. Lido nesta sessão. Sustenta a afirmação de que a avaliação offline é adequada ao início do desenvolvimento mas não consegue avaliar como mudanças de modelo beneficiam ou degradam a experiência em produção; o funil de métricas que vai da oportunidade de sugerir até a resposta aceita e mantida; as métricas de tokens, erros 429, respostas truncadas e filtradas por conteúdo, tempo até o primeiro token em vários percentis, polegar e retenção; e os desenhos de modo escuro e experimento 0-1 (no lançamento), experimento sombra (depois do lançamento, em que métricas que dependem da reação do usuário não podem ser medidas) e experimento 1-N. microsoft.com.
- Zheng, L., Chiang, W.-L., Sheng, Y. e coautores. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv 2306.05685, 9 de junho de 2023. PDF lido nesta sessão. Sustenta a concordância acima de 80 por cento entre juízes fortes e preferências humanas, no mesmo nível da concordância entre humanos; a tabela 2 de viés de posição (consistência de 65,0, 46,2 e 23,8 por cento para GPT-4, GPT-3.5 e Claude-v1 com o prompt padrão, e 75,0 por cento de preferência pela primeira posição no Claude-v1); a tabela 3 do ataque de lista repetitiva (91,3, 91,3 e 8,7 por cento de falha em 23 respostas); a observação sobre autopromoção (10 e 25 por cento a mais de taxa de vitória, com a ressalva de que o estudo não consegue determinar o viés); e as mitigações de inverter a ordem e usar resposta de referência (falhas de 14 em 20 para 3 em 20). arxiv.org.
- Anthropic. Model IDs and versioning. Documentação da plataforma Claude, consultada em 13 de setembro de 2026. Sustenta que cada identificador de modelo é uma versão fixada, que aliases de modelos anteriores à geração 4.6 apontam para o snapshot datado mais recente daquela versão, e que mudanças de infraestrutura de serviço podem produzir pequenas diferenças de comportamento mesmo sem mudança de identificador e pesos. platform.claude.com.
- Anthropic. Create a Message, parâmetro temperature. Referência da API Claude, consultada em 13 de setembro de 2026. Sustenta que mesmo com temperatura 0,0 os resultados não são totalmente determinísticos, e que o parâmetro está descontinuado: modelos lançados depois do Claude Opus 4.6 só aceitam o valor 1,0. platform.claude.com.
- LaunchDarkly. AgentControl. Documentação (o endereço antigo /docs/home/ai-configs redireciona para esta página), consultada em 13 de setembro de 2026. Exemplo de plataforma de experimentação que trata prompts, instruções e parâmetros de modelo como variações de configuração e compara variações por custo, latência, satisfação e outras métricas; citado como ilustração do desenho, não como recomendação. launchdarkly.com.
Leia também: Personalização com IA e teste A/B · Variantes de teste A/B geradas por IA · Copilots de IA em ferramentas de teste A/B · Métricas de razão e método delta · Unidade de sorteio · Métricas de guardrail · Efeito novidade · Calculadora de significância · Read in English
Perguntas frequentes
- O que é um teste A/B de LLM?
- É um experimento controlado em que usuários reais são sorteados entre duas configurações de uma funcionalidade construída com modelo de linguagem, por exemplo dois prompts, dois modelos, duas temperaturas ou a mesma resposta com e sem busca em base de conhecimento (RAG). A diferença para uma avaliação offline é que o teste mede o efeito causal no comportamento do usuário, como aceitar a resposta, concluir a tarefa ou voltar a usar a função, e não uma nota dada por um avaliador sobre um conjunto fixo de perguntas.
- Avaliação offline com LLM como juiz substitui o teste A/B?
- Não. Ela serve para filtrar candidatos antes de expor usuários. O artigo da Microsoft Research sobre avaliação de funcionalidades de LLM afirma que a avaliação offline é adequada ao início do desenvolvimento, mas não consegue medir se uma mudança de modelo melhora ou piora a experiência em produção. E o juiz tem vieses documentados: no estudo de Zheng e coautores (2023), o mais consistente dos três juízes avaliados manteve o mesmo veredito ao inverter a ordem das respostas, com o prompt padrão, em só 65,0 por cento dos casos.
- Qual deve ser a unidade de sorteio num teste de prompt ou modelo?
- O usuário, quase sempre. Sortear por requisição faz a mesma conversa misturar dois comportamentos, contamina a métrica por usuário e impede medir retenção. A consequência estatística é que métricas por mensagem, como taxa de aceitação, passam a ser métricas de razão e exigem o método delta. Na simulação feita para este guia, o intervalo ingênuo por mensagem produziu falso positivo em 49,15 por cento de 2.000 testes A/A num cenário de chat intenso, contra 4,50 por cento com o método delta.
- Quais métricas usar num teste A/B de LLM?
- Uma métrica primária por usuário ligada ao valor da tarefa, como a proporção de usuários que aceitaram uma resposta sem regenerar, mais sinais de uso (copiou, aplicou, regenerou, reformulou) e guardrails específicos de LLM: tokens e custo por requisição, latência em percentil alto, taxa de erro e de recusa, e incidentes de segurança. Avaliação explícita por polegar serve como sinal secundário, porque só uma fração dos usuários responde e ela não é sorteada.
- Quanto tempo leva um teste A/B de prompt?
- Depende da taxa base e do efeito que você quer detectar. No exemplo deste guia, com 30 por cento de usuários aceitando uma resposta sem regenerar e efeito mínimo de mais 5 por cento relativo, a 95 por cento de confiança e 80 por cento de poder, são 14.856 usuários por variação. Com 10.000 usuários novos elegíveis por semana, isso dá 21 dias, três semanas cheias, o que também ajuda a atravessar o efeito novidade.
- Como decidir se um prompt que converte mais mas custa mais vale a pena?
- Converta o ganho e o custo para a mesma unidade e use o intervalo, não só a estimativa central. No exemplo ilustrativo deste guia, o prompt novo custa US$ 101,69 a mais por 10.000 usuários e gera 126,9 usuários adicionais que aceitam uma resposta, cerca de US$ 0,80 por usuário adicional. No limite inferior do intervalo de confiança, o mesmo custo compra só 23,3 usuários adicionais, cerca de US$ 4,36 cada. Se um usuário adicional vale menos que isso para o seu negócio, a decisão depende de quanto risco você aceita.