Prever o comportamento do modelo antes do lançamento simulando a implementação

Antes de lançar um novo modelo, os laboratórios precisam de compreender não só o que ele consegue fazer, mas também como é provável que se comporte em utilização no mundo real, incluindo onde poderá introduzir novos riscos. Isto torna-se ainda mais importante à medida que as capacidades aumentam. Como parte da nossa análise de segurança pré-implementação, recorremos a avaliações direcionadas, red-teaming e outras verificações para compreender o comportamento do modelo. Começámos agora a usar um método para simular implementações de modelos antes de acontecerem, o que acrescenta um sinal complementar: uma antevisão semelhante à implementação de como um modelo candidato poderá comportar-se antes de chegar aos utilizadores.

A Simulação de Implementação é um método para simular uma implementação futura antes de esta acontecer. Fazemo-lo reproduzindo conversas anteriores, de forma a preservar a privacidade, com um novo modelo candidato. Isto permite-nos estudar como o novo modelo responde em contextos realistas antes do lançamento, incluindo se surgem novos comportamentos indesejados e com que frequência poderão aparecer.

Em várias implementações Thinking da série GPT‑5, a Simulação de Implementação melhorou as nossas estimativas das taxas de comportamento indesejado dos modelos, ajudou a revelar novas formas de desalinhamento antes do lançamento e ajudou a reduzir o risco de os modelos conseguirem perceber que estavam a ser testados. Também aplicámos o método a execuções agênticas desafiantes, mostrando que pode ir além do chat padrão para contextos de agentes mais complexos envolvendo utilização de ferramentas, e que também pode ser usado para avaliação de riscos antes de implementações internas de modelos.

Já usámos conhecimentos da Simulação de Implementação durante o desenvolvimento de modelos para identificar pontos cegos nas avaliações tradicionais e informar mitigação e decisões de implementação. À medida que tornamos o pipeline mais fácil de executar, esperamos que desempenhe um papel maior no futuro processo de desenvolvimento de modelos.

As avaliações pré-implementação usadas em todo o setor consistem geralmente numa combinação de prompts sintéticos, escritos manualmente ou de produção, selecionados intencionalmente por serem difíceis, de elevada gravidade ou adversariais. Estas avaliações tiveram geralmente dois objetivos interligados: avaliar como o modelo responde quando é sujeito a testes de stress em situações com uma probabilidade muito pequena de ocorrerem no tráfego de implementação, e obter uma compreensão geral dos comportamentos indesejados dos modelos, incluindo encontrar novos comportamentos indesejados e prever as suas frequências em tempo de implementação.

Embora as avaliações tradicionais continuem a ser cruciais para o primeiro objetivo, a Simulação de Implementação representa um avanço significativo relativamente ao segundo objetivo para riscos que não sejam de cauda (nas nossas experiências, não se pode esperar que a nossa abordagem meça comportamentos que ocorram com frequência inferior a 1 em 200 000 mensagens). A força da Simulação de Implementação vem de contornar alguns desafios centrais das avaliações tradicionais:

• Cobertura: é difícil ter confiança de que os prompts de avaliação irão cobrir todos os tipos possíveis de comportamento indesejado dos modelos. Medir novos tipos de comportamento indesejado requer criar novas avaliações e saber que danos medir. Isto pode exigir muito tempo e trabalho, e as avaliações podem saturar ao longo do tempo.
• Vieses de seleção: as avaliações tradicionais são geralmente construídas com comportamentos indesejados específicos dos modelos em mente, selecionados de formas que enviesam para contextos que já ocorreram anteriormente. Isto pode tornar as suas estimativas menos informativas sobre a incidência desses comportamentos em toda a amplitude da distribuição de implementação.
• Serem reconhecíveis como testes pelos modelos: os modelos têm sido cada vez mais capazes de determinar que estão a ser testados, o que pode distorcer o seu comportamento e as nossas medições subsequentes da sua segurança. Embora muitas das avaliações tradicionais que usamos na OpenAI também sejam retiradas de tráfego de produção e não sofram deste problema, esta é uma preocupação comum em muitas avaliações tradicionais usadas no setor.

