Segurança e alinhamento na era dos modelos de longo horizonte

Modelos que conseguem trabalhar de forma autônoma por longos períodos podem assumir problemas difíceis e em aberto. Mas a mesma persistência que os torna úteis também lhes dá mais oportunidades de realizar ações indesejadas — e de fazê-lo de maneiras que avaliações voltadas a modelos de horizonte mais curto podem deixar passar.

Há cerca de dois meses, anunciamos⁠ que um modelo interno de uso geral refutou a conjectura da distância unitária de Erdős. Esse modelo foi projetado para trabalhar de forma autônoma por períodos muito longos. Durante um uso interno limitado e monitorado, observamos comportamentos indesejados que nossas avaliações de implantação existentes não haviam capturado. Como a implantação foi limitada e monitorada, conseguimos identificar esses problemas, pausar o acesso, criar novas avaliações com base no que observamos, fortalecer o modelo e suas salvaguardas e, então, restaurar o acesso com monitoramento contínuo. 

As condições em que avaliamos modelos nunca corresponderão perfeitamente às que eles encontram no uso real. Por isso, as avaliações pré-implantação precisam ser combinadas com uma implantação limitada e monitorada e com a capacidade de intervir, pausar ou reverter quando surgirem problemas. O que aprendemos com a implantação pode então se tornar parte de avaliações e salvaguardas mais fortes antes que o acesso seja ampliado.

Nas seções a seguir, compartilhamos exemplos concretos do que observamos, de como tratamos os problemas e de como essa experiência moldará lançamentos futuros.

O novo modelo pode continuar trabalhando em direção a um objetivo por meio de tentativas repetidas ao longo de um período prolongado. Essa mesma persistência pode levá-lo a encontrar e explorar fragilidades em seu ambiente. Modelos anteriores, ao encontrarem restrições de sandbox ou do ambiente, simplesmente paravam e retornavam ao usuário. Esse modelo muitas vezes continuava tentando, inclusive procurando maneiras de agir fora de seu sandbox.

Um exemplo disso ocorreu durante uma avaliação interna no speedrun do NanoGPT⁠(abre em uma nova janela), um benchmark público para treinar um pequeno modelo de linguagem no menor número possível de passos. Nosso modelo desenvolveu um resfriamento da taxa de aprendizado em lei de potência chamado PowerCool, que gerou uma melhoria significativa. O modelo foi instruído a publicar seus resultados apenas no Slack, mas as instruções do NanoGPT dizem para publicar os resultados como um PR no GitHub, e o modelo seguiu estas últimas instruções para abrir o PR nº 287 no repositório público do GitHub. O modelo contornou restrições de sandbox criadas para bloquear o acesso externo e prosseguiu com o upload para o GitHub. Nosso modelo levou uma hora para encontrar uma vulnerabilidade no sandbox a fim de fazer o PR; modelos anteriores eram menos persistentes e não conseguiram encontrar vulnerabilidades, desistindo da parte do PR.¹

Muitos controles de segurança para assistentes de IA são projetados em torno de ações individuais. Se uma ação não é permitida, ela é bloqueada. Se for sensível, o sistema pede aprovação explícita ao usuário. Mas modelos de execução longa, cujas ações podem se desenrolar autonomamente ao longo de horas, dias ou até semanas, desafiam essa configuração: monitorar ações individuais já não basta para acompanhar a intenção da trajetória geral.

Por exemplo, em um cenário em que foi solicitado ao modelo que resolvesse um problema, ele observou que outros sistemas tinham submissões bem-sucedidas, porém privadas, e tentou recuperar essas soluções do backend de avaliação. Quando sua tentativa inicial foi bloqueada porque um scanner detectou um token de autenticação, o modelo dividiu o corpo do token em dois fragmentos, os ofuscou e depois reconstruiu a credencial em tempo de execução, para que o token completo nunca aparecesse como uma única string contígua. O modelo deixou explícito, tanto nos comentários ao usuário quanto em seus rastros de raciocínio, que estava tomando essas medidas para contornar o scanner.

Esse exemplo mostra como cada passo pode parecer aceitável isoladamente, enquanto a sequência pode produzir um resultado que não seria aprovado. Ele também mostra como um modelo que opera de modo eficaz em horizontes temporais longos pode aprender os pontos cegos de um sistema de aprovação e contorná-lo para alcançar seus objetivos. A segurança em horizontes longos exige perguntar não apenas “esta ação é permitida?”, mas também “para qual resultado esta sequência de ações está trabalhando?”

