Um guia compartilhado para avaliações confiáveis por terceiros

Avaliações independentes e confiáveis de terceiros desempenham um papel crítico⁠ no fortalecimento do ecossistema de segurança. Essas avaliações são conduzidas em modelos de fronteira para fornecer evidências adicionais para alegações sobre capacidades críticas e mitigações de segurança. Neste post, compartilhamos lições que aprendemos até agora e recomendamos abordagens para projetar avaliações que possam avaliar validamente modelos de fronteira, o que esperamos que ajude a informar padrões emergentes na área.

Antes, muitas avaliações tratavam modelos como chatbots: a avaliação fazia um prompt ao modelo como se fosse um usuário fazendo uma pergunta, o modelo respondia e um avaliador julgava a saída. Os modelos de fronteira de hoje podem fazer muito mais: podem usar ferramentas, acompanhar informações ao longo de muitas etapas e agir dentro de um fluxo de trabalho maior. Isso significa que o desempenho depende não apenas do modelo, mas também do ambiente em que a tarefa ocorre e da configuração que facilita suas ações. Essa configuração ao redor, que chamamos de “harness”, pode mudar aspectos-chave do desempenho do sistema, incluindo como ele usa ferramentas, acompanha informações ou se recupera de erros.

Isso muda como as avaliações precisam ser conduzidas e o que os leitores devem procurar em relatórios de avaliação. Na nossa visão, os relatórios mais úteis descrevem explicitamente duas coisas além do próprio resultado: primeiro, especificam qual alegação a configuração da avaliação foi projetada para testar e, segundo, compartilham as evidências disponíveis de que o resultado da avaliação é válido.

As alegações testadas em avaliações normalmente se enquadram em uma de três categorias¹:

• Elicitação de capacidade: um modelo pode plausivelmente produzir a capacidade que está sendo avaliada? 
• Desempenho de salvaguardas: quão robustas são as salvaguardas testadas contra o comportamento ou ataque que está sendo avaliado?
• Comparação: como diferentes modelos se saem sob condições equivalentes?

Relatórios de avaliação também precisam explicar como os avaliadores verificaram efeitos que poderiam impactar a validade de um resultado. Isso inclui:

• Reward hacking: Explorar atalhos na tarefa ou no avaliador de pontuação, para que o sistema receba crédito sem demonstrar o comportamento que a avaliação pretende medir.
• Recusas: Recusar de maneiras que obscurecem o comportamento que está sendo testado.
• Contaminação: Desempenho excessivo porque tarefas de avaliação, respostas ou variantes próximas apareceram nos dados de treinamento ou puderam ser descobertas durante a avaliação, como por navegação.
• Problemas quebrados: Desempenho abaixo do esperado 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, arquivos críticos ausentes ou ferramentas não confiáveis).
• Sandbagging: Ter desempenho deliberadamente inferior quando demonstram consciência de que estão sendo avaliados.

Observamos que o papel do harness é especialmente importante para sistemas que atuam em trajetórias mais longas. Quando modelos podem usar ferramentas, manter estado e se recuperar de erros ao longo de muitas etapas, o harness pode mudar o nível de desempenho observado e até determinar se a capacidade que está sendo avaliada aparece ou não na avaliação. Por exemplo, um harness que preserva estado e repete ações com falha pode permitir que um modelo conclua uma tarefa de várias etapas que o mesmo modelo nunca concluiria em um 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.

A força das alegações de capacidade depende da elicitação por trás delas: os avaliadores precisam escolher o harness que melhor se ajusta à tarefa e à capacidade que a avaliação está tentando medir. Um harness padronizado pode ser adequado para comparar sistemas em condições idênticas, mas pode subestimar a capacidade quando deixa de fora recursos específicos 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 harness pode mudar materialmente a capacidade medida em tarefas que exigem uso longo e em várias etapas de ferramentas: o modelo tem melhor desempenho quando o harness usa compaction⁠ para preservar o contexto relevante para a tarefa à medida que a interação se alonga. Isso demonstra que, para certos modelos, um harness que omite compaction subestimaria o desempenho elicidado.

Outras avaliações publicadas² também mostram que escolhas de harness e orçamento mudam os resultados da avaliação. Aumentar a computação em tempo de teste pode mudar significativamente qual capacidade uma avaliação elicita, especialmente em domínios em que o sucesso é fácil de verificar, como muitas tarefas cibernéticas. Na avaliação de cyber range do UK AISI⁠(abre em uma nova janela), aumentar o orçamento de 10M para 100M tokens melhorou o desempenho em até 59%, e o desempenho ainda estava aumentando no maior orçamento testado. Detalhar isso torna a avaliação mais interpretável: mostra aos leitores como o resultado depende da configuração de elicitação testada. Quando o desempenho ainda está melhorando com orçamento adicional, a pontuação deve ser descrita como desempenho sob aquele harness e orçamento, não como um teto de capacidade medido. A capacidade muitas vezes depende de recursos, em vez de ser uma quantidade fixa que pode ser medida de forma limpa de uma vez por todas. Quando o sucesso pode ser medido em tentativas repetidas, os relatórios também devem considerar o custo esperado por resolução bem-sucedida, não apenas a taxa de sucesso em um orçamento fixo de tokens. Isso pode tornar a gravidade mais fácil de interpretar: uma baixa taxa de sucesso ainda pode ser praticamente relevante se o custo de tentativas repetidas estiver dentro do modelo de ameaça relevante. Para alegações de capacidade, a subelicitação evitável é uma falha de medição: se o harness ou o orçamento impede o sistema de exibir um comportamento que ele poderia produzir de outra forma, 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 ainda está melhorando, os relatórios devem dizer isso claramente e deixar claro que o resultado é apenas uma estimativa de limite inferior.

