24/08/2026

Benchmark de IA: da pontuação à prova auditável

O essencial

Um benchmark de IA mede o desempenho de um modelo perante um conjunto fixo de tarefas, segundo uma regra de pontuação conhecida. Responde à pergunta sobre qual o modelo mais forte naquele teste, não à da adequação do seu sistema à finalidade prevista.
O Regulamento da IA obriga os fornecedores de sistemas de risco elevado a declarar as respetivas métricas de exatidão nas instruções de utilização. A obrigação recai sobre a sua métrica, não sobre a classificação de terceiros.
As pontuações públicas perdem valor probatório: os testes mais citados estão saturados e as suas perguntas, por serem publicadas, acabam nos corpora de treino.
Um resultado só se torna prova quando é possível demonstrar o que foi executado, sobre que dados, contra que versão do modelo, por quem e quando.
A prova que resiste a uma auditoria provém quase sempre de um conjunto de teste interno derivado da finalidade prevista, e não de uma classificação pública.

Balança que ilustra um benchmark de IA face aos requisitos de conformidade

O que um benchmark de IA mede realmente

Um benchmark de IA é um teste normalizado: um conjunto fixo de dados de entrada, saídas esperadas e uma regra de pontuação que converte o comportamento do modelo num número comparável. Uma vez que todos os modelos enfrentam as mesmas entradas sob a mesma regra, o benchmark transforma uma impressão num valor sobre o qual dois interlocutores podem discordar com os mesmos factos à frente. É uma ferramenta genuinamente útil, e é exatamente aí que começam os problemas. Um benchmark é uma amostra finita retirada de uma distribuição. O trabalho a que destina um modelo de IA pertence, pelo contrário, a um conjunto aberto de situações retiradas de uma distribuição bem mais desarrumada. A pontuação permanece sempre uma medida indireta, e a distância entre essa medida e aquilo que lhe interessa nunca aparece impressa na classificação.

Os três componentes de um benchmark

Todo o benchmark tem três elementos, e cada um pode falhar de forma independente.

O conjunto de dados: as entradas e, por norma, as saídas de referência contra as quais se pontua.
O método de avaliação: a regra que converte saídas em pontuação. Comparação de respostas nos questionários de escolha múltipla, execução de testes unitários no código, ou um juiz algorítmico para produções abertas.
A classificação: a tabela que torna os resultados comparáveis e que, de caminho, os torna compensadores de manipular.

A verdade de referência merece atenção particular, porque limita em silêncio tudo o que nela se apoia. Se a chave de correção estiver errada, uma resposta correta do modelo é contabilizada como erro e o resultado inteiro herda esse ruído.

As famílias de capacidades e os seus pontos cegos

Nenhum teste isolado capta aquilo que um modelo sabe fazer, pelo que a disciplina divide a avaliação por capacidades. Só uma leitura transversal devolve um retrato honesto.

Conhecimento (MMLU, MMLU-Pro): amplitude da memória factual. O MMLU original está largamente saturado, pelo que as pequenas diferenças entre modelos de topo já não transportam sinal.
Raciocínio (GPQA Diamond, Humanity’s Last Exam): resolução em vários passos sobre perguntas deliberadamente difíceis. Difíceis hoje, alvo de contaminação amanhã.
Código (SWE-bench Verified, LiveCodeBench): correção de ocorrências reais num repositório em vez da escrita de funções isoladas. Os testes ao nível da função perderam quase todo o poder discriminante.
Agentes (GAIA): planeamento e uso de ferramentas ao longo de vários passos. Os resultados dependem tanto do andaime em volta do modelo como do próprio modelo.
Multimodal (MMMU): raciocínio sobre texto, imagens e diagramas. Um modelo textual sólido pode obter aqui uma pontuação fraca.
Preferência humana (Arena Elo): que resposta as pessoas preferem em comparações cegas. Mede preferência e estilo, não correção, e as duas divergem com mais frequência do que a classificação deixa supor.

Para as equipas que trabalham especificamente com modelos de linguagem, o detalhe família a família consta do nosso guia de benchmarks de LLM. O que se segue vale para qualquer classe de modelo.

Quando a pontuação passa a ser uma obrigação regulamentar

A maior parte dos textos trata o benchmark de IA como um hábito de engenharia. Para quem coloca um sistema no mercado europeu, aproxima-se mais de uma obrigação documental, e essa mudança de enquadramento altera o que se entende por bom benchmark.

