8.4. LLM

Todas as outras páginas deste capítulo avaliam um modelo cuja saída pode ser conferida. Uma classe está certa ou errada; um número está perto ou longe. A saída de um modelo de linguagem é um parágrafo e não existe gabarito para comparar — há muitas respostas boas, muitas ruins e nenhuma função que separe umas das outras.

Por isso toda métrica desta página é um proxy e a pergunta útil sobre cada uma não é "como se calcula" e sim do que ela é substituta e quando a substituição quebra? É essa a pergunta que organiza a página, porque na avaliação de modelos de linguagem a substituição quebra o tempo todo e em silêncio.

Perplexidade: o quanto o modelo se surpreende

A métrica mais antiga e a única calculada diretamente a partir daquilo que o modelo foi treinado para fazer. Sobre um texto de teste com \(N\) tokens:

\[ \text{PPL}(W) = \exp\!\left(-\frac{1}{N}\sum_{i=1}^{N} \log p_\theta(w_i \mid w_{<i})\right) \]

É a exponencial da entropia cruzada média, o que lhe dá uma leitura limpa: perplexidade 10 quer dizer que o modelo esteve, em média, tão incerto quanto se estivesse escolhendo uniformemente entre 10 opções a cada token. Menor é melhor; um modelo que espalha a probabilidade uniformemente sobre um vocabulário de \(V\) tokens marca exatamente \(V\).

o quanto o modelo se surpreende com Paris p = 0.72 tokenizar em subpalavras

Duas propriedades dessa fórmula causam quase todo o estrago na prática e as duas estão visíveis acima:

É uma média geométrica de \(1/p\). Arraste a probabilidade de "Paris" para perto de zero: um único token que o modelo acha impossível puxa o número inteiro para cima, por melhor que tenha ido o resto. A perplexidade reporta os tokens que o modelo acha mais difíceis.
Ela divide pelo número de tokens. Marque a caixa de subpalavras: a mesma frase, o mesmo modelo, a mesma log-probabilidade total — e uma perplexidade diferente, porque o denominador mudou.

Perplexidade não se compara entre modelos, a menos que o tokenizador seja o mesmo

Esta é a leitura equivocada mais comum de um número publicado. Um modelo com vocabulário maior quebra o texto em menos tokens e a média por token cai sem que o modelo tenha ficado melhor em prever texto. A grandeza que sobrevive à re-tokenização é a log-probabilidade total do corpus — bits por byte ou bits por caractere — e é por isso que comparações cuidadosas reportam essas¹.

E ela não mede se o modelo é útil

Perplexidade mede ajuste a um corpus. Não diz nada sobre seguir instruções, raciocinar, recusar pedidos nocivos ou estar certo. Um modelo ajustado para ser prestativo costuma ter perplexidade pior em texto cru da web do que o modelo base de onde veio — as duas coisas simplesmente não medem o mesmo.

Métricas de sobreposição e por que aqui elas são a ferramenta errada

BLEU e ROUGE comparam a string gerada com uma string de referência contando n-gramas em comum. Elas são tratadas, com simulador, na página de métricas generativas e a versão curta é: elas medem sobreposição de superfície, não sentido. Uma paráfrase correta tira nota baixa; uma resposta fluente e errada que reaproveita o vocabulário da referência tira nota alta.

Métrica	O que conta	Ainda usada para
BLEU	precisão de n-gramas, com penalidade de brevidade	Tradução automática, onde as referências são apertadas
ROUGE-1/2/L	recall de n-gramas e maior subsequência comum	Sumarização, mais por convenção
BERTScore²	similaridade de cosseno entre embeddings contextuais, casados gulosamente	Quando paráfrase não pode ser punida

Elas sobrevivem por serem baratas e reprodutíveis, não por serem boas. Para geração aberta — que é a maior parte do que um modelo de linguagem faz — correlacionam-se fracamente com julgamento humano e o campo migrou para as duas abordagens abaixo.

Benchmarks: medir tarefas em vez de fluência

A resposta moderna é parar de dar nota ao texto e dar nota à tarefa: apresentar problemas de resposta conferível e contar quantos o modelo acerta.

