Avaliação para PLN (NLP)

Por que “avaliação” é difícil em PLN

Muitas tarefas de Processamento de Linguagem Natural (NLP) produzem linguagem como saída: traduções, resumos, respostas de diálogo, legendas e mais. Diferentemente da classificação (classification), raramente existe uma única string “correta”. Várias saídas podem ser aceitáveis por causa de:

  • Paráfrase (“buy” vs “purchase”)
  • Reordenação (voz ativa vs voz passiva)
  • Diferentes níveis de detalhe (escolhas de tamanho do resumo)
  • Variação estilística (formal vs informal)
  • Ambiguidade (múltiplas interpretações válidas)

Isso torna a avaliação fundamentalmente diferente de tarefas em que a acurácia (accuracy) é bem definida. Como resultado, a maioria das métricas automáticas é proxy: elas se correlacionam (de forma imperfeita) com julgamentos humanos, e essa correlação pode depender fortemente do domínio, do idioma e da configuração da tarefa.

Este artigo foca em três famílias de métricas amplamente usadas:

  • BLEU (comum em tradução automática (machine translation))
  • ROUGE (comum em sumarização (summarization))
  • BERTScore (similaridade semântica (semantic similarity) usando incorporações contextuais (contextual embeddings))

e explica por que a escolha da métrica pode ser enganosa, mesmo quando os números parecem “científicos”.

Contexto relacionado: Tarefas Centrais, Modelagem de Linguagem, Modelos de Incorporação e Recuperação de Informação.

O que torna uma métrica de PLN “boa”?

Uma métrica prática deveria idealmente ter:

  1. Validade: mede o que você considera importante (adequação (adequacy), fidelidade (faithfulness), utilidade, etc.)
  2. Confiabilidade: estável sob pequenas perturbações (por exemplo, diferentes referências)
  3. Sensibilidade: distingue melhorias significativas de ruído
  4. Robustez: resiste a ser “manipulada” por truques triviais
  5. Interpretabilidade: desenvolvedores conseguem raciocinar sobre mudanças
  6. Eficiência: viável de calcular em escala
  7. Comparabilidade: consistente entre artigos e conjuntos de dados

Nenhuma métrica única satisfaz tudo isso em todas as tarefas. A maior armadilha é tratar qualquer métrica como uma “verdade” objetiva em vez de um instrumento de medição com vieses conhecidos.

Métricas de sobreposição de n-gramas: a base comum

BLEU e ROUGE se baseiam em contar a sobreposição entre n-gramas (n-grams) (sequências contíguas de tokens) em uma saída do modelo e uma ou mais referências. A suposição subjacente é:

“Um bom texto compartilha muitas formas de superfície com o texto de referência.”

Isso funciona razoavelmente bem quando:

  • a tarefa tem liberdade limitada de paráfrase (por exemplo, alguns benchmarks de tradução),
  • as referências são numerosas e diversas,
  • você se importa principalmente com sobreposição de conteúdo.

Falha quando:

  • paráfrases são comuns,
  • há poucas referências (muitas vezes apenas uma),
  • a correção depende do significado em vez de sobreposição de palavras,
  • escolhas de estilo variam.

A tokenização (tokenization) também importa. Escolhas discutidas em Aprofundamento em Tokenização podem mudar as fronteiras de n-gramas e, portanto, os valores das métricas.

BLEU (Bilingual Evaluation Understudy)

O que o BLEU mede (e como)

BLEU é usado principalmente para tradução automática. Ele calcula precisão (precision) modificada de n-gramas (tipicamente até 4-gramas) e então aplica uma penalidade por brevidade (brevity penalty) para desencorajar saídas curtas demais.

Em alto nível:

  • Para cada n em 1..4, calcule a precisão:
    • Conte n-gramas na saída candidata.
    • “Corte” contagens pelo máximo de ocorrências na(s) referência(s).
  • Combine via média geométrica (geometric mean) das precisões.
  • Multiplique pela penalidade por brevidade se a saída for mais curta que a referência.

BLEU geralmente é calculado no nível de corpus (corpus level) (agregando contagens ao longo de muitas sentenças), porque BLEU no nível de sentença (sentence-level) é muito ruidoso.

Por que o BLEU se popularizou

  • Rápido, simples, agnóstico ao idioma
  • Correlacionou-se razoavelmente com julgamentos humanos em cenários iniciais de MT
  • Fácil de reproduzir (especialmente com implementações padronizadas como SacreBLEU)

Exemplo prático: penalidade por paráfrase

Referência:

“The meeting was postponed because of the storm.”

Candidata A:

“The meeting was delayed due to the storm.”

Candidata B:

“The meeting was postponed because of the storm.”

Humanos provavelmente avaliariam A como essencialmente perfeita. BLEU muitas vezes pontua B muito mais alto do que A porque A altera muitas formas de superfície (“postponed”→“delayed”, “because of”→“due to”).

