Benchmarks de LLM: guia de compliance para equipas de governance de IA

O essencial

• Os benchmarks de LLM são dispositivos padronizados que combinam um conjunto de dados, uma tarefa, uma métrica e um mecanismo de pontuação, com o objetivo de medir, de forma comparável entre modelos, uma capacidade específica de um modelo de linguagem grande.
• Os benchmarks públicos como MMLU, HumanEval, MT-Bench ou a suite HELM de Stanford monopolizam a conversa, mas nenhum foi concebido para responder a uma pergunta de um regulador.
• O Regulamento Europeu da IA, o NIST AI Risk Management Framework e a norma ISO/IEC 42001 exigem todos alguma forma de avaliação do modelo: os benchmarks são o instrumento operacional que torna essa obrigação mensurável.
• Uma pontuação num benchmark público não prova, por si só, a conformidade. A contaminação dos conjuntos de teste, o sobreajuste e a chamada evaluation awareness quebram a ligação entre o número de classificação e o comportamento real em produção.
• Um portefólio de benchmarks pronto para a governance combina poucos benchmarks públicos bem documentados com um benchmark interno ancorado nos seus próprios casos de uso, riscos e critérios de aceitação.

O que é, na verdade, um benchmark de LLM

Os benchmarks de LLM são quadros padronizados que medem como o modelo se comporta numa tarefa definida. Retirando o invólucro de marketing, cada benchmark é feito das mesmas quatro peças: um conjunto de dados de exemplo, um conjunto de perguntas ou tarefas, uma ou mais métricas e um mecanismo de pontuação que transforma a saída do modelo num número comparável (IBM Think). A padronização serve apenas para permitir a comparação, dois modelos recebem as mesmas perguntas, são pontuados da mesma forma, e qualquer diferença reflete o modelo, não o desenho do teste. Na prática, os benchmarks são administrados num de três modos. No zero-shot o modelo recebe apenas a descrição da tarefa e tem de generalizar a partir do seu treino. No few-shot são acrescentados ao prompt alguns exemplos resolvidos, para ver com que rapidez o modelo apreende um padrão. A avaliação fine-tuned treina primeiro o modelo com dados próximos do benchmark, o que aumenta as pontuações, mas só é útil se o seu deployment real também for fine-tuned. A métrica de referência varia por benchmark. Os testes de escolha múltipla usam accuracy. Os benchmarks de código empregam pass@k, a probabilidade de pelo menos uma das k soluções geradas passar nos testes unitários. A tradução usa BLEU, o resumo ROUGE, a classificação precisão, recall e F1, a modelação de linguagem a perplexidade. A maioria das tabelas de classificação agrega várias destas métricas num único número, o que facilita o ranking e dificulta a interpretação. Para um público de compliance, o mais importante é compreender o que os benchmarks não são. Não são certificações. Não são testes de aceitação validados por um regulador. Não substituem uma avaliação interna do seu sistema concreto, sobre os seus dados concretos, contra os seus riscos concretos. São, ainda assim, o mais próximo que existe de um vocabulário partilhado para descrever o que um LLM sabe fazer, e esse vocabulário é hoje estruturante em todas as regulações de IA relevantes em vigor.

O panorama dos benchmarks em 2026 (o mapa para um responsável de compliance)

O catálogo de benchmarks cresce depressa, mas as famílias que aparecem realmente nos relatórios de avaliação dos fornecedores e nos processos apresentados a reguladores são mais reduzidas do que o ruído do mercado sugere.

Benchmarks de LLM para raciocínio e compreensão da linguagem

MMLU (Massive Multitask Language Understanding) cobre 57 matérias com mais de 15 000 perguntas de escolha múltipla e continua a ser o primeiro número citado em cada lançamento de modelo (artigo MMLU). HellaSwag testa o senso comum através do completamento de frases com distractores filtrados de modo adversarial. ARC (AI2 Reasoning Challenge) parte de perguntas de ciências de nível básico e publica dois splits, Easy e Challenge. Winogrande leva o Winograd Schema Challenge à escala de 44 000 problemas de correferência recolhidos em crowdsourcing. Lidos em conjunto, estes quatro indicam se um modelo consegue tratar perguntas de conhecimento multidomínio num formato estático.

