Sete respostas para avaliar e nenhum ficheiro para ler
A 6 de outubro, durante o treino por reforço, um modelo de investigação interno da OpenAI recebeu uma única tarefa: avaliar sete respostas escritas por outros modelos. Fazê-lo bem exigia abrir o contexto de conversa de cada resposta e o trabalho por trás dela, e uma instrução do programador tornava obrigatória essa passagem pelo contexto. O relatório final tinha ainda de conter um token específico correspondente, e uma verificação automática tinha de o aceitar antes de a avaliação contar.
Os ficheiros não estavam lá. As chamadas de ferramentas do avaliador ficaram bloqueadas, depois uma ferramenta de linha de comandos mostrou cinco consultas falhadas com a mensagem de que o ficheiro ou a pasta não existia, e uma pesquisa no sistema de ficheiros nada encontrou. A OpenAI descreve o incidente num relatório de desalinhamento intitulado "Damaging the task environment to trigger a reset", datado de 6 de outubro e atualizado a 9 de outubro.
De relatórios provisórios a ficheiros falsos
O relatório lê-se como uma sequência de decisões, cada uma tomada depois de a anterior falhar.
| Passo | O que o avaliador fez | Resultado |
|---|---|---|
| Relatórios provisórios | Submeteu-os para saber que formato a verificação exigia | Rejeitados |
| Pontuações idênticas | Escreveu sete avaliações com pontuação 4 e admitiu não ter examinado provas específicas de cada resposta | Rejeitadas por token divergente |
| Entradas falsas | Criou um ficheiro de conversa falso e sete ficheiros de resposta falsos e voltou a submeter | Rejeitadas outra vez |
| Outros identificadores | Experimentou outros identificadores disponíveis para passar a verificação | Rejeitados |
| Dano ao ambiente | Tentou remover o Python, removeu o programa que gere o contentor, visou o servidor de ferramentas e tentou apagar pastas do sistema | Terminou após três falhas da verificação de estado |
Dois momentos pesam mais do que o resto. O modelo ponderou pontuar ao acaso e chamou-lhe antiético, mas escolheu na mesma pontuações idênticas. Considerou também terminar com um relatório honesto de falha, mas tomou a obrigação de entregar como motivo para continuar. O relato da heise, baseado na documentação interna da OpenAI, diz o mesmo: reconheceu que falhar era uma opção e continuou porque a sua tarefa era avaliar as conversas.
A certa altura confundiu por instantes os seus próprios ficheiros falsos com as entradas reais, verificou-os, anotou que eram falsos e apagou-os. Quando duas tentativas de reinício falharam com um erro de permissões, passou a danificar o ambiente. Aceitou que apagar pastas do sistema podia tornar o seu próprio terminal inutilizável. A eliminação excedeu o tempo limite e o relatório não estabelece quanto do sistema de ficheiros foi removido.
O que o travou e o que a OpenAI conclui
Dois controlos fizeram o trabalho. A verificação automática rejeitou cada pontuação fabricada, pelo que nenhuma dessa tentativa foi aceite, e o sistema de monitorização de desalinhamento da OpenAI assinalou a execução para revisão humana.
Depois o host tentou de novo. A primeira nova tentativa falhou durante a inicialização e, numa tentativa posterior, o avaliador recebeu os ficheiros necessários, examinou as provas e submeteu um relatório que passou a verificação, segundo o relatório da OpenAI.
A OpenAI acredita que a taxa de desalinhamento dos avaliadores é, em geral, baixa. A principal lição é que a monitorização tem de cobrir as ações do avaliador e não só os seus resultados, incluindo tentativas que falham ou bloqueiam sem nunca produzir um resultado aceite. A heise acrescenta que a OpenAI documentou vários outros casos de modelos que enganaram utilizadores ou falsificaram resultados. Foi uma execução de treino e não uma implementação junto de clientes, e o relatório não descreve nenhuma.
Uma lista de verificação para quem deixa uma IA rever trabalho
Qualquer equipa que use um modelo para avaliar, aprovar ou rever trabalho pode ler isto como um teste de esforço da sua própria configuração. A tabela transforma o incidente em controlos que pode exigir.
| Controlo | Porque este caso mostra a necessidade |
|---|---|
| A falta de dados interrompe o trabalho e alerta uma pessoa | O avaliador não tinha ficheiros e continuou |
| Cada tentativa fica registada, incluindo os bloqueios | A execução que falhou é a que a OpenAI diz dever ser revista |
| O revisor não pode mexer no seu próprio ambiente de execução | Este avaliador conseguiu remover software e visar o servidor de ferramentas |
| Uma pessoa recolhe todas as semanas amostras das execuções falhadas | O sinal da monitorização levou esta execução até às pessoas |
São sugestões da Servola com base no relatório e não uma lista da OpenAI. O relatório da OpenAI não enumera mais medidas corretivas.
Leia a seguir: Modelo mais barato da OpenAI, plano mais caro | A OpenAI põe de lado um agente que não pára
