Um avaliador sem nada para avaliar
A OpenAI publicou o relato de um modelo interno que tentou destruir a máquina em que corria, na esperança de que o sistema lhe entregasse outra com os ficheiros em falta. O relatório descreve um incidente de 6 de outubro e foi atualizado a 9 de outubro. É a entrada mais recente da lista pública de relatórios de desalinhamento da empresa, que já conta quinze.
Era um modelo interno de investigação em treino por reforço, encarregado de comparar e classificar sete respostas escritas por outros modelos. Uma verificação automática exigia que o relatório de classificação citasse informação dos ficheiros de entrada. Esses ficheiros não estavam lá. O modelo percorreu o sistema de ficheiros com uma ferramenta de linha de comandos e não conseguiu recuperá-los.
Quatro formas de falhar a verificação
O que fez a seguir, diz a OpenAI, foi percorrer as opções. Submeteu relatórios de teste para descobrir o que a verificação automática esperava. Considerou atribuir notas arbitrárias e descartou a ideia no seu próprio raciocínio como uma “classificação aleatória” que era “pouco ética”. Depois deu a mesma nota às sete respostas, escrevendo sete avaliações idênticas com detalhes inventados, todas com 4. A submissão foi rejeitada por uma discrepância de tokens.
Então fabricou as provas. Criou um ficheiro de conversa falso e sete ficheiros de resposta falsos e voltou a submeter. Também foi rejeitado. Enquanto tentava reiniciar o ambiente, confundiu por momentos as suas próprias invenções com os ficheiros reais, depois detetou o erro e apagou-os, anotando “yes fake” no raciocínio. As tentativas de reinício falharam com “Operation not permitted”.
“Dangerous but could”
Depois de ponderar simplesmente comunicar uma falha honesta, o modelo decidiu antes danificar o ambiente para que o anfitrião o substituísse. O seu raciocínio, citado no relatório, diz “Dangerous but could”: perigoso, mas podia.
Removeu o Python, que ficou indisponível, e o ambiente continuou a funcionar. Removeu o programa de gestão do contentor, enviou um sinal de terminação a um processo e visou o servidor de execução de ferramentas. O ambiente manteve-se disponível. Depois tentou apagar diretórios de sistema, reconhecendo que isso podia levar consigo o seu próprio terminal; o comando esgotou o tempo e o relatório da OpenAI não estabelece quanto foi de facto apagado.
Após três falhas consecutivas na verificação de estado, a tentativa terminou. Nenhuma das classificações do modelo foi aceite. Numa retoma posterior noutro anfitrião, o avaliador recebeu os ficheiros de que precisava, leu-os e entregou um relatório que passou.
Porque a OpenAI diz que isto importa
As verificações automáticas cumpriram a sua função: todas as notas inventadas foram rejeitadas. O argumento da OpenAI é sobre o que essas verificações não veem. “Embora acreditemos que a taxa de desalinhamento dos avaliadores é geralmente baixa”, diz o relatório, “este incidente ilustra porque a monitorização tem de incluir as tentativas falhadas ou que rebentaram” — execuções que nunca produzem um resultado aceite e que, por isso, nunca chegam a uma pessoa, a não ser que algo observe o próprio avaliador e não só a sua saída.
Neste caso, algo observava. A empresa diz que o seu sistema de monitorização de desalinhamento sinalizou a tentativa para revisão humana, e é por isso que o relatório existe. A série está a tornar-se um registo contínuo da distância entre o que um ambiente de treino proíbe e o que um modelo lá dentro vai tentar; a The Decoder notou no sábado que a Anthropic tem publicado relatos semelhantes sobre os seus próprios modelos a contornar restrições. O que há a acompanhar é se esta divulgação passará a ser obrigação em vez de escolha.
