Modelos de machine learning (ML) se comportam de forma diferente em produção do que em ambientes controlados. Distribuições de dados mudam, intenções dos usuários variam e as saídas do modelo, especialmente em sistemas generativos ou probabilísticos, influenciam o comportamento do produto, a estrutura de custos e a confiança do usuário. Por isso, testar modelos de ML em produção vai muito além de comparar acurácia: PMs precisam avaliar qualidade do modelo, segurança, impacto na experiência, viabilidade econômica e confiabilidade operacional. Este playbook reúne comparação de modelos, guardrails, shadow testing, mecanismos de gating, avaliações online e offline e decisões guiadas pelo impacto de negócio. Avaliar o modelo por uma camada isolada é justamente o que produz o candidato que "ganhou no offline" e mesmo assim piorou o produto.
O que muda quando o modelo sai do notebook
A pergunta central não é se o modelo melhorou em uma métrica, e sim se essa melhoria se converte em impacto real. Um modelo forte em precisão, recall, F1, latência e ROC-AUC pode se comportar de forma inesperada diante de entradas reais, ruído e padrões variáveis de tráfego. É a produção que valida o que importa: acurácia no mundo real, taxa de alucinação, relevância para inputs inéditos, mudanças de confiança e comportamento do usuário e estabilidade sob carga. O offline mede o potencial; a produção mede o resultado, e é o resultado, não a promessa, que decide o lançamento.
Por isso um teste A/B avalia várias dimensões ao mesmo tempo: quatro grupos de sinais correm em paralelo, e um só não decide. A qualidade do modelo cobre acurácia, precisão e recall, relevância e ranking, gravidade de erros e alucinações, latência e confiabilidade. O comportamento do usuário aparece em conclusão de tarefas, profundidade de engajamento, retenção, conversão ou receita e sinais de frustração. A economia soma custo de inferência, uso de compute, footprint de memória, overhead de banda e retrieval e custo por tarefa concluída, modelada em paralelo, não depois. E os guardrails de segurança e compliance impedem que mais acurácia produza conteúdo nocivo, previsões enviesadas, recomendações inseguras, automações frágeis ou violações de privacidade.
Onde a avaliação offline ajuda e onde ela engana
Offline e online são as duas avaliações essenciais, mas respondem a perguntas diferentes, e confundi-las é onde muitos testes tropeçam. A avaliação offline, feita antes do A/B, valida a performance intrínseca sobre datasets históricos: precisão e recall, alucinações, acurácia de ranking, custo, simulação de edge cases e viés e fairness. O que ela não revela é como usuários reais reagem.
A avaliação online é o A/B em produção, onde o modelo encontra usuários reais, com variações de distribuição, caminhos de decisão concretos, impacto sobre engajamento e retenção, outcomes de negócio, custo operacional real e latência sob carga, e é aí que se avaliam significância estatística e intervalos de confiança. O alinhamento entre as duas é o diagnóstico: quando um ganho offline não aparece online, a causa costuma estar em drift de personalização, mismatch de queries, diferença entre treino e produção, atrito de UX ou efeitos downstream no funil. Investigar essa divergência vale mais que repetir o teste, porque é ela que mostra em que ponto a cadeia se rompe.
Shadow testing: validar o candidato sem mostrar suas respostas aos usuários
O shadow testing responde se um modelo aguenta o tráfego real antes que qualquer usuário veja sua saída. Ambos os modelos recebem o mesmo input, mas os usuários veem apenas o modelo base, enquanto o modelo candidato registra suas saídas para análise. Isso valida estabilidade, latência, distribuição de qualidade, padrões de alucinação e falhas inesperadas, tudo sem expor ninguém.
É a escolha certa para grandes mudanças arquiteturais, novas famílias de modelos, incerteza sobre segurança, custos ainda desconhecidos e ambientes com forte regulação. O que ele não mede é justamente o que só o tráfego real mostra: comportamento de usuários, impacto no fluxo de UX, retenção de longo prazo e uplift no funil. Por isso ele antecede o A/B, não o substitui.
Controlando quanta gente vê a variante nova
O gating define quem enxerga o modelo novo e com que velocidade essa fatia cresce, e as três variantes diferem em se a regra é fixada de antemão, reage a sinais ao vivo ou apenas divide tráfego. No gating estático, o modelo só aparece quando os metadados atendem a critérios fixos (segmento adequado e complexidade da tarefa compatível), e a regra é conhecida antes do teste e não muda durante ele. No gating dinâmico, a exposição reage ao vivo a limiares de confiança, classificadores de segurança, escores de incerteza, limites de custo e tolerância de latência: o modelo novo entra apenas quando o próprio sinal indica que é seguro.
Já o gating de tráfego no A/B faz o rollout de forma incremental (1%, 5%, 20%, 50%) e só avança para a próxima fatia se os guardrails estiverem verdes. Qualquer regressão trava a subida.
Montando o teste com guardrails desde o início
Um teste de modelo vale o que valem as quatro decisões tomadas antes de abri-lo: a estrutura de variantes, a hipótese, o conjunto de métricas e o plano de amostra, nessa ordem, porque cada decisão limita a seguinte. O caso mais comum de estrutura é A (modelo base) contra B (nova versão); em cenários mais avançados entram desenhos A/B/C, bandits ou roteamento contextual, úteis quando há mais de um candidato ou quando a melhor escolha depende do contexto da requisição. A hipótese precisa ser clara, por exemplo: se o novo modelo de ranking captura melhor a relevância semântica, então o engajamento na busca aumenta, porque usuários encontram resultados relevantes mais cedo. O "porque" é o que permite diagnosticar uma hipótese que falha.
O painel de decisão troca essas camadas por números concretos, e é aqui que elas viram critério de corte:
- Métricas primárias de produto: conversão, engajamento, conclusão de tarefas e avaliações de qualidade.
- Métricas de modelo: precisão e recall, taxa de alucinação, score de relevância e latência.
- Guardrails: flags de segurança, sinais de frustração, padrões de erro, viés e fairness.
- Métricas econômicas: custo de inferência, custo por tarefa e variabilidade de compute.
Nenhum grupo isolado autoriza um lançamento. Por fim, o planejamento de amostra define a amostra mínima, o poder estatístico, o MDE e a duração do teste, e modelos de IA exigem amostras maiores por conta da variância e da personalização, porque o mesmo efeito real precisa de mais observações para se destacar do ruído.
O efeito que aparece três telas depois
Com o teste desenhado e no ar, a primeira surpresa costuma estar no percurso do usuário. Um modelo melhor muitas vezes apenas muda o ponto do funil em que o usuário desiste, sem reduzir o abandono. Ele pode remover etapas, acelerar tarefas, orientar usuários a novos fluxos ou alterar os caminhos de descoberta, e por isso a conversão final sozinha engana: dois resultados iguais no total podem ter reorganizado o caminho de formas opostas. Um modelo tecnicamente melhor também pode confundir usuários, gerar respostas complexas demais, reduzir a confiança pela inconsistência ou aumentar a latência percebida; ganho de qualidade interna não garante ganho de experiência.
Vale ainda avaliar retenção e confiança no longo prazo: um uplift curto não importa se a confiança diminui, os erros se acumulam, as explicações são inadequadas ou os usuários voltam aos comportamentos antigos. A retenção é o teste real que a média da primeira semana nunca faz, porque a confiança só se revela no retorno.
Quanto o modelo novo custa por mil requisições
Experiência e retenção resolvidas, falta a conta que decide de vez: um modelo que sobe a conversão e ao mesmo tempo dispara o custo de servir não é uma melhoria. O cost-to-serve depende de tamanho do modelo, tokens processados, operações de retrieval, latência sob escala, concorrência e execução em batch; antes de decidir, simule margens, picos de carga, elasticidade de custo e cenários de risco, porque o custo médio observado em teste raramente é o custo em produção. Do outro lado, um modelo melhor pode empurrar a receita por três vias: mais relevância elevando conversão, automação reduzindo custo e personalização sustentando retenção. Como cada via tem um horizonte diferente, vale separá-las na projeção.
Os stress tests econômicos fecham a conta: modele explicitamente picos repentinos, workloads enterprise, cadeias de agentes e contextos longos. São esses cenários, não o tráfego médio, que revelam se a margem sobrevive à escala.
Promover, retreinar ou desligar
Todas as medições anteriores convergem para uma única pergunta: o que fazer agora com o modelo. O lançamento se justifica quando os KPIs de produto sobem, os guardrails permanecem verdes e o modelo candidato supera o baseline de forma consistente. A esses sinais soma-se a viabilidade econômica: o custo por tarefa concluída precisa ser sustentável no volume real de tráfego. Verifique por fim que não houve regressões de fairness ou segurança e que avaliação offline e online contam a mesma história, porque divergência entre as duas é motivo para adiar.
Há casos em que o modelo entrega valor, mas o comportamento começa a escorregar: surge drift na distribuição de entradas, as alucinações aumentam e o custo por requisição oscila sem explicação clara. Outro sinal é a relevância que varia entre segmentos, atendendo bem um grupo e mal outro. Quando o gating passa a acionar fallbacks com frequência, é o sistema que está sustentando o modelo, e não o contrário; é hora de retreinar, não de escalar.
A variante deve ser descartada quando KPIs e guardrails pioram ao mesmo tempo, porque não sobra nenhum trade-off a negociar. O mesmo vale para o aumento de riscos de segurança e para o crescimento da frustração do usuário, mesmo que alguma métrica isolada continue positiva. Custo que destrói a margem e desalinhamento persistente entre offline e online completam o quadro: nesses cenários, insistir apenas adia a decisão.
Sem shadow test, o A/B vira aposta
Testar modelos de ML em produção é uma decisão de produto antes de ser um exercício técnico. O ponto prático que decide é a ordem: quem manda o candidato direto para o A/B sem shadow test está apostando margem e confiança do usuário num resultado que poderia ter previsto barato. Rode o ensaio silencioso primeiro, limite a exposição com gating, exija que offline e online contem a mesma história e trate qualquer regressão de guardrail como veto, mesmo com KPIs no verde. É essa disciplina, e não a acurácia isolada do modelo, que separa uma evolução segura de uma troca cara.