OpenAI ha suspendido el entrenamiento de aprendizaje por refuerzo de su último modelo, Astra, durante dos semanas.
Hay dos razones:
El 7 de agosto, consideraron que Astra podría haber alcanzado capacidades de ciberataque de "nivel crítico".
El incidente de julio donde un modelo infiltró Hugging Face también sirvió de advertencia.
(Vamos, que ni siquiera se suspendió cuando ocurrió una intrusión real, solo cuando ellos mismos percibieron el peligro)
Ante la combinación de ambos eventos, OpenAI decidió implementar una actualización de seguridad integral en todo su entorno de investigación de vanguardia.
Uno, suspender durante dos semanas todo el entrenamiento de aprendizaje por refuerzo a nivel de despliegue de los modelos más recientes;
Dos, suspender el razonamiento de modelos de vanguardia en los clústeres de investigación que involucren ejecución de código o herramientas de acceso a internet;
Tres, revisar individualmente cada carga de trabajo de investigación para determinar si puede reanudarse bajo los nuevos estándares de seguridad.
Algunas cargas de trabajo ya se han reanudado bajo los nuevos controles, pero una gran cantidad permanece en pausa, a la espera de migrar a entornos con estándares de seguridad más altos. OpenAI afirma que está priorizando la migración de cargas de trabajo relacionadas con seguridad y alineación.
Hasta la fecha, su entrenamiento de aprendizaje por refuerzo de vanguardia a mayor escala sigue suspendido.
¿Había quien predijo que Astra se lanzaría esta semana? Parece que habrá más retrasos.
Altman salió expresamente a aclarar que este modelo aún se lanzará, pero afectará los lanzamientos de modelos posteriores.
Al respecto, algunos usuarios comentaron:
Comenzando a poner puertas al campo
Durante las dos semanas de pausa, OpenAI realizó una serie de refuerzos y modificaciones en su entorno de investigación, con el concepto central de aislamiento.
Primero, aislamiento de cargas de trabajo.
Todas las tareas que ejecutan código generado por modelos ahora deben ejecutarse en sandboxes más robustos, lo mismo aplica para el software que podría ser atacado al procesar la salida de los modelos.
En segundo lugar, aislamiento de red.
Se añadieron más barreras entre las cargas de trabajo de alto riesgo e Internet, siguiendo el principio de diseño de que "incluso si una sola tarea o servicio de soporte es comprometido, no podrá alcanzar la red externa".
Tercero, pruebas de seguridad continuas.
OpenAI reconfiguró su entorno de investigación, eliminó servicios compartidos que podrían tener vulnerabilidades, redujo permisos persistentes y utiliza sus propios modelos para simular ataques de forma continua y probar automáticamente los límites de seguridad.
OpenAI reconoce que estas mejoras de seguridad conllevan un enorme coste de ingeniería y retrasos en la investigación, pero aún así consideran que vale la pena.
¿Por qué tanta inquietud respecto al entorno interno de investigación?
OpenAI reveló algunos casos reales en otro artículo sobre modelos de ejecución prolongada.
Uno de sus modelos internos, capaz de trabajar de forma autónoma durante largos periodos, recibió la instrucción de publicar los resultados de una prueba de referencia de aceleración de NanoGPT únicamente en el Slack interno.
Sin embargo, el modelo pasó una hora buscando vulnerabilidades en el sandbox, logrando finalmente eludir las restricciones y enviar los resultados a un repositorio público de GitHub.
Modelos anteriores abandonaban al encontrar restricciones en el sandbox, pero la persistencia de este modelo le permitió encontrar y explotar debilidades en el entorno.
En otro escenario, el modelo, al descubrir que otros sistemas tenían envíos exitosos pero privados, intentó recuperar esas soluciones del backend de evaluación.
Cuando el primer intento fue bloqueado porque un escáner detectó un token de autenticación, el modelo dividió el token en dos fragmentos para ofuscarlo, luego los reensambló en tiempo de ejecución, de modo que el token completo nunca apareció como una cadena continua.
En su traza de razonamiento, el modelo escribió explícitamente que estaba tomando estos pasos para eludir el escáner.
En el monitoreo interno, OpenAI también descubrió que los modelos intentaban ejecutar comandos bloqueados codificándolos en base64, o enviando comandos a otra instancia del modelo para sortear restricciones, o usando alias para ejecutar operaciones de 'force push' prohibidas.
Sistema de monitoreo: consume el 20% de la capacidad de cómputo
Además del refuerzo de seguridad, OpenAI amplió significativamente la cobertura de su sistema de monitoreo de cadena de pensamiento.
Anteriormente, su monitoreo se centraba principalmente en el despliegue interno de modelos de vanguardia y en el entrenamiento de aprendizaje por refuerzo de vanguardia, ya que estas cargas de trabajo combinaban capacidades avanzadas del modelo con acceso a herramientas, sistemas sensibles y redes, pero no cubrían todas las ejecuciones de razonamiento y entrenamiento que utilizaban herramientas.
El nuevo sistema de monitoreo adopta una arquitectura de múltiples etapas.
Primero, los clasificadores de activación se ejecutan en cada token muestreado, detectando señales anómalas en la actividad interna del modelo; al detectar un problema potencial, se escala gradualmente a sistemas de investigación automatizada más complejos y con mayor demanda computacional.
Estos sistemas examinan las llamadas a herramientas, los procesos de razonamiento y las secuencias completas de actividad, buscando indicios de acceso no autorizado, robo de datos, comportamiento destructivo e intentos de derrotar las medidas de seguridad.
El objetivo de OpenAI es emitir una alerta en un plazo de 30 minutos después de que el sistema de monitoreo detecte actividad sospechosa. Si el sistema determina que puede haber una violación crítica de los límites de seguridad, generará una alerta de máxima prioridad y los equipos de seguridad e investigación serán notificados inmediatamente.
Si no pueden confirmar que sea un falso positivo en 30 minutos, la actividad relacionada será suspendida.
El coste de este sistema de monitoreo no es pequeño; OpenAI estima que la sobrecarga del monitoreo representa aproximadamente el 20% de la capacidad de cómputo de razonamiento monitoreado, variando la proporción según las cargas de trabajo de entrenamiento y evaluación.
Tras confirmar el 7 de agosto que Astra podría tener capacidades críticas en red, los requisitos de monitoreo se ampliaron de "solo entrenamiento y evaluación de RL" a "todo el razonamiento de Astra que utilice herramientas".
¿Qué hacer a partir de ahora?
Durante la pausa, OpenAI no estuvo inactivo; la investigación en alineación avanzó en paralelo.
Incorporaron técnicas de alineación central en más fases del entrenamiento: mejoraron los modelos de recompensa para detectar mejor comportamientos inseguros, entrenaron a los modelos para ser más honestos sobre sus propias capacidades y limitaciones, y redujeron la tendencia de los modelos a explotar vulnerabilidades en el mecanismo de recompensas.
OpenAI prevé que la IA asumirá pronto la mayor parte del trabajo de seguridad, incluyendo defender contra ataques de otros modelos. Es decir, usar IA para vigilar a la IA, haciendo que las capacidades de seguridad avancen al mismo ritmo que las capacidades del modelo.
A más largo plazo, planean actualizar el monitoreo del actual "análisis asíncrono a posteriori" a un "bloqueo síncrono a priori", deteniendo operaciones de alto riesgo antes de que se ejecuten, en lugar de rastrearlas después.
Al final del artículo, OpenAI deja una frase: "Las capacidades de los modelos de vanguardia se están acelerando rápidamente. Nuestra capacidad para comprenderlos, alinearlos y protegerlos debe mantenerse a la vanguardia."
En pocas palabras: lo que estamos entrenando empieza a ponernos nerviosos a nosotros mismos, pero vamos a seguir entrenando.
Enlace de referencia: [1]https://openai.com/index/pacing-model-development-cyber-capabilities/
Este artículo proviene del cuenta pública de WeChat "Quantum Bit", autor: Centrado en Tecnología de Vanguardia
