LLM Evals O Funil Que Torna Seus Testes A/B Mais Inteligentes (Não Redundantes)

O Novo Superpoder: Julgamento Automatizado de Qualidade em Escala

Por anos, o teste A/B foi o padrão ouro para decisões de produto. No Spotify, apenas cerca de 12% dos testes A/B resultam em algo positivo lançado — mas 64% produzem aprendizado válido: uma regressão detectada, uma ideia descartada, uma hipótese refinada. A taxa de sucesso subestima o valor da experimentação.

Agora temos uma nova capacidade: LLM evals. Esses juízes automatizados podem avaliar dimensões que não conseguíamos escalar antes — relevância, coerência, tom, alinhamento de intenção — mais rápido e mais barato que anotação humana, em qualquer dado, de conjuntos de teste a variantes de teste A/B.

O insight crítico? Evals e experimentos medem coisas diferentes. A relação correta é um funil, não um garfo. Como os pesquisadores Schultzberg e Ottens (2024) descrevem, os evals vêm antes do seu experimento, não no lugar dele.

Verificação vs. Validação: Entenda a Diferença

LLM evals verificam: a saída está de acordo com os padrões de qualidade? Experimentos validam: usuários reais respondem como previsto?

Uma stack de evals forte significa que você não testa para descobrir se a mudança faz o que você pretendia. Os evals já te disseram isso. Você testa para validar que a mudança pretendida gera o resultado de negócio esperado, e para limitar o risco de prejudicar o negócio.

# Exemplo simplificado: usando um juiz LLM para filtrar prompts candidatos

def avaliar_candidato(prompt: str, modelo_juiz: str = "gpt-4") -> dict:
    """
    Retorna uma pontuação de qualidade e problemas sinalizados para um prompt.
    Isso roda ANTES do teste A/B para descartar variantes de baixa qualidade.
    """
    resposta = openai.chat.completions.create(
        model=modelo_juiz,
        messages=[
            {"role": "system", "content": "Você é um juiz de qualidade. Avalie o prompt a seguir em relevância, coerência e tom. Saída JSON com score (0-1) e lista de problemas."},
            {"role": "user", "content": prompt}
        ],
        response_format={"type": "json_object"}
    )
    return json.loads(resposta.choices[0].message.content)

# Uso em um funil
candidatos = [prompt_a, prompt_b, prompt_c]
filtrados = []
for c in candidatos:
    resultado = avaliar_candidato(c)
    if resultado["score"] > 0.7:  # só passa candidatos de alta qualidade para o A/B
        filtrados.append(c)
# Agora roda o teste A/B apenas nos candidatos filtrados

Evals também geram hipóteses. Considere um time que constrói um juiz LLM para sinalizar conteúdo que quebra a confiança — por exemplo, uma recomendação compartilhada com um usuário que não se encaixa. O juiz revela padrões que o time não sabia que existiam. Esses padrões viram correções de produto. Depois que a correção é lançada, o mesmo juiz pode verificar se funcionou: as violações sinalizadas devem cair. Esse é o eval fazendo dois trabalhos: descobrir o que melhorar e confirmar que a melhoria foi realizada.

Duas Camadas de Calibragem, Um Único Loop de Feedback

Evals são proxies. Eles substituem uma pontuação por um resultado que você realmente se importa. Essa substituição só é válida enquanto a pontuação acompanha o resultado real — a mesma dinâmica que descrevemos com métricas proxy.

Agora, 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 oferece 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 modelo Opus 4.5, os evals de código do Qodo não mostraram melhora, mas o modelo havia melhorado substancialmente em tarefas mais longas — um experimento controlado teria captado isso. O descalibramento funciona nos dois sentidos. Sem calibragem do sinal offline-online, nossos evals são opiniões, não evidências.

O Loop de Feedback na Prática

Ao ajustar continuamente os evals para melhorar seu mapeamento para resultados online, os evals se tornam ferramentas de verificação cada vez melhores. Não estamos descartando que, no futuro, conforme a IA avança, os evals possam mapear bem o suficiente para começar a atuar como validações — mas apenas se o loop de calibragem offline/online estiver em vigor.

Fechando o Loop: De Opiniões a Evidências

Times sob pressão de velocidade às vezes chamam testes A/B de "caros". Sabemos por experiência que lançar sem um experimento pode ser incrivelmente caro, se uma grande regressão em métricas de negócio passar despercebida. Quanto mais complexo o sistema, mais importante é limitar o risco.

Conselho prático para seu time:

1. Rode evals cedo e com frequência para encontrar os melhores tratamentos.
2. Deixe o experimento validar que usuários e sistemas reais respondem como previsto.
3. Monitore métricas que você não otimizou — guardrails capturam regressões.
4. Rode seus LLM evals nos próprios dados do teste A/B. A versão que o juiz preferiu realmente teve melhor desempenho com os usuários? Isso estende o funil de avaliação tradicional.

Quando o gap entre as pontuações do eval e os resultados do experimento é grande, isso é ouro diagnóstico. Cada ciclo ajuda a calibrar o próximo. Se usuários que receberam a versão melhorada mostrarem engajamento de longo prazo superior, o time confirmou que o que o juiz mede realmente importa. Se as pontuações do juiz melhoraram mas os resultados dos usuários não, esse é o sinal de calibragem: o juiz está capturando algo, mas não a coisa que gera valor.

Limitações e Cuidados

• Evals têm dificuldade com tarefas de longa duração e comportamento de longo prazo por construção. São instantâneos, não trajetórias.
• Juízes LLM podem alucinar ou exibir viés. Sempre valide com revisão humana em um subconjunto.
• Calibragem não é um esforço único. Conforme modelos e comportamento do usuário evoluem, seus evals também devem evoluir.

Próximos Passos

• Comece com um juiz LLM simples para uma dimensão (ex.: consistência de tom).
• Construa um pipeline pequeno que rode evals antes de cada teste A/B.
• Após o teste, compare as pontuações dos evals com os resultados do experimento.
• Itere nos prompts e thresholds do seu juiz com base no gap.

Para mais sobre a arquitetura por trás da separação entre personalização e experimentação, confira nosso mergulho em por que stacks de tecnologia separadas para personalização e experimentação. E se você está curioso sobre como a IA está passando de prototipação para produção, veja nossa análise da nova plataforma v0 da Vercel.

Este artigo se baseia em pesquisas e práticas internas do Spotify, originalmente publicado no Spotify Engineering.