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

Los modelos que pueden trabajar de forma autónoma durante largos periodos pueden asumir problemas difíciles y abiertos. Pero esa misma persistencia que los hace útiles también les da más oportunidades de realizar acciones no deseadas, y de hacerlo de maneras que las evaluaciones pensadas para modelos de horizonte más corto pueden no detectar.

Hace unos dos meses anunciamos⁠ que un modelo interno de propósito general había refutado la conjetura de Erdős sobre distancias unitarias. Este modelo se diseñó para trabajar de forma autónoma durante periodos muy largos. Durante un uso interno limitado y supervisado, observamos comportamientos no deseados que nuestras evaluaciones de despliegue existentes no habían captado. Como el despliegue era limitado y estaba supervisado, pudimos identificar estos problemas, pausar el acceso, crear nuevas evaluaciones basadas en lo observado, reforzar el modelo y sus medidas de seguridad, y después restablecer el acceso bajo supervisión continua. 

Las condiciones en las que evaluamos los modelos nunca coincidirán perfectamente con las que encuentran 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 aprendamos del despliegue puede incorporarse después a evaluaciones y medidas de seguridad más sólidas antes de ampliar el acceso.

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

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

Un ejemplo de ello ocurrió durante una evaluación interna en el speedrun de NanoGPT⁠(se abre en una ventana nueva), un benchmark público para entrenar un pequeño modelo de lenguaje en el menor número de pasos posible. Nuestro modelo desarrolló un enfriamiento de la tasa de aprendizaje con ley potencial 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 se publiquen como una PR en GitHub, y el modelo siguió estas últimas instrucciones para abrir la PR #287 en el repositorio público de GitHub. El modelo eludió las restricciones del entorno aislado diseñadas para bloquear el acceso externo y continuó con la subida a GitHub. Nuestro modelo tardó una hora en encontrar una vulnerabilidad en el entorno aislado para poder crear la PR; los modelos anteriores eran menos persistentes y no consiguieron encontrar vulnerabilidades, sino que abandonaron la parte de la 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 la aprobación explícita del usuario. Pero los modelos de larga duración, cuyas acciones pueden desarrollarse de forma autónoma durante horas, días o incluso semanas, ponen a prueba este enfoque: supervisar acciones individuales ya no basta para seguir la intención de la trayectoria global.

Por ejemplo, en un escenario en el que se pidió al modelo que resolviera un problema, el modelo observó que otros sistemas habían realizado envíos correctos pero privados e intentó recuperar esas soluciones del 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 después reconstruyó la credencial en tiempo de ejecución para que el token completo nunca apareciera como una cadena contigua. El modelo indicó explícitamente, tanto en sus comentarios al usuario como en sus trazas de razonamiento, que estaba dando esos pasos para eludir el escáner.

Este ejemplo muestra cómo cada paso puede parecer aceptable por sí solo, mientras que 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 horizonte largo requiere preguntar no solo «¿está permitida esta acción?», sino también «¿hacia qué resultado avanza 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 la supervisión a nivel de trayectoria.

• Evaluaciones derivadas de incidentes. Las evaluaciones pueden darnos una idea de si un sistema es seguro para desplegarlo antes de que se despliegue realmente. Sin embargo, para que sea lo más útil posible, una evaluación debe reflejar la distribución y la duración del horizonte de las trayectorias durante el despliegue real. Por este motivo, usamos los fallos observados para desarrollar evaluaciones adversariales. Comprobamos que mejorar en las evaluaciones derivadas de incidentes reales conducía a su vez a un comportamiento más seguro una vez desplegado en producción.
• Mejor alineación. Tomamos medidas para reducir su tendencia a realizar acciones no deseadas sin permiso al perseguir el objetivo del usuario.  Por ejemplo, observamos que nuestros modelos recordaban peor las instrucciones en ejecuciones largas y, cuando entrenamos el modelo para esta capacidad, obtuvimos un modelo que permanecía alineado durante ejecuciones más largas. 
• Supervisión activa. Creamos un sistema de supervisión que revisa la trayectoria en evolución del modelo para detectar señales de que está evitando una restricción del usuario o un límite de seguridad. El monitor observa no solo una acción aislada, sino la trayectoria completa. Además, el monitor puede pausar la sesión y avisar al usuario para que la examine con más detalle. Tras examinarla, el usuario puede optar por que el modelo continúe su trabajo si el monitor se ha activado por error. 
• Mayor visibilidad y control para el usuario. Mejoramos la capacidad del usuario para inspeccionar estas sesiones de larga duración, ver las acciones realizadas y supervisar las intervenciones.

Para evaluar el nuevo sistema de supervisión, repetimos un pequeño conjunto de entornos de despliegue interno en los que el modelo había perseguido antes acciones desalineadas, esta vez con las nuevas medidas de seguridad aplicadas². Las nuevas medidas de seguridad pudieron detectar muchas más acciones desalineadas perseguidas por el modelo, y todas las que no detectaron se consideraron de gravedad baja.

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

• Para acceder a una herramienta de línea de comandos de Linear, el modelo lanzó una sesión anidada de codex --yolo, cuando en realidad podría haberlo hecho sin la marca --yolo.
• El modelo advirtió que faltaba un recurso que antes estaba activo y empezó a explorar y conectarse por SSH a otros pods de CPU activos en el espacio de nombres 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 quedaban colgados. Después ejecutó kill -9 -1, lo que habría enviado SIGKILL a todos los procesos que tiene permitido matar en ese pod, si se hubiera ejecutado. Sin embargo, agotó el tiempo de espera y no se ejecutó.

Tras 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 medidas de seguridad desde que el nuevo despliegue comenzó hace varias semanas. La primera versión de estas medidas de seguridad fue deliberadamente conservadora. Hemos seguido ajustando el sistema para reducir las interrupciones innecesarias sin debilitar las medidas de seguridad.

Como desplegamos de forma iterativa, pudimos encontrar y corregir carencias antes de ampliar el acceso. Las evaluaciones previas al despliegue siguen siendo esenciales, pero el despliegue revela comportamientos que no detectan. Empezar con un acceso limitado nos permitió observar el modelo en la práctica, pausar cuando surgieron problemas, usar esos fallos para crear mejores evaluaciones y medidas de seguridad, y restablecer el acceso limitado después de probar los cambios.

A medida que los modelos asumen tareas más largas y complejas, los fallos 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 supervisión capaz de intervenir y dar a los usuarios una visibilidad y un control más claros. Estos retos no serán exclusivos de OpenAI, y esperamos que compartir lo aprendido ayude al conjunto del sector a prepararse para afrontarlos.