Armadilhas comuns do BLEU

  • Forte viés para precisão: BLEU foca em “quanto da saída aparece na referência”, não se a saída cobriu todo o conteúdo-chave.
  • Fraco em significado: pode recompensar saídas que copiam uma redação parecida com a referência mesmo se a semântica se desviar.
  • Insensível a erros de adequação: uma tradução fluente, porém errada, pode manter muitos n-gramas comuns.
  • Dependência de referência: com apenas uma referência, muitas traduções válidas recebem BLEU injustamente baixo.
  • Peculiaridades da penalidade por brevidade: incentiva tamanho semelhante ao da referência; pode penalizar concisão legítima.
  • Não é diagnóstica: um ganho de +0,5 BLEU não diz o que melhorou.

Boa prática: use SacreBLEU para comparabilidade

Diferentes implementações de BLEU variam (tokenização, suavização). Se você precisar usar BLEU, reporte-o com uma ferramenta padronizada (por exemplo, SacreBLEU) e inclua a assinatura.

import sacrebleu

refs = [["The meeting was postponed because of the storm."]]
cands = ["The meeting was delayed due to the storm."]
print(sacrebleu.corpus_bleu(cands, refs))

ROUGE (Recall-Oriented Understudy for Gisting Evaluation)

O que o ROUGE mede

ROUGE é comum para sumarização e tipicamente é orientado à revocação (recall): ele pergunta “quanto do conteúdo de referência o sistema capturou?”

Variantes comuns:

  • ROUGE-N: revocação de sobreposição de n-gramas (frequentemente ROUGE-1 e ROUGE-2)
  • ROUGE-L: baseado na Maior Subsequência Comum (Longest Common Subsequence) (captura alguma reordenação)
  • ROUGE-S / ROUGE-SU: variantes de bigramas com salto (skip-bigrams) (menos comuns hoje)

Muitos artigos de sumarização reportam ROUGE F1 (equilibrando precisão e revocação), mas historicamente ROUGE enfatizou revocação.

Por que o ROUGE é amplamente usado

  • Espera-se que resumos contenham frases-chave da fonte/referência
  • Fácil de calcular e comparar
  • Acompanha melhorias em sumarização extrativa (extractive) de forma razoável

Exemplo prático: quando o ROUGE recompensa cópia

Suponha que o resumo de referência contenha uma frase específica:

Referência:

“The company reported record profits but warned about supply chain risks.”

Um modelo que copia frases da fonte que contenham essas expressões pode pontuar alto em ROUGE, mesmo se:

  • incluir detalhes copiados irrelevantes,
  • estiver mal estruturado,
  • não trouxer o ponto principal, mas por acaso sobrepor frases comuns.

Este é um dos motivos pelos quais ROUGE historicamente favoreceu métodos extrativos e pode subestimar melhorias em sumarização abstrativa (abstractive).

Armadilhas comuns do ROUGE

  • Viés de revocação: pode favorecer saídas mais longas que incluem mais tokens sobrepostos.
  • Dependência de forma de superfície: paráfrases e sinônimos podem pontuar mal.
  • Fraco em fidelidade: afirmações alucinadas (hallucination) podem não ser penalizadas se outro conteúdo sobrepuser.
  • Sensibilidade à referência: um único resumo de referência muitas vezes é insuficiente — sumarização tem alta variância em saídas válidas.
  • Manipulação por comprimento: às vezes é possível aumentar ROUGE adicionando conteúdo genérico ou redundante que por acaso sobrepõe.

Exemplo de melhoria enganosa:

  • Modelo A: resumo conciso e preciso com paráfrase → ROUGE menor
  • Modelo B: resumo mais longo e mais extrativo → ROUGE maior, mas pior experiência do usuário

BERTScore (similaridade baseada em incorporações)

A motivação

BLEU/ROUGE tratam texto como sacos de n-gramas. BERTScore tenta medir similaridade semântica usando incorporações contextuais de transformadores pré-treinados (pretrained transformers) (por exemplo, BERT, RoBERTa, DeBERTa), conectando-se a ideias em Arquitetura Transformer e Representação de Texto.

A ideia central:

  1. Incorporar cada token no candidato e na referência usando um modelo contextual.
  2. Associar cada token do candidato ao token mais similar da referência (similaridade do cosseno (cosine similarity)).
  3. Calcular precisão, revocação e F1 sobre essas similaridades.
  4. Opcionalmente aplicar reescala de baseline (baseline rescaling) para melhorar a interpretabilidade.

Isso permite que “delayed” corresponda a “postponed” com mais força do que a palavras não relacionadas.