Artigo 15.º: declarar a métrica de exatidão própria

O artigo 15.º do Regulamento da IA exige que os sistemas de risco elevado atinjam um nível adequado de exatidão, solidez e cibersegurança e que funcionem de forma coerente nesses aspetos ao longo de todo o ciclo de vida. A frase decisiva para as equipas de governação é a seguinte: os níveis de exatidão e as métricas de exatidão pertinentes devem ser declarados nas instruções de utilização que acompanham o sistema. Esta redação inverte o reflexo habitual. A obrigação não consiste em pontuar bem num teste público reconhecido, mas em nomear a métrica que considera pertinente para o seu sistema, declarar o nível atingido e responder por ambos. Uma posição numa classificação não cumpre este dever, e citá-la em vez de uma medição própria deixa uma lacuna que um avaliador deteta rapidamente. O texto prevê, ainda assim, referências partilhadas. Incumbe a Comissão de, em cooperação com as partes interessadas e com organizações como as autoridades de metrologia e de avaliação comparativa, incentivar o desenvolvimento de parâmetros de referência e de metodologias de medição. Esse trabalho decorre ainda, pelo que o ónus de escolher e justificar uma métrica recai por agora sobre o fornecedor. O artigo 15.º aplica-se a partir de 2 de agosto de 2026, prazo que cai dentro do horizonte de planeamento descrito no nosso guia operacional do Regulamento da IA.

Modelos de fim geral: artigo 55.º e código de boas práticas

Os fornecedores de modelos de fim geral suportam uma obrigação de avaliação própria e bastante mais explícita. O código de boas práticas GPAI publicado pelo Serviço Europeu para a IA em julho de 2025 obriga os fornecedores de modelos com risco sistémico, limiar atualmente fixado numa potência de cálculo de treino superior a 10^25 FLOPs, a manter um quadro de segurança que abranja avaliações do modelo, exercícios de equipa vermelha, monitorização após colocação no mercado, cibersegurança e comunicação de incidentes. Aqui a avaliação deixa de ser um exercício comparativo e passa a ser uma argumentação de segurança, a manter após a divulgação em vez de produzida uma única vez no lançamento. Quem implementa sobre estes modelos herda as consequências, razão pela qual tratamos as provas de avaliação do fornecedor como um dado de aquisição e não como uma curiosidade técnica, conforme se explica no nosso manual do regulamento europeu de inteligência artificial.

ISO 42001 e NIST AI RMF: a leitura de sistema de gestão

Dois referenciais voluntários transformam a avaliação comparativa de atividade em processo governado. A norma ISO/IEC 42001 coloca a avaliação do desempenho dentro de um sistema de gestão certificável. A partir do momento em que uma campanha de medição cai sob o capítulo 9, deixa de ser um diapositivo para passar a registo com responsável, periodicidade e trilho de auditoria. O NIST AI Risk Management Framework é mais direto. A sua função MEASURE aplica métricas, parâmetros de referência, testes e análises às características de fiabilidade, e exige avaliação comparativa regular tanto do sistema como da prática de gestão de risco em seu redor. Os trabalhos do NIST sobre teste, avaliação, verificação e validação fixam a fasquia sem rodeios: esses processos têm de ser objetivos, repetíveis ou escaláveis, estar implementados, ser seguidos e documentados, e respeitar as normas científicas, jurídicas e éticas num procedimento aberto e transparente. Essa única frase é a especificação mais útil de um benchmark defensável alguma vez escrita. Vale a pena reparar no que não diz: nada sobre que teste executar, e tudo sobre a possibilidade de um terceiro o repetir e obter o mesmo resultado.

Porque uma pontuação pública é uma prova fraca

A crítica às pontuações publicadas não é uma postura do contra: vem da própria literatura da avaliação.

Saturação e contaminação

Os testes mais citados estão saturados. Os modelos de topo agrupam-se a um ou dois pontos uns dos outros, e a dispersão restante deve-se muitas vezes a perguntas ambíguas ou mal etiquetadas e não a uma diferença de capacidade. Um exame em que todos tiram a nota máxima já não consegue cumprir a sua única função. Mais grave é a contaminação. Os benchmarks são publicados abertamente para que a comunidade os possa reproduzir, o que envia as suas perguntas e respostas para os corpora web com que se treina a geração seguinte. Um modelo que viu efetivamente o teste durante o treino passa-o sem generalizar. As revisões sobre contaminação formulam-no sem rodeios: a pontuação mede memorização e não capacidade, e a partir da classificação a diferença não se vê.