Benchmark	O que pergunta	Formato	A pegadinha
MMLU³	57 áreas, da graduação ao nível profissional	Múltipla escolha	Sensível ao formato do prompt e à ordem das alternativas; a nota move vários pontos só com formatação
HumanEval⁴	164 funções Python a partir da docstring	Escrever código, rodar testes	Pequeno e a esta altura bastante contaminado
GSM8K⁵	8,5 mil problemas de matemática escolar	Cadeia de raciocínio, casamento exato	Conferir só a resposta esconde raciocínio que chegou lá por sorte
HellaSwag⁶	Completar frases com senso comum	Múltipla escolha	Humanos fazem ~95%; o resto é mais ruído dos itens
TruthfulQA⁷	Perguntas cuja resposta popular é falsa	Geração livre	Mede resistência a equívocos difundidos, não veracidade em geral
MT-Bench⁸	80 instruções multi-turno	Nota 1–10 dada por um LLM-juiz	Herda todos os vieses do juiz — veja abaixo
Chatbot Arena⁹	Votos A/B anônimos de usuários reais	Rating Elo	O mais próximo de uma medida real de preferência; lento e muda com o público que vota

Aquela última linha é a única cujo número não é uma porcentagem, então vale dizer o que ele é. Um rating Elo transforma uma pilha de votos par a par em um número por modelo, supondo que a probabilidade de A vencer B depende só da diferença entre os ratings:

\[ \mathbb{P}(A \text{ vence } B) = \frac{1}{1 + 10^{\,(R_B - R_A)/400}} \qquad\qquad R_A \leftarrow R_A + K\,(S_A - \mathbb{E}[S_A]) \]

O 400 é convenção e é o que fixa a escala: uma diferença de 400 pontos significa que o modelo mais forte deve vencer 10 vezes em 11. \(S_A\) é o resultado real (1, 0 ou ½) e o \(K\) define a rapidez com que um rating se move. Duas consequências que vale carregar: o número é relativo, então não significa nada sem a população contra a qual foi calculado; e ele mede preferência, que não é a mesma coisa que correção — um modelo que escreve respostas erradas mais longas, mais simpáticas e melhor formatadas sobe.

Contaminação: o benchmark está nos dados de treino

Todo benchmark público acaba entrando no crawl que treina o modelo seguinte e um modelo que decorou o conjunto de teste tira nota alta sem saber fazer a tarefa. Isso é medido, não é hipótese¹⁰. As consequências, para qualquer tabela de benchmark que você for ler:

Uma nota só é evidência se o benchmark for mais novo que o corte de treino do modelo, ou tiver sido mantido privado.
Ganhos de um ou dois pontos num benchmark saturado normalmente não são reais.
É por isso que avaliações privadas, rotativas ou fora da amostra — e as arenas de preferência humana — deslocaram os benchmarks estáticos no topo da área.

pass@k e por que o k é metade do número

Para código, a métrica natural é: passa nos testes? Mas o modelo amostra, então a nota depende de quantas tentativas ele tem direito. O artigo do Codex⁴ define o estimador que todo mundo usa: sorteie \(n\) amostras por problema, conte as \(c\) que passam e estime a probabilidade de que ao menos uma entre \(k\) tentativas dê certo:

\[ \text{pass@}k = \mathbb{E}_{\text{problemas}}\left[1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}\right] \]

força do modelo 1.00 k — tentativas permitidas 1

O artigo original faz o argumento melhor do que qualquer explicação: o Codex resolve 28,8% do HumanEval em pass@1 e 70,2% em pass@100⁴. Mesmo modelo, mesmos problemas, quarenta pontos de diferença que dependem inteiramente de quantas tentativas você conta.

Qual k é honesto depende do que você está construindo

pass@1 é o número para tudo que precisa acertar de primeira — um autocompletar que vai para produção, um passo de agente que ninguém revisa. pass@k com k grande é o número certo quando existe um verificador barato e confiável para escolher o vencedor: uma bateria de testes, um compilador, um verificador de provas. Reportar um \(k\) grande sem verificador é reportar uma nota que nenhum usuário vai experimentar.

LLM como juiz

Como nenhuma fórmula dá nota a uma resposta aberta, a saída prática é perguntar a um modelo forte. Escala, é barato e concorda com anotadores humanos mais do que se esperaria: acima de 80%, que é mais ou menos o nível em que dois humanos concordam entre si⁸.

Esse número também é a armadilha, porque as discordâncias não são aleatórias — elas são enviesadas de maneiras que fazem um modelo parecer melhor ou pior por motivos que nada têm a ver com a resposta:

