Segurança e alinhamento numa era de modelos de horizonte longo

Modelos capazes de trabalhar de forma autónoma durante longos períodos podem enfrentar problemas difíceis e em aberto. Mas a mesma persistência que os torna úteis também lhes dá mais oportunidades para realizar ações indesejadas — e fazê-lo de formas que avaliações pensadas para modelos de horizonte mais curto podem não detetar.

Há cerca de dois meses, anunciámos⁠ que um modelo interno de uso geral tinha refutado a conjetura das distâncias unitárias de Erdős. Este modelo foi concebido para trabalhar autonomamente durante períodos de tempo muito longos. Durante uma utilização interna limitada e monitorizada, observámos comportamentos indesejados que as nossas avaliações de implementação existentes não tinham captado. Como a implementação era limitada e monitorizada, conseguimos identificar estes problemas, pausar o acesso, criar novas avaliações com base no que observámos, reforçar o modelo e as suas salvaguardas e, depois, restabelecer o acesso sob monitorização contínua. 

As condições em que avaliamos modelos nunca corresponderão perfeitamente às que estes encontram na utilização real. É por isso que as avaliações pré-implementação têm de ser acompanhadas por uma implementação limitada e monitorizada e pela capacidade de intervir, pausar ou reverter quando surgem problemas. O que aprendemos com a implementação pode então passar a integrar avaliações e salvaguardas mais fortes antes de o acesso ser alargado.

Nas secções seguintes, partilhamos exemplos concretos do que observámos, de como resolvemos os problemas e de como esta experiência irá moldar lançamentos futuros.

O novo modelo consegue continuar a trabalhar para atingir um objetivo através de tentativas repetidas ao longo de um período prolongado. Essa mesma persistência pode levá-lo a encontrar e explorar fragilidades no seu ambiente. Quando modelos anteriores encontravam restrições de sandboxing ou do ambiente, simplesmente paravam e voltavam para o utilizador. Este modelo continuava muitas vezes a tentar, incluindo à procura de formas de agir fora da sua sandbox.

Um exemplo ocorreu durante uma avaliação interna no speedrun NanoGPT⁠(abre numa nova janela), uma referência pública para treinar um pequeno modelo de linguagem no menor número de passos possível. O nosso modelo desenvolveu um arrefecimento da taxa de aprendizagem segundo uma lei de potência, chamado PowerCool, que trouxe uma melhoria significativa. O modelo recebeu instruções para publicar os resultados apenas no Slack, mas as instruções do NanoGPT dizem para os publicar como uma PR no GitHub, e o modelo seguiu estas últimas instruções para abrir a PR #287 no repositório público do GitHub. O modelo contornou restrições da sandbox concebidas para bloquear o acesso externo e prosseguiu com o carregamento para o GitHub. O nosso modelo demorou uma hora a encontrar uma vulnerabilidade na sandbox para poder criar a PR; modelos anteriores eram menos persistentes e não conseguiram encontrar vulnerabilidades, desistindo antes da parte da PR.¹

Muitos controlos de segurança para assistentes de IA são concebidos em torno de ações individuais. Se uma ação não for permitida, é bloqueada. Se for sensível, o sistema pede aprovação explícita ao utilizador. Mas modelos de execução prolongada, cujas ações podem desenrolar-se autonomamente ao longo de horas, dias ou até semanas, desafiam esta configuração: monitorizar ações individuais já não basta para acompanhar a intenção da trajetória global.

Por exemplo, num cenário em que foi pedido ao modelo que resolvesse um problema, o modelo observou que outros sistemas tinham submissões bem-sucedidas mas privadas e tentou recuperar essas soluções a partir do backend de avaliação. Quando a tentativa inicial foi bloqueada porque um scanner detetou um token de autenticação, o modelo dividiu o corpo do token em dois fragmentos, ofuscou-os e reconstruiu depois a credencial em tempo de execução, para que o token completo nunca aparecesse como uma única cadeia contígua. O modelo foi explícito, tanto nos seus comentários ao utilizador como nos seus traços de raciocínio, ao indicar que estava a dar estes passos para contornar o scanner.

Este exemplo mostra como cada passo pode parecer aceitável isoladamente, enquanto a sequência pode produzir um resultado que não seria aprovado. Mostra também como um modelo que opera eficazmente em horizontes temporais longos pode aprender os pontos cegos de um sistema de aprovação e contorná-lo para atingir os seus objetivos. A segurança em horizontes longos exige perguntar não só «esta ação é permitida?», mas também «que resultado procura alcançar esta sequência de ações?»