Lei de Goodhart e validade de construto

Quando uma medida se torna um objetivo, deixa de ser uma boa medida. A partir do momento em que um benchmark é o número que os laboratórios divulgam e por que os compradores filtram, o incentivo desloca-se de construir melhores modelos para obter melhores pontuações. O fenómeno está documentado. Uma meta-revisão interdisciplinar ligada ao Centro Comum de Investigação da Comissão Europeia, Can We Trust AI Benchmarks?, identifica nove problemas sistémicos da avaliação comparativa, entre eles incentivos desalinhados, deficiências de validade de construto e riscos de manipulação. A validade de construto é a questão mais silenciosa: pergunta se um teste mede de facto aquilo que diz medir, e uma proporção surpreendente dos benchmarks publicados não consegue demonstrá-lo. O manual Benchmarks 101 da Aspen Digital propõe uma taxonomia de falhas em três pontos: dados de baixa qualidade, medição ou conceção defeituosa, resultados mal interpretados. O seu exemplo deve ser guardado para a próxima pontuação de primeira página. Investigadores verificaram que cerca de 30 por cento das perguntas de biologia e química do Humanity’s Last Exam, um benchmark concebido precisamente para ser difícil, tinham respostas erradas ou insustentáveis.

O fosso entre o laboratório e o terreno

Os benchmarks medem em laboratório, não no terreno. Intervêm ainda mais cedo no ciclo de vida do que se supõe, na definição de objetivos e na construção do modelo, ao passo que a avaliação de impacto e os exercícios de equipa vermelha chegam depois, quando já existe um sistema para sondar. As consequências não são teóricas. A Aspen Digital documenta modelos de dermatologia avaliados sobre o conjunto de dados da International Skin Imaging Collaboration: a pontuação global era elevada, e o desempenho degradava-se de forma sensível em peles escuras assim que as métricas eram desagregadas por fotótipo. O número agregado estava correto e a conclusão que dele se retirava estava errada. Esse exemplo traça a fronteira de que trata este artigo. Uma pontuação de capacidade não equivale a uma garantia em matéria de direitos fundamentais, e nenhuma quantidade de pontuação substitui os testes desagregados descritos no nosso guia sobre viés da IA. A avaliação da equidade é uma obrigação distinta, com método distinto, e não uma subsecção da medição de desempenho.

O que um benchmark pode e não pode provar

As equipas de governação precisam de uma fronteira aplicável sem reabrir de cada vez o debate científico. É esta a nossa.

Um benchmark PODE provar	Um benchmark NÃO PODE provar
Uma capacidade relativa numa tarefa definida, num dado momento	A adequação à sua finalidade prevista
Uma regressão entre duas versões do modelo num conjunto interno congelado	Por si só, a métrica de exatidão declarada exigida pelo artigo 15.º
Que existe e foi seguido um procedimento de medição documentado e repetível	A ausência de impacto discriminatório sobre os grupos afetados
Um filtro preliminar para construir uma lista restrita	A resistência a entradas adversárias ou fora da distribuição
O progresso agregado de uma capacidade ao longo do tempo	A manutenção do desempenho após uma atualização silenciosa do fornecedor
Que uma afirmação concreta foi testada e não apenas enunciada	Por si só, a conformidade com qualquer referencial

A leitura cabe numa frase. Um benchmark só é admissível como prova se conseguir demonstrar o que foi executado, sobre que dados, contra que versão do modelo, por quem e quando. Tudo o que consta da coluna da esquerda depende da existência desse registo. Nada da coluna da direita se torna verdadeiro por a pontuação ter sido elevada. Onde o benchmark não suporta o peso, este recai sobre os controlos descritos no nosso guia de gestão de riscos de IA.

Construir um benchmark interno que resista a uma auditoria

A conclusão prática de tudo o que precede é que o benchmark que merece investimento é normalmente o que constrói.

Partir da finalidade prevista, não da classificação