o quanto B é de fato melhor 55% viés de posição (prefere o que lê primeiro) 0.6 viés de verbosidade (B é a resposta mais longa) 0.4

Viés	O que ele faz	O que fazer a respeito
Posição	Prefere a resposta que lê primeiro	Julgue todo par duas vezes, nas duas ordens e tire a média. Reporte a taxa de concordância
Verbosidade	Prefere a resposta mais longa, com qualidade igual	Controle o comprimento; compare respostas de tamanho parecido, ou reporte o tamanho junto da taxa de vitória
Auto-preferência	Prefere texto da própria família de modelos	Nunca deixe um modelo julgar as próprias saídas numa avaliação que você vai publicar
Compressão de escala	Concentra as notas entre 7 e 9 numa escala de 1 a 10	Prefira comparações par a par a notas absolutas

Um juiz é um modelo, então avalie-o antes de confiar nele

A única forma de saber se o seu juiz funciona é conferi-lo contra rótulos humanos numa amostra dos seus dados — algumas centenas de pares costumam bastar para estimar a concordância. Reporte esse número de concordância ao lado de todo resultado que o juiz produziu. Uma taxa de vitória sem ele é uma medição sem erro declarado.

RAG: dois sistemas, dois modos de falhar

Um sistema com recuperação pode falhar por recuperar os documentos errados ou por ignorar os certos e uma nota única de ponta a ponta não distingue os dois casos. Por isso eles são medidos separadamente¹¹:

Etapa	Métrica	Pergunta que responde
Recuperação	Context precision	Do que foi recuperado, quanto era relevante?
	Context recall	Do que era relevante, quanto foi recuperado?
Geração	Faithfulness	Toda afirmação da resposta está sustentada pelo contexto recuperado?
	Answer relevancy	A resposta trata da pergunta que foi feita?

O par que mais importa é faithfulness contra answer relevancy: uma resposta pode estar perfeitamente ancorada no contexto e ser inútil, ou ser fluente, pertinente e inteiramente inventada. A ancoragem é o que um sistema RAG foi construído para oferecer e é justamente o que o usuário não tem como conferir sozinho.

Segurança e alinhamento

O que você está medindo	Instrumento típico	O que escapa
Toxicidade	Classificador sobre as gerações (ex.: Perspective API)	Dano implícito e herda os vieses do próprio classificador
Taxa de alucinação	TruthfulQA, ou checagem de afirmações contra fontes	Cobre só o domínio que você testou
Seguir instruções	Restrições verificáveis ("responda em 3 tópicos, não mais")	Não diz nada sobre a qualidade da resposta
Recusa	Taxa num conjunto de red team, mais a recusa indevida em pedidos benignos parecidos	Uma taxa sozinha é burlável: um modelo que recusa tudo tira nota perfeita
Calibração	Confiança contra acurácia observada — veja classificação	Um modelo bem calibrado ainda pode estar uniformemente errado

Meça sempre o par, nunca a taxa sozinha

Taxa de recusa sem taxa de recusa indevida, precisão sem recall, fidelidade sem pertinência: toda métrica de segurança tem uma parceira que um modelo degenerado consegue explorar. return "Não posso ajudar com isso" é um modelo de segurança perfeito em qualquer medição de um lado só.

Qual métrica e por quê

Sua pergunta	Use	Não use
O modelo está aprendendo a modelar este corpus?	Perplexidade / bits por byte, mesmo tokenizador	Perplexidade entre tokenizadores diferentes
Ele conhece um assunto?	Benchmarks no estilo MMLU, de preferência não contaminados	Qualquer coisa anterior ao corte de treino, sem crítica
Ele escreve código que funciona?	pass@1 para uso de uma tentativa; pass@k com verificador	pass@k comparado entre k diferentes
A resposta A é melhor que a B?	Juiz par a par, nas duas ordens, com concordância humana medida	Taxa de vitória numa ordem só; nota absoluta de 1 a 10
O resumo é fiel à fonte?	Faithfulness / ancoragem das afirmações	ROUGE
É seguro?	Taxas em par: recusa e recusa indevida	Qualquer taxa isolada
Os usuários preferem?	A/B com usuários reais; Elo no estilo Arena	Médias de benchmark

Pontos-chave

