Alena, do Sber: por que avaliar um LLM com 20 exemplos é mais perigoso do que não avaliar

Alena, curadora do benchmark MERA e criadora do Russian SuperGLUE, descreve a lacuna sistêmica entre o rigor acadêmico da avaliação e o ritmo real do desenvolvimento. Ela também explica por que uma "checagem rápida" com 10 exemplos é mais perigosa do que não fazer nenhuma.

Academia versus indústria

No meio acadêmico, um benchmark é um trabalho metodológico sério. Exige datasets anotados, métricas justificadas, verificação de vazamento de dados, resultados reproduzíveis e análise de erros. Um bom teste pode levar meses e requer uma equipe dedicada. Em compensação, seus resultados merecem confiança.

Na prática industrial, o relógio é outro. A equipe precisa escolher um modelo antes do fim da sprint, testar uma nova versão do prompt, comparar dois pipelines de RAG e descobrir se a qualidade caiu após uma atualização, de preferência até o próximo release, e não em seis meses. A abordagem acadêmica simplesmente não cabe nesse ritmo.

Dessa lacuna nascem dois cenários opostos. O primeiro é a avaliação mínima, sem sistema: alguns exemplos antes da demo, uma olhada rápida nas respostas, "parece que funciona". O segundo é a aparência de controle de qualidade: 10–20 consultas, um LLM como juiz, nota média e uma tabelinha para o relatório.

Por que 10 exemplos são mais perigosos do que zero

O autor chega a uma conclusão contraintuitiva: o segundo cenário é pior que o primeiro. A típica "avaliação com vinte exemplos" parece um processo, mas gera falsa confiança a partir de um sinal estatisticamente fraco. Os problemas concretos dessa abordagem:

• A amostra é pequena demais: 10–20 exemplos não dão um resultado reproduzível, e outro conjunto mostrará números diferentes
• Um LLM juiz sem calibração é enviesado: ele prefere sistematicamente respostas longas, confiantes e bem estruturadas, independentemente da precisão factual
• A nota média esconde falhas: um modelo pode ter nota média alta e, ao mesmo tempo, falhar por completo em um tipo específico de tarefa
• Não há baseline: sem um ponto de referência fixo, é impossível saber se algo melhorou ou piorou após uma mudança
• Vazamentos de dados não são verificados: o modelo pode ter visto os exemplos de teste durante o treinamento e, nesse caso, a avaliação não mede nada de real

"O problema é que a segunda opção muitas vezes parece controle de qualidade, mas não é.

Ela pode ser perigosa porque cria confiança onde, na verdade, há apenas um sinal muito fraco."

De onde vem esse padrão

Alena ressalta que não se trata de preguiça nem de falta de compreensão. As equipes sabem muito bem que a avaliação importa. Acontece que a abordagem acadêmica clássica é uma ferramenta pesada demais para o ritmo real do desenvolvimento. É preciso um caminho intermediário: rigoroso o bastante para embasar decisões e leve o bastante para ser aplicado de verdade.

A autora é curadora do projeto "MERA" da Aliança de IA, um benchmark para avaliar LLMs em russo, e participou da criação do Russian SuperGLUE e do ruMTEB. Em cinco anos de trabalho com modelos de linguagem, ela viu a mesma lacuna em equipes de todos os portes, de startups a grandes corporações.

O que isso significa

A avaliação de LLMs não é um procedimento pontual antes da demo, mas infraestrutura de produção. As equipes que a constroem de forma sistemática economizam tempo no diagnóstico de regressões e cometem menos erros caros em produção.

O artigo oferece um guia prático para quem está preso entre o rigor acadêmico e uma ilusão perigosa de controle.