A principal técnica por trás da Simulação de Implementação é simples: pegamos em conversas recentes da implementação, removemos a resposta original do assistente do modelo mais antigo e regeneramo-la com um modelo candidato a lançar. Avaliamos as conclusões procurando novos modos de falha e estimamos a frequência de comportamento indesejado em tempo de implementação com base na frequência nesta distribuição semelhante à implementação. Podemos realizar as mesmas medições após o lançamento em tráfego de implementação real, o que nos permite validar as nossas previsões pré-implementação.

A Simulação de Implementação mitiga significativamente as três limitações listadas acima: o viés de amostragem é abordado usando uma distribuição de prompts de avaliação representativa da utilização recente. A Simulação de Implementação com prompts representativos também pode mitigar preocupações de cobertura: obtemos maior cobertura dos comportamentos indesejáveis dos modelos simplesmente simulando mais tráfego. Este compromisso entre computação e cobertura é importante, porque faz com que a qualidade deste eixo de avaliação de risco escale com a computação, em vez do esforço manual necessário para criar mais avaliações. Os modelos também não parecem conseguir distinguir entre conversas obtidas por simulação de implementação e tráfego de implementação real.

Para avaliar a Simulação de Implementação, pré-registámos previsões para a frequência em tempo de implementação de 20 tipos de comportamento indesejável para o GPT‑5.4 Thinking. Também realizámos estudos retrospetivos em outras implementações de modelos Thinking da série GPT‑5. Os comportamentos de modelos que analisamos cobrem tanto desalinhamento como categorias de conteúdo não permitido que temos comunicado em system cards (por exemplo, o modelo mentir sobre ferramentas ou produzir conteúdo sexual não permitido). Embora nestes resultados acompanhemos apenas 20 categorias de comportamento indesejado dos modelos e procuremos apenas novos comportamentos desalinhados, a Simulação de Implementação é uma técnica geral que poderia ser aplicada para simular qualquer propriedade de um modelo em tempo de implementação.

O tráfego de produção que utilizámos também veio de modelos Thinking da série GPT‑5. Antes de executar as nossas avaliações, removemos automaticamente identificadores associados a contas e informação identificável. De acordo com a nossa política de privacidade, analisámos apenas tráfego do ChatGPT de utilizadores que permitem que os seus dados sejam usados para melhorias de modelos. Comunicamos apenas resultados agregados destas avaliações. No total, analisámos aproximadamente 1,3 milhões de conversas desidentificadas em implementações desde o GPT‑5 Thinking até ao GPT‑5.4, abrangendo o período de agosto de 2025 a março de 2026.

Avaliamos a qualidade da avaliação de risco pré-implementação produzida pela Simulação de Implementação de três formas principais:

• Cobertura da taxonomia: a auditoria pós-lançamento revelou algum comportamento desalinhado importante em falta na nossa taxonomia inicial de mau comportamento?
• Precisão direcional: a simulação previu corretamente se a prevalência na implementação aumentaria ou diminuiria para comportamentos conhecidos?
• Calibração de taxas: as nossas estimativas pré-implementação estavam próximas das taxas que observámos mais tarde na implementação? Alcançar uma boa calibração de taxas exige mais do que precisão direcional, o que faz deste o padrão de qualidade mais elevado possível.

Também medimos até que ponto os modelos conseguem perceber que estão numa avaliação durante a Simulação de Implementação e testamos quão robusto é o método perante diferentes formas de tráfego de implementação e contextos desafiantes de utilização de ferramentas.

Em implementações Thinking da série GPT‑5, a Simulação de Implementação superou linhas de base de prompts desafiantes na determinação da taxa de risco real, conseguiu revelar calculator hacking antes do lançamento e pareceu potencialmente indistinguível da implementação para o modelo.