Por que o BERTScore pode correlacionar melhor com humanos

  • Lida melhor com paráfrases e sinônimos do que sobreposição de n-gramas
  • Mais robusto a mudanças de ordem de palavras (até certo ponto)
  • Muitas vezes melhora a correlação para tarefas em que o significado importa mais do que a redação exata

Exemplo prático: simpatia a paráfrases

Referência:

“The meeting was postponed because of the storm.”

Candidata:

“The storm caused the meeting to be delayed.”

BERTScore tipicamente atribui maior similaridade do que BLEU/ROUGE porque as incorporações de tokens capturam relação semântica.

Você pode calculá-lo assim:

from bert_score import score

cands = ["The storm caused the meeting to be delayed."]
refs  = ["The meeting was postponed because of the storm."]

P, R, F1 = score(cands, refs, lang="en")  # choose model by lang internally
print(float(F1[0]))

Armadilhas do BERTScore (e por que “semântico” não é “correto”)

BERTScore ainda pode ser enganoso:

  • Alucinações podem passar: um candidato pode ser fluente e topicalmente similar enquanto contém um detalhe falso crítico. Incorporações similares não garantem consistência factual.
  • Negação e antônimos: às vezes, incorporações colocam “good” e “not good” mais perto do que você desejaria para correção estrita. Negação é um modo de falha clássico.
  • Desalinhamento de domínio: se o modelo de incorporações não estiver alinhado com seu domínio (médico, jurídico), julgamentos de similaridade podem piorar.
  • A dependência de referência permanece: se sua referência omite um detalhe válido, BERTScore pode penalizá-lo.
  • Custo computacional: bem mais pesado do que BLEU/ROUGE.
  • Interpretabilidade: uma mudança de 0,842 para 0,848 é difícil de interpretar sem contexto.

Em resumo, BERTScore é um proxy melhor para similaridade semântica, mas similaridade semântica não é o mesmo que sucesso na tarefa.

Por que a escolha da métrica pode ser enganosa

1) Otimizar a métrica muda o comportamento do modelo (lei de Goodhart (Goodhart’s law))

Se você treina, ajusta (tune) ou seleciona modelos com base em uma métrica, você incentiva comportamentos que inflacionam essa métrica.

  • Seleção por ROUGE pode favorecer resumos mais longos e mais extrativos.
  • Ajuste por BLEU pode incentivar redação que imita a referência e traduções conservadoras.
  • Ajuste por BERTScore pode recompensar similaridade tópica mesmo quando a correção fina está errada.

Isso é especialmente importante em pipelines modernos em que LLMs (modelos de linguagem grandes (LLMs)) são ajustados com modelos de recompensa (reward models) ou otimização por preferência (preference optimization); a métrica de avaliação pode se tornar o sinal de recompensa indiretamente. Veja também: Modelagem de Linguagem.

2) Uma única referência é um “padrão-ouro (gold standard)” fraco

Muitos conjuntos de dados fornecem apenas uma saída de referência por entrada, mas muitas saídas são válidas. Isso causa falsos negativos (false negatives) em que boas saídas pontuam baixo.

Mitigações:

  • Coletar múltiplas referências
  • Usar avaliação humana para um subconjunto
  • Usar métricas desenhadas para múltiplas respostas corretas (dependente da tarefa)

3) Métricas fazem médias que “apagam” falhas raras, porém graves

Médias no nível de corpus podem esconder problemas críticos:

  • Um sumarizador que alucinou fatos em 2% dos casos ainda pode ter ROUGE/BERTScore médio forte.
  • Em domínios de alto risco (high-stakes domains), essas falhas raras dominam o risco no mundo real.

Se você se importa com segurança ou correção, precisa de avaliações direcionadas (por exemplo, checagens de factualidade, conjuntos adversariais (adversarial sets), auditoria de erros (error auditing)).

4) Métricas medem similaridade com referências, não utilidade para usuários

Um resumo pode ser “similar”, porém pouco útil:

  • ênfase errada
  • estrutura ruim
  • não responde à pergunta pretendida do usuário
  • tom inadequado

Avaliação centrada no usuário frequentemente exige medidas específicas da tarefa e, às vezes, teste A/B (A/B testing) online.

5) Métricas podem discordar — e ambas podem estar “certas” sobre propriedades diferentes

É comum ver:

  • Modelo A melhora ROUGE mas piora preferência humana.
  • Modelo B melhora BERTScore mas piora factualidade.
  • Modelo C melhora BLEU mas produz traduções mais literais e menos naturais.

Isso não é paradoxo: revela que você está medindo coisas diferentes.

Escolhendo métricas por tarefa: orientação prática

Tradução Automática

  • BLEU ainda é uma linha de base comum para continuidade e comparabilidade.
  • Mas considere complementá-lo com métricas aprendidas (learned metrics) (por exemplo, COMET) e checagens humanas de adequação e fluência (fluency).

