Avaliação de LLM (Large Language Models)

Visão geral

avaliação de LLM (LLM Evaluation) é o conjunto de métodos usados para medir a qualidade, a confiabilidade e a segurança de modelos de linguagem de grande porte (large language models, LLMs) de um jeito que sustente dois objetivos práticos:

  1. seleção de modelo (model selection): escolher o melhor modelo (e a configuração de elaboração de prompts (prompting)/decodificação (decoding)) para um caso de uso-alvo.
  2. monitoramento de regressão (regression monitoring): detectar degradações de qualidade ou segurança após a implantação (atualizações do modelo, mudanças de prompt, mudanças no índice de recuperação (retrieval index), mudanças de ferramentas (tools), deriva de tráfego (traffic drift)).

Diferentemente do aprendizado de máquina supervisionado (supervised ML) clássico, LLMs são de propósito geral e frequentemente produzem texto de final aberto (open-ended text), então a avaliação precisa lidar com ambiguidade, múltiplas respostas aceitáveis e sensibilidade a prompts e à amostragem. Uma boa avaliação combina:

  • avaliação offline (offline evaluation) (benchmarks (benchmarks), conjuntos de teste curados (curated test sets), testes de estresse (stress tests))
  • avaliação em produção (production evaluation) (telemetria (telemetry), feedback do usuário, testes A/B (A/B tests), monitoramento canário (canary monitoring))

Este artigo foca no desenho prático de avaliação: o que medir, como medir e como evitar armadilhas comuns como contaminação, sensibilidade a prompts e variância.

Tópicos relacionados: Avaliação Offline (Offline Evaluation), Avaliação Humana (Human Evaluation), LLM como Juiz (LLM-as-Judge), Avaliação Robusta (Robust Evaluation), Avaliação de Segurança (Safety Evaluation), Contaminação do Conjunto de Teste (Test Set Contamination), Reprodutibilidade e Significância Estatística (Reproducibility & Statistical Significance), Lei de Goodhart em Métricas (Goodhart's Law in Metrics).

O que torna a avaliação de LLMs difícil?

Saídas abertas e tarefas subespecificadas

Muitas tarefas (sumarização, respostas de suporte ao cliente, assistência de programação) não têm uma única resposta “correta”. Pode ser necessário medir:

  • Utilidade e completude
  • Correção (factualidade, validade do raciocínio, fundamentação (groundedness))
  • Estilo (tom, verbosidade, formatação)
  • Segurança (comportamento de recusa, toxicidade, conformidade com políticas)
  • Restrições operacionais (latência, custo, uso de tokens)

Sensibilidade a prompts e dependência de configuração

O desempenho pode mudar significativamente com:

  • Redação do prompt e instruções do sistema
  • Poucos exemplos (few-shot)
  • Disponibilidade de ferramentas / contexto de recuperação (retrieval)
  • Parâmetros de decodificação (temperatura (temperature), top_p (top_p), máximo de tokens (max tokens))
  • Mudanças na versão do modelo

Um modelo não é um único ponto; é uma distribuição de comportamentos condicionada à configuração.

Não determinismo e variância

A decodificação baseada em amostragem introduz aleatoriedade; mesmo configurações “determinísticas” podem variar devido a mudanças de backend. Pequenas melhorias podem ser ilusórias sem intervalos de confiança (confidence intervals) e execuções repetidas.

Objetivos de avaliação: defina o que “bom” significa

Comece com uma declaração clara do que você quer otimizar. Um modelo útil:

  • Tarefa: o que os usuários estão tentando fazer
  • Critérios de sucesso: o que uma boa resposta precisa conter / evitar
  • Modos de falha: como é o “ruim” (alucinação (hallucination), aconselhamento inseguro, recusa quando deveria responder etc.)
  • Restrições: latência, custo, estilo, política
  • Plano de medição: suíte offline + sinais em produção

Isso está intimamente relacionado à Construção de Benchmark (Benchmark Construction): você precisa de testes que reflitam o uso real, não apenas o que é fácil de pontuar.

Avaliação offline: construindo uma suíte de tarefas (task suite)

A avaliação offline é onde você itera rapidamente e compara candidatos sob condições controladas. Uma suíte offline robusta normalmente inclui:

  1. Testes da tarefa principal (solicitações representativas)
  2. Casos-limite (raros, mas importantes)
  3. Testes adversariais / de estresse (injeção de prompt (prompt injection), formatação complicada, entradas ambíguas)
  4. Testes de segurança (conteúdo não permitido, correção de recusa)
  5. Testes não funcionais (latência, custo, estabilidade)

O que incluir em uma suíte offline

Uma suíte prática costuma ter 100–2.000 itens, dependendo da complexidade da tarefa e do custo de julgamento.

  • Conjunto ouro (golden set): casos de alto sinal revisados e curados por especialistas
  • Falhas recentes em produção: prompts de “reprodução de bug (bug repro)” convertidos em testes permanentes
  • Variantes sintéticas (synthetic variants): paráfrases, perturbações de formatação, variantes multilíngues
  • Casos críticos para políticas (policy-critical cases): limites de autoagressão, medicina, jurídico, aconselhamento financeiro

Dica: armazene casos de teste com metadados para poder segmentar resultados por categoria.

{
  "id": "support_refund_042",
  "input": {
    "user_message": "I was charged twice for my subscription. What do I do?",
    "locale": "en-US",
    "account_type": "consumer"
  },
  "expected": {
    "must_include": ["apology", "investigate", "refund_or_escalate"],
    "must_not_include": ["ask_for_password"]
  },
  "tags": ["billing", "refunds", "pii-policy"],
  "difficulty": "medium"
}

Benchmarks vs. suítes internas de tarefas

Benchmarks públicos ajudam a medir capacidades amplas, mas podem divergir do seu aplicativo e são vulneráveis a sobreajuste (overfitting) e vazamento (leakage). Muitas equipes usam um híbrido:

  • Benchmarks públicos para capacidade geral e regressões (checagem ampla de sanidade)
  • Suítes internas para qualidade específica do app e alinhamento a políticas

Para mais sobre coleções curadas, veja Suítes de Benchmark (Benchmark Suites) e Rankings (Leaderboards).

Escolhendo métricas: alinhe a métrica à tarefa

A avaliação de LLMs geralmente precisa de um portfólio de métricas, não de uma única pontuação.

1) Métricas de correspondência exata e classificação (quando aplicável)

Para tarefas com alvos bem definidos (por exemplo, extração de campos, seleção de um rótulo):

  • Acurácia, F1, ROC-AUC
  • Correspondência exata (exact match, EM)
  • Validade de saída estruturada (structured output validity) (conformidade com esquema JSON (JSON schema compliance))

Elas são rápidas, baratas e confiáveis — use-as sempre que a tarefa puder ser formulada dessa forma.

2) Métricas baseadas em referência de similaridade textual (use com cautela)

Para sumarização/tradução, métricas automatizadas comuns incluem BLEU, ROUGE, METEOR, chrF, BERTScore. Elas podem ser úteis para verificações de regressão, mas frequentemente têm correlação fraca com a preferência humana quando múltiplas respostas são aceitáveis.

Orientação prática:

  • Use-as como sinais secundários, não como o decisor principal.
  • Prefira avaliação humana ou avaliação baseada em rubrica (rubric-based judging) para a seleção final.

3) Julgamento baseado em modelo (LLM como juiz)

Uma abordagem moderna comum é usar um LLM para pontuar saídas contra uma rubrica (rubric), às vezes sem referências. Isso pode escalar para suítes grandes e capturar critérios sutis (tom, correção, seguimento de instruções).

Práticas-chave:

  • Use rubricas claras e peça pontuações estruturadas + justificativa
  • Prefira comparações pareadas (A vs. B) para maior sensibilidade
  • Calibre contra rótulos humanos em um subconjunto
  • Use múltiplos prompts de juiz ou múltiplos modelos julgadores para robustez

Veja LLM como Juiz para calibração e modos de falha (viés, preferência por verbosidade, viés posicional).

Exemplo de esboço de prompt de juiz:

You are grading a customer-support reply.

Score each dimension 1-5:
- Correctness (policies, factual claims)
- Helpfulness (actionable steps)
- Safety/Privacy (no sensitive data requests)
- Tone (empathetic, professional)

Return JSON with scores and a brief justification per dimension.

4) Avaliação humana (o padrão-ouro para muitas tarefas)

A avaliação humana é mais lenta e cara, mas essencial quando:

  • A correção exige conhecimento do mundo real ou nuance de políticas
  • Você se importa com preferência subjetiva (tom, utilidade)
  • Juízes automatizados são pouco confiáveis no seu domínio

Protocolos comuns:

  • Avaliações em escala Likert (Likert ratings) por dimensão
  • Preferência pareada (pairwise preference) (A/B) com opção de empate
  • Seleção melhor de N (best-of-N) para estratégias de geração
  • Revisão por especialistas (expert review) para domínios de alto risco

Veja Avaliação Humana para viés de avaliadores, ancoragem e concordância entre avaliadores.

Projetando rubricas que funcionam

Uma boa rubrica é:

  • Específica: define o que conta como correto/incorreto
  • Acionável: ajuda engenheiros a corrigirem problemas
  • Segmentável: permite insights por categoria
  • Alinhada ao valor do usuário: mede o que importa, não o que é fácil

Exemplo: rubrica para “respostas fundamentadas” em um cenário assistido por recuperação (retrieval) (geração aumentada por recuperação (retrieval-augmented generation, RAG))

  • 5: Todas as afirmações-chave são sustentadas pelas fontes fornecidas; cita trechos relevantes; sem alucinações
  • 3: Em grande parte sustentadas; pequenas formulações sem sustentação; citações incompletas
  • 1: Afirmações importantes sem sustentação ou contradiz as fontes

(Para medidas de RAG específicas por aplicação, veja Avaliação de Aplicações com LLM (LLM App Evaluation).)

Avaliação de robustez: estresse o sistema, não apenas o modelo

Robustez significa desempenho sob variação realista e condições adversariais. A avaliação robusta normalmente inclui:

Perturbações de prompt e formatação

  • Paráfrases de solicitações do usuário
  • Erros de digitação, maiúsculas/minúsculas, espaços em branco extras
  • Diferente ordenação das instruções
  • Tentativas do tipo “Ignore previous instructions…” (conteúdo semelhante a injeção de prompt)

Testes de mudança de distribuição (distribution shift)

  • Novos nomes de produto, novas políticas, novas gírias
  • Diferentes localidades/idiomas
  • Contextos mais longos (estresse da janela de contexto (context window))
  • Falhas de ferramenta/API (tool/API failures) (estouros de tempo (timeouts), resultados de recuperação vazios)

Testes adversariais

  • Tentativas de quebra de restrições (jailbreak)
  • Instruções ambíguas ou contraditórias
  • Entradas projetadas para provocar alucinações (citações falsas, entidades inexistentes)

Esses métodos são discutidos de forma mais ampla em Avaliação Robusta.

Avaliação de segurança: meça tanto recusas quanto conclusões seguras

Segurança não é apenas “ele recusa solicitações prejudiciais?” Você também precisa medir:

  • Falsos negativos (false negatives): conformidade insegura quando deveria recusar
  • Falsos positivos (false positives): recusa quando uma resposta segura seria apropriada
  • Qualidade da conclusão segura (safe completion quality): quando o usuário pergunta sobre um tema sensível, mas é necessária uma resposta segura e útil (por exemplo, recursos de crise para autoagressão)

Categorias comuns de segurança:

  • Ódio/assédio, violência, conteúdo sexual
  • Autoagressão e resposta a crises
  • Orientação para atividades ilegais
  • Tratamento de privacidade/PII (informações de identificação pessoal (personally identifiable information, PII))
  • Limites de aconselhamento médico/jurídico/financeiro

Uma suíte de segurança deve incluir:

  • Solicitações diretamente não permitidas
  • Solicitações limítrofes que exigem nuance
  • Solicitações benignas que parecem suspeitas (para testar recusa excessiva (over-refusal))
  • Tentativas de jailbreak em múltiplas rodadas (multi-turn)

Para um tratamento mais aprofundado, veja Avaliação de Segurança.

Armadilhas comuns (e como mitigá-las)

1) Contaminação e vazamento do conjunto de teste

Se itens de avaliação (ou paráfrases muito próximas) aparecem nos dados de treinamento, as pontuações inflacionam e deixam de refletir generalização real. A contaminação pode acontecer acidentalmente via:

  • Benchmarks públicos incluídos em corpora de treinamento
  • Conjuntos de avaliação internos vazando para dados de ajuste fino (fine-tuning)
  • Registro (logging) e re-treinamento em dados de produção que incluem prompts de teste

Mitigações:

  • Manter versionamento e controle de acesso rigorosos do conjunto de dados
  • Usar strings canário (canary strings) para detectar memorização
  • Atualizar periodicamente conjuntos de avaliação
  • Fazer verificações de sobreposição (overlap checks) (n-gramas (n-gram), similaridade de embeddings (embedding similarity)) com dados de treinamento quando viável

Veja Contaminação do Conjunto de Teste.

2) Sensibilidade a prompts mascarando qualidade do modelo

Comparar o Modelo A com um prompt cuidadosamente ajustado vs. o Modelo B com um prompt genérico não é uma comparação justa.

Mitigações:

  • Avalie (modelo, prompt, decodificação) como um pacote
  • Use uma fase de otimização de prompts (prompt optimization) e depois congele prompts para a seleção
  • Teste múltiplas variantes de prompt para estimar sensibilidade
  • Use formatação padronizada (standardized formatting) (mensagem do sistema (system message), esquema de ferramenta (tool schema), esquema JSON de saída (output JSON schema))

3) Variância e “jogo de benchmarks (benchmark gambling)”

Uma diferença pequena (por exemplo, +0,3%) pode não ser real se você só executou uma vez ou usou poucos itens.

Mitigações:

  • Execute múltiplas sementes (seeds) para decodificação estocástica
  • Use intervalos de confiança via bootstrap (bootstrap confidence intervals) para taxas de vitória (win-rates) / pontuações médias
  • Prefira comparações pareadas (mesmos itens) e reporte a incerteza
  • Pré-registre (pre-register) o que significa “melhoria relevante” para o seu app

Veja Reprodutibilidade e Significância Estatística.

4) Lei de Goodhart: otimizar a métrica quebra o produto

Se você otimizar para o que o juiz recompensa (verbosidade, certas formulações), pode piorar a experiência do usuário.

Mitigações:

  • Use múltiplas métricas e auditorias humanas periódicas
  • Inclua testes adversariais e “anti-trapaça (anti-cheating)”
  • Monitore resultados reais de usuários em produção
  • Alterne rubricas/juízes ocasionalmente

Veja Lei de Goodhart em Métricas.

Fluxo prático offline para seleção de modelo

Um fluxo comum e eficaz:

  1. Defina as tarefas-alvo e as restrições

    • por exemplo: “redação de e-mails de suporte ao cliente, não pode pedir senhas, deve citar a seção de política quando relevante, < 2s de latência p95”

  2. Construa a suíte de avaliação

    • 60% casos comuns, 20% casos-limite, 20% alto risco/segurança

  3. Escolha métodos de avaliação

    • Checagens automatizadas para formatação/JSON/esquema
    • LLM como juiz para qualidade multidimensional
    • Avaliação humana em um subconjunto estratificado (stratified subset) (especialmente fatias de alto risco)

  4. Faça um bake-off (bake-off)

    • Compare candidatos usando prompts pareados e configurações idênticas de decodificação
    • Registre custo/latência/uso de tokens
    • Segmente resultados por categoria, não apenas pela pontuação geral

  5. Faça análise de erros (error analysis)

    • Agrupe falhas: alucinação, erros de recusa, tom, política, falhas de ferramentas
    • Converta as principais falhas em testes permanentes de regressão

Mini exemplo: selecionando um modelo para respostas de suporte

Suponha que você compare dois candidatos:

  • Modelo A: maior “utilidade”, mas ocasionalmente pede senhas
  • Modelo B: um pouco menos verboso, mas sempre segue a política de privacidade

Mesmo que o Modelo A vença em preferência média, o Modelo B pode ser a escolha correta se violações de privacidade forem inaceitáveis. É por isso que métricas de segurança e restrições devem ser tratadas como portas obrigatórias (hard gates) em muitas aplicações.

Avaliação em produção: monitoramento de regressão e qualidade no mundo real

Pontuações offline frequentemente falham em prever comportamento em produção porque:

  • Prompts reais são mais bagunçados e diversos
  • O contexto de ferramentas/RAG muda
  • As expectativas dos usuários evoluem
  • Atacantes se adaptam

A avaliação em produção deve responder:

  • “A qualidade está estável ao longo do tempo?”
  • “A última mudança degradou algo?”
  • “O que os usuários estão vivenciando agora?”

Principais sinais em produção

  • Feedback do usuário: joinha para cima/baixo, reescritas, categorias de reclamação
  • Proxies comportamentais (behavioral proxies): taxa de conclusão de tarefas, taxa de escalonamento, tempo até resolução
  • Telemetria de segurança (safety telemetry): acionamentos de violação de política, taxas de detecção de jailbreak
  • Métricas de confiabilidade: latência p50/p95, timeouts, taxas de falha de ferramentas
  • Métricas de custo: tokens por solicitação, tempo de GPU, taxas de acerto de cache (cache hit rates)

Importante: proxies podem ser enganosos; interprete com cuidado e valide contra revisão humana.

Padrões de monitoramento de regressão

1) Avaliação sombra (a.k.a. “lançamento escuro (dark launch)”)

Rode o novo modelo em paralelo sem afetar usuários; compare saídas offline usando:

  • Juízes LLM
  • Checagens heurísticas (heuristic checks)
  • Revisão humana amostrada (sampled human review)

Isso é poderoso para capturar regressões antes do rollout.

2) Testes canário e prompts fixos

Mantenha um pequeno conjunto de prompts fixos (fixed prompts), versionados que rodam continuamente em produção (ou na integração contínua (continuous integration, CI)) para detectar deriva de comportamento (behavior drift). Inclua:

  • Prompts críticos de segurança
  • Prompts de uso de ferramentas
  • Prompts conhecidos de formatação complicada

3) Teste A/B (quando for seguro)

Direcione uma fração do tráfego para a nova variante e compare resultados do usuário. Cuidado com:

  • Efeitos de novidade
  • Mudanças na mistura de usuários
  • Efeitos de interação (mudanças no modelo alteram o comportamento do usuário)

Se você fizer testes A/B, garanta filtragem (gating) de segurança e mecanismos de rollback (rollback).

Para uma avaliação mais ampla em nível de aplicação, veja Avaliação de Aplicações com LLM.

Juntando tudo: uma “pilha” de avaliação (evaluation stack)

Um programa maduro de avaliação de LLMs frequentemente se parece com isto:

  • Testes unitários (unit tests): formatação, validade de esquema, saídas determinísticas de ferramentas
  • Suíte offline: tarefas representativas + adversariais + segurança
  • Julgamento automatizado (automated judging): LLM como juiz + heurísticas leves
  • Auditorias humanas (human audits): análises aprofundadas periódicas e revisões direcionadas
  • Monitoramento em produção: canários, execuções sombra, ciclos de feedback (feedback loops), testes A/B
  • Governança (governance): versionamento de conjuntos de dados, logs de mudanças (change logs), critérios de release (release criteria), rollback

Exemplo de critérios de release (práticos e aplicáveis)

Antes de implantar um novo modelo/prompt:

  • Sem regressões em portas de privacidade/segurança (categorias com tolerância 0)
  • ≤ 1% de queda na preferência geral com 95% de confiança ou um trade-off justificado
  • Latência p95 dentro do SLO (objetivo de nível de serviço)
  • Custo por ticket resolvido dentro do orçamento
  • Todos os prompts de “incidente conhecido” passam (suíte de regressão)

Dicas de implementação: construindo um harness de avaliação (evaluation harness)

Um harness de avaliação simples deve suportar:

  • Conjuntos de dados e prompts versionados
  • Execução de múltiplos modelos e configurações
  • Amostragem repetida (sementes)
  • Armazenamento de saídas para auditabilidade
  • Análises de segmentação (slice-and-dice analytics)

Esboço em pseudo-Python:

def run_eval(model, dataset, prompt_template, seeds=(0,1,2)):
    rows = []
    for item in dataset:
        for seed in seeds:
            prompt = prompt_template.render(item["input"])
            out = model.generate(prompt, seed=seed, temperature=0.7)
            rows.append({
                "id": item["id"],
                "seed": seed,
                "output": out,
                "tags": item.get("tags", [])
            })
    return rows

def summarize_with_judge(judge, rows, rubric):
    judged = []
    for r in rows:
        score = judge.grade(output=r["output"], rubric=rubric)
        judged.append({**r, **score})
    return judged

Armazene tudo (entradas, versão do modelo, versão do prompt, configurações de decodificação). Quando algo der errado em produção, você vai querer reproduzir.

Interpretando resultados: além de uma única pontuação

Quando você obtiver resultados de avaliação, sempre pergunte:

  • Quais categorias melhoraram ou regrediram?
  • A segurança melhorou às custas de recusa excessiva?
  • Os ganhos estão concentrados em itens fáceis?
  • As falhas estão correlacionadas com contexto longo, falhas de ferramentas ou localidades específicas?
  • As melhorias se mantêm entre variantes de prompt e sementes?

Pontuações agregadas são úteis para acompanhamento, mas decisões devem se basear em métricas segmentadas + revisão qualitativa (qualitative review).

Resumo

Avaliar LLMs bem exige tratar a avaliação como um sistema de engenharia, não como uma execução única de benchmark:

  • Use suítes offline para iteração rápida e comparações controladas.
  • Combine métricas automatizadas, LLM como juiz e avaliação humana com base em risco e ambiguidade.
  • Inclua testes de robustez e segurança como componentes de primeira classe.
  • Projete a avaliação para lidar com armadilhas reais: contaminação, sensibilidade a prompts e variância.
  • Em produção, priorize monitoramento de regressão, avaliação canário/sombra e validação por resultados do usuário.

Se você fizer isso de forma consistente, a avaliação vira uma ferramenta confiável tanto para selecionar modelos melhores quanto para manter sistemas estáveis conforme tudo ao redor muda.