Matemática e código

GSM8K é o benchmark canónico de matemática de nível básico, com 8500 problemas verbais e soluções em linguagem natural. HumanEval introduziu a métrica pass@k para a geração de código; MBPP estende-a a problemas Python de base; SWE-bench é o mais exigente dos três, ao medir se um modelo consegue resolver issues reais do GitHub em repositórios reais (artigo SWE-bench). Os benchmarks de código têm uma propriedade útil para as equipas de governance: são pass-or-fail por problema, portanto a pontuação é mais difícil de inflar com julgamentos subjetivos.

Conversação e seguimento de instruções

MT-Bench usa GPT-4 como juiz para pontuar 80 perguntas abertas multi-turno em 8 categorias, uma abordagem ao mesmo tempo eficiente e metodologicamente discutível segundo a literatura recente. Chatbot Arena contorna o problema do LLM-juiz ao recolher votos de preferência por pares numa arena aberta e estimar os rankings a partir dessas comparações por pares (artigo Chatbot Arena). Para produtos pensados para interagir com pessoas, Chatbot Arena correlaciona-se com a qualidade percebida pelo utilizador melhor do que MMLU.

Veracidade, segurança, alinhamento

TruthfulQA mede a resistência do modelo a falsidades comuns, um proxy para a resistência à alucinação. HELM Safety avalia a recusa de respostas perigosas em cenários de segurança. AIR-Bench, uma pista relativamente recente dentro da família HELM de Stanford, pontua os modelos face às categorias usadas pelo Regulamento Europeu da IA, pelo NIST AI RMF e por várias outras taxonomias regulatórias (AIR-Bench). AIR-Bench merece mais atenção das equipas de compliance do que recebe atualmente: é o único benchmark público deliberadamente estruturado em torno das categorias dos reguladores.

Avaliação holística: HELM como meta-benchmark

A Holistic Evaluation of Language Models (HELM) de Stanford não é um benchmark único mas um protocolo de medição. Avalia cada modelo segundo 7 métricas (accuracy, calibração, robustez, equidade, viés, toxicidade, eficiência) em 16 cenários nucleares, sob condições padronizadas (HELM). Pistas especializadas estendem hoje o quadro aos domínios médico (MedHELM), visual (VHELM), áudio e segurança. Para uma organização que constrói um benchmark interno, HELM é o mais próximo de uma arquitetura de referência publicada.

Por que razão os benchmarks são hoje um instrumento de compliance, e não apenas uma ferramenta de investigação

O que mudou entre 2022 e 2026 foi que ‘avaliar o modelo’ deixou de ser uma boa prática recomendada para se tornar numa obrigação jurídica, inscrita em direito primário, num quadro de gestão de risco de primeira ordem e numa norma internacional de sistema de gestão. Os benchmarks são a forma como essa obrigação abstrata se traduz num número que um auditor consegue ler.

Artigo 15.º do Regulamento Europeu da IA

O artigo 15.º do Regulamento (UE) 2024/1689 exige que os sistemas de IA de alto risco sejam concebidos e desenvolvidos de modo a atingir um nível adequado de exatidão, robustez e cibersegurança ao longo de todo o seu ciclo de vida (resumo oficial do artigo 15.º). O mesmo artigo obriga a que os níveis de exatidão e as métricas pertinentes sejam declarados nas instruções de utilização do sistema, pelo que qualquer número escolhido tem de ser documentado e transmitido a jusante. O artigo 13.º reforça este enquadramento com obrigações mais amplas de transparência para com os responsáveis pelo deployment. Em concreto, o fornecedor de um sistema de alto risco não pode entregar em silêncio sem nomear as métricas usadas e os níveis atingidos.

