Benchmark público não conhece sua aplicação

Escolher modelo pela posição num leaderboard público é, na melhor das hipóteses, um filtro inicial. Tratar essa posição como decisão final é ignorar que nenhum benchmark genérico foi desenhado conhecendo os documentos, o vocabulário, o formato de resposta esperado ou os erros mais caros da aplicação específica que está sendo construída.

O benchmark mede uma habilidade geral, não a sua tarefa

Um benchmark público, mesmo bem construído e livre dos problemas de saturação e contaminação que já são conhecidos em benchmarks mais antigos, ainda mede uma habilidade geral: conhecimento amplo, raciocínio matemático, geração de código correto num conjunto padronizado de problemas. Isso é informação real e útil, mas é uma proxy distante da pergunta que realmente importa na hora de decidir: esse modelo responde bem às perguntas específicas que meus usuários fazem, sobre os documentos específicos que minha aplicação usa, no formato específico que meu sistema espera?

Um modelo pode ser excelente em raciocínio matemático geral e medíocre em extrair um dado específico de um contrato jurídico com formatação irregular, porque essa segunda tarefa nunca apareceu, na mesma forma, em nenhum benchmark público usado para posicionar aquele modelo no leaderboard.

Domínio específico tem armadilha que benchmark genérico não vê

Terminologia interna de uma empresa, jargão de um setor regulado, formato de documento específico de um tipo de negócio: nada disso é representado em benchmark de propósito geral, porque esses benchmarks são desenhados justamente para serem aplicáveis amplamente, o que exige evitar especificidade de domínio. Um modelo pode processar perfeitamente bem um texto genérico em português e ainda tropeçar consistentemente numa nomenclatura técnica específica do domínio de uma aplicação, sem que isso apareça em nenhuma métrica de benchmark público.

O que resolve isso é construir a própria régua

A resposta prática para essa lacuna é construir um eval interno, focado nos dados reais do produto: perguntas reais (ou representativas) que os usuários fazem, documentos reais (ou uma amostra fiel deles) que o sistema precisa processar, critério de sucesso definido pelas pessoas que realmente entendem o domínio, não por quem desenhou um benchmark de propósito geral sem contexto nenhum sobre esse caso de uso específico.

Isso não é trabalho pequeno, e é exatamente por isso que benchmark público é tão convidativo como atalho: já existe, já tem número pronto, não exige construir nada. O problema é que esse atalho responde uma pergunta diferente da que precisa ser respondida antes de decidir o que colocar em produção.

Comparando modelos na régua certa

Com um eval interno construído, comparar modelos diferentes deixa de depender de leaderboard genérico e passa a depender do desempenho de cada modelo especificamente nos casos que importam para aquela aplicação. É perfeitamente possível, e não incomum, que um modelo mais barato e mais rápido tenha desempenho equivalente a um modelo de fronteira mais caro justamente na tarefa restrita que a aplicação precisa resolver, uma informação que nenhum benchmark público, medindo capacidade ampla, jamais revelaria.

Benchmark público decide o que testar primeiro, não o que usar em produção

Isso não torna benchmark público inútil. Ele ainda serve bem para uma triagem inicial, reduzindo de dezenas para poucos candidatos antes de investir esforço construindo e rodando avaliação própria. O erro é parar nessa triagem e tratar o resultado dela como decisão final, quando na verdade ela só define a lista curta de modelos que merecem ser testados de verdade, contra os dados e os critérios que realmente representam o problema em questão.