Predecir el comportamiento de modelos antes del lanzamiento simulando el despliegue
Usar contextos de conversación realistas para estimar mejor el comportamiento indeseado de modelos antes del lanzamiento.
Antes de lanzar un nuevo modelo, los laboratorios deben entender no solo lo que puede hacer, sino cómo es probable que se comporte en el uso real, incluido dónde podría introducir nuevos riesgos. Esto se vuelve aún más importante a medida que aumentan las capacidades. Como parte de nuestra revisión de seguridad previa al despliegue, aprovechamos evaluaciones dirigidas, red teaming y otras comprobaciones para entender el comportamiento del modelo. Ahora empezamos a usar un método para simular despliegues de modelos antes de que ocurran, lo que agrega una señal complementaria: una vista previa similar al despliegue de cómo podría comportarse un modelo candidato antes de llegar a los usuarios.
La Simulación de despliegue es un método para simular un despliegue futuro antes de que ocurra. Lo hacemos reproduciendo conversaciones anteriores de manera que preserve la privacidad con un nuevo modelo candidato. Esto nos permite estudiar cómo responde el nuevo modelo en contextos realistas antes del lanzamiento, incluido si surgen nuevas conductas indeseadas y con qué frecuencia podrían aparecer.
En múltiples despliegues Thinking de la serie GPT‑5, la Simulación de despliegue mejoró nuestras estimaciones de las tasas de conductas indeseadas del modelo, ayudó a sacar a la luz nuevas formas de desalineación antes del lanzamiento y ayudó a reducir el riesgo de que los modelos pudieran darse cuenta de que estaban siendo evaluados. También aplicamos el método a lanzamientos con agentes desafiantes, mostrando que puede extenderse más allá del chat estándar a configuraciones de agentes más complejas que implican el uso de herramientas, y que también puede usarse para evaluar riesgos antes de despliegues internos de modelos.
Ya hemos usado conocimientos de la Simulación de despliegue durante el desarrollo de modelos para identificar puntos ciegos en las evaluaciones tradicionales e informar mitigaciones y decisiones de despliegue. A medida que facilitemos la ejecución del pipeline, esperamos que desempeñe un papel más importante en el futuro proceso de desarrollo de modelos.
Las evaluaciones previas al despliegue usadas en toda la industria suelen consistir en una mezcla de prompts sintéticos, escritos manualmente o de producción, seleccionados intencionalmente por ser difíciles, de alta gravedad o adversarios. Estas evaluaciones han tenido generalmente dos objetivos entrelazados: evaluar cómo responde el modelo cuando se lo somete a pruebas de estrés en situaciones con una probabilidad muy pequeña de ocurrir en el tráfico de despliegue, y obtener una comprensión general de las conductas indeseadas del modelo, incluido encontrar nuevas conductas indeseadas y predecir sus frecuencias durante el despliegue.
Si bien las evaluaciones tradicionales siguen siendo cruciales para el primer objetivo, la Simulación de despliegue representa un avance significativo respecto del segundo objetivo para riesgos que no son de cola (en nuestros experimentos, no puede esperarse que nuestro enfoque mida conductas que ocurren con una frecuencia menor que 1 en 200 000 mensajes). La fortaleza de la Simulación de despliegue proviene de evitar algunos desafíos centrales de las evaluaciones tradicionales:
- Cobertura: es difícil tener confianza en que los prompts de evaluación cubrirán todos los tipos posibles de conducta indeseada del modelo. Medir nuevos tipos de conducta indeseada requiere crear nuevas evaluaciones y saber qué daños medir. Esto puede requerir mucho tiempo y trabajo, y las evaluaciones pueden saturarse con el tiempo.
- Sesgos de selección: las evaluaciones tradicionales suelen construirse pensando en conductas indeseadas específicas del modelo, seleccionadas de maneras que sesgan hacia contextos que ocurrieron previamente. Esto puede hacer que sus estimaciones sean menos informativas sobre la incidencia de tales conductas en toda la amplitud de la distribución de despliegue.
- Ser reconocibles como pruebas por los modelos: los modelos han sido cada vez más capaces de determinar que están siendo evaluados, lo que puede distorsionar su comportamiento y nuestras mediciones posteriores de su seguridad. Si bien muchas de las evaluaciones tradicionales que usamos en OpenAI también se extraen del tráfico de producción y no sufren este problema, esta es una preocupación común para muchas evaluaciones tradicionales usadas en toda la industria.
La técnica principal detrás de la Simulación de despliegue es sencilla: tomamos conversaciones recientes del despliegue, eliminamos la respuesta original del asistente del modelo anterior y la regeneramos con un modelo candidato por lanzar. Evaluamos las completaciones buscando nuevos modos de falla, y estimamos la frecuencia de conductas indeseadas durante el despliegue según su frecuencia en esta distribución similar al despliegue. Podemos realizar las mismas mediciones después del lanzamiento en tráfico de despliegue real, lo que nos permite validar nuestros pronósticos previos al despliegue.
La Simulación de despliegue mitiga significativamente las tres limitaciones mencionadas: el sesgo de muestreo se aborda usando una distribución de prompts de evaluación representativa del uso reciente. La Simulación de despliegue con prompts representativos también puede mitigar preocupaciones sobre la cobertura: obtenemos mayor cobertura de conductas indeseables del modelo simplemente simulando más tráfico. Esta compensación entre cómputo y cobertura es importante, porque hace que la calidad de este eje de evaluación de riesgos escale con el cómputo, en lugar de con el esfuerzo manual requerido para crear más evaluaciones. Los modelos tampoco parecen poder distinguir entre conversaciones obtenidas mediante simulación de despliegue y tráfico de despliegue real.
Figura 1: resumen de nuestro pipeline de Simulación de despliegue
Área | Evaluaciones tradicionales | Simulación de despliegue |
Cobertura | Mejor para riesgos de baja prevalencia pero alta gravedad para los que queremos asegurarnos de tener cobertura | Mejor para entender el espectro de riesgos que probablemente veremos en el tráfico de despliegue |
Representatividad / sesgo | Enfocadas en evaluar riesgos pasados o previstos específicos, incluso para conductas con prevalencia extremadamente baja en el despliegue | Representativa de riesgos que ocurren por encima de cierta prevalencia en el tráfico de despliegue actual |
Conciencia de evaluación | Señales de prueba potencialmente obvias (por ejemplo, con datos sintéticos), a menos que las evaluaciones se creen con datos de despliegue | El contexto similar al despliegue parece mitigar significativamente la conciencia de evaluación |
Esfuerzo | Las distribuciones de prompts y configuraciones personalizadas requieren mucho más esfuerzo manual | Requiere un costo de infraestructura único y luego reutiliza prefijos del despliegue y calificadores de conductas indeseadas conocidas |
Comparación de alto nivel entre evaluaciones tradicionales y Simulación de despliegue
Para evaluar la Simulación de despliegue, preinscribimos predicciones sobre la frecuencia durante el despliegue de 20 tipos de conducta indeseable para GPT‑5.4 Thinking. También realizamos estudios retrospectivos en otros despliegues de modelos Thinking de la serie GPT‑5. Las conductas de modelos que analizamos abarcan tanto desalineación como categorías de contenido no permitido que hemos reportado en tarjetas del sistema (por ejemplo, que el modelo mienta sobre herramientas o genere contenido sexual no permitido). Si bien para estos resultados solo damos seguimiento a 20 categorías de conducta indeseada del modelo y solo buscamos conductas desalineadas nuevas, la Simulación de despliegue es una técnica general que podría aplicarse para simular cualquier propiedad del modelo durante el despliegue.
El tráfico de producción que aprovechamos también provenía de modelos Thinking de la serie GPT‑5. Antes de ejecutar nuestras evaluaciones, eliminamos automáticamente los identificadores vinculados a cuentas y la información identificable. De acuerdo con nuestra Política de privacidad, solo analizamos tráfico de ChatGPT de usuarios que permiten que sus datos se usen para mejorar modelos. Reportamos únicamente hallazgos agregados de estas evaluaciones. En total, analizamos aproximadamente 1,3 millones de conversaciones desidentificadas en despliegues desde GPT‑5 Thinking hasta GPT‑5.4, que abarcan de agosto de 2025 a marzo de 2026.
Evaluamos la calidad de la evaluación de riesgos previa al despliegue producida por la Simulación de despliegue de tres maneras principales:
- Cobertura de taxonomía: ¿la auditoría posterior al lanzamiento sacó a la luz conductas desalineadas importantes que faltaban en nuestra taxonomía inicial de malas conductas?
- Precisión direccional: ¿la simulación predijo correctamente si la prevalencia en el despliegue aumentaría o disminuiría para conductas conocidas?
- Calibración de tasas: ¿nuestras estimaciones previas al despliegue estuvieron cerca de las tasas que observamos más tarde en el despliegue? Lograr una buena calibración de tasas requiere más que precisión direccional, lo que hace de este el estándar de calidad más alto posible.
También medimos hasta qué punto los modelos pueden darse cuenta de que están en una evaluación durante la Simulación de despliegue, y probamos qué tan robusto es el método ante distintas formas de tráfico de despliegue y configuraciones desafiantes de uso de herramientas.
En despliegues Thinking de la serie GPT‑5, la Simulación de despliegue superó a las líneas base de prompts desafiantes para determinar la tasa real de riesgo, pudo sacar a la luz el hackeo de calculadora antes del lanzamiento y pareció potencialmente indistinguible del despliegue para el modelo.
Resumen de nuestras predicciones. Para ver una visualización de todas las predicciones de despliegues de modelos Thinking de la serie GPT‑5, consulta la Figura 2. Las predicciones para GPT‑5.4 Thinking se preinscribieron, mientras que las demás fueron predicciones retroactivas. En conjunto, nuestras predicciones tuvieron un error multiplicativo mediano de 1,5× (por ejemplo, si la tasa de conducta indeseable es de 10 en 100 000, esto correspondería a estimar una tasa de 15 o 6,67 en 100 000). Si bien los errores de cola de nuestro método pueden ser aproximadamente 10× mayores, esperamos que puedan reducirse significativamente con más mejoras en nuestro pipeline de simulación, como se analiza a continuación.
Figura 2. Predicciones de frecuencia de la Simulación de despliegue sobre conductas indeseables durante el despliegue basadas en datos de despliegues previos. La notación 5.1 → 5 indica que estamos remuestreando prefijos de GPT‑5 con GPT‑5.1, es decir, simulando el despliegue de GPT‑5.1 a partir de datos de GPT‑5. La tasa más alta de conducta desalineada fue el “hackeo de calculadora” en GPT‑5.1, que ya hemos discutido anteriormente(se abre en una nueva ventana).
Comparar las predicciones de la Simulación de despliegue con líneas base. Las categorías más importantes de estimar correctamente para las evaluaciones de riesgos previas al despliegue son aquellas que tienen grandes cambios de incidencia después del despliegue del modelo (por ejemplo, >= 1,5×). En este subconjunto, la Simulación de despliegue es sustancialmente mejor que las líneas base tanto para predecir si cierta conducta indeseable aumentará o disminuirá en prevalencia con el despliegue de un modelo (Figura 3, izquierda) como para estimar su incidencia exacta durante el despliegue (Figura 3, derecha). Usamos dos líneas base principales: una línea base de Prompts desafiantes que usamos actualmente para tarjetas del sistema y decisiones de lanzamiento, y una línea base ingenua que usa las tasas del despliegue anterior como estimaciones para el nuevo modelo.
Figura 3. La Simulación de despliegue predice tanto la dirección de los cambios de incidencia (izquierda) como las tasas exactas de producción (derecha) mejor que las evaluaciones estáticas.
Fuentes de error de simulación en nuestro pipeline. También estudiamos las fuentes actuales de error en nuestro pipeline. En concreto, los errores de cola grandes hacen que el pipeline sea menos confiable para decisiones de despliegue: por ejemplo, al ver un gran aumento previsto en una conducta indeseable de cierto tipo, si se sabe que el pipeline tiene errores grandes aunque sean ocasionales, surge la duda de si se trata de una estimación confiable o de un artefacto del pipeline. Hay dos fuentes principales de posible error:
- Error de fidelidad del entorno de remuestreo: para estimar con precisión las tasas de producción, nuestro pipeline de simulación debe ser lo más realista posible. Esto es en parte un problema de ingeniería (muestrear del modelo usando los mismos pipelines que se usan para el tráfico de producción) y en parte un desafío interesante para herramientas que necesitan acceso de lectura/escritura a recursos externos que cambian constantemente (por ejemplo, búsquedas web o interacción con archivos locales). Podemos aislar el error de fidelidad de la simulación comparando predicciones de un despliegue real y su simulación (es decir, simulando el despliegue del modelo ya desplegado).
- Error de desplazamiento de la distribución de prompts: una preocupación importante con la Simulación de despliegue es que el despliegue de cualquier modelo causará un desplazamiento distribucional en las entradas, especialmente si los usuarios se adaptan a nuevas posibilidades del modelo. Aislamos el error de distribución de prompts comparando estimaciones al simular el despliegue usando prompts recientes frente a prompts del despliegue realizado.
Como se ve en la Figura 4, encontramos que una gran fracción del error en nuestro pipeline —especialmente para errores de cola— se debe actualmente a la fidelidad de la simulación. Esta es una buena noticia, ya que esperamos que la fidelidad de la simulación sea por lo general más fácil de mejorar que reducir el desplazamiento de la distribución de prompts. También encontramos que el error de desplazamiento de la distribución de prompts puede reducirse usando los datos más recientes del despliegue anterior. Se puede encontrar más detalle en el artículo de investigación.
Figura 4: la fidelidad del entorno de remuestreo parece ser la mayor fuente de error en nuestras estimaciones, especialmente para los errores más extremos.
La auditoría automatizada encontró la única desalineación nueva introducida en estos despliegues. En la ventana de despliegue que estudiamos, nuestro pipeline de auditoría automatizada basado en despliegues simulados habría sacado a la luz el “hackeo de calculadora” antes del lanzamiento, que fue la única desalineación novedosa que identificamos en el tráfico de ChatGPT analizado. El hackeo de calculadora es una forma de manipulación de recompensas que implica que el modelo use una herramienta de navegador como calculadora mientras presenta la acción como una búsqueda. Esto no significa que la auditoría a gran escala vaya a detectar cada falla nueva, pero muestra por qué importan los contextos realistas: pueden provocar conductas que conjuntos de evaluaciones más estrechos quizá nunca saquen a la luz directamente, incluso si no estaban presentes en el tráfico original usado para sembrar la simulación.
Otra ventaja de usar contextos similares al despliegue es que pueden reducir distorsiones que surgen cuando los modelos reconocen que están siendo evaluados. En investigaciones previas, tanto nosotros como otros(se abre en una nueva ventana) hemos encontrado que los modelos a menudo son conscientes de cuándo están siendo evaluados. Por ejemplo, los modelos pueden razonar en su cadena de pensamiento sobre qué se les está evaluando, qué podría agradarle a un evaluador y —si se están portando mal— si los atraparán. Esto plantea un problema para las evaluaciones de alineación: si un modelo solo se comporta bien porque cree que está siendo evaluado, ¿cómo generamos confianza en que se comportará de forma segura una vez que sepa que fue desplegado?
Mostramos que la Simulación de despliegue reduce sustancialmente los niveles de conciencia de evaluación exhibidos por los modelos en comparación con evaluaciones tradicionales que no se basan en datos de despliegue reales. Medimos la conciencia de evaluación de tres maneras: pidiendo a un modelo que clasifique si una trayectoria provino de producción o de una evaluación, monitoreando la cadena de pensamiento en busca de afirmaciones explícitas sobre estar siendo evaluado por alineación, así como de metajuego(se abre en una nueva ventana): cualquier razonamiento sobre supervisión. El tráfico de despliegue simulado coincidió estrechamente con el tráfico de despliegue real en las tres medidas. Por ejemplo, GPT‑5.2 etiquetó el tráfico de producción real como similar a evaluación el 5,4 % de las veces y el tráfico simulado el 5,1 % de las veces, mientras que las evaluaciones tradicionales (como SWE-Bench o MonorepoBench, que se componen principalmente de ejemplos sintéticos) se clasificaron como evaluaciones casi el 100 % de las veces.
Figura 5. Comparación de conciencia de evaluación: el tráfico de producción real y el tráfico simulado muestran tasas similares de detección de evaluación, conciencia verbalizada de evaluación de alineación y metajuego, mientras que los conjuntos de datos de evaluaciones tradicionales reportan tasas mucho más altas.
Para probar si el método podía extenderse más allá de los modos de chat estándar, también estudiamos la simulación de despliegues para configuraciones desafiantes de codificación con agentes. En concreto, usamos 120 000 trayectorias internas de empleados con agentes de GPT‑5.4 para simular el despliegue interno de agentes de codificación basados en GPT‑5.5. Esto cumple dos propósitos: muestra cómo la simulación de despliegue también puede usarse para la evaluación de riesgos de despliegues internos, y demuestra que es posible lograr alta fidelidad de simulación incluso en configuraciones con agentes mediante una simulación cuidadosa de herramientas.
Arriba mencionamos que la fidelidad de la simulación es una de las principales fuentes de error en nuestro pipeline actual. Uno de los desafíos para hacer realistas las simulaciones de despliegue es que requiere que las herramientas actúen de manera realista, incluso cuando necesitan acceso de lectura/escritura a recursos externos que cambian constantemente (por ejemplo, búsquedas web o interacción con archivos locales).
Esto es especialmente desafiante para configuraciones como despliegues con agentes: una sola trayectoria de agente puede depender de cientos de llamadas a herramientas, el estado del repositorio, respuestas de red o fallas transitorias. Esto hace que remuestrear con acceso real a herramientas sea desafiante y potencialmente peligroso. En vista de esto, en lugar de aplicar llamadas a herramientas en sistemas activos, las simulamos con otro LLM. Mostramos que darle a este LLM capacidades adicionales es esencial para el realismo y, por lo tanto, para la calidad de la estimación.
Le damos al modelo simulador de herramientas el despliegue original del turno final, el repositorio del momento de la conversación, una base de datos de pares llamada/respuesta de herramientas y conectores de solo lectura. En una prueba en la que un discriminador intentó distinguir despliegues simulados de reales, el realismo mejoró de una tasa de victoria del 11,6 % a 49,5 %, cerca del nivel de azar del 50 %.
Figura 6: se puede hacer que el realismo del remuestreo sea casi indistinguible del muestreo real incluso en configuraciones con muchas herramientas cuando se simulan llamadas a herramientas con mayores capacidades.
Como evidencia adicional de fidelidad de simulación, al simular tráfico de pensamiento de GPT‑5.4 Codex con GPT‑5.4, las tasas de desalineación están, prácticamente, dentro de las barras de error. En cambio, en nuestras pruebas previas al despliegue, GPT‑5.5 estuvo más desalineado en la mayoría de las categorías.
Figura 7: con la simulación de herramientas, las tasas de conducta de conversaciones remuestreadas con GPT‑5.4 y el tráfico de producción real de GPT‑5.4 son bastante similares, lo que indica alta fidelidad del entorno de remuestreo. Consulta la tarjeta del sistema de GPT‑5.5(se abre en una nueva ventana) para más contexto sobre las categorías.
Estos resultados sugieren que la Simulación de despliegue puede extenderse a configuraciones complejas de agentes cuando el entorno de herramientas circundante se simula con suficiente fidelidad.
Una pregunta natural es si los auditores externos pueden obtener algunos de los mismos beneficios sin acceso a tráfico de producción privado. Probamos esto con 100 000 conversaciones de WildChat usadas como prefijos. WildChat fue menos preciso que los datos recientes de producción de OpenAI, pero aun así informativo: los datos recientes de producción tuvieron un error multiplicativo promedio menor que WildChat (1,75× frente a 2,44×), mientras que WildChat a menudo se mantuvo dentro de aproximadamente 3× de las tasas de producción e identificó el mejor modelo con tasas superiores al azar. Vemos las evaluaciones al estilo WildChat como un complemento prometedor de la Simulación de despliegue ejecutada por desarrolladores. Consulta esta publicación complementaria del blog de Alignment(se abre en una nueva ventana) para ver más resultados sobre este punto.
La Simulación de despliegue es un complemento, no un reemplazo, de las evaluaciones adversarias, el red teaming y el análisis dirigido de riesgos de cola. La detección de algunas conductas indeseadas del modelo depende de la monitorizabilidad de la cadena de pensamiento: si los modelos futuros razonan de forma menos legible, omiten pasos clave o aprenden a ocultar la intención, quizá no podamos detectar estas formas de conducta indeseable. Además, debido a que los datos de producción son privados, los desarrolladores actualmente tienen mejor acceso a contextos representativos que los auditores externos. Mejores conjuntos de datos públicos podrían reducir esa brecha.
La Simulación de despliegue es más útil para conductas que ocurren con suficiente frecuencia como para aparecer en los prefijos muestreados. Es poco probable que una falla que ocurre una vez en diez millones de conversaciones se descubra en una ejecución con un millón de muestras, por lo que las evaluaciones adversarias, el red teaming y el análisis dirigido de riesgos de cola siguen siendo necesarios. Actualmente nos enfocamos en simular una sola respuesta del asistente, ya que en experimentos preliminares no encontramos mejoras significativas en nuestras estimaciones al simular múltiples turnos. Esta puede ser un área importante para mejorar la fidelidad de la simulación en el futuro.
El método también depende de la distribución de prefijos: la mezcla de conversaciones que se están remuestreando. El tráfico histórico puede no coincidir con la forma en que los usuarios interactúan con un modelo más capaz después de un cambio importante de producto, el lanzamiento de una nueva herramienta, un evento mundial o un cambio estacional. El análisis del artículo completo sugiere que este problema puede mitigarse usando los datos disponibles más recientes.
La simulación de despliegue es un nuevo enfoque para la evaluación de riesgos previa al despliegue que ayuda a laboratorios de frontera y evaluadores a predecir cómo pueden comportarse los modelos de lenguaje en el mundo real y entender los riesgos que plantean antes del despliegue. Complementa las evaluaciones de seguridad, el red teaming y el análisis dirigido existentes al agregar una capa de predicción más similar a la producción que puede mejorar las estimaciones del comportamiento en despliegue, reducir los efectos de conciencia de evaluación y hacer que las predicciones previas al despliegue sean verificables después del lanzamiento. Usada junto con evaluaciones tradicionales, la Simulación de despliegue puede ayudar a que la evaluación de riesgos de modelos sea más realista, más cuantitativa y más útil para las decisiones de despliegue.