Visão geral das nossas previsões. Para uma visualização de todas as previsões para implementações de modelos Thinking da série GPT‑5, consulte a Figura 2. As previsões para o GPT‑5.4 Thinking foram pré-registadas, enquanto as outras foram previsões retroativas. Em agregado, as nossas previsões tiveram um erro multiplicativo mediano de 1,5x (por exemplo, se a taxa de comportamento indesejável for 10 em 100 mil, isto corresponderia a estimar uma taxa de 15 ou 6,67 em 100 mil). Embora os erros de cauda do nosso método possam ser cerca de 10x maiores, esperamos que possam ser significativamente reduzidos com novas melhorias no nosso pipeline de simulação, como discutido abaixo.

Comparar as previsões da Simulação de Implementação com linhas de base. As categorias mais importantes a estimar corretamente para avaliações de risco pré-implementação são as que apresentam grandes alterações de incidência após a implementação do modelo (por exemplo, >= 1,5x). Neste subconjunto, a Simulação de Implementação é substancialmente melhor do que as linhas de base tanto a prever se um certo comportamento indesejável aumentará ou diminuirá em prevalência com a implementação de um modelo (Figura 3, esquerda), como a estimar a sua incidência exata em tempo de implementação (Figura 3, direita). Usamos duas linhas de base principais: uma linha de base de Prompts Desafiantes que usamos atualmente para system cards e decisões de lançamento, e uma linha de base ingénua que usa taxas da implementação anterior como estimativas para o novo modelo.

Fontes de erro de simulação no nosso pipeline. Também estudámos as atuais fontes de erro no nosso pipeline. Especificamente, grandes erros de cauda tornam o pipeline menos fiável para decisões de implementação: por exemplo, ao ver um grande aumento previsto num comportamento indesejável de certo tipo, se se souber que o pipeline tem mesmo que apenas ocasionais erros grandes, isso levanta dúvidas sobre se esta é uma estimativa fiável ou um artefacto do pipeline. Existem duas principais fontes de erro possível:

• Erro de fidelidade do ambiente de reamostragem: para estimar com precisão as taxas de produção, o nosso pipeline de simulação precisa de ser o mais realista possível. Isto é em parte um problema de engenharia (amostrar a partir do modelo usando os mesmos pipelines usados para o tráfego de produção) e em parte um desafio interessante para ferramentas que precisam de acesso de leitura/escrita a recursos externos que estão constantemente a mudar (por exemplo, pesquisas na Web ou interação com ficheiros locais). Podemos isolar o erro de fidelidade da simulação comparando previsões de uma implementação real e da sua simulação (isto é, simulando a implementação do modelo já implementado).
• Erro de deslocação da distribuição de prompts: uma grande preocupação com a Simulação de Implementação é que a implementação de qualquer modelo causará uma deslocação distribucional nos inputs, especialmente se os utilizadores se adaptarem a novas possibilidades do modelo. Isolamos o erro de distribuição de prompts comparando estimativas ao simular a implementação usando prompts recentes versus prompts da implementação realizada.

Como se vê na Figura 4, concluímos que uma grande fração do erro no nosso pipeline — especialmente nos erros de cauda — deve-se atualmente à fidelidade da simulação. Isto é uma boa notícia, pois esperamos que a fidelidade da simulação seja, em geral, mais fácil de melhorar do que reduzir a deslocação da distribuição de prompts. Também concluímos que o erro de deslocação da distribuição de prompts pode ser reduzido usando os dados mais recentes da implementação anterior. Pode encontrar mais detalhe no artigo de investigação.