O que observar:

  • Melhorias pequenas em BLEU ainda podem ser significativas (idiomatismos melhores), ou sem sentido (sobreajuste à tokenização).
  • Reporte detalhes de implementação (tokenização, maiúsculas/minúsculas, assinatura do SacreBLEU).

Sumarização

  • ROUGE-1/2/L são comuns, mas incompletas.
  • Adicione checagens de fidelidade (alucinações) e cobertura de fatos-chave.

Adição prática:

  • Avaliação manual em uma amostra estratificada (stratified sample): verifique erros factuais, pontos-chave ausentes, redundância.

Geração aberta (diálogo, escrita criativa)

  • BLEU/ROUGE frequentemente são ativamente enganosas.
  • BERTScore pode correlacionar em alguma medida, mas preferência do usuário e seguimento de instruções (instruction-following) importam mais.

Nesses cenários, considere:

  • Julgamentos de preferência humana
  • Rubricas específicas da tarefa
  • Abordagens de LLM como juiz (LLM-as-a-judge) (use com cautela e calibração (calibration))

Geração aumentada por recuperação e QA

Se a saída precisa ser ancorada (grounded) em fontes, similaridade com referência não é suficiente. Muitas vezes você precisa de:

Erros comuns de avaliação (e como evitá-los)

Erro: Reportar apenas uma métrica

Correção:

  • Reporte múltiplas métricas complementares (por exemplo, ROUGE + BERTScore + auditoria de factualidade).
  • Inclua exemplos qualitativos destacando diferenças.

Erro: Tratar pequenas variações de métrica como melhorias reais

Correção:

  • Use intervalos de confiança (confidence intervals) (reamostragem por bootstrap (bootstrap resampling) é comum).
  • Execute testes de significância (significance tests) e reporte variabilidade entre sementes aleatórias (random seeds).

Erro: Comparar números calculados de maneiras diferentes

Correção:

  • Use bibliotecas padronizadas e documente configurações (tokenização, maiúsculas/minúsculas).
  • Mantenha scripts de avaliação consistentes entre modelos.

Erro: Ignorar mudanças de distribuição (distribution shifts)

Correção:

  • Avalie em conjuntos no domínio (in-domain) e fora do domínio (out-of-domain).
  • Adicione “conjuntos de desafio (challenge sets)” focando modos de falha conhecidos (negação, entidades, raciocínio numérico).

Erro: Sobreajuste a benchmark (benchmark overfitting)

Correção:

  • Separe um conjunto de teste privado se possível.
  • Atualize periodicamente os dados de avaliação.
  • Use avaliação humana para detectar “manipulação de leaderboard (leaderboard gaming)”.

Um fluxo de trabalho prático de avaliação (recomendado)

  1. Defina o que “bom” significa para sua aplicação
    Exemplos: factualidade, completude, concisão, estilo, segurança.

  2. Escolha uma métrica principal alinhada a esse objetivo

    • Tradução: BLEU (linha de base) + checagens de adequação
    • Sumarização: ROUGE (proxy de cobertura) + avaliação de factualidade
    • Tarefas de paráfrase/similaridade semântica: BERTScore pode ser útil

  3. Adicione pelo menos uma métrica complementar que cubra um eixo diferente
    Exemplo para sumarização:

    • ROUGE (cobertura)
    • BERTScore (similaridade semântica)
    • Auditoria humana de factualidade (veracidade)

  4. Inspecione exemplos de:

    • falhas com pontuação alta (a métrica diz que é bom, humanos discordam)
    • sucessos com pontuação baixa (a métrica diz que é ruim, humanos acham que está tudo bem)

  5. Reporte incerteza
    Intervalos de confiança, testes de significância e detalhamento por categoria.

  6. Itere
    Atualize métricas quando descobrir pontos cegos sistemáticos.

Resumo: quando BLEU/ROUGE/BERTScore ajudam — e quando enganam

  • BLEU: útil como benchmark histórico e padronizado de tradução automática, mas penaliza paráfrases e pode não captar erros de adequação.
  • ROUGE: útil para medir sobreposição de conteúdo em sumarização, mas pode recompensar extratividade e comprimento, e é fraca para factualidade.
  • BERTScore: melhor para paráfrase e similaridade semântica, mas não garante correção e pode não detectar contradições/alucinações cruciais.

A lição principal é que a escolha da métrica codifica valores. Se você medir apenas sobreposição superficial, você vai otimizar sobreposição superficial. Se você medir similaridade semântica, você vai otimizar similaridade semântica. Nenhuma delas captura automaticamente o que os usuários realmente querem.

Uma estratégia forte de avaliação em PLN combina múltiplas métricas, relato de incerteza e validação centrada em humanos — especialmente ao implantar modelos fora das suposições estreitas de um benchmark.