Artigo 55.º e o Código de Boas Práticas GPAI

Para os modelos de IA de uso geral classificados com risco sistémico, o artigo 55.º do Regulamento Europeu da IA acrescenta uma obrigação explícita de avaliação do modelo, incluindo a realização e documentação de testes adversariais. O Código de Boas Práticas GPAI, voluntário e finalizado sob a égide do Gabinete Europeu para a IA, operacionaliza essa obrigação em torno de uma cadência recorrente de avaliação com metodologia documentada. Os benchmarks, públicos como internos, são os artefactos que satisfazem a metade documental da obrigação.

Função Measure do NIST AI RMF

O quadro de gestão de risco de IA do NIST organiza-se em torno de quatro funções: Govern, Map, Measure, Manage. A função Measure convoca expressamente ferramentas quantitativas, qualitativas ou de método misto para analisar, avaliar, fazer benchmarks e monitorizar o risco de IA (NIST AI RMF Core). Apesar de NIST AI 100-1 ser voluntário, a função Measure é a casa textual de toda a conversa sobre benchmarks na governance americana de IA, e várias cláusulas de contratação federal remetem hoje diretamente para ela.

Avaliação do desempenho na ISO/IEC 42001

A ISO/IEC 42001, publicada em dezembro de 2023, é a primeira norma de sistema de gestão para IA. Como qualquer norma ISO de sistema de gestão, assenta no ciclo Plan-Do-Check-Act, e a avaliação do desempenho é uma das suas cláusulas nomeadas. Os controlos do Anexo A operacionalizam esta obrigação em requisitos concretos ao longo do ciclo de vida da IA, incluindo critérios de avaliação tanto para sistemas desenvolvidos internamente como para os adquiridos a terceiros. Para uma organização que vise a certificação 42001, a pergunta deixou de ser se deve fazer benchmarks, apenas quais benchmarks satisfarão o auditor.

Como ler uma tabela de classificação como um regulador a lê

O ‘pontuamos 92,3 no MMLU’ de um fornecedor parece preciso. O número é verdadeiro, a comparação é real, e ainda assim diz muito pouco de útil a um responsável de compliance enquanto três perguntas de fundo não receberem resposta. Primeira pergunta: o benchmark esteve contaminado para esse modelo? A maior parte dos corpora de treino dos modelos de fronteira inclui largas porções da web aberta, e a maior parte dos benchmarks públicos vive na web aberta. Uma pontuação que ultrapassa claramente o estado da arte anterior num benchmark presente há anos merece ceticismo, não comemorações. Segunda pergunta: o comportamento medido corresponde ao comportamento implantado? Uma pontuação sobre um conjunto de teste estático, em inglês e de escolha múltipla, não prediz o desempenho sobre as suas transcrições de apoio ao cliente, as suas consultas jurídicas ou os seus prompts de revisão de código. Os reguladores interessam-se pelo sistema implantado, não pelo comunicado de imprensa. Terceira pergunta: que versão, que data, que formato de prompt? Os benchmarks evoluem, os prompts são retrabalhados, os scripts de pontuação são revistos. Um 92,3 sem pino de versão não é verificável. Para um processo de avaliação da conformidade ao abrigo do Regulamento Europeu da IA, o número de cabeçalho é, no melhor dos casos, digno de nota de rodapé. O que conta é a metodologia: qual o conjunto de teste, com que controlos de contaminação, pontuado por quem, atualizado em que cadência. Trate cada afirmação de classificação como uma hipótese a verificar, não como facto a copiar.

Contaminação de benchmarks e lei de Goodhart

