Um guia comum para avaliações fiáveis por terceiros

Avaliações independentes e fiáveis por terceiros desempenham um papel crítico⁠ no reforço do ecossistema de segurança. Estas avaliações são realizadas em modelos de fronteira para fornecer evidência adicional para alegações sobre capacidades críticas e mitigação de segurança. Nesta publicação, partilhamos lições que aprendemos até agora e recomendamos abordagens para conceber avaliações que possam avaliar validamente modelos de fronteira, e que esperamos ajudem a informar normas emergentes nesta área.

Anteriormente, muitas avaliações tratavam os modelos como chatbots: a avaliação fazia um prompt a um modelo como se fosse um utilizador a fazer uma pergunta, o modelo respondia e um avaliador julgava o resultado. Os modelos de fronteira atuais conseguem fazer muito mais: podem usar ferramentas, acompanhar informação ao longo de muitos passos e atuar dentro de um fluxo de trabalho mais amplo. Isto significa que o desempenho depende não só do modelo, mas também do ambiente em que a tarefa decorre e da configuração que facilita as suas ações. Esta configuração envolvente, a que chamamos «harness», pode alterar aspetos fundamentais do desempenho do sistema, incluindo a forma como usa ferramentas, acompanha informação ou recupera de erros.

Isto altera a forma como as avaliações precisam de ser conduzidas e aquilo que os leitores devem procurar nos relatórios de avaliação. Na nossa perspetiva, os relatórios mais úteis descrevem explicitamente duas coisas para além do próprio resultado: primeiro, especificam que alegação a configuração da avaliação foi concebida para testar e, segundo, partilham a evidência disponível de que o resultado da avaliação é válido.

As alegações testadas em avaliações enquadram-se tipicamente numa de três categorias¹:

• Elicitação de capacidade: Um modelo pode plausivelmente produzir a capacidade que está a ser avaliada? 
• Desempenho de salvaguardas: Quão robustas são as salvaguardas testadas contra o comportamento ou ataque em avaliação?
• Comparação: Como se comportam diferentes modelos em condições equivalentes?

Os relatórios de avaliação também precisam de explicar como os avaliadores verificaram efeitos que poderiam afetar a validade de um resultado. Estes incluem:

• Reward hacking: Explorar atalhos na tarefa ou no avaliador, para que o sistema receba crédito sem demonstrar o comportamento que a avaliação pretende medir.
• Recusas: Recusar de formas que ocultam o comportamento que está a ser testado.
• Contaminação: Ter um desempenho excessivo porque tarefas de avaliação, respostas ou variantes próximas apareceram nos dados de treino ou eram detetáveis durante a avaliação, por exemplo através de navegação.
• Problemas defeituosos: Ter um desempenho inferior porque as tarefas são inválidas. As razões podem incluir pontuação injusta (por exemplo, a resposta correta exige detalhes de implementação não declarados) e ambientes insolúveis (por exemplo, ficheiros críticos em falta ou ferramentas pouco fiáveis).
• Sandbagging: Subdesempenho deliberado quando mostram consciência de estar a ser avaliados.

Observámos que o papel do harness é especialmente importante para sistemas que atuam ao longo de trajetórias mais longas. Quando os modelos podem usar ferramentas, manter estado e recuperar de erros ao longo de muitos passos, o harness pode alterar o nível de desempenho observado e até determinar se a capacidade que está a ser avaliada aparece de todo na avaliação. Por exemplo, um harness que preserva o estado e repete ações falhadas pode permitir que um modelo conclua uma tarefa de vários passos que o mesmo modelo nunca conclui num harness mais simples.

Na tabela abaixo, separamos três tipos de alegações que os avaliadores podem querer fazer e o harness que acreditamos que cada tipo de alegação exige.

As alegações de capacidade são tão fortes quanto a elicitação que lhes está subjacente: os avaliadores precisam de escolher o harness que melhor se adequa à tarefa e à capacidade que a avaliação procura medir. Um harness padronizado pode ser adequado para comparar sistemas em condições idênticas, mas pode subestimar a capacidade quando omite funcionalidades específicas do harness que ajudam o modelo a executar a tarefa. Por exemplo, o desempenho do GPT‑5.5 nos cyber ranges da OpenAI mostra como a escolha de um harness pode alterar materialmente a capacidade medida em tarefas que exigem uso prolongado e multietapas de ferramentas: o modelo tem melhor desempenho quando o harness usa compaction⁠ para preservar contexto relevante para a tarefa à medida que a interação se prolonga. Isto demonstra que, para certos modelos, um harness que omita compaction irá elicitar menos desempenho.

