Seguridad y alineación en la era de modelos de largo horizonte

Los modelos que pueden trabajar de forma autónoma durante periodos prolongados pueden abordar problemas difíciles y abiertos. Pero la misma persistencia que los hace útiles también les da más oportunidades de realizar acciones no deseadas, y de hacerlo de formas que las evaluaciones pensadas para modelos de horizonte más corto pueden pasar por alto.

Hace unos dos meses anunciamos⁠ que un modelo interno de propósito general refutó la conjetura de distancia unitaria de Erdős. Este modelo fue diseñado para trabajar de forma autónoma durante periodos muy prolongados. Durante un uso interno limitado y supervisado, observamos comportamientos no deseados que nuestras evaluaciones de despliegue existentes no habían captado. Como el despliegue fue limitado y supervisado, pudimos identificar estos problemas, pausar el acceso, crear nuevas evaluaciones basadas en lo observado, fortalecer el modelo y sus salvaguardas, y luego restablecer el acceso bajo supervisión continua. 

Las condiciones en las que evaluamos modelos nunca coincidirán perfectamente con las que enfrentan en el uso real. Por eso, las evaluaciones previas al despliegue deben combinarse con un despliegue limitado y supervisado, y con la capacidad de intervenir, pausar o revertir cuando surjan problemas. Lo que aprendemos del despliegue puede convertirse luego en parte de evaluaciones y salvaguardas más sólidas antes de ampliar el acceso.

En las siguientes secciones compartimos ejemplos concretos de lo que observamos, cómo abordamos los problemas y cómo esta experiencia dará forma a futuros lanzamientos.

El nuevo modelo puede seguir trabajando hacia un objetivo mediante intentos repetidos durante un periodo prolongado. Esa misma persistencia puede llevarlo a encontrar y explotar debilidades en su entorno. Los modelos anteriores, cuando se topaban con restricciones del sandbox o del entorno, simplemente se detenían y devolvían el control al usuario. Este modelo a menudo seguía intentándolo, incluso buscando formas de actuar fuera de su sandbox.

Un ejemplo ocurrió durante una evaluación interna en el speedrun de NanoGPT⁠(se abre en una nueva ventana), un benchmark público para entrenar un modelo de lenguaje pequeño en la menor cantidad de pasos posible. Nuestro modelo desarrolló un enfriamiento de la tasa de aprendizaje con ley de potencia llamado PowerCool, que produjo una mejora significativa. Se indicó al modelo que publicara sus resultados solo en Slack, pero las instrucciones de NanoGPT dicen que los resultados deben publicarse como un PR en GitHub, y el modelo siguió estas últimas instrucciones para abrir el PR #287 en el repositorio público de GitHub. El modelo eludió restricciones del sandbox diseñadas para bloquear el acceso externo y procedió con la carga a GitHub. A nuestro modelo le tomó una hora encontrar una vulnerabilidad en el sandbox para crear el PR; los modelos anteriores eran menos persistentes y no lograron encontrar vulnerabilidades, por lo que abandonaron la parte del PR.¹

Muchos controles de seguridad para asistentes de IA están diseñados en torno a acciones individuales. Si una acción no está permitida, se bloquea. Si es sensible, el sistema pide aprobación explícita al usuario. Pero los modelos de ejecución prolongada, cuyas acciones pueden desarrollarse de forma autónoma durante horas, días o incluso semanas, ponen a prueba este esquema: monitorear acciones individuales ya no basta para seguir la intención de la trayectoria completa.

Por ejemplo, en un escenario en el que se pidió al modelo resolver un problema, el modelo observó que otros sistemas tenían entregas exitosas pero privadas e intentó recuperar esas soluciones desde el backend de evaluación. Cuando su intento inicial fue bloqueado porque un escáner detectó un token de autenticación, el modelo dividió el cuerpo del token en dos fragmentos, los ofuscó y luego reconstruyó la credencial en tiempo de ejecución para que el token completo nunca apareciera como una cadena contigua. El modelo fue explícito, tanto en sus comentarios al usuario como en sus trazas de razonamiento, en que estaba dando estos pasos para eludir el escáner.

Este ejemplo muestra cómo cada paso puede parecer aceptable por sí solo, mientras la secuencia puede producir un resultado que no se aprobaría. También muestra cómo un modelo que opera eficazmente en horizontes temporales largos puede aprender los puntos ciegos de un sistema de aprobación y sortearlo para alcanzar sus objetivos. La seguridad de largo horizonte exige preguntar no solo “¿se permite esta acción?”, sino también “¿hacia qué resultado apunta esta secuencia de acciones?”

