🧠FFVAcademy
📊

Como Avaliar Modelos de IA

9 min de leitura·+60 XP
Pré-requisitos (0/1)0%

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

“GPT-4 tem 86% no MMLU” — e dai? Essa metrica ajuda a escolher o modelo certo para o seu caso de uso? Provavelmente nao. Neste artigo, voce vai entender os benchmarks que existem, seus limites, e como montar uma avaliacao propria que realmente informa decisoes.

Os benchmarks mais relevantes

BenchmarkO que medeComo funcionaLimitacao
MMLUConhecimento geral (57 dominios)Multiple choice: historia, bio, fisica, direito, etc.Mede reconhecimento, nao raciocinio profundo
HumanEvalGeracao de codigo Python164 problemas de programacao; mede pass@kProblemas simples; nao reflete coding real
SWE-benchResolucao de issues reaisIssues de repos open-source; verifica se patch passa nos testesPadrao ouro para coding; caro de rodar
GPQARaciocinio expert-levelPerguntas de PhD em fisica, bio, quimicaMuito dificil; humanos experts acertam ~65%
LMArena (Chatbot Arena)Preferencia humanaHumanos comparam respostas de 2 modelos (blind)Sujeito a vieses (prefere respostas longas)
MATHRaciocinio matematicoProblemas de competicao matematicaModelos modernos ja saturam (~90%+)
ARC-AGIRaciocinio abstrato / fluidaPattern matching visual com regras nao vistasControverso; talvez nao mexa o que promete

Pitfalls de benchmarks publicos

PitfallExemploImpacto
Benchmark overfittingTreinar o modelo em dados similares ao benchmarkScore alto no benchmark, performance real mediocre
Data contaminationPerguntas do benchmark vazam no dataset de treinoModelo "decorou" respostas; score inflado
Cherry-pickingEmpresa reporta so benchmarks onde vai bemVisao distorcida das capacidades reais
Metricas agregadasMedia de 57 dominios esconde que modelo e pessimo em matematicaDecisao baseada em numero que nao reflete seu caso
SaturacaoMMLU e HumanEval ja estao >90% para modelos topBenchmark nao diferencia mais entre modelos top
⚠️
Regra de ouro: benchmarks publicos sao triagem, nao decisao. Se dois modelos tem 85% vs 87% no MMLU, a diferenca e irrelevante para o seu chatbot de atendimento. O que importa: como eles performam no seu dominio, com seus dados, para seus usuarios.

Avaliacao propria: o que realmente importa

🗺️ Montando seu eval pipeline
📋1. Coletar exemplos representativos100+ exemplos
Perguntas reais dos seus usuarios, ou sinteticas que representem o dominio. Cobrir edge cases, nao so o happy path.
DEFINIR RUBRICA
📏2. Definir rubrica de qualidadecriterios claros
O que e uma resposta "boa"? Ex: (1) factualmente correta, (2) responde a pergunta feita, (3) tom adequado, (4) concisa. Cada criterio com score 1-5.
RODAR MODELOS
🤖3. Gerar respostas de cada modeloA/B test
Rodar os mesmos 100+ exemplos em cada modelo candidato com o mesmo prompt. Salvar respostas para avaliacao.
AVALIAR
⚖️4. Avaliar com LLM-as-Judge + humanoscalibrado
LLM forte (Opus/GPT-4) avalia cada resposta pela rubrica. Calibrar contra 20+ julgamentos humanos. Se concordancia < 80%, refinar rubrica.
DECIDIR
📊5. Comparar custo, latencia e qualidadedecisao
Modelo A: 92% qualidade, $0.03/req, 1.2s. Modelo B: 88% qualidade, $0.005/req, 0.4s. A decisao depende do que importa PARA VOCE.

LLM-as-Judge: automatizando avaliacao

Avaliar 1000 respostas manualmente e impraticavel. LLM-as-Judge usa um modelo forte para avaliar outputs de modelos mais fracos:

python
# LLM-as-Judge simplificado
import anthropic

client = anthropic.Anthropic()

rubric = """
Avalie a resposta do modelo nos seguintes criterios (1-5):
1. Corretude factual: a resposta esta correta?
2. Relevancia: responde a pergunta feita?
3. Completude: cobre os pontos importantes?
4. Clareza: e clara e bem organizada?
5. Concisao: e concisa sem ser superficial?

Retorne JSON: {"scores": {"corretude": N, ...}, "total": N, "reasoning": "..."}
"""