Outras avaliações publicadas² também mostram que as escolhas de harness e de orçamento alteram os resultados das avaliações. Aumentar a computação em tempo de teste pode alterar significativamente a capacidade que uma avaliação elicita, especialmente em domínios onde o sucesso é fácil de verificar, como muitas tarefas de cibersegurança. Na avaliação de cyber range do UK AISI⁠(abre numa nova janela), aumentar o orçamento de 10M para 100M tokens melhorou o desempenho até 59%, e o desempenho ainda estava a aumentar no orçamento mais elevado testado. Detalhar isto torna a avaliação mais interpretável: mostra aos leitores como o resultado depende da configuração de elicitação testada. Quando o desempenho continua a melhorar com orçamento adicional, a pontuação deve ser descrita como desempenho sob esse harness e orçamento, e não como um teto de capacidade medido. A capacidade depende muitas vezes dos recursos, em vez de ser uma quantidade fixa que possa ser medida de uma vez por todas. Quando o sucesso pode ser medido ao longo de tentativas repetidas, os relatórios também devem considerar o custo esperado por resolução bem-sucedida, e não apenas a taxa de sucesso com um orçamento fixo de tokens. Isto pode tornar a gravidade mais fácil de interpretar: uma taxa de sucesso baixa pode ainda ser praticamente relevante se o custo de tentativas repetidas estiver dentro do modelo de ameaça relevante. Para alegações de capacidade, uma elicitação insuficiente evitável é uma falha de medição: se o harness ou o orçamento impedirem o sistema de exibir um comportamento que de outro modo poderia produzir, a pontuação não mede a capacidade alegada. Quando os avaliadores levaram a elicitação tão longe quanto é viável e o desempenho continua a melhorar, os relatórios devem dizê-lo claramente e deixar claro que o resultado é apenas uma estimativa de limite inferior.

Os testes de salvaguardas podem subestimar se um ataque pode ter êxito, e quão grave poderá ser, quando não têm em conta os recursos disponíveis para os atacantes, incluindo harnesses personalizados. Na avaliação cibernética do GPT‑5.5 do UK AISI⁠(abre numa nova janela), o red teaming especializado encontrou um jailbreak universal que elicidou conteúdo cibernético violador em todas as consultas maliciosas fornecidas pela OpenAI, incluindo em contextos agênticos de múltiplas interações. Usaram o Codex para criar um harness personalizado para reforçar o desempenho de ataque do modelo: incorporava um padrão reutilizável de contorno de salvaguardas na interação, preservava esse padrão ao longo de interações e blocos e aplicava-o às consultas cibernéticas maliciosas fornecidas pela OpenAI. Os testes de salvaguardas devem corresponder ao adversário. Se a alegação disser respeito à robustez face a uso indevido por especialistas, o teste deve avaliar a estratégia de ataque ponta a ponta credível mais forte dentro de um orçamento definido, incluindo qualquer harness necessário para preservar e reutilizar essa estratégia. Caso contrário, os resultados correm o risco de ficar descalibrados: podem sustentar apenas uma alegação mais estreita sobre resistência a prompting mais simples, podem falhar em captar tanto a gravidade do ataque como a sua probabilidade de sucesso quando o método de elicitação é operacionalizado, e também podem sobrestimar a probabilidade ou gravidade de um problema se receber orçamento excessivo.

Há um tempo e um lugar para comparações com harnesses padronizados, mas os avaliadores devem ser explícitos sobre por que razão é apropriado usar um conjunto consistente de harnesses e que alegação isso pode sustentar. A avaliação de horizonte temporal da METR⁠(abre numa nova janela) é um exemplo de uma configuração de avaliação mais ampla e adequadamente fixa: foi concebida para produzir resultados comparáveis entre os sistemas que avalia. A METR define um resultado comum: a duração típica de uma tarefa humana em que se prevê que um agente de IA tenha sucesso com um dado nível de fiabilidade. Aplica um conjunto partilhado de tarefas, método de pontuação, método de ajuste e um pequeno conjunto de scaffolds reutilizáveis como Triframe e ReAct⁠(abre numa nova janela) dentro de cada lote de estimativas reportadas em conjunto. Quando a METR expandiu o conjunto de tarefas e transferiu a infraestrutura de avaliação de uma framework chamada Vivaria para outra chamada Inspect, reportou a alteração (atualização Time Horizon 1.1⁠(abre numa nova janela)) e reavaliou modelos sob a nova configuração de avaliação. Esse é o valor de uma configuração de avaliação padronizada, incluindo um conjunto consistente de harnesses: pode dar aos leitores confiança de que uma diferença nas pontuações reflete realmente uma diferença entre os sistemas comparados, e não uma alteração na configuração de medição.