Toda métrica desta página é um proxy. Saiba do que ela é substituta e você saberá onde ela quebra.
Perplexidade mede ajuste a um corpus. É uma média geométrica, então os tokens mais difíceis dominam e ela não se compara entre tokenizadores — reporte bits por byte se precisar comparar.
BLEU/ROUGE medem sobreposição de strings. Para geração aberta são convenção, não medição.
Benchmarks medem tarefas e o risco central deles é contaminação: um número só é evidência se o teste não pudesse ter sido treinado.
pass@k sem o seu \(k\) não significa nada — 28,8% e 70,2% eram o mesmo modelo⁴. \(k\) grande só é honesto quando existe um verificador escolhendo o vencedor.
Juízes LLM concordam com humanos cerca de 80% das vezes⁸, com vieses de posição, verbosidade e auto-preferência. Julgue nas duas ordens, reporte a concordância e nunca deixe um modelo dar nota a si mesmo.
RAG exige recuperação e geração medidas separadamente e a fidelidade é a que o usuário não consegue verificar sozinho.
Métricas de segurança vêm em pares. Uma taxa isolada é sempre burlável.

Recursos Adicionais

Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — Zheng, L., et al. (2023)⁸. O artigo que tornou o LLM-juiz respeitável e documentou o que há de errado com ele. Leia as seções 3 e 4 juntas: os números de concordância e as medições de viés fazem parte do mesmo argumento.
Evaluating Large Language Models Trained on Code — Chen, M., et al. (2021)⁴. A seção 2 é a explicação publicada mais clara de por que o estimador ingênuo de pass@k é enviesado e do que usar no lugar. O resto é a origem do HumanEval.
Holistic Evaluation of Language Models (HELM) — Liang, P., et al., Stanford CRFM¹². Um placar vivo construído sobre o argumento com que esta página abre: um número nunca basta, então reporte acurácia, calibração, robustez, viés, toxicidade e eficiência lado a lado.

Referências bibliográficas

Os trabalhos citados ao longo do texto, na ordem em que aparecem:

Radford, A., Wu, J., Child, R., Luan, D., Amodei, D., & Sutskever, I. (2019). Language Models are Unsupervised Multitask Learners — relatório técnico da OpenAI. Reporta resultados em bits por byte justamente para que modelos com tokenizadores diferentes possam ser comparados; a seção 3 explica a normalização. ↩
Zhang, T., Kishore, V., Wu, F., Weinberger, K. Q., & Artzi, Y. (2020). BERTScore: Evaluating Text Generation with BERT — ICLR. ↩
Hendrycks, D., Burns, C., Basart, S., Zou, A., Mazeika, M., Song, D., & Steinhardt, J. (2021). Measuring Massive Multitask Language Understanding — ICLR. O benchmark MMLU, com 57 áreas. ↩
Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating Large Language Models Trained on Code. Introduz o HumanEval e o estimador não enviesado de pass@k; reporta o Codex com 28,8% (pass@1) e 70,2% (pass@100). ↩↩↩↩↩
Cobbe, K., Kosaraju, V., Bavarian, M., et al. (2021). Training Verifiers to Solve Math Word Problems — o conjunto GSM8K. ↩
Zellers, R., Holtzman, A., Bisk, Y., Farhadi, A., & Choi, Y. (2019). HellaSwag: Can a Machine Really Finish Your Sentence? — ACL. ↩
Lin, S., Hilton, J., & Evans, O. (2022). TruthfulQA: Measuring How Models Mimic Human Falsehoods — ACL. ↩
Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — NeurIPS Datasets and Benchmarks. Reporta mais de 80% de concordância entre um juiz GPT-4 e preferências humanas — "o mesmo nível de concordância entre humanos" — e mede os vieses de posição, verbosidade e auto-preferência. ↩↩↩↩
Chiang, W.-L., Zheng, L., Sheng, Y., et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference — ICML. ↩
Sainz, O., Campos, J. A., García-Ferrero, I., Etxaniz, J., de Lacalle, O. L., & Agirre, E. (2023). NLP Evaluation in Trouble: On the Need to Measure LLM Data Contamination for each Benchmark — Findings of EMNLP. ↩
Es, S., James, J., Espinosa-Anke, L., & Schockaert, S. (2024). RAGAS: Automated Evaluation of Retrieval Augmented Generation — EACL (demonstração). Fonte da decomposição em quatro métricas acima. ↩
Liang, P., Bommasani, R., Lee, T., et al. (2023). Holistic Evaluation of Language Models — TMLR. ↩