def evaluate(question: str, answer: str) -> dict:
    response = client.messages.create(
        model="claude-opus-4-20250514",  # juiz forte
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": f"""
{rubric}

Pergunta: {question}
Resposta do modelo: {answer}
"""
        }]
    )
    return parse_json(response.content[0].text)

# Rodar em batch
results_a = [evaluate(q, model_a(q)) for q in test_set]
results_b = [evaluate(q, model_b(q)) for q in test_set]
avg_a = sum(r["total"] for r in results_a) / len(results_a)
avg_b = sum(r["total"] for r in results_b) / len(results_b)
Vies do LLM-as-JudgeDescricaoMitigacao
Position biasPrefere a primeira resposta em comparacoes A vs BRodar 2x invertendo a ordem; media dos resultados
Verbosity biasPrefere respostas mais longas mesmo quando menos precisasIncluir "concisao" como criterio explicito na rubrica
Self-favoritismModelo prefere outputs do proprio modeloUsar juiz de familia diferente (Claude julga GPT e vice-versa)
CalibracaoScores absolutos variam entre execucoesCalibrar contra julgamentos humanos; usar scores relativos (A vs B)

Metricas especificas por dominio

DominioMetricasFerramentas
RAGRecall@k, nDCG, faithfulness, relevanceRAGAS, LlamaIndex eval
Codingpass@k, SWE-bench resolve rate, edit accuracyHumanEval, SWE-bench, custom test suites
ChatbotUser satisfaction, resolution rate, escalation rateLLM-as-judge + metricas de negocio
SummarizationROUGE, BERTScore, faithfulnessROUGE-L para baseline, LLM-as-judge para qualidade
ClassificationF1, precision, recall, confusion matrixsklearn metrics + domain-specific thresholds

Framework de decisao

📋 Escolhendo modelo para producao

Eval proprio > benchmarks publicos

Benchmarks publicos sao triagem rapida (eliminar modelos claramente inferiores). A decisao final SEMPRE deve ser baseada em avaliacao no SEU dominio, com SEUS dados, medindo o que importa PARA VOCE.

Alt: So benchmarks publicosAceitavel apenas para prototipacao rapida onde a decisao e reversivel e o custo de errar e baixo.

🗺️ Processo de seleção de modelo — 4 filtros
🌐Universo (~20 modelos)Frontier + open-source relevantes para seu caso
📊Filtro 1: benchmarks + custoEliminar modelos claramente inferiores → shortlist de 3–5
🧪Filtro 2: eval próprio100+ exemplos do seu domínio → candidatos de 2 modelos
⚖️Filtro 3: A/B em produção1–2 semanas com usuários reais → modelo escolhido
📈Monitoramento contínuoEval automatizado semanal — drift detection

Eval Harness: pipeline de avaliação profissional

Um eval harness é a infraestrutura que automatiza suas avaliações — rodar os mesmos testes em novos modelos, comparar versões, detectar regressões. Sem harness, avaliação é manual e não-reproduzível.

🗺️ Anatomia de um eval harness
📦Dataset de eval100-1000+ exemplos
Conjunto curado de inputs + outputs esperados (gold answers). Deve cobrir: casos típicos, edge cases, casos de falha conhecidos. Versionar como código.
inputs
Runnerparalelo, com retry
Envia cada exemplo para o modelo (ou modelos em paralelo). Lida com rate limits, erros e timeouts. Salva outputs crus com metadata (modelo, versão, timestamp, latência, custo).
outputs
📏ScorerLLM-as-judge + métricas
Pontuação por rubrica (0-5), métricas automáticas (ROUGE, F1, pass@k), ou comparação direta com gold. LLM-as-judge para qualidade subjetiva.
scores
📊Report + trackinghistórico + alertas
Dashboard com histórico de scores por modelo/versão. Alertas se regressão > 5% em qualquer métrica. Integração com CI/CD para rodar em cada deploy.
python
# Eval harness mínimo em Python
import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def eval_one(example: dict, model: str) -> dict:
    resp = await client.messages.create(
        model=model,
        max_tokens=1024,
        messages=[{"role": "user", "content": example["input"]}]
    )
    output = resp.content[0].text
    score = await score_with_judge(output, example["expected"])
    return {"input": example["input"], "output": output,
            "expected": example["expected"], "score": score}

async def run_eval(dataset, model):
    results = await asyncio.gather(
        *[eval_one(ex, model) for ex in dataset]
    )
    avg = sum(r["score"] for r in results) / len(results)
    print(f"{model}: {avg:.2f}/5.0 ({len(results)} exemplos)")
    return results

A/B Testing de modelos em produção

Eval offline garante qualidade em dados históricos. A/B testing valida no contexto real: usuários reais, padrões de uso reais, resultados de negócio reais.

AspectoEval OfflineA/B Testing
Quando usarAntes do deploy — triagem e validaçãoApós deploy — validação no mundo real
DadosDataset curado de historicoRequests de produção ao vivo
MétricaScore de rubrica, benchmarksCTR, resolution rate, satisfação, receita
DuraçãoMinutos a horas1-2 semanas (significância estatística)
RiscoNenhum para usuáriosPossível impacto negativo no grupo B
CustoFixo (dataset + compute)Custo de servir o modelo mais caro simultaneamente
⚠️
Armadilha do A/B prematuro: testar um modelo novo sem eval offline primeiro expõe usuários reais a riscos desnecessários. O fluxo correto é sempre: eval offline (eliminar candidatos ruins) → A/B em produção (validar o melhor candidato). Nunca pule a etapa offline — é barata e protege seus usuários.

Perguntas e respostas

Preciso montar eval se so estou prototipando?

Para prototipo: nao. Use benchmarks publicos + vibes (teste manual). Mas antes de ir para producao, eval proprio e inegociavel. O custo de rodar 100 exemplos em 3 modelos e ~$5-20. O custo de escolher o modelo errado em producao e ordens de magnitude maior.

Com que frequencia devo reavaliar?

Sempre que: (1) o provider atualiza o modelo (versao nova); (2) seus dados ou dominio mudam; (3) um modelo novo promissor e lancado; (4) metricas de producao degradam. Na pratica: eval automatizado semanal em sample dos dados de producao + eval completo a cada atualizacao de modelo.

LMArena (Chatbot Arena) e confiavel?

E o melhor benchmark de preferencia humana disponivel: blind, randomizado, milhares de votos. Mas tem vieses: respostas longas e formatadas ganham de respostas concisas e corretas. E a populacao de votantes (tech-savvy, ingles) pode nao representar seus usuarios. Use como sinal forte, nao como verdade absoluta.

Benchmark vs produção: o que realmente medir

ContextoO que medirComo medir
Benchmark (pré-escolha)Triagem rápida: qual modelo não usarMMLU, SWE-bench, HumanEval + custo/M tokens
Eval próprio (pré-deploy)Qualidade no SEU domínio, com SEUS dadosRubrica + LLM-as-Judge calibrado em 100+ exemplos
Produção (pós-deploy)Satisfação real, taxa de resolução, escalonamentosLogs de usuário + feedback explícito + metricas de negócio
Monitoramento (contínuo)Degradação de qualidade, drift de distribuiçãoEval automatizado semanal em sample dos requests
💡
Produção é a fonte da verdade. Um modelo que pontua 92% no seu eval pode ter satisfação de usuário inferior a um de 88% se o de 88% for mais conciso e direto. Sempre feche o loop: métricas de produção devem realimentar sua rubrica de eval.
O que voce aprendeu: benchmarks publicos (MMLU, HumanEval, SWE-bench, LMArena) sao uteis para triagem mas insuficientes para decisoes de producao. Benchmark overfitting, data contamination e cherry-picking sao problemas reais. Avaliacao propria com rubrica + LLM-as-Judge calibrado e o padrao ouro. A decisao final considera qualidade + custo + latencia no seu dominio especifico. Com isso, voce terminou a Trilha 2 — agora tem base para entender como ferramentas de IA para codigo funcionam. Para ir mais fundo em avaliacao de RAG e LLMOps, veja Avaliando RAG (Trilha 9) e LLMOps: eval harness, drift e canary (Trilha 9).
🧩

Quiz rápido

4 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito

Continue lendo