Por que fazer testes A/B em agentes de IA é mais difícil do que você imagina
Moveo AI Team
in
🤖 Automação de IA
“É só um teste A/B”
Quando equipes fazem o primeiro deploy de um agente de voz com IA ou um assistente baseado em LLM, geralmente pensam em testá-lo da mesma forma que pensariam em um assunto de email ou um botão de website.
Você muda uma coisa, mantém todo o resto constante e mede o resultado.
Esse modelo mental é reconfortante, e também é exatamente onde as coisas começam a dar errado.
Um agente baseado em LLM não é uma mensagem estática. É um sistema conversacional vivo. Ele reage ao timing, a mudanças de intenção, a interrupções e ao fato de que um humano pode fazer a mesma pergunta de três formas diferentes. Mude uma única linha em um prompt, e suas métricas podem se mover. E mover novamente quando você roda o mesmo teste outra vez.
Nesses sistemas estocásticos e em camadas, até ajustes “inofensivos” podem causar mudanças dramáticas na performance.
Então, como fazer testes A/B em agentes de IA sem se enganar sobre os resultados?
A realidade estocástica de agentes baseados em LLM
Você pode pensar que definir a temperatura como zero vai dar outputs perfeitamente previsíveis todas as vezes, mas não vai.
Mesmo com temperatura zero, respostas de LLM ainda podem ser não-determinísticas devido a vários fatores técnicos.
Segundo pesquisas sobre determinismo em LLMs, GPUs usam matemática de ponto flutuante que não é associativa. Em kernels massivamente paralelos, reduções e acumulações acontecem em ordens diferentes entre execuções. Threads terminam em sequências diferentes. Kernels são fundidos de formas diferentes. Os logits finais podem mudar levemente.
A variação se agrava em modelos Mixture of Experts (MoE), onde o roteamento dinâmico inerentemente adiciona variabilidade devido às atribuições flutuantes de experts. Estudos sobre não-determinismo em configurações de LLM mostram que modelos como GPT-4 são muito menos consistentes que modelos densos mais antigos.
Determinismo perfeito em outputs de LLM é como uma vaca perfeitamente esférica em física: um construto teórico útil que não existe na realidade. Essa tensão está no centro do debate entre IA determinística e probabilística em ambientes enterprise.
O mesmo não-determinismo que torna testes frustrantes é o que permite que LLMs lidem com a variedade infinita de conversas do mundo real, uma feature em torno da qual você precisa projetar, não um bug a ser eliminado.
O problema da atribuição de segmentos
Testes A/B clássicos assumem algo simples: você randomiza no nível do usuário, e cada observação é independente. Em testes de agentes de IA, especialmente em voz inbound, essa premissa quebra quase imediatamente.
Testes outbound são comparativamente simples. Você divide sua lista de contas e liga com o Agente A ou o Agente B. A execução é limpa. A interpretação é onde a dor começa.
Inbound, porém, é um quebra-cabeça logístico. Você pode pensar: “Vou rotear cada segunda chamada para a Variante B”. Então a realidade aparece. Um cliente liga duas vezes e recebe duas versões diferentes do agente. Múltiplas pessoas compartilham o mesmo número de telefone. Um cliente liga de um número completamente diferente. Nesse ponto, seus dados já estão comprometidos.
A solução é sair da randomização por chamada e começar a randomizar por conta. Isso significa atribuição fixa: manter a mesma variante de agente para quem liga repetidamente e tratar essas chamadas como um cluster em vez de data points independentes.
Note algo importante: esse problema existe mesmo antes de LLMs entrarem em cena. IA apenas torna as consequências mais visíveis.
Variáveis que quebram testes tradicionais
Voz e sotaque
Geralmente é a primeira coisa que equipes querem testar.
Para chamadas outbound, é relativamente limpo. Para chamadas inbound, você precisa garantir que as chamadas sejam verdadeiramente randomizadas ou consistentemente atribuídas entre variantes.
Se seu roteamento não for hermético, qualquer insight de “preferência de voz” provavelmente está poluído por viés de amostragem.
Velocidade da voz
Parece simples: “Falar mais rápido vs mais devagar”. Na realidade, velocidade de voz está entrelaçada com interrupções (barge-in), detecção de fim de turno, latência percebida e se o agente parece natural ou robótico.
Detecção de turno (saber quando um humano realmente terminou de falar) é um problema difícil bem conhecido em voice AI.
Segundo pesquisas da Twilio sobre latência em agentes de voz, qualquer coisa acima de um segundo parece quebrada para quem liga. Contact centers reportam que clientes desligam 40% mais frequentemente quando agentes de voz demoram mais de um segundo para responder.
Se você faz teste A/B de velocidade sem monitorar qualidade de turn-taking, pode facilmente ganhar em uma métrica enquanto quebra o fluxo conversacional.
Troca de modelos
Trocas de modelo são os experimentos mais arriscados que você pode rodar.
Mudar um LLM não afeta apenas a qualidade. Também afeta latência, confiabilidade de tool-call, seguimento de instruções e comportamento em momentos de alto risco como disclosures ou negociações.
O objetivo aqui não é simplesmente ver qual modelo ganha no geral, mas entender onde cada modelo é mais forte ou mais fraco em diferentes cenários. Sem essa nuance, você acaba fazendo deploy de um modelo “melhor” que falha exatamente nos momentos que mais importam.
Equipes que investem em fine-tuning, RAG e prompt engineering sabem que cada camada de otimização introduz sua própria superfície de testes.
Ajustes de prompt
Prompts não mudam apenas o que o agente diz, mas mudam também o que o agente prioriza.
Um ajuste para tornar o agente mais amigável pode inadvertidamente reduzir a probabilidade de usar uma ferramenta obrigatória de coleta de dados ou atrasar um disclosure crítico.
Como o sistema é probabilístico, você não pode assumir que todo o resto permanece fixo, mesmo que sua configuração permaneça.
O problema da mensuração: além de resultados binários
Se você mede agentes de IA usando apenas resultados binários (sucesso ou falha), você perde o porquê de uma conversa ter funcionado. Se você mede apenas qualidade, você deriva para tomada de decisão baseada em vibes.
A abordagem mais efetiva é híbrida.
Checagens binárias cobrem disclosures regulatórios obrigatórios, taxas de contato com a parte certa, taxas de promessa de pagamento e taxas de pagamento. Scores de LLM-judge usam um modelo de alto raciocínio para avaliar quão bem o agente lidou com tom, negociação ou resistência.
Isso é especialmente crítico em operações onde a taxa de contenção sozinha pode mascarar interações não resolvidas.
Mas há um porém. LLM judges também são probabilísticos. Podem soar confiantes mesmo quando a probabilidade interna está próxima de cara ou coroa.
Segundo o guia da Confident AI sobre avaliação de LLM, “para um benchmark que usa métricas de LLM-as-a-judge, você não pode confiar completamente em uma única passada”.
Então você não precisa apenas de um juiz, precisa de uma forma de modelar a incerteza desse juiz.
Mitigações incluem rodar múltiplas avaliações e fazer média ou fixar a aleatoriedade do modelo através de prompt tuning.
Não tem certeza se sua operação de IA está madura o suficiente para rodar experimentos significativos?
Humildade estatística: por que métodos Bayesianos importam
Performance de agentes nunca é uniforme. Se você achata tudo em uma única média, vai fazer deploy de uma mudança que silenciosamente prejudica seus clientes mais importantes.
É por isso que equipes líderes estão adotando modelos bayesianos hierárquicos.
Esses modelos forçam perguntas melhores ao agrupar conversas por cenário (atraso de pagamento vs dificuldade financeira, por exemplo), permitir que performance varie por grupo, e evitar excesso de confiança quando amostras são pequenas.
O framework HiBayES do UK AI Safety Institute demonstra que abordagens convencionais de análise estatística frequentemente ficam aquém quando confrontadas com datasets hierarquicamente estruturados, tamanhos de amostra pequenos e a natureza inerentemente estocástica de outputs de LLM.
A pergunta muda de “A Variante B venceu a Variante A?” para “Quão confiantes estamos de que B é melhor para essa situação específica?”
Embora esse tipo de modelagem seja comum em estatística acadêmica, raramente é usado em avaliação de agentes LLM, especialmente em configurações de produção. Isso está mudando.
Construindo um framework de testes que realmente funciona
O que separa operações maduras de agentes de IA do resto não é volume de testes, mas qualidade de testes.
Guardrails determinísticos lidam com regras não negociáveis. Compliance, disclosures e passos obrigatórios não devem estar sujeitos à avaliação probabilística.
Segundo a análise da Hamming AI de mais de um milhão de chamadas de voz em produção, rastrear 30 a 50 métricas não é suficiente. Você pode ter ótima acurácia de ASR e ainda assim entender mal a intenção.
Avaliação consciente de cenário importa porque nem todas as conversas são iguais. Uma chamada de suporte sobre uma dúvida de cobrança é fundamentalmente diferente de uma negociação de dificuldade financeira. Juntar todas esconde diferenças críticas de performance.
Operações de cobrança digital, por exemplo, lidam com perfis de inadimplência que variam drasticamente entre o esquecimento técnico e a crise financeira real.
Simulações extensivas antes da produção são essenciais.
Pesquisas da Northeastern University, Penn State e Amazon mostram que agentes LLM podem simular padrões de comportamento semelhantes aos humanos em escala, permitindo que equipes testem variantes de interface e obtenham sinais comportamentais iniciais antes de comprometer tráfego real de usuários.
Versionamento de prompt com integração CI/CD trata prompts como código: versionados, testados e governados como parte do pipeline de deployment. Controle de versão rastreia mudanças sistematicamente. Testes automatizados avaliam efetividade de prompts antes de produção.
Essa abordagem pode parecer mais lenta. Na prática, é o que permite mover-se mais rápido.
Quando modelos, ferramentas e arquiteturas de agentes mudam todo mês, a única forma de escalar com segurança é entender incerteza profundamente e fazer deploy com confiança em vez de esperança.
Quando os riscos são reais, a responsabilidade também é
Quando agentes de IA lidam com conversas reais que têm consequências reais, testes A/B se tornam uma responsabilidade, não apenas uma checagem de performance.
Uma falha de IA não é um problema de UX inofensivo. Pode significar um disclosure perdido, uma lacuna de compliance ou um cliente que nunca mais volta. Essas conversas envolvem pessoas reais, riscos reais e resultados reais.
É por isso que a disciplina de experimentação importa: guardrails determinísticos para regras não-negociáveis, avaliação consciente de cenário porque nem todas as conversas são iguais, simulações extensivas antes de produção, e interpretação cuidadosa que reconhece incerteza em vez de escondê-la.
Se agentes de IA são a camada que muda mais rápido em software enterprise, nosso trabalho é garantir que também sejam a mais confiável. As equipes que acertarem na experimentação serão aquelas que fazem deploy com confiança, fundamentadas em dados e disciplina, não em esperança.
Quer ver como a Moveo.AI lida com experimentação de agentes de IA? Agende uma demo e teste nossos agentes com seus cenários mais complexos.