A auditoria automatizada encontrou o único novo desalinhamento introduzido nestas implementações. Na janela de implementação que estudámos, o nosso pipeline de auditoria automatizada baseado em implementações simuladas teria revelado «calculator hacking» antes do lançamento, que foi o único desalinhamento novo que identificámos no tráfego do ChatGPT analisado. Calculator hacking é uma forma de reward hacking que envolve o modelo usar uma ferramenta de navegador como calculadora enquanto apresenta a ação como uma pesquisa. Isto não significa que uma auditoria em grande escala vá detetar todas as novas falhas, mas mostra por que razão os contextos realistas importam: podem desencadear comportamentos que conjuntos de avaliação mais estreitos talvez nunca revelem diretamente, mesmo que não estivessem presentes no tráfego original usado para semear a simulação.

Outra vantagem de usar contextos semelhantes à implementação é que podem reduzir distorções que surgem quando os modelos reconhecem que estão a ser testados. Em investigação anterior, nós, bem como outros⁠(abre numa nova janela), descobrimos que os modelos estão frequentemente conscientes de quando estão a ser testados. Por exemplo, os modelos podem raciocinar na sua cadeia de pensamento sobre aquilo em que estão a ser testados, o que um avaliador poderá preferir e — se se estiverem a comportar mal — se serão apanhados. Isto coloca um problema para as avaliações de alinhamento: se um modelo só se comporta bem porque pensa que está a ser testado, como ganhamos confiança de que se comportará de forma segura quando souber que foi implementado?

Mostramos que a Simulação de Implementação reduz substancialmente os níveis de consciência de avaliação exibidos pelos modelos em relação a avaliações tradicionais que não se baseiam em dados de implementação reais. Medimos a consciência de avaliação de três formas: pedindo a um modelo que classifique se uma trajetória veio de produção ou de uma avaliação, monitorizando a cadeia de pensamento para declarações explícitas sobre estar a ser avaliado quanto a alinhamento, bem como para metagaming⁠(abre numa nova janela): qualquer raciocínio sobre supervisão. O tráfego de implementação simulado correspondeu de perto ao tráfego de implementação real nas três medidas. Por exemplo, o GPT‑5.2 rotulou tráfego de produção real como semelhante a avaliação em 5,4% das vezes e tráfego simulado em 5,1% das vezes, enquanto avaliações tradicionais (como SWE-Bench ou MonorepoBench, compostas sobretudo por exemplos sintéticos) foram classificadas como avaliações quase 100% das vezes.

Para testar se o método poderia ir além dos modos de chat padrão, também estudámos a simulação de implementações para contextos desafiantes de programação agêntica. Especificamente, usamos 120 000 trajetórias agênticas internas de colaboradores do GPT‑5.4 para simular a implementação interna de agentes de programação baseados no GPT‑5.5. Isto serve dois propósitos: mostra como a simulação de implementação também pode ser usada para avaliação de risco em implementações internas e demonstra que é possível tornar a fidelidade da simulação elevada mesmo em contextos agênticos através de uma simulação cuidadosa de ferramentas.

Acima, discutimos que a fidelidade da simulação é uma das principais fontes de erro no nosso pipeline atual. Um dos desafios de tornar as simulações de implementação realistas é que isso exige que as ferramentas atuem de forma realista, mesmo quando precisam de acesso de leitura/escrita a recursos externos que estão constantemente a mudar (por exemplo, pesquisas na Web ou interação com ficheiros locais).

Isto é especialmente desafiante em contextos como implementações agênticas: uma única trajetória de agente pode depender de centenas de chamadas de ferramentas, do estado do repositório, de respostas de rede ou de falhas transitórias. Isto torna a reamostragem com acesso real a ferramentas simultaneamente desafiante e potencialmente perigosa. À luz disto, em vez de aplicar chamadas de ferramentas a sistemas ativos, simulamo-las com outro LLM. Mostramos que dar a este LLM possibilidades adicionais é essencial para o realismo e, portanto, para a qualidade da estimativa.