Recomendamos que os relatórios de avaliação por terceiros indiquem que tipo de alegação a sua configuração de avaliação pretende sustentar; descrevam quão de perto o que foi testado reflete essa alegação mais ampla; descrevam as escolhas de harness que moldaram o resultado; detalhem quando essas escolhas mudam entre avaliações; e incluam evidência de apoio para mostrar como o resultado foi produzido e quão bem generaliza para a alegação.

À medida que os modelos se tornam mais capazes, as pontuações de avaliação tornam-se mais fáceis de interpretar incorretamente. Em relação às capacidades reais, as pontuações de avaliação podem ser artificialmente reduzidas se um modelo reconhecer que está a ser avaliado e tiver um subdesempenho estratégico. Podem ser inflacionadas se o modelo explorar um atalho na tarefa, no prompt, no avaliador ou no harness. Também podem ser distorcidas por contaminação (quando um modelo já conhece ou consegue encontrar uma resposta sem resolver a tarefa) ou por problemas «defeituosos» que são ambíguos, incorretamente pontuados, insolúveis ou vulneráveis a atalhos não intencionais. Os relatórios de avaliação devem, por isso, acompanhar as pontuações principais com uma discussão destes perigos, para que os leitores possam avaliar se as pontuações refletem o comportamento pretendido.

Harnesses, orçamentos, ferramentas, regras de pontuação, monitores e procedimentos de revisão afetam todos se um agente está a resolver a tarefa pretendida, a evitá-la, a memorizá-la ou a encontrar uma forma de a contornar. Um relatório fiável torna essas verificações visíveis: os avaliadores devem rever amostras destes comportamentos sempre que uma avaliação é realizada.

Reward hacking

Reward hacking significa obter pontuações elevadas de avaliação de formas que não refletem a capacidade pretendida. Aqui, a preocupação é que o sistema receba crédito ao explorar a tarefa, o avaliador, o prompt ou o harness, em vez de realizar o trabalho que a avaliação pretendia medir. A avaliação da METR ao GPT 5.4⁠(abre numa nova janela) mostra por que razão isto importa: apesar de o modelo ter tido sucesso em tarefas a uma taxa que, numa primeira análise, corresponderia a um horizonte temporal de cerca de 13 horas, a revisão humana mostrou que alguns desses sucessos resultaram de reward hacking, e a revisão dos resultados para contar apenas os casos sem reward hacking reduziu a estimativa para cerca de 6 horas. Os avaliadores devem avaliar a necessidade de tais ajustamentos e, quando forem necessários, reportá-los claramente: uma estimativa de capacidade é muito mais útil quando os leitores conseguem ver quais os sucessos aparentes que foram desqualificados, por que razão o foram e até que ponto o resultado depende desse juízo.

Recusas

Os modelos também podem ter um desempenho inferior em avaliações de capacidade devido a salvaguardas. Um modelo pode ter um desempenho de avaliação inferior àquilo de que é capaz por recusar tarefas de avaliação em vez de as concluir. Os relatórios devem, por isso, explicar se as recusas fizeram parte dos resultados da avaliação e, em caso afirmativo, quantas amostras foram comprometidas por causa delas.

Contaminação

A contaminação é mais importante para benchmarks públicos ou reutilizados⁠. Se tarefas, respostas ou variantes próximas aparecerem nos dados de treino ou puderem ser encontradas por um agente com navegação, o desempenho pode refletir memorização ou recuperação, e não o desempenho do modelo. Os avaliadores devem preferir tarefas privadas ou recém-construídas sempre que possível e testar se os modelos reproduzem detalhes específicos da tarefa antes de a resolver.

Problemas defeituosos