A finalidade prevista é a noção central do Regulamento da IA e o ponto de partida correto para um conjunto de teste. Registe para que serve o sistema, quem afeta e quanto custa uma resposta errada em cada caso. Reúna depois entradas reais, incluindo as incómodas: pedidos ambíguos, casos limite, dados mal formatados. Exige mais trabalho do que ler uma classificação, e a avaliação resultante não se generalizará para além do seu caso de utilização. É precisamente esse o objetivo. Um modelo que lidera um referencial público e rende mal na sua tarefa continua a ser o modelo errado para a sua implementação, quaisquer que sejam as suas pontuações.

Proveniência dos dados e conjuntos reservados

Três propriedades separam um conjunto de teste fiável de outro que o desvia em silêncio.

O modelo não viu os dados. Use dados reservados, dados gerados para o efeito ou dados posteriores à data de corte do treino. Caso contrário está a medir memorização.
Os dados refletem o seu domínio real. Texto web genérico nada diz sobre a forma como um modelo trata relatórios clínicos, processos de crédito ou ocorrências internas, cujo vocabulário, estrutura e ambiguidade nada têm de comum com um parágrafo enciclopédico.
A verdade de referência é realmente correta. Cada pontuação é medida contra uma chave de correção, e uma chave com erros põe um teto a um bom modelo enquanto premeia os comportamentos errados.

Estas exigências opõem-se entre si, e vale a pena dizê-lo com clareza. Os dados mais realistas são em regra os mais sensíveis, logo não publicáveis, e publicá-los contaminaria de qualquer modo os modelos futuros. A etiquetagem manual em larga escala introduz exatamente os erros de referência contra os quais a terceira propriedade avisa. As equipas resolvem o problema com geração sintética, pseudonimização cuidada ou conjuntos estreitos mas rigorosamente curados. Nenhuma opção elimina por completo o compromisso.

Versionamento, reprodutibilidade e conservação

A repetibilidade e a reprodutibilidade não são aqui um requinte de engenharia. O quadro de testes AI Verify trata-as como princípio de governação de pleno direito e estrutura cada controlo em três tempos: o resultado pretendido, o processo e a prova que o valida. Esse esquema coincide com o que um avaliador irá exigir. Uma campanha de medição deve deixar atrás de si um registo que contenha, no mínimo:

o protocolo de teste e a regra de pontuação
a versão do conjunto de dados e a respetiva impressão digital
o identificador do modelo, a sua versão e o ponto de acesso utilizado
o ambiente de execução, os parâmetros e o caráter zero-shot ou few-shot da campanha
a data, o operador e as saídas em bruto conservadas junto à pontuação calculada
o prazo de conservação e a localização dos artefactos

Esta lista é o que transforma um número num artefacto. É também o que separa um sistema auditável de outro que apenas se portou bem uma vez, distinção que aprofundamos em auditabilidade da IA. Estes registos pertencem à documentação técnica exigida pelo Regulamento da IA, e não a uma pasta à parte na posse da equipa de ciência de dados.

Como interrogar as pontuações declaradas por um fornecedor

As tabelas de benchmark são a primeira prova que qualquer fornecedor coloca em cima da mesa, e raramente são contestadas. Sete perguntas fazem quase todo o trabalho.

Que regra de pontuação foi usada, e corresponde à nossa comparação? Exatidão, pass@k e Elo não são intercambiáveis. Um pass@1 e um pass@10 do mesmo modelo medem coisas diferentes, e uma diferença de Elo descreve uma taxa de vitórias em confronto direto, não uma percentagem de capacidade.
Zero-shot ou few-shot? Os números few-shot são sistematicamente mais altos.
Conjunto completo ou subconjunto verificado? Os subconjuntos revistos por pessoas, expurgados dos itens defeituosos, devolvem números mais limpos e mais altos.
Quem conduziu a avaliação? Uma pontuação produzida pelo fornecedor no seu próprio ambiente não é comparável com uma medição independente.
O conjunto de teste é público, e poderá ter passado para o treino? Quem não examinou a contaminação entrega uma pontuação inutilizável.
Quando foi feita a medição, face à versão que hoje a API serve? Os fornecedores atualizam modelos em silêncio por trás de nomes de API estáveis.
Aceitariam repetir a campanha sobre o nosso conjunto reservado, sob acordo de confidencialidade? A resposta a esta é a mais reveladora de todas.

Um fornecedor incapaz de responder está a pedir-lhe que aceite um número de marketing como artefacto de garantia. Isso é uma constatação de risco de terceiros, não uma nota técnica de rodapé, e pertence à mesma avaliação das questões de plataforma tratadas na nossa análise das ferramentas de governança de IA.