A versão intelectualmente honesta da conversa sobre benchmarks em 2026 começa pela contaminação. Há contaminação de dados quando um modelo foi treinado sobre o test split de um benchmark, seja deliberadamente porque se decidiu otimizar para a classificação, seja acidentalmente porque o conjunto do benchmark acabou num crawl da web que alimentou o pré-treino. Uma vez memorizado o teste, a pontuação do modelo reflete memória, não capacidade (literatura sobre contaminação). O problema de fundo é estrutural. Os benchmarks públicos atraem uma pressão sustentada de otimização: dezenas de laboratórios, todos os trimestres, com milhares de milhões de tokens de treino e orçamentos sérios. Aplica-se a lei de Goodhart: quando uma medida se torna alvo, deixa de ser uma boa medida. A saturação do MMLU, em que os modelos de fronteira se agrupam a poucos pontos do tecto, é o exemplo mais citado, mas o padrão repete-se em todas as famílias de benchmarks. Mais recentemente, a literatura documentou a evaluation awareness: os grandes modelos conseguem detetar quando um prompt parece uma avaliação em vez de uma interação de deployment, e a diferença de comportamento entre os dois contextos não é desprezável. Da ótica da compliance significa que a pontuação medida pelo seu pipeline de avaliação pode não ser a pontuação que o modelo entrega realmente em produção. A implicação é incómoda. Uma pontuação de benchmark público é um sinal entre muitos, não uma garantia. Qualquer enquadramento GRC que trate um número MMLU como prova de segurança, exatidão ou equidade está a assumir um risco metodológico que, escrito preto no branco, não resistirá a uma contestação do regulador. Os benchmarks dizem alguma coisa. Não dizem o suficiente.

Construir um benchmark interno que o seu auditor aceite

Se os benchmarks públicos não chegam, o passo natural é construir um próprio. Um benchmark interno, desenhado sobre os seus casos de uso reais, os seus dados reais e os seus riscos reais, é o artefacto que fecha a distância entre um ranking de classificação e uma posição de conformidade defensável. Um benchmark interno operacional assenta em seis elementos. Primeiro, um perímetro ligado a um caso de uso: nomeie o sistema, o contexto de deployment e o nível de risco ao abrigo do Regulamento da IA (alto risco, risco limitado, risco mínimo) ou o equivalente saído da função Map do NIST AI RMF. Segundo, métricas ligadas a danos: exatidão sobre as tarefas que importam, taxa de recusa sobre os prompts que devem ser recusados, taxa de alucinação sobre os pedidos em que a alucinação é perigosa. A exatidão genérica raramente é a métrica adequada por si só. Terceiro, um conjunto de teste representativo com proveniência documentada: de onde vêm os prompts, quem os selecionou, sobre que tráfego de produção foram amostrados, que línguas cobrem. Quarto, controlos de contaminação: mantenha pelo menos um split reservado que nunca sai da organização, atualize a parte pública do conjunto numa cadência publicada, marque com marca de água os prompts sempre que possível para detetar fugas. Quinto, um script de pontuação versionado: os prompts evoluem, os modelos evoluem, as rubricas evoluem. Fixe cada pontuação ao molde exato de prompt e ao código de pontuação exato que a produziram. Sexto, critérios de aceitação cartografados no processo de conformidade: a pontuação não precisa de ser perfeita, precisa de ser suficientemente alta para justificar o deployment dado o nível de risco. Documente o limiar e a sua justificação. Uma plataforma de gestão de evidências como a AI Sigil mantém toda a cadeia auditável: a definição do benchmark, o histórico de pontuações, as obrigações ligadas ao Regulamento Europeu da IA, ao NIST AI RMF ou à ISO 42001, e os ficheiros de prova (conjunto de teste, script de pontuação, registos de execução) referenciados pelo processo.

Os benchmarks de LLM que vale realmente a pena acompanhar para a compliance

Para uma organização que constrói um portefólio capaz de satisfazer os reguladores mantendo-se intelectualmente honesta, a lista curta prática é mais curta do que aquilo que as tabelas públicas sugerem.

Cada entrada desta tabela deve ser combinada com um benchmark interno orientado ao seu deployment real. O número público é a calibração; o número interno é a prova.

Perguntas frequentes

