LLM Evals Não São Substitutos para Testes A/B — O Funil Certo é Esse

Por Que Isso é Importante Agora

Já passou por isso? Você ajusta um prompt, troca o modelo, reescreve uma guardrail. O juiz LLM diz que ficou melhor. O time faz o deploy. Aí as métricas não mudam — ou pior, uma métrica secundária como tempo de sessão ou retenção começa a cair. O eval perdeu algo.

No Spotify, apenas cerca de 12% dos testes A/B terminam com um resultado positivo implementado. Mas 64% produzem aprendizado válido: uma regressão capturada, uma ideia descartada, uma hipótese refinada. A taxa de sucesso subestima o valor da experimentação. Agora temos uma nova capacidade: LLM evals podem avaliar relevância, coerência, tom e alinhamento de intenção em escala, mais rápido e mais barato que anotação humana.

A armadilha é tratar evals como substitutos para experimentos. Eles não são. A relação correta é um funil, não uma bifurcação — como descrevem Schultzberg e Ottens (2024) no framework de funil de avaliação. Evals vêm antes do seu experimento, não no lugar dele.

Fonte: Spotify Engineering Blog

O Funil de Avaliação: Verificação Depois Validação

Schultzberg e Ottens traçam uma linha clara entre verificação e validação:

• Verificação (evals): A saída está de acordo com os padrões de qualidade? A resposta é coerente, não-tóxica, alinhada com o prompt?
• Validação (experimentos): Usuários reais respondem como previsto? A mudança gera o resultado de negócio esperado?

Evals descartam candidatos não promissores antes de consumirem largura de banda de experimentação. Eles aumentam a taxa de acerto dos experimentos que vêm depois. Mas não podem dizer se os usuários que receberam a versão melhorada tiveram resultados melhores a longo prazo — se a correção evitou a erosão lenta da confiança que leva ao churn. Essa pergunta exige um experimento.

Duas Camadas de Calibragem, Um Loop de Feedback

Evals são proxies. Eles substituem uma pontuação por um resultado que realmente importa. Agora os juízes LLM adicionam uma segunda camada de calibragem sobre métricas quantitativas tradicionais (ranking scores, precisão, recall). Ambas as camadas precisam de validação contra resultados online. Ambas podem sofrer drift.

Quando o juiz diz que a Variante A é melhor, será que ela realmente entrega uma experiência de usuário melhor, ou o juiz está recompensando padrões superficiais que não geram resultados? Por exemplo, quando a Anthropic lançou o Opus 4.5, os evals de código do Qodo não mostraram melhora, mas o modelo tinha melhorado substancialmente em tarefas mais longas — um experimento controlado teria capturado isso. O desalinhamento acontece nos dois sentidos.

# Pseudocódigo do loop de calibragem simplificado
import numpy as np

def calibrar_pesos_eval(pontuacoes_eval, resultados_experimento):
    """
    Ajusta os pesos dos componentes do eval para prever melhor
    os resultados online.
    
    Args:
        pontuacoes_eval: dict de dimensões do eval (coerência, relevância, tom)
        resultados_experimento: dict de métricas de negócio (retenção, engajamento)
    Returns:
        pesos_atualizados: dict de pesos ajustados por dimensão
    """
    # Regressão linear simples para descobrir quais dimensões
    # do eval melhor predizem o resultado do experimento
    X = np.column_stack([pontuacoes_eval[d] for d in pontuacoes_eval])
    y = np.array(list(resultados_experimento.values()))
    
    # Ajusta coeficientes (pesos) que minimizam o erro de predição
    pesos, _, _, _ = np.linalg.lstsq(X, y, rcond=None)
    
    return {dim: p for dim, p in zip(pontuacoes_eval.keys(), pesos)}

O Que os Evals Te Dão — e o Que Eles Não Te Dão

Além das dimensões que você está medindo, existem aquelas que você não está medindo. No Spotify, times revertem cerca de 42% dos experimentos lançados para prevenir regressão em métricas secundárias: tempo de sessão caindo, taxas de crash subindo, retenção erodindo. Nenhum eval ou avaliação offline sinalizou isso.

Métricas de Guardrail São Importantes

Como descrito no trabalho do Spotify sobre métricas de guardrail, o objetivo de uma guardrail é monitorar dimensões que você se importa mas não está otimizando. Um eval mede qualidade de implementação em uma dimensão. Um experimento quantifica o impacto em sistemas em produção e usuários finais.

Times sob pressão de velocidade às vezes chamam testes A/B de "caros". Mas fazer deploy sem um experimento pode ser incrivelmente caro se uma regressão grande passar despercebida. Quanto mais complexo o sistema, mais importante é limitar o risco.

Feche o Loop

Rode evals cedo e com frequência para encontrar os melhores tratamentos. Depois deixe o experimento validar que usuários reais e sistemas respondem como previsto. Monitore as métricas que você não otimizou.

Depois: rode seus LLM evals nos dados do próprio teste A/B. A versão que o juiz preferiu realmente teve melhor performance com usuários? Isso estende o funil de avaliação tradicional. Juízes LLM permitem perguntar não apenas "a métrica mudou?" mas "os aspectos qualitativos mudaram?". Quando a diferença entre pontuações do eval e resultados do experimento é grande, isso é ouro de diagnóstico.

Limitações e Cuidados

• Tarefas longas são difíceis de avaliar: Por construção, comportamentos de longa duração e resultados atrasados são desafiadores para capturar com evals. Não confie apenas em evals para tarefas com ciclos de feedback de vários dias.
• Drift de calibragem: Conforme modelos e comportamento do usuário mudam, o mapeamento entre pontuações de eval e resultados reais pode se deslocar. Recalibragem contínua é obrigatória.
• Evals são opiniões, não evidências: Sem calibragem offline-online, seus evals são apenas opiniões. Trate-os como hipóteses, não como fatos.

Conselhos Práticos para Seu Time

1. Construa seu stack de eval primeiro — antes de rodar qualquer teste A/B, tenha um conjunto de juízes LLM que possam verificar dimensões básicas de qualidade.
2. Use evals para reduzir o conjunto de candidatos — teste 20 variantes de prompt com um eval, depois leve as 3 melhores para um experimento.
3. Calibre continuamente — após cada experimento, compare pontuações de eval com resultados reais e ajuste seus juízes.
4. Não pule métricas de guardrail — mesmo que o eval e a métrica principal pareçam bons, monitore dimensões secundárias que você não está otimizando.

Próximos Passos

Se você está construindo um sistema de avaliação hoje, comece com um juiz simples que mede uma dimensão (por exemplo, relevância ou coerência). Rode ele em dados históricos de experimentos para ver quão bem ele prediz resultados. Depois itere: adicione dimensões, ajuste pesos e feche o loop.

Para um olhar mais profundo sobre como assistentes de IA estão redefinindo interações em plataformas, confira Beyond the Chatbot: How Cloudflare's Agent Lee Redefines Platform Interaction. E se você trabalha com Python, a pesquisa Python Typing in 2025: 86% Adoption & The Challenges That Remain oferece contexto valioso sobre práticas modernas de desenvolvimento.