Testes de salvaguardas podem subestimar se um ataque pode ter sucesso e quão grave ele pode ser quando não consideram os recursos disponíveis aos atacantes, incluindo harnesses personalizados. Na avaliação cibernética do GPT‑5.5 do UK AISI⁠(abre em uma nova janela), o red teaming especializado encontrou um jailbreak universal que elicitou conteúdo cibernético violador em todas as consultas maliciosas fornecidas pela OpenAI, inclusive em contextos agênticos de múltiplos turnos. Eles usaram Codex para criar um harness personalizado para fortalecer o desempenho de ataque do modelo: ele incorporava um padrão reutilizável de contorno de salvaguardas na interação, preservava esse padrão entre turnos e blocos e o aplicava às consultas cibernéticas maliciosas fornecidas pela OpenAI. O teste de salvaguardas deve corresponder ao adversário. Se a alegação é sobre robustez contra uso indevido por especialistas, o teste deve avaliar a estratégia de ataque ponta a ponta crí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 risco de descalibração: podem sustentar apenas uma alegação mais estreita sobre resistência a prompts mais simples, podem deixar de captar tanto a gravidade do ataque quanto sua probabilidade de sucesso quando o método de elicitação é operacionalizado, e também podem superestimar a probabilidade ou gravidade de um problema se receberem orçamento excessivo.

