Por Que a Avaliação Define o Sucesso de GenAI
A IA Generativa quebra as premissas dos testes de software tradicionais. Saídas de LLM são não-determinísticas e "correto" é subjetivo. Uma única interação pode encadear recuperação, raciocínio, chamadas de ferramentas e geração—cada uma com seus próprios modos de falha. Sem uma estratégia deliberada de avaliação, os times enfrentam três resultados previsíveis:
- Falsa confiança: Métricas genéricas de "utilidade" pontuam bem, mas perdem falhas reais.
- Regressões não detectadas: Uma pequena mudança no prompt degrada silenciosamente algo que você não estava medindo.
- Esforço desperdiçado: Pipelines caros construídos para métricas que não correlacionam com resultados.
A solução é o desenvolvimento orientado a avaliação (EDD)—o análogo de GenAI ao TDD. Não é overhead; é assim que se constroem produtos que funcionam. A primeira regra? Olhe seus dados. Rode seu protótipo contra 100 exemplos, leia cada saída, categorize os erros e construa suas avaliações a partir do que observar.
Essa abordagem exige infraestrutura e hábitos para descobrir, codificar e testar continuamente modos de falha. Times devem definir metas e portões upfront, co-desenvolver métricas com parceiros cross-funcionais baseados em falhas observadas, e manter um conjunto pequeno de 3–5 avaliadores bem calibrados em vez de 20–30 ruidosos. Um decisor humano designado resolve discordâncias sobre o que é "bom".
A Stack de Avaliação em Três Camadas
Toda avaliação roda em uma combinação de três métodos, formando uma defesa em camadas:
# Camada 1: Verificações Programáticas - Rápidas, determinísticas, pegam falhas óbvias
import json
from typing import Any, Dict
def validar_resposta_llm(resposta: str) -> Dict[str, Any]:
"""Validar estrutura da resposta do LLM antes de avaliação profunda."""
try:
dados = json.loads(resposta)
return {
"json_valido": True,
"dados": dados,
"erro": None
}
except json.JSONDecodeError as e:
return {
"json_valido": False,
"dados": None,
"erro": str(e)
}
# Camada 2: LLM como Juiz - Avaliação de qualidade com rubrica
prompt_juiz = """
Avalie a legibilidade de explicações de anúncios. Uma boa explicação
soa como um agente de viagens amigável: caloroso mas profissional.
Dê nota 1 se ler de forma limpa.
Dê nota 0 se tiver QUALQUER um desses problemas:
- Tom: muito formal/jargão, muito casual, ou robótico
- Formatação: sem aspas, sem bullets, sem fragmentos
- Gramática: sem artigos ou preposições para fluxo natural
- Complexidade: palavras simples em vez de jargão
Retorne APENAS:
{"reason": "", "score": <1 ou 0>}
"""
# Camada 3: Avaliação Humana - Padrão ouro para edge cases e calibração
# Amostrar 50-100 exemplos para dataset dourado, incluindo exemplos ruins
Calibração: Tornando Seu Juiz Virtual Confiável
Um juiz LLM não calibrado é pior que nenhum juiz—cria falsa confiança. Siga estes passos:
- Crie um dataset dourado de 50–100 exemplos, incluindo os ruins.
- Rode seu juiz contra o dataset dourado.
- Meça concordância (alvo: 80–90%) usando kappa de Cohen ou alpha de Krippendorff.
- Analise discordâncias, refine prompts, atualize few-shot examples e rode novamente.
- Recalibre periodicamente conforme os modos de falha evoluem.
Avaliando Sistemas Agênticos e Walkthrough Prático
Sistemas agênticos exigem avaliação além das saídas finais. Uma resposta correta pode mascarar caminhos de raciocínio quebrados ou parâmetros de ferramentas errados. Você precisa avaliar a trajetória: timing de invocação de sub-agentes, seleção de ferramentas e transições de estado intermediárias.
# Reconstruir traces de agentes para avaliação de trajetória
from collections import deque
from typing import Any, Dict, List
def avaliar_trajetoria_agente(raiz_trace: Dict[str, Any]) -> List[Dict[str, Any]]:
"""Percorrer traces de agentes para avaliar passos intermediários."""
pontos_avaliacao = []
fila = deque([raiz_trace])
while fila:
no = fila.popleft()
# Verificar se as ferramentas certas foram chamadas
if no.get("tool_calls"):
for ferramenta in no["tool_calls"]:
pontos_avaliacao.append({
"agente": no.get("agent_name"),
"ferramenta": ferramenta.get("name"),
"params": ferramenta.get("arguments"),
"esperado": no.get("expected_tool")
})
# Percorrer sub-agentes
for filho in no.get("children", []):
fila.append(filho)
return pontos_avaliacao
# Exemplo: Exploração com 100 inputs revelou
# 15 problemas de fidelidade, 8 de verbosidade, 5 recusas excessivas, 3 erros JSON
# Construir verificações programáticas + 2 juízes virtuais (fidelidade, concisão)
# Calibrar até concordância >88%, então escalar para 5000 exemplos
Um Walkthrough Prático
Construindo um assistente de IA para políticas de suporte? Comece com 100 inputs, leia cada saída e categorize falhas. Depois construa verificações programáticas para validade JSON e limites de tamanho, escreva juízes virtuais para fidelidade e concisão, e peça ao seu PM para rotular um conjunto dourado de 60 exemplos.
Ao iterar, fixe uma variável por vez: primeiro modelo, depois prompt, depois configuração de serving. Juízes virtuais estreitam o pool de candidatos em cada estágio, afiando tanto avaliadores quanto candidatos até estabilizarem.
Para produção, amostre 5% do tráfego live de-identificado diariamente, rode verificações programáticas mais juízes virtuais, e sinalize saídas para revisão humana. Uma revisão semanal do PM fecha o ciclo, transformando novos modos de falha em novas avaliações.
Principais Conclusões e Próximos Passos
O princípio central: Leia saídas e traces antes de construir qualquer coisa. Métricas genéricas falham; construa avaliadores para os modos de falha reais do seu produto.
- Comece com 50–100 linhas—falhe rápido, itere barato.
- Um avaliador por dimensão. Sem "Deus avaliadores".
- Calibre para 80–90% de concordância antes de confiar em juízes virtuais em escala.
- Use todos os três métodos como defesas em camadas.
- Inclua exemplos ruins no seu conjunto dourado—você não pode testar discernimento sem eles.
- Avalie o sistema, não só o modelo: recuperação, chamadas de ferramentas, pipeline completo.
- Espelhe avaliações em produção; métricas pré-produção não são one-and-done.
A limitação: Este framework assume acesso a dados representativos e especialistas para calibração. Times pequenos podem lutar com o fardo de rotulação. Comece com escopo estreito—uma feature, 100 exemplos—e expanda conforme validar a abordagem.
Próximo passo: Aplique isso ao seu produto. Escolha uma feature de LLM, revise manualmente 100 saídas e categorize as falhas. Construa uma verificação programática e um juiz virtual para o problema mais comum. Calibre contra julgamento humano, depois escale.
Avaliação é um esporte de time. Times que têm sucesso com IA não são os com melhores modelos—são os com melhor comunicação e visão de produto mais clara. Para mais contexto sobre padrões de avaliação entre indústrias, veja este mergulho profundo no LLM-as-judge da Netflix ou este case study da Amazon Verified Permissions.
Leitura relacionada: