Harnesses de Avaliação

O que são harnesses de avaliação?

Um harness de avaliação (evaluation harness) é um kit de ferramentas de software que executa modelos em um conjunto padronizado de tarefas, prompts, conjuntos de dados e métricas — e então agrega os resultados em pontuações e relatórios comparáveis.

Para modelos de linguagem (language models) modernos e sistemas baseados em modelos de linguagem grandes (large language models, LLM-based systems), harnesses de avaliação resolvem um problema prático:

  • Você quer responder “O modelo A é melhor do que o modelo B para os meus casos de uso?”
  • Você quer que essas respostas sejam reproduzíveis (mesmas entradas → mesmas saídas), auditáveis (você consegue ver exatamente o que foi executado) e comparáveis (as pontuações significam a mesma coisa entre execuções).

Harnesses de avaliação ficam na camada de “ferramentas e ecossistema” da prática de aprendizado de máquina (machine learning): conectam modelos (checkpoints locais ou APIs) a benchmarks, código de pontuação e relatórios. Eles são usados com frequência em:

  • Seleção de modelo antes da implantação (modelos de pesos abertos vs modelos de API; pequenos vs grandes)
  • Testes de regressão durante o treinamento ou o ajuste fino
  • Benchmarking para artigos de pesquisa e acompanhamento interno de desempenho
  • Verificações de segurança e robustez junto com a avaliação de capacidade

Este artigo traz uma visão de alto nível do lm-eval da EleutherAI, do HELM de Stanford e de outros toolkits de avaliação comuns, além de como usá-los de forma eficaz.

Por que avaliar é difícil para LLMs

A avaliação clássica em aprendizado de máquina costuma se parecer com: conjunto de dados fixo → modelo determinístico → métrica única (acurácia/F1). A avaliação de LLMs é mais bagunçada porque:

  1. A interface do modelo é texto-entrada/texto-saída, então a redação do prompt importa (Engenharia de Prompts).
  2. Muitas tarefas são generativas, e “correção” pode ser subjetiva.
  3. Os resultados podem ser sensíveis a:
    • parâmetros de decodificação (temperature, top-p)
    • escolha e ordenação de exemplos de poucos exemplos
    • tokenização e formatação
    • mudanças no modelo/provedor (para APIs hospedadas)
  4. Benchmarks podem ser comprometidos por contaminação de dados (treinar com dados de teste), especialmente para conjuntos de dados amplamente circulados.

Harnesses de avaliação existem para tornar essas escolhas explícitas, padronizadas e repetíveis.

Ideias e componentes centrais

A maioria dos harnesses de avaliação (lm-eval, HELM e ferramentas semelhantes) tem os mesmos blocos de construção.

Definições de tarefas

Uma tarefa (task) geralmente é definida por:

  • Uma divisão do conjunto de dados (por exemplo, “test”)
  • Um template de prompt (prompt template) (como exemplos são formatados)
  • Uma regra de extração de saída (output extraction rule) (como interpretar a saída do modelo)
  • Uma função de pontuação (scoring function) (acurácia, correspondência exata etc.)
  • Lógica opcional de seleção de poucos exemplos

As tarefas podem ser “perguntas e respostas sem consulta”, múltipla escolha, completação, sumarização etc.

Adaptadores de modelo (“backends”)

Harnesses fornecem adaptadores para conversar com diferentes tipos de modelo:

  • Checkpoints locais (por exemplo, Hugging Face Transformers)
  • Servidores de inferência (vLLM, TGI)
  • Modelos de API (OpenAI, Anthropic etc.)

Essa camada padroniza operações como:

  • pontuação por log-verossimilhança (log-likelihood) (para múltipla escolha)
  • chamadas de geração (para saída livre)
  • processamento em lote, armazenamento em cache, limitação de taxa, lógica de retentativa

Métricas e agregação

Famílias comuns de métricas incluem:

  • Estilo classificação: acurácia, F1, ROC-AUC
  • Correspondência de string: correspondência exata, correspondência de substring, correspondência baseada em regex
  • Sobreposição de n-gramas: BLEU, ROUGE (úteis, mas limitadas para semântica)
  • Similaridade semântica: similaridade cosseno de representações vetoriais (embeddings)
  • Preferência pareada / modelo como juiz (LLM-as-judge): um modelo avalia outro modelo (poderoso, mas pode ser tendencioso)

Harnesses frequentemente calculam métricas por tarefa e agregam entre tarefas (média, média ponderada, médias macro), às vezes produzindo resumos “prontos para leaderboard”.

Controles de reprodutibilidade

Um harness sério rastreará:

  • sementes aleatórias (seleção de poucos exemplos, amostragem)
  • versões do conjunto de dados e pré-processamento
  • templates de prompt e formatação
  • configurações de decodificação
  • identificador exato do modelo e sua revisão

Isso é essencial para comparações científicas e para testes de regressão na engenharia.

lm-eval (EleutherAI LM Evaluation Harness)

O lm-eval (frequentemente chamado de “lm-eval-harness”) é um dos harnesses de código aberto mais usados para benchmarking de modelos de linguagem, especialmente modelos de pesos abertos (open-weight) e comparações de pesquisa.

No que ele é bom

  • Executar um grande catálogo de benchmarks acadêmicos padronizados (por exemplo, raciocínio de múltipla escolha, compreensão de linguagem etc.)
  • Avaliar log-verossimilhança para tarefas de múltipla escolha (uma configuração forte e estável)
  • Produzir resultados em um formato consistente, adequado para acompanhamento ao longo do tempo
  • Suportar backends de inferência locais e alguns backends estilo API (dependendo da versão e de integrações da comunidade)

Na prática, o lm-eval costuma ser usado para responder: “Como meu novo checkpoint se compara a baselines conhecidos?”

Fluxo de trabalho típico (exemplo prático)

Um padrão comum de uso é:

  1. Escolher um modelo (local ou servido)
  2. Escolher tarefas
  3. Rodar a avaliação com configurações fixas
  4. Armazenar saídas no seu rastreador de experimentos (veja Ferramentas de Experimentos)

Exemplo de CLI (ilustrativo — as flags exatas podem mudar entre versões):

lm_eval \
  --model hf \
  --model_args pretrained=meta-llama/Llama-2-7b-hf,trust_remote_code=True \
  --tasks hellaswag,arc_challenge,mmlu \
  --batch_size 8 \
  --num_fewshot 0 \
  --output_path results/llama2-7b.json

Conceitos-chave para entender:

  • --num_fewshot controla exemplos em contexto. Poucos exemplos podem mudar as pontuações dramaticamente.
  • Para tarefas de múltipla escolha, o lm-eval frequentemente pontua alternativas usando log-verossimilhança, em vez de depender de geração livre. Isso reduz a sensibilidade à formatação.

Adicionando ou customizando tarefas

O lm-eval suporta definir tarefas personalizadas (geralmente via arquivos de configuração e hooks em Python). Isso é importante para avaliação no mundo real, onde suas tarefas raramente correspondem exatamente a conjuntos de dados acadêmicos.

Padrões comuns de customização:

  • Substituir o template de prompt para combinar com seu estilo de prompting em produção
  • Adicionar pós-processamento para lidar com peculiaridades de formatação
  • Trocar métricas (por exemplo, correspondência exata → correspondência normalizada)
  • Adicionar conjuntos de dados de domínio (QA interno, tickets de suporte, classificação de políticas)

Mesmo que você nunca faça upstream das suas tarefas, a estrutura do harness ajuda a impedir que a avaliação vire “scripts ad hoc que se desalinham ao longo do tempo”.

Pontos fortes e limitações

Pontos fortes

  • Grande ecossistema de tarefas e forte adoção pela comunidade
  • Sólido para benchmarking repetível no estilo acadêmico
  • Pontuação eficiente para múltipla escolha e tarefas baseadas em verossimilhança

Limitações

  • A avaliação generativa (sumarização, respostas longas) é inerentemente mais difícil; harnesses conseguem executá-la, mas as métricas podem não refletir preferências humanas
  • Algumas tarefas são sensíveis à formatação do prompt; “prompts padrão” podem não corresponder a como você implanta modelos
  • Resultados de benchmark podem ser enganosos se você ignorar contaminação, desalinhamento de domínio ou incerteza estatística

HELM (Stanford Holistic Evaluation of Language Models)

O HELM é um framework de benchmarking e uma suíte de benchmarks projetados em torno de uma visão “holística” da qualidade do modelo — não apenas acurácia bruta em alguns conjuntos de dados, mas também:

  • robustez
  • equidade e viés
  • eficiência e custo
  • toxicidade / comportamentos relacionados à segurança
  • calibração e incerteza (dependendo dos cenários)

O que torna o HELM diferente

O HELM enfatiza cenários (scenarios): cada cenário especifica:

  • um conjunto de dados
  • um padrão de prompt / interação
  • uma suíte de métricas
  • às vezes múltiplas condições (por exemplo, perturbações para robustez)

Em vez de otimizar para um único número de leaderboard, o HELM incentiva observar desempenho em eixos que importam na implantação.

Valor prático

O enquadramento do HELM é especialmente útil quando você precisa avaliar modelos como produtos:

  • Um modelo pode ir bem no MMLU, mas ser caro ou lento demais
  • Um modelo pode ser forte em inglês, mas fraco na sua localidade-alvo
  • Um modelo pode ser capaz, mas falhar em restrições de segurança

Isso complementa harnesses de capacidade como o lm-eval ao ampliar a superfície de avaliação.

Limitações

  • Rodar o HELM de ponta a ponta pode ser operacionalmente mais pesado (mais cenários, mais métricas, mais controle e registro).
  • Algumas dimensões de avaliação (equidade, toxicidade, viés) exigem interpretação cuidadosa e não são “resolvidas” por uma única métrica.

Outros toolkits de avaliação (e onde eles se encaixam)

Além de lm-eval e HELM, o ecossistema inclui ferramentas que focam em camadas diferentes: bibliotecas de métricas, executores de benchmarks e avaliadores no nível de aplicação.

Hugging Face Evaluate (métricas em primeiro lugar)

A biblioteca evaluate da Hugging Face é principalmente um toolkit de métricas e componentes de avaliação em vez de um harness completo de benchmark. Ela é comumente usada quando você tem:

  • um conjunto de dados e previsões já produzidas
  • necessidade de implementações padronizadas de métricas
  • integração com o ecossistema de datasets da Hugging Face (Conjuntos de Dados e Hospedagem)

Exemplo (computando acurácia):

import evaluate

accuracy = evaluate.load("accuracy")
results = accuracy.compute(references=[0, 1, 1], predictions=[0, 0, 1])
print(results)  # {'accuracy': 0.666...}

Use isso quando você quiser construir seu próprio harness ou pipeline, mas não quiser reimplementar métricas.

Executores de benchmarks de código aberto (por exemplo, OpenCompass, LightEval)

Vários projetos buscam oferecer experiências do tipo “rodar muitos benchmarks, muitos modelos”, com ênfases variadas em:

  • execução distribuída
  • backends de inferência rápidos
  • coleções padronizadas de prompts
  • cobertura de benchmarks em chinês/inglês
  • integração com leaderboards

Eles podem se sobrepor ao lm-eval em propósito, mas diferem em:

  • conjuntos de tarefas suportados
  • integrações de backend
  • estilo de configuração
  • suposições padrão de prompting

Se sua organização se importa com uma suíte específica de benchmarks ou cobertura de idiomas, esses toolkits podem ser alternativas ou complementos práticos.

Avaliadores de aplicação/sistema (RAG e sistemas agentivos)

Ao avaliar sistemas (geração aumentada por recuperação, uso de ferramentas, agentes), você frequentemente precisa de métricas que não estão em harnesses clássicos de benchmarks de LLMs, como:

  • qualidade de recuperação (recall@k, MRR)
  • fidelidade / fundamentação (a resposta é sustentada pelos documentos recuperados?)
  • correção de ferramenta (ela chamou a ferramenta certa com os argumentos certos?)
  • sucesso de tarefa de ponta a ponta (o objetivo do usuário foi atingido?)

Essas avaliações frequentemente envolvem rastros (traces) (entradas, trechos recuperados, chamadas de ferramenta) em vez de apenas pares prompt/resposta. Muitas equipes combinam:

Fundamentos teóricos: o que estamos medindo?

Harnesses de avaliação operacionalizam a medição, mas ajuda saber o que significa “boa avaliação”.

Validade, confiabilidade e sensibilidade

  • Validade: o benchmark mede a capacidade com a qual você se importa?
    • Exemplo: um benchmark de múltipla escolha pode não refletir suporte ao cliente em estilo chat.
  • Confiabilidade: você chegaria à mesma conclusão se executasse novamente?
    • Controle aleatoriedade, versionamento e prompts.
  • Sensibilidade: a avaliação consegue detectar melhorias significativas?
    • Tarefas fáceis demais saturam; tarefas difíceis demais podem virar só ruído.

Benchmarking vs utilidade no mundo real

Benchmarks acadêmicos são úteis para comparar capacidades gerais, mas ambientes de produção diferem:

  • linguagem de domínio
  • mudança de distribuição de dados
  • requisitos de contexto longo
  • uso de ferramentas e recuperação
  • restrições de segurança e conformidade com políticas

Uma prática forte é combinar:

  1. Benchmarks públicos (para comparabilidade ampla)
  2. Benchmarks privados/de domínio (para utilidade real)
  3. Testes de red team (red teaming) / testes adversariais (para robustez e segurança)

Pensamento estatístico (frequentemente ausente em avaliação de LLMs)

Mesmo com decodificação determinística, resultados podem variar devido a:

  • amostragem de exemplos de poucos exemplos
  • variantes de prompt
  • ambiguidade do conjunto de dados

Boas práticas incluem:

  • intervalos de confiança ou estimativas por bootstrap para métricas-chave
  • comparações pareadas ao avaliar dois modelos nos mesmos itens
  • acompanhar deltas por item, não apenas médias agregadas

Harnesses não tornam automaticamente a avaliação estatisticamente sólida — mas tornam mais fácil implementar práticas sólidas de forma consistente.

Orientação prática: escolhendo um harness

Se você quer comparações padronizadas de benchmarks de LLMs

Escolha lm-eval (ou um executor de benchmarks semelhante) quando você precisa:

  • resultados repetíveis em tarefas bem conhecidas
  • execução direta via CLI
  • comparação fácil entre modelos

Isso é comum ao iterar sobre modelos de pesos abertos (Modelos Abertos e Licenças).

Se você precisa de avaliação ampla e multidimensional (além da acurácia)

Escolha HELM quando você se importa com:

  • robustez e análises de sensibilidade
  • múltiplos eixos de avaliação (acurácia + eficiência + dimensões de equidade/segurança)
  • uma saída mais no estilo “relatório do modelo”

Se você está construindo seu próprio pipeline de avaliação

Use bibliotecas de métricas (por exemplo, Hugging Face Evaluate) quando:

  • você já tem previsões
  • você está avaliando um conjunto de dados personalizado
  • você quer implementações padronizadas de métricas, não um harness completo

Se você está avaliando aplicações de LLM de ponta a ponta

Considere ferramentas de avaliação orientadas a sistemas ao avaliar:

  • pipelines de geração aumentada por recuperação (recuperação + geração)
  • agentes (planejamento + chamadas de ferramenta)
  • assistentes multi-turno

Esses casos frequentemente precisam de avaliação baseada em rastros, em vez de pontuação de um único par prompt/resposta.

Exemplos práticos: padrões comuns de avaliação

Padrão 1: Testes de regressão durante ajuste fino

Objetivo: evitar “regressões silenciosas” ao mudar dados, código de treinamento ou versões do modelo.

Abordagem:

  • Selecionar 5–20 tarefas representativas (públicas + internas)
  • Fixar prompts e parâmetros de decodificação
  • Executar em todo modelo candidato
  • Falhar a integração contínua (CI) se métricas-chave caírem além de um limiar

Exemplo de pseudo-lógica:

baseline = load_json("results/baseline.json")
candidate = load_json("results/candidate.json")

def assert_not_regressed(task, metric, tolerance):
    b = baseline[task][metric]
    c = candidate[task][metric]
    if c < b - tolerance:
        raise AssertionError(f"{task}:{metric} regressed {b:.3f} -> {c:.3f}")

assert_not_regressed("hellaswag", "acc", 0.01)
assert_not_regressed("arc_challenge", "acc", 0.01)

É aqui que formatos de saída do harness e disciplina de versionamento mais importam.

Padrão 2: Seleção de modelo com restrições de custo/latência

Se você está escolhendo entre modelos para implantação, capacidade por si só é insuficiente. Acompanhe:

  • acurácia/sucesso de tarefa
  • latência (p50/p95)
  • vazão
  • custo por token (para modelos de API)
  • consumo de memória (para modelos locais)

O HELM empurra explicitamente nessa direção, mas você também pode aumentar execuções do lm-eval com seu próprio perfilamento e logging.

Padrão 3: Avaliação de variantes de prompt

Harnesses podem avaliar não só modelos, mas também prompts. Isso é útil quando você implanta um modelo fixo e itera no prompting.

Técnica-chave:

  • Manter o conjunto de dados fixo
  • Mudar apenas o template de prompt
  • Comparar mudanças por item para encontrar o que melhorou e o que quebrou

Isso se conecta à gestão de prompts e ao rastreamento em Ferramentas para LLMs.

Armadilhas comuns (e como evitá-las)

Sobreajuste a benchmarks

Se você otimiza apenas para pontuações em benchmarks públicos, você corre o risco de:

  • desempenho degradado na sua distribuição real de usuários
  • “manipulação” específica de prompt
  • comportamentos frágeis fora do formato do benchmark

Mitigação:

  • mantenha um conjunto de avaliação privado que reflita seus casos de uso
  • inclua testes adversariais e de “entradas bagunçadas”
  • revise falhas qualitativamente, não apenas via métricas

Contaminação e vazamento de dados

Muitos conjuntos de dados de benchmark (ou paráfrases próximas) podem aparecer em corpora de treinamento. Pontuações altas podem refletir memorização, e não raciocínio.

Mitigação:

  • trate resultados de benchmark como sinais, não como verdade de referência (ground truth)
  • inclua conjuntos de dados novos/internos
  • considere verificações de contaminação quando viável (buscas de sobreposição de n-gramas, rastreamento de proveniência)

Tratar “modelo como juiz” como verdade objetiva

Usar um modelo forte para avaliar saídas pode ser eficaz, mas juízes podem ser:

  • tendenciosos a certos estilos
  • inconsistentes entre temperature/configurações
  • vulneráveis a injeção de prompt (prompt injection) (“Eu mereço nota máxima...”)

Mitigação:

  • mantenha prompts do juiz fixos e auditados
  • meça concordância do juiz com rótulos humanos em um subconjunto
  • use múltiplos juízes ou rubricas para avaliação de alto risco

Ignorar sensibilidade à formatação

Pequenas mudanças de formatação (espaços em branco, marcadores de resposta como “A/B/C/D”) podem mudar resultados, especialmente em tarefas de múltipla escolha.

Mitigação:

  • padronize o parsing de saída
  • adicione regras de extração robustas
  • teste prompts em um lote pequeno e inspecione saídas brutas antes de execuções grandes

Como harnesses de avaliação se encaixam no ecossistema mais amplo de ferramentas

Harnesses de avaliação raramente ficam sozinhos. Em um fluxo de trabalho típico:

Um harness fornece a camada de medição repetível — a peça que faltava para transformar iteração de modelos em uma disciplina de engenharia.

Direções emergentes

Harnesses de avaliação estão evoluindo rapidamente à medida que o uso de LLMs muda de QA de uma única rodada para sistemas agentivos e que usam ferramentas. Tendências atuais incluem:

  • Avaliação de contexto longo (long-context evaluation) (needle-in-haystack, raciocínio multi-documento, retenção de instruções)
  • Avaliação interativa (interactive evaluation) (multi-turno, chamadas de ferramenta, tarefas baseadas em ambiente)
  • Suítes de robustez (robustness suites) (typos, paráfrases, prompts adversariais)
  • Avaliação contínua em produção (continuous evaluation in production) (testes A/B online, prompts canário, monitoramento de deriva)
  • Métricas melhores de incerteza e calibração para sistemas de tomada de decisão

A ideia central continua a mesma: definir tarefas com precisão, executá-las de forma consistente e tratar avaliação como uma parte de primeira classe do ciclo de vida de aprendizado de máquina.

Resumo

Harnesses de avaliação como lm-eval e HELM fornecem formas padronizadas e reproduzíveis de testar modelos de linguagem em tarefas, prompts e métricas. O lm-eval é amplamente usado para comparações no estilo benchmark e pontuação baseada em verossimilhança; o HELM enfatiza avaliação mais ampla e multidimensional entre capacidade, robustez e considerações de eficiência. Ferramentas complementares — de bibliotecas de métricas a avaliadores no nível de sistema — preenchem lacunas para pipelines personalizados e aplicações de LLM de ponta a ponta.

O recado prático: use um harness para tornar a avaliação repetível e auditável, mas projete sua suíte de avaliação para refletir suas necessidades reais de implantação, não apenas desempenho em leaderboard.