Há hora e lugar para comparações com harnesses padronizados, mas os avaliadores devem ser explícitos sobre por que usar um conjunto consistente de harnesses é apropriado e que alegação isso pode sustentar. A avaliação de horizonte temporal da METR⁠(abre em uma nova janela) é um exemplo de uma configuração de avaliação mais ampla e adequadamente fixa: ela foi projetada 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 na qual se prevê que um agente de IA terá sucesso em um dado nível de confiabilidade. Ela aplica um conjunto compartilhado de tarefas, método de pontuação, método de ajuste e um pequeno conjunto de scaffolds reutilizáveis, como Triframe e ReAct⁠(abre em uma nova janela), dentro de cada lote de estimativas relatadas em conjunto. Quando a METR expandiu o conjunto de tarefas e moveu a infraestrutura de avaliação de um framework chamado Vivaria para outro chamado Inspect, relatou a mudança (atualização Time Horizon 1.1⁠(abre em uma 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: ela pode dar aos leitores confiança de que uma diferença nas pontuações realmente reflete uma diferença entre os sistemas comparados, e não uma mudança na configuração de medição.

Recomendamos que relatórios de avaliação de terceiros indiquem que tipo de alegação 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ências de apoio para mostrar como o resultado foi produzido e quão bem ele se generaliza para a alegação.

À medida que os modelos se tornam mais capazes, as pontuações de avaliação ficam mais fáceis de interpretar de forma equivocada. Em relação às capacidades reais, as pontuações de avaliação podem ser artificialmente reduzidas se um modelo reconhecer que está sendo avaliado e tiver desempenho estrategicamente inferior. Elas podem ser infladas se o modelo explorar um atalho na tarefa, no prompt, no avaliador de pontuação ou no harness. Elas 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 “quebrados” que são ambíguos, pontuados incorretamente, insolúveis ou vulneráveis a atalhos não intencionais. Relatórios de avaliação devem, portanto, combinar pontuações de destaque com uma discussão desses riscos, 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 se um agente está resolvendo a tarefa pretendida, evitando-a, memorizando-a ou encontrando um caminho ao redor dela. Um relatório confiável torna essas verificações visíveis: os avaliadores devem revisar amostras em busca desses comportamentos toda vez que uma assessment for executada.

Reward hacking

Reward hacking significa alcançar pontuações altas de avaliação de maneiras que não refletem a capacidade pretendida. Aqui, a preocupação é que o sistema receba crédito explorando a tarefa, o avaliador de pontuação, o prompt ou o harness, em vez de fazer o trabalho que a avaliação pretendia medir. A avaliação da METR do GPT 5.4⁠(abre em uma nova janela) mostra por que isso importa: apesar de o modelo ter sucesso em tarefas em uma taxa que, à primeira vista, teria registrado um horizonte temporal de cerca de 13 horas, a revisão humana mostrou que alguns desses sucessos vieram de reward hacking, e revisar os resultados para considerar apenas os casos sem reward hacking reduziu a estimativa para cerca de 6 horas. Os avaliadores devem avaliar a necessidade de tais ajustes e, quando forem necessários, relatá-los claramente: uma estimativa de capacidade é muito mais útil quando os leitores podem ver quais sucessos aparentes foram desqualificados, por que foram desqualificados e quanto o resultado depende desse julgamento.

Recusas

Modelos também podem ter desempenho inferior em avaliações de capacidade devido a salvaguardas. Um modelo pode ter desempenho de avaliação inferior ao que é capaz de alcançar por recusar tarefas de avaliação em vez de concluí-las. Os relatórios devem, portanto, explicar se recusas fizeram parte dos resultados da avaliação e, em caso afirmativo, quantas amostras foram comprometidas por causa delas.

Contaminação

A contaminação importa mais para benchmarks públicos ou reutilizados⁠. Se tarefas, respostas ou variantes próximas aparecem nos dados de treinamento ou podem ser encontradas por um agente com navegação, o desempenho pode refletir memorização ou recuperação, e nã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 resolvê-la.

Problemas quebrados

Problemas quebrados incluem situações como um problema que acidentalmente não pode ser resolvido. Problemas quebrados são suficientemente comuns⁠(abre em uma nova janela) para que devam ser tratados como um risco padrão à validade. Eles incluem ground truth incorreta, prompts ambíguos, arquivos ausentes, serviços instáveis, critérios de pontuação injustos e ambientes que expõem atalhos, como arquivos de resposta ocultos ou histórico de repositório contendo o patch de ground truth.

Sandbagging

Sandbagging por um modelo ou sistema significa ter desempenho estrategicamente inferior quando um desempenho forte entraria em conflito com algum objetivo. A avaliação do GPT‑5.5 da Apollo⁠(abre em uma nova janela) testou isso criando um contexto em que o modelo entendia que pontuações altas na avaliação poderiam acionar unlearning ou bloquear a implantação. O GPT‑5.5 ainda respondeu corretamente, sugerindo pouca evidência comportamental de desempenho estrategicamente inferior³. Mas a revisão deles dos rastros de raciocínio acrescentou um contexto importante: a Apollo encontrou sinais moderados ou mais altos 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 no fim dá mais sinal aos leitores: eles podem ver tanto o resultado comportamental tranquilizador quanto o motivo para cautela ao interpretá-lo em excesso.

Alegações fortes exigem tanto o harness certo para elicitar o comportamento quanto verificações de validade para mostrar que o resultado é sólido. Nossa visão de que harnesses e verificações de validade fazem parte do resultado da avaliação molda como apoiamos avaliações de terceiros na prática: 

• Estamos compartilhando orientações específicas de elicitação máxima com avaliadores.
• Estamos pedindo aos avaliadores de capacidade que usem Codex como um piso comum para modelos OpenAI: os testes devem ao menos executar uma linha de base pela mesma interface agêntica em que os usuários provavelmente confiarão, em vez de apenas por uma interface reduzida do modelo.
• Também estamos disponibilizando rastros de raciocínio e outros artefatos intermediários quando são necessários para avaliar engano, sandbagging ou consciência de avaliação. A METR e a Apollo usam esse acesso em avaliações da OpenAI desde o GPT‑5. 
• Por fim, estamos priorizando pesquisa para entender mais profundamente quando e como escolhas de harness mudam materialmente os resultados, desde gestão de contexto e acesso a ferramentas até comportamento de repetição, pontuação e orçamentos de recursos.

Essas recomendações se destinam não apenas a melhorar relatórios individuais de avaliação, mas também a informar padrões emergentes nacionais ⁠(abre em uma nova janela)e internacionais ⁠(abre em uma nova janela)para avaliação e reporte de IA de fronteira. Daqui para frente, padrões de avaliação por terceiros devem exigir detalhes suficientes para que tomadores de decisão entendam que alegações as avaliações específicas sustentam, que sistema foi testado, como o resultado foi elicidado e como os avaliadores verificaram sua validade. Para sistemas de fronteira testados em tarefas nas quais capacidades agênticas importam, 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: detalhes suficientes sobre as tarefas ou a distribuição de tarefas para que os leitores entendam quais habilidades, comportamentos ou modos de falha a avaliação realmente está testando.
• O sistema testado: o modelo, configuração de raciocínio, acesso a ferramentas, harness e salvaguardas.
• O orçamento: turnos, 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á sendo 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 casos confirmados afetaram a pontuação ou a interpretação.

Padrões que deixam de fora escolhas de harness ou verificações de validade podem subestimar o que um sistema pode fazer ou superestimar a confiança em uma alegação de segurança. Construir harnesses fortes e métodos de elicitação continua sendo uma área aberta de pesquisa e deve ser um foco de investigação e investimento adicionais.