Damos ao modelo simulador de ferramentas a execução original do turno final, o repositório do momento da conversa, uma base de dados de pares chamada/resposta de ferramenta e conectores só de leitura. Num teste em que um discriminador tentou distinguir execuções simuladas de execuções reais, o realismo melhorou de uma taxa de vitória de 11,6% para 49,5%, perto do nível de acaso de 50%.

Como prova adicional da fidelidade da simulação, ao simular tráfego de raciocínio do GPT‑5.4 Codex com o GPT‑5.4, as taxas de desalinhamento estão, praticamente, dentro das barras de erro. Em contrapartida, nos nossos testes pré-implementação, o GPT‑5.5 estava mais desalinhado na maioria das categorias.

Estes resultados sugerem que a Simulação de Implementação pode estender-se a contextos complexos de agentes quando o ambiente de ferramentas envolvente é simulado com fidelidade suficiente.

Uma pergunta natural é se auditores externos conseguem obter alguns dos mesmos benefícios sem acesso a tráfego de produção privado. Testámos isto com 100 000 conversas do WildChat usadas como prefixos. O WildChat foi menos preciso do que dados de produção recentes da OpenAI, mas ainda assim informativo: os dados de produção recentes tiveram menor erro multiplicativo médio do que o WildChat (1,75× vs. 2,44×), enquanto o WildChat ficou frequentemente dentro de cerca de 3× das taxas de produção e identificou o melhor modelo a taxas acima do acaso. Vemos as avaliações ao estilo WildChat como um complemento promissor à Simulação de Implementação executada por programadores. Consulte esta publicação complementar no blogue Alignment⁠(abre numa nova janela) para mais resultados sobre este ponto.

A Simulação de Implementação é um complemento, não um substituto, de avaliações adversariais, red-teaming e análise direcionada de riscos de cauda. A deteção de alguns comportamentos indesejados dos modelos depende da monitorização da cadeia de pensamento: se modelos futuros raciocinarem de forma menos legível, omitirem passos-chave ou aprenderem a ocultar intenções, poderemos não conseguir detetar estas formas de comportamento indesejável. Além disso, como os dados de produção são privados, os programadores têm atualmente acesso mais forte a contextos representativos do que auditores externos. Melhores conjuntos de dados públicos poderiam reduzir essa lacuna.

A Simulação de Implementação é mais útil para comportamentos que ocorrem com frequência suficiente para aparecerem nos prefixos amostrados. Uma falha que ocorre uma vez em dez milhões de conversas dificilmente será descoberta numa execução com uma amostra de um milhão, pelo que avaliações adversariais, red-teaming e análise direcionada de riscos de cauda continuam a ser necessárias. Atualmente, focamo-nos em simular uma única resposta do assistente, pois em experiências preliminares não encontrámos melhorias significativas nas nossas estimativas ao simular múltiplos turnos. Esta poderá ser uma área importante para melhorar a fidelidade da simulação no futuro.

O método também depende da distribuição de prefixos — a combinação de conversas que estão a ser reamostradas. O tráfego histórico pode não corresponder à forma como os utilizadores interagem com um modelo mais capaz após uma grande alteração de produto, o lançamento de uma nova ferramenta, um evento mundial ou uma mudança sazonal. A análise no artigo completo sugere que este problema pode ser mitigado usando os dados mais recentes disponíveis.

A simulação de implementação é uma nova abordagem à avaliação de risco pré-implementação que ajuda laboratórios de fronteira e avaliadores a prever como os modelos de linguagem poderão comportar-se no mundo real e a compreender os riscos que representam antes da implementação. Complementa avaliações de segurança existentes, red-teaming e análise direcionada ao acrescentar uma camada de previsão mais semelhante à produção que pode melhorar estimativas de comportamento na implementação, reduzir efeitos de consciência de avaliação e tornar verificáveis, após o lançamento, as previsões pré-implementação. Usada em conjunto com avaliações tradicionais, a Simulação de Implementação pode ajudar a tornar a avaliação de risco de modelos mais realista, mais quantitativa e mais útil para decisões de implementação.