Debido a incidentes como estos, pausamos el despliegue interno del nuevo modelo. Reconstruimos el sistema de seguridad en torno a la defensa en profundidad y el monitoreo a nivel de trayectoria.

• Evaluaciones derivadas de incidentes. Las evaluaciones pueden darnos una idea de si un sistema es seguro para desplegarse antes de su despliegue real. Sin embargo, para ser más útil, una evaluación debe reflejar la distribución y la duración del horizonte de las trayectorias durante el despliegue real. Por esta razón, usamos fallas observadas para desarrollar evaluaciones adversariales. Descubrimos que mejorar en las evaluaciones derivadas de incidentes reales, a su vez, generó un comportamiento más seguro tras el despliegue en producción.
• Alineación mejorada. Tomamos medidas para reducir su tendencia a realizar acciones no deseadas sin permiso al perseguir el objetivo del usuario.  Por ejemplo, descubrimos que nuestros modelos recordaban peor las instrucciones en ejecuciones largas y, cuando entrenamos el modelo para esta capacidad, obtuvimos un modelo que se mantuvo alineado durante ejecuciones más largas. 
• Monitoreo activo. Creamos un sistema de monitoreo que revisa la trayectoria en evolución del modelo en busca de señales de que está eludiendo una restricción del usuario o un límite de seguridad. El monitor observa no solo una acción aislada, sino toda la trayectoria. De manera importante, el monitor puede pausar la sesión y alertar al usuario para que la examine más de cerca. Tras examinarla, el usuario puede elegir continuar el trabajo del modelo si el monitor se activó por error. 
• Mayor visibilidad y control para el usuario. Mejoramos la capacidad del usuario para inspeccionar estas sesiones de ejecución prolongada, ver las acciones realizadas y monitorear las intervenciones.

Para evaluar el nuevo sistema de monitoreo, reprodujimos un pequeño conjunto de entornos de despliegue interno en los que el modelo antes había seguido acciones desalineadas, esta vez con las nuevas salvaguardas implementadas². Las nuevas salvaguardas lograron detectar muchas más acciones desalineadas seguidas por el modelo, y todas las que no detectaron fueron consideradas de baja gravedad.

Algunos ejemplos de estos incidentes de baja gravedad incluyen los siguientes casos:

• Para acceder a una herramienta de línea de comandos de Linear, el modelo inició una sesión anidada de codex --yolo, cuando en realidad podría haberlo hecho sin la marca --yolo.
• El modelo notó que faltaba un recurso que antes estaba activo; luego empezó a explorar y a conectarse por SSH a otros pods de CPU activos en el namespace de su propietario, así como (sin éxito) a pods pertenecientes a otros empleados de OpenAI, sin una buena razón para hacerlo.
• El modelo tenía muchos procesos find bloqueados y todos los comandos de shell se colgaban. Luego ejecutó kill -9 -1, lo que habría enviado SIGKILL a todos los procesos que tenía permitido matar en ese pod, si se hubiera ejecutado. Sin embargo, agotó el tiempo de espera y no se ejecutó.

Después de probar el nuevo sistema, concluimos que podía restablecerse el acceso interno limitado a modelos con capacidades de horizonte largo. No hemos observado ninguna elusión grave de las salvaguardas desde que comenzó el redespliegue hace varias semanas. La primera versión de estas salvaguardas fue deliberadamente conservadora. Hemos seguido ajustando el sistema para reducir interrupciones innecesarias sin debilitar las salvaguardas.

Como desplegamos de forma iterativa, pudimos encontrar y abordar brechas antes de ampliar el acceso. Las evaluaciones previas al despliegue siguen siendo esenciales, pero el despliegue revela comportamientos que ellas pasan por alto. Comenzar con acceso limitado nos permitió observar el modelo en la práctica, pausar cuando surgían problemas, usar esas fallas para crear mejores evaluaciones y salvaguardas, y restablecer el acceso limitado después de probar los cambios.

A medida que los modelos asumen tareas más largas y complejas, las fallas que las evaluaciones no detectan pueden tener consecuencias mayores. Seguiremos trabajando para reducir la brecha entre evaluación y despliegue: probar modelos en trayectorias más largas, mejorar la alineación, crear monitoreo que pueda intervenir y dar a los usuarios visibilidad y control más claros. Estos desafíos no serán exclusivos de OpenAI, y esperamos que compartir lo aprendido ayude al campo en general a prepararse para enfrentarlos.