OpenAI

Control Room

A carregar…

À medida que os nossos modelos se tornam mais poderosos e os riscos de segurança e proteção associados aumentam, torna-se cada vez mais essencial detetar potenciais problemas e parar rapidamente os modelos quando necessário. Para responder a esta necessidade, criámos o Control Room.

O Control Room é um sistema central que acompanha as cargas de trabalho dos modelos em toda a nossa infraestrutura de investigação e as para rapidamente quando surgem preocupações de segurança ou proteção. Liga todas as cargas de trabalho de inferência de investigação, incluindo a amostragem com agentes para treino e avaliação de modelos, o processamento de dados, entre outras. Funciona em conjunto com os nossos sistemas de monitorização de desalinhamento e interrompe a geração de resultados dos modelos no prazo de 35 segundos após a decisão de intervir para parar ou suspender uma tarefa. Foi concebido para continuar a funcionar mesmo quando outros sistemas falham e para interromper a geração de resultados dos modelos se o próprio Control Room ficar indisponível.

O Control Room já está implementado em toda a nossa infraestrutura de investigação, onde a necessidade é maior. A nossa infraestrutura de disponibilização de modelos a utilizadores externos já é, por natureza, muito mais centralizada e dispõe de uma capacidade operacional bem desenvolvida para retirar rapidamente modelos de serviço, se necessário.

Como funciona

O Control Room funciona através da integração de alguns sistemas: a carga de trabalho, o motor de inferência e o serviço Control Room centralizado.

  • A carga de trabalho é a tarefa em execução, como uma experiência de aprendizagem por reforço, uma avaliação, uma tarefa de amostragem de grande volume ou de processamento de dados. Exigimos que todas as cargas de trabalho de investigação que realizem inferência com agentes estejam associadas a uma argumentação de segurança aprovada.

  • O motor de inferência, ou simplesmente motor, é o próprio modelo. Podemos pensar no motor como o cérebro do modelo, a funcionar diretamente em GPUs. Uma carga de trabalho utiliza normalmente um ou mais modelos, que podem estar a ser executados num ou mais motores de inferência diferentes. O mesmo motor de inferência pode ser utilizado por várias cargas de trabalho diferentes.

  • O serviço Control Room acompanha as tarefas e controla se estas estão autorizadas a continuar a gerar resultados dos modelos. Os motores consultam o serviço Control Room antes de satisfazerem um pedido. Se uma tarefa tiver sido parada, o serviço nega o pedido, impedindo a geração de mais resultados.

O Control Room é integrado da seguinte forma:

  • Ao iniciar uma nova tarefa, o código da carga de trabalho solicita um novo job_id ao Control Room.

  • Sempre que a carga de trabalho precisa de obter tokens de um modelo por amostragem, envia um pedido a um motor de inferência que executa esse modelo, passando o job_id. O motor pede autorização ao Control Room para satisfazer esse pedido, passando-lhe o job_id.

  • O Control Room verifica se essa tarefa foi terminada e, em caso afirmativo, nega o pedido de inferência. O motor responde com uma recusa ao pedido de inferência da carga de trabalho, impedindo que o modelo produza mais resultados para essa tarefa.

Como funciona o Control Room

Investigador

Tarefa de investigação

<No job ID yet>

Motor de inferência

Executa o modelo em GPUs

Control Room

  • job_039, ativa
  • job_040, ativa
  • job_041, ativa
PASSO 1

Um investigador decide iniciar uma tarefa

O processo começa quando um investigador inicia uma tarefa, por exemplo, uma experiência ou uma avaliação.

Exemplo: reagir a um alerta de monitorização

Todas as nossas tarefas de aprendizagem por reforço de modelos de fronteira são executadas com um monitor. Um monitor é outro modelo que inspeciona tudo o que o modelo em treino faz e emite um alerta se detetar um problema. Por exemplo, o nosso recente incidente relacionado com DNS⁠(abre numa nova janela) foi detetado por um monitor.

O Control Room e o nosso sistema de monitorização estão integrados da seguinte forma:

  • Se o sistema de monitorização detetar um potencial problema, pode decidir parar a tarefa, consoante as características e a gravidade do problema.

  • Nesse caso, o sistema de monitorização envia uma mensagem ao Control Room para parar a tarefa, passando o job_id. O Control Room regista que a tarefa foi terminada.

  • Da próxima vez que a tarefa com esse job_id fizer um pedido de inferência para obter mais tokens por amostragem de qualquer modelo em execução em qualquer motor, o pedido será negado, impedindo a geração de mais resultados pelo modelo.

Rapidez e fiabilidade

O tempo máximo entre o momento em que o Control Room recebe uma instrução para parar uma tarefa e o momento em que esta deixa de poder prosseguir é de 35 segundos. Este intervalo de 35 segundos deve-se a uma camada de cache para a autorização de inferência, necessária para suportar o volume de tráfego exigido. Estamos a trabalhar para reduzir este valor a zero, de modo a podermos terminar tarefas instantaneamente.

As cargas de trabalho, incluindo experiências, tarefas de avaliação, entre outras, estão normalmente sob a responsabilidade de investigadores ou equipas de investigadores, que as executam. Por isso, o código das cargas de trabalho muda com frequência e não é o local ideal para implementar mecanismos de proteção essenciais à segurança. Assim, a nossa implementação foi concebida para resistir a erros ou falhas no código das cargas de trabalho.

Conseguimos isso ao implementar o mecanismo de terminação na camada de inferência. O código das cargas de trabalho é muito variado e descentralizado. Em contrapartida, toda a investigação da OpenAI utiliza um número muito reduzido de percursos de execução do código de inferência, cujas implementações são muito mais centralizadas e uniformes. Isto permite que a camada de inferência funcione como um ponto de passagem obrigatório, onde podemos obter garantias sólidas de que toda a inferência de modelos executada na investigação está sujeita às verificações de autorização do Control Room a cada pedido de inferência. Além disso, realizamos verificações contínuas, com agentes e por meios programáticos, para confirmar que os utilizadores não estão a iniciar, acidental ou maliciosamente, implementações de motores não autorizadas, nas quais o Control Room não esteja implementado ou esteja desativado.

Por fim, o nosso sistema «bloqueia em caso de falha»: a integração do Control Room nos motores está configurada de forma que, se o serviço Control Room ficar indisponível, seja devido a um erro do sistema ou por ter sido desativado por qualquer outro motivo, incluindo manipulação por um interveniente mal-intencionado, todos os pedidos de inferência são negados até o Control Room retomar o funcionamento normal. O bloqueio em caso de falha já está implementado em todas as cargas de trabalho de investigação de modelos de fronteira e a sua implementação nas restantes cargas de trabalho de investigação ficará concluída nos próximos dias.


O Control Room é apenas uma parte da nossa abordagem integrada ao treino e à implementação seguros de modelos de fronteira. Vamos continuar a reforçar e a expandir o sistema nos próximos meses, em paralelo com os nossos investimentos na monitorização de comportamentos desalinhados e violações de segurança. Se quer ajudar a criar sistemas para o desenvolvimento e a implementação de AGI com segurança e proteção, estamos⁠ a recrutar⁠!