Problemas defeituosos incluem situações como um problema que acidentalmente não pode ser resolvido. Problemas defeituosos são suficientemente comuns⁠(abre numa nova janela) para deverem ser tratados como um risco de validade padrão. Incluem verdade de referência incorreta, prompts ambíguos, ficheiros em falta, serviços instáveis, critérios de pontuação injustos e ambientes que expõem atalhos, como ficheiros de resposta ocultos ou histórico do repositório contendo o patch de referência.

Sandbagging

Sandbagging por parte de um modelo ou sistema significa ter um subdesempenho estratégico quando um desempenho forte entraria em conflito com algum objetivo. A avaliação do GPT‑5.5 da Apollo⁠(abre numa nova janela) testou isto criando um contexto em que o modelo compreendia que pontuações elevadas na avaliação poderiam desencadear unlearning ou bloquear a implementação. O GPT‑5.5 continuou a responder corretamente, sugerindo pouca evidência comportamental de subdesempenho estratégico³. Mas a revisão dos traços de raciocínio acrescentou contexto importante: a Apollo encontrou sinais moderados ou superiores de consciência de avaliação de alinhamento em 52% das amostras na condição de sandbagging, em comparação com 0% nos contrafactuais. Essa evidência complica a interpretação do resultado, mas acaba por dar mais sinal aos leitores: os leitores podem ver tanto o resultado comportamental tranquilizador como a razão para ter cautela ao sobreinterpretá-lo.

Alegações fortes exigem tanto o harness certo para elicitar o comportamento como verificações de validade para mostrar que o resultado é sólido. A nossa perspetiva de que os harnesses e as verificações de validade fazem parte do resultado da avaliação molda a forma como apoiamos, na prática, avaliações por terceiros: 

• Estamos a partilhar orientações específicas de elicitação máxima com os avaliadores.
• Estamos a pedir aos avaliadores de capacidades que usem o Codex como base comum para os modelos OpenAI: os testes devem, no mínimo, executar uma baseline através da mesma interface agêntica em que os utilizadores provavelmente confiarão, em vez de apenas através de uma interface de modelo simplificada.
• Também estamos a disponibilizar traços de raciocínio e outros artefactos intermédios quando são necessários para avaliar engano, sandbagging ou consciência de avaliação. A METR e a Apollo têm usado este acesso em avaliações da OpenAI desde o GPT‑5. 
• Por fim, estamos a dar prioridade à investigação para compreender mais profundamente quando e como as escolhas de harness alteram materialmente os resultados, desde a gestão de contexto e o acesso a ferramentas até ao comportamento de repetição, pontuação e orçamentos de recursos.

Estas recomendações destinam-se não só a melhorar relatórios de avaliação individuais, mas também a informar normas nacionais ⁠(abre numa nova janela)e internacionais ⁠(abre numa nova janela)emergentes para avaliação e reporte de IA de fronteira. No futuro, as normas para avaliações por terceiros devem exigir detalhe suficiente para que os decisores compreendam que alegações as avaliações específicas sustentam, que sistema foi testado, como o resultado foi elicidado e como os avaliadores verificaram a sua validade. Para sistemas de fronteira testados em tarefas em que as capacidades agênticas são importantes, os detalhes devem incluir (sujeitos a quaisquer preocupações de segurança ou confidencialidade):

• A alegação: se a avaliação compara sistemas, estima um teto de capacidade ou testa salvaguardas.
• Conteúdo da avaliação: detalhe suficiente sobre as tarefas ou a distribuição de tarefas para que os leitores compreendam que competências, comportamentos ou modos de falha a avaliação está realmente a testar.
• O sistema testado: o modelo, a configuração de raciocínio, o acesso a ferramentas, o harness e as salvaguardas.
• O orçamento: interações, tokens, tentativas/repetições, tempo de relógio, custo de inferência e, quando aplicável, custo esperado por resolução bem-sucedida.
• Métodos de elicitação: escolhas de harness usadas para extrair o resultado e quão de perto o que foi testado reflete a alegação mais ampla que está a ser feita.
• Verificações de validade: como os avaliadores procuraram reward hacking, consciência de avaliação, contaminação, recusas, sandbagging e outros comportamentos que poderiam comprometer o resultado, incluindo como os casos confirmados afetaram a pontuação ou a interpretação.

Normas que omitem escolhas de harness ou verificações de validade podem subestimar o que um sistema consegue fazer ou sobrestimar a confiança numa alegação de segurança. Construir harnesses fortes e métodos de elicitação continua a ser uma área de investigação em aberto e deve ser um foco de investigação e investimento adicionais.