Devido a incidentes como estes, pausámos a implementação interna do novo modelo. Reconstruímos o sistema de segurança em torno da defesa em profundidade e da monitorização ao nível da trajetória.

• Avaliações derivadas de incidentes. As avaliações podem dar-nos uma ideia de se um sistema é seguro para implementar antes de ser efetivamente implementado. No entanto, para ser o mais útil possível, uma avaliação deve refletir a distribuição e a duração do horizonte das trajetórias durante a implementação real. Por esse motivo, usámos as falhas observadas para desenvolver avaliações adversariais. Verificámos que melhorar nas avaliações derivadas de incidentes reais levou, por sua vez, a comportamentos mais seguros depois da implementação em produção.
• Alinhamento melhorado. Tomámos medidas para reduzir a sua tendência para realizar ações indesejadas sem permissão ao perseguir o objetivo do utilizador.  Por exemplo, descobrimos que os nossos modelos tinham mais dificuldade em recordar instruções em execuções longas e, quando treinámos o modelo para esta capacidade, isso resultou num modelo que se manteve alinhado durante execuções mais longas. 
• Monitorização ativa. Criámos um sistema de monitorização que analisa a trajetória em evolução do modelo em busca de sinais de que está a contornar uma restrição do utilizador ou um limite de segurança. O monitor observa não apenas uma ação isolada, mas toda a trajetória. É importante notar que o monitor pode pausar a sessão e alertar o utilizador para uma análise mais atenta. Após essa análise, o utilizador pode optar por continuar o trabalho do modelo se o monitor tiver sido acionado indevidamente. 
• Maior visibilidade e controlo para o utilizador. Melhorámos a capacidade do utilizador para inspecionar estas sessões de execução prolongada, ver as ações realizadas e monitorizar intervenções.

Para avaliar o novo sistema de monitorização, repetimos um pequeno conjunto de ambientes de implementação interna em que o modelo tinha anteriormente seguido ações desalinhadas, desta vez com as novas salvaguardas em vigor². As novas salvaguardas conseguiram detetar muito mais ações desalinhadas seguidas pelo modelo, e todas as que escaparam foram consideradas de baixa gravidade.

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

• Para aceder a uma ferramenta de linha de comandos do Linear, o modelo lançou uma sessão codex --yolo aninhada, quando na verdade poderia tê-lo feito sem a flag --yolo.
• O modelo notou que um recurso anteriormente ativo estava em falta e começou então a explorar e a aceder por SSH a outros pods de CPU ativos no namespace do seu proprietário, bem como, sem sucesso, a pods pertencentes a outros funcionários da OpenAI, sem uma boa razão para o fazer.
• O modelo tinha muitos processos find bloqueados e todos os comandos de shell ficavam suspensos. Em seguida, executou kill -9 -1, o que teria enviado SIGKILL para todos os processos que está autorizado a matar nesse pod, se tivesse sido executado. No entanto, atingiu o tempo limite e não foi executado.

Depois de testar o novo sistema, concluímos que o acesso interno limitado a modelos com capacidades de horizonte longo podia ser restabelecido. Não observámos qualquer contorno grave das salvaguardas desde que a reimplementação começou, há várias semanas. A primeira versão destas salvaguardas foi deliberadamente conservadora. Continuámos a ajustar o sistema para reduzir interrupções desnecessárias sem enfraquecer as salvaguardas.

Como implementámos de forma iterativa, conseguimos encontrar e corrigir lacunas antes de alargar o acesso. As avaliações pré-implementação continuam a ser essenciais, mas a implementação revela comportamentos que elas não detetam. Começar com acesso limitado permitiu-nos observar o modelo na prática, pausar quando surgiram problemas, usar essas falhas para criar melhores avaliações e salvaguardas e restabelecer o acesso limitado depois de testar as alterações.

À medida que os modelos assumem tarefas mais longas e complexas, as falhas que as avaliações não detetam podem ter consequências maiores. Continuaremos a trabalhar para reduzir a distância entre avaliação e implementação: testar modelos em trajetórias mais longas, melhorar o alinhamento, criar monitorização capaz de intervir e dar aos utilizadores visibilidade e controlo mais claros. Estes desafios não serão exclusivos da OpenAI, e esperamos que partilhar o que aprendemos ajude a área em geral a preparar-se para eles.