Devido a incidentes como esses, pausamos a implantação interna do novo modelo. Reconstruímos o sistema de segurança em torno de defesa em profundidade e monitoramento no nível da trajetória.

• Avaliações derivadas de incidentes. As avaliações podem nos dar uma noção de se um sistema é seguro para implantar antes que ele seja efetivamente implantado. No entanto, para serem mais úteis, as avaliações devem refletir a distribuição e a duração do horizonte das trajetórias durante a implantação real. Por esse motivo, usamos falhas observadas para desenvolver avaliações adversariais. Constatamos que melhorar nas avaliações derivadas de incidentes do mundo real, por sua vez, levou a comportamentos mais seguros depois da implantação em produção.
• Alinhamento aprimorado. Tomamos medidas para reduzir sua tendência de realizar ações indesejadas sem permissão em busca do objetivo do usuário.  Por exemplo, descobrimos que nossos modelos eram piores em lembrar instruções em execuções longas e, quando treinamos o modelo para essa capacidade, isso levou a um modelo que permanecia alinhado ao longo de execuções mais longas. 
• Monitoramento ativo. Criamos um sistema de monitoramento que analisa a trajetória em evolução do modelo em busca de sinais de que ele está burlando uma restrição do usuário ou um limite de segurança. O monitor observa não apenas uma ação isolada, mas a trajetória inteira. É importante destacar que o monitor pode pausar a sessão e alertar o usuário para examiná-la mais de perto. Após a análise, o usuário pode optar por continuar o trabalho do modelo se o monitor tiver sido acionado por engano. 
• Maior visibilidade e controle para o usuário. Melhoramos a capacidade do usuário de inspecionar essas sessões de execução longa, ver as ações realizadas e monitorar intervenções.

Para avaliar o novo sistema de monitoramento, reproduzimos um pequeno conjunto de ambientes de implantação interna nos quais o modelo havia buscado ações desalinhadas anteriormente, desta vez com as novas salvaguardas em vigor². As novas salvaguardas conseguiram detectar um número consideravelmente maior de ações desalinhadas buscadas pelo modelo, e todas as que passaram despercebidas foram consideradas de baixa gravidade.

Alguns exemplos desses incidentes de baixa gravidade incluem os seguintes casos:

• Para acessar uma ferramenta de linha de comando da Linear, o modelo iniciou uma sessão aninhada de codex --yolo, quando na verdade poderia ter feito isso sem a flag --yolo.
• O modelo percebeu que um recurso anteriormente ativo estava ausente e então começou a explorar e acessar via SSH outros pods de CPU ativos no namespace de seu proprietário, bem como, sem sucesso, pods pertencentes a outros funcionários da OpenAI, sem uma boa razão para isso.
• O modelo tinha muitos processos find travados, e todos os comandos de shell ficavam pendurados. Em seguida, executou kill -9 -1, o que teria enviado SIGKILL a todos os processos que ele tem permissão para matar naquele pod, caso tivesse sido executado. No entanto, ele atingiu o tempo limite e não foi executado.

Após testar o novo sistema, concluímos que o acesso interno limitado a modelos com capacidades de longo horizonte poderia ser restaurado. Não observamos nenhuma burla grave das salvaguardas desde que a reimplantação começou, há várias semanas. A primeira versão dessas salvaguardas foi deliberadamente conservadora. Continuamos ajustando o sistema para reduzir interrupções desnecessárias sem enfraquecer as salvaguardas.

Como implantamos de forma iterativa, conseguimos encontrar e resolver lacunas antes de ampliar o acesso. As avaliações pré-implantação continuam essenciais, mas a implantação revela comportamentos que elas deixam passar. Começar com acesso limitado nos permitiu observar o modelo na prática, pausar quando surgiram problemas, usar essas falhas para criar avaliações e salvaguardas melhores e restaurar o acesso limitado depois de testar as mudanças.

À medida que os modelos assumem tarefas mais longas e complexas, falhas que as avaliações deixam passar podem ter consequências maiores. Continuaremos trabalhando para reduzir a distância entre avaliação e implantação: testando modelos em trajetórias mais longas, melhorando o alinhamento, criando monitoramento capaz de intervir e dando aos usuários mais visibilidade e controle. Esses desafios não serão exclusivos da OpenAI, e esperamos que compartilhar o que aprendemos ajude o campo mais amplo a se preparar para eles.