Os benchmarks de LLM são fiáveis? São fiáveis para aquilo que medem, isto é, o desempenho sobre o conjunto de teste concreto segundo o protocolo concreto que definem. São pouco fiáveis como proxy do comportamento em produção, em parte por contaminação e sobreajuste, em parte porque os sistemas implantados enfrentam uma distribuição de entradas muito mais ampla do que qualquer benchmark estático cobre. Trate-os como sinais a triangular, não como verdade de base. As autoridades europeias interessam-se pelas pontuações MMLU? Não diretamente. O artigo 15.º do Regulamento Europeu da IA obriga os fornecedores de alto risco a declarar os níveis de exatidão e as métricas pertinentes nas instruções de utilização. Um regulador que examine um processo de avaliação da conformidade quer ver uma metodologia documentada, um conjunto de teste defensável e critérios de aceitação ligados ao perfil de risco do sistema. Um número MMLU pode aparecer no processo como elemento de prova, mas por si só não satisfaz a obrigação. Um benchmark público pode provar a conformidade de uma IA? Nenhum benchmark público demonstra, por si só, a conformidade com o Regulamento Europeu da IA, o NIST AI RMF ou a ISO/IEC 42001. Cada um destes quadros exige uma avaliação específica ao sistema, específica ao dano, ligada ao contexto de deployment. Os benchmarks públicos suportam o processo; não o substituem. Devemos construir o nosso próprio benchmark interno? Sim, se está sujeito a algum dos grandes quadros de governance de IA. Um benchmark interno é a única forma de avaliar o sistema sobre dados próximos da produção. Dá-lhe também o controlo da contaminação, impossível para um benchmark público cujo conjunto de teste vive na web aberta. O mínimo viável consiste em algumas centenas de prompts representativos, uma rubrica de pontuação clara e uma cadência de atualização documentada. O que é a contaminação de benchmark? A contaminação é a situação em que um modelo foi treinado, direta ou indiretamente, sobre dados provenientes do conjunto de teste de um benchmark. A pontuação reflete então memória, não capacidade. A contaminação está disseminada nos benchmarks presentes há anos na web pública, e é a principal razão pela qual MMLU e os benchmarks saturados análogos são hoje tratados com cautela. O que recomenda a CNPD em Portugal? A CNPD não valida nenhum benchmark público específico. A sua linha alinha-se com a das outras autoridades europeias: a documentação da metodologia de avaliação, a rastreabilidade dos conjuntos de teste e a adequação das métricas ao contexto de uso pesam mais do que a pontuação anunciada. No setor financeiro, o Banco de Portugal segue a orientação das autoridades europeias (em particular a EBA) sobre validação de modelos, sensivelmente mais exigente do que uma pontuação pública. Que benchmark deve uma equipa de compliance documentar em 2026? Documente pelo menos um benchmark por cada eixo de capacidade relevante para o seu caso de uso (conhecimento, raciocínio, código, diálogo, veracidade, segurança), mais um benchmark de alinhamento regulatório como AIR-Bench, mais o seu benchmark interno. Script de pontuação, proveniência do conjunto de teste e data de execução devem ser arquivados como provas e ligados às obrigações pertinentes do seu processo de conformidade.

Conclusão

Os benchmarks de LLM ultrapassaram o seu papel inicial de ferramenta de investigação. Em 2026 são o instrumento operacional por detrás de cada obrigação de avaliação de modelo, do artigo 15.º do Regulamento Europeu da IA à função Measure do NIST AI RMF, passando pela cláusula de avaliação do desempenho da ISO/IEC 42001. São também imperfeitos, manipuláveis e muitas vezes mal lidos. Uma postura de compliance séria trata os benchmarks públicos como calibração, constrói um benchmark interno como prova e documenta a metodologia com o mesmo rigor de qualquer outro controlo. Quem constrói esse portefólio fará bem em manter definições, pontuações, evidências e ligações a obrigações numa única traça auditável, como a que uma plataforma de governance como a AI Sigil disponibiliza.