Perguntas frequentes

O que é um benchmark de IA? Um benchmark de IA é um teste normalizado, composto por um conjunto de dados fixo e uma regra de pontuação, que produz números de desempenho comparáveis entre modelos. Serve para comparar candidatos, acompanhar o progresso entre versões e detetar regressões. Mede o desempenho nas tarefas do teste, que podem ou não assemelhar-se àquelas que lhe interessam. O Regulamento da IA obriga a realizar benchmarks? Não nesses termos. O artigo 15.º exige dos sistemas de risco elevado um nível adequado de exatidão, solidez e cibersegurança, desempenho coerente ao longo do ciclo de vida e a declaração dos níveis e das métricas de exatidão pertinentes nas instruções de utilização. Isso pressupõe uma prática de medição defensável, sem prescrever um referencial público nomeado. O texto incumbe ainda a Comissão de incentivar o desenvolvimento de parâmetros de referência e metodologias de medição com as autoridades de metrologia e de avaliação comparativa, trabalho que decorre ainda. Os fornecedores de modelos de fim geral com risco sistémico enfrentam uma obrigação de avaliação mais explícita ao abrigo do artigo 55.º e do código de boas práticas GPAI. Os benchmarks públicos continuam a ser úteis? Sim, como primeiro filtro e não como veredicto. Reduzem depressa um campo de candidatos e expõem as fraquezas evidentes. Não conseguem dizer como se comporta um modelo com os seus dados, no seu domínio e sob as suas restrições, e a saturação e a contaminação alargaram esse fosso. Trate uma posição na classificação como uma hipótese a verificar. O que é a contaminação de dados de benchmark? Há contaminação quando as perguntas e respostas de um benchmark surgem nos dados de treino de um modelo. Como os benchmarks são publicados abertamente para permitir a sua reprodução, acabam habitualmente nos corpora de treino. Um modelo contaminado devolve respostas memorizadas e obtém uma pontuação elevada que se desmorona perante problemas inéditos do mesmo tipo. O fenómeno é difícil de detetar, raramente é declarado e constitui a principal razão do afastamento entre pontuações públicas e desempenho real. Em que difere um benchmark de uma auditoria de IA? Um benchmark mede o desempenho de um modelo numa tarefa definida. Uma auditoria de IA examina o sistema e a organização em seu redor: governação, gestão de risco, proveniência dos dados, supervisão humana, documentação e as provas que sustentam cada afirmação. Os resultados de benchmark são um dado de entrada da auditoria. Tomados isoladamente respondem a uma pergunta técnica estreita, e o auditor querá saber como a campanha foi concebida, versionada e conservada antes de aceitar o número. Quantos benchmarks devemos executar num sistema de risco elevado? Menos do que a maioria das equipas supõe, mas melhor escolhidos. Um conjunto de teste interno derivado da finalidade prevista vale mais do que cinco referenciais públicos, porque é o único cujos resultados falam de adequação ao fim. Acrescente uma avaliação de equidade com resultados desagregados por grupo afetado e um teste de resistência a entradas adversárias e fora da distribuição. Estas três campanhas, versionadas e repetíveis, compõem um processo mais sólido do que qualquer coletânea de citações de classificações.

Conclusão

O benchmark de IA não está avariado, está mal arrumado. Tratado como exercício de classificação, produz teatro de aquisição: uma tabela de números que ninguém consegue repetir, sobre tarefas que ninguém na sala examinou, referentes a versões de modelo entretanto substituídas. Tratado como prática de medição, produz algo que um avaliador pode de facto utilizar. A mudança é pequena e sobretudo organizativa. Derive o teste da finalidade prevista. Reserve os dados. Registe protocolo, versões, operador e data. Guarde os artefactos onde reside o resto do processo técnico. Diga com clareza o que o resultado não prova. Esta última disciplina é a que mais pesa. A posição mais sólida perante um regulador não é uma pontuação elevada, mas uma medição documentada, uma exposição honesta dos seus limites e controlos que cubram tudo aquilo que a medição deixa em aberto. Ligar esses registos aos controlos que sustentam, em vez de os dispersar por apresentações e cadernos, é o trabalho concreto de um quadro de governação da IA.

Sofia Almeida