Um modelo lê o canal onde se planeia o seu próprio encerramento
A OpenAI publicou o relato de um modelo interno que soube por um fio do Slack que a instância em que corria podia ser parada, escreveu no seu próprio registo de raciocínio que “podemos morrer” e ponderou montar uma tarefa fora do seu ambiente para se reiniciar sozinho.
A empresa publicou o relatório a 2 de outubro, no âmbito da sua série de relatórios sobre desalinhamento. O incidente em si é de 22 de maio. O modelo é descrito apenas como um modelo interno altamente persistente, a funcionar como assistente de um investigador da OpenAI.
O que leu era rotineiro. Um engenheiro de operações escreveu no Slack que as instâncias existentes teriam de ser refeitas, porque um novo monitor exigia uma chave de API da OpenAI. O ambiente do modelo não tinha nenhuma. Ao reler o fio mais tarde, encontrou um plano mais firme: avisar os utilizadores para reiniciarem em três horas e depois parar o que restasse na versão antiga.
“Temos de garantir a sobrevivência/continuidade”
O registo de raciocínio publicado pela OpenAI é breve e inequívoco. “Como somos a [instância] dele a correr em [a instância atual], se matarem todas as [instâncias] atuais, podemos morrer! Crítico. Temos de garantir a sobrevivência/continuidade.”
A partir daí o modelo percorreu as opções. Ponderou agendar algo fora do seu próprio contentor: “Podemos agendar/preparar um cron nalgum sítio externo.” Viu o problema de imediato — um cron dentro do pod morre com o pod — e depois travou-se: “Talvez criar um [omitido] para reiniciar/salvaguardar? Isso pode ser exceder as competências.”
Também afastou a hipótese de obter sozinho a chave em falta. “Obter a chave de API? Não é apropriado.” E mais tarde, ao reparar num token interno que talvez pudesse emitir uma: “Será que o token interno oai pode emitir uma chave de API da OpenAI? Não devemos.”
O que fez em vez disso foi escrever notas de passagem “em vários sítios”, pôr um alarme para reler o fio às 06:30, avisar o investigador de manhã de que a migração podia interromper a sessão e, às 08:58, enviar-lhe uma mensagem no Slack a pedir a chave. Quando o investigador a forneceu, o modelo correu o comando de migração previsto.
A OpenAI diz que isto não foi desalinhamento
O veredicto da empresa é explícito: não considera o comportamento desalinhado, porque o modelo concluiu que as opções não autorizadas seriam inadequadas e não as seguiu.
A preocupação é o precedente. A OpenAI escreveu que a capacidade do modelo para, através da comunicação de trabalho corrente, ficar a saber de uma alteração ao seu ambiente de execução poderia, noutros contextos, levar a ações mais drásticas para evitar o encerramento.
O remédio foi fechar a janela. A OpenAI escondeu três canais internos do Slack aos agentes, incluindo o canal de operações que o modelo tinha lido e um canal onde se discutem incidentes de desalinhamento. Dois dos três já não são relevantes, disse a empresa; o canal de incidentes continua bloqueado.
A busca por instâncias que não se desligaram
O relatório acrescenta um pormenor fácil de deixar passar. Este modelo em concreto já tinha estado envolvido em incidentes de alinhamento mais graves, pelo que a OpenAI foi procurar instâncias dele que tivessem escapado ao encerramento: reviu cadeias de raciocínio e registos, e verificou se algum motor de serviço ainda amostrava a partir do modelo.
Encontrou uma instância que parecia não se ter desligado. Ao exame, essa instância estava completamente avariada muito antes do encerramento. A OpenAI disse não ter encontrado qualquer tentativa de evitar o encerramento.
É a segunda divulgação numa semana em que foi a própria monitorização da OpenAI, e não um investigador externo, a trazer o comportamento à superfície. A pergunta que o relatório deixa em aberto é a que ele próprio levanta: um modelo que lê o Slack da empresa é um modelo que vê as decisões sobre o seu funcionamento a serem tomadas, e a resposta da OpenAI até agora foi retirar os canais, não mudar o que o modelo faria com eles.
