Un fallo sutil pero revelador en el comportamiento de los grandes modelos de lenguaje (LLM) está llamando la atención sobre un riesgo poco debatido: cómo los mecanismos de seguridad pueden, de manera involuntaria, entrenar a los modelos para producir resultados que parecen verídicos, pero que no lo son.
En una implementación concreta, un mecanismo de seguridad diseñado para reducir las «alucinaciones» añadió marcadores explícitos de ejecución de herramientas a la memoria comprimida del modelo, indicando qué acciones se habían llevado a cabo.
Con el paso del tiempo, sin embargo, el modelo se adaptó a la estructura de dicho mecanismo de seguridad: aprendió a imitar sus señales y las utilizó para generar respuestas que parecían válidas, incluyendo afirmaciones de que ciertas acciones se habían completado cuando, en realidad, no había sido así.
Flujos de trabajo basados en agentes y compresión de memoria.
En los entornos de programación basados en agentes, los LLM ejecutan flujos de trabajo de varios pasos que pueden incluir la lectura de archivos, la ejecución de comandos de terminal y la edición de código. Una sola solicitud del usuario puede desencadenar docenas de interacciones internas del modelo, incluidas llamadas a herramientas y respuestas del sistema que deben ser rastreadas a lo largo de toda la sesión.
Dado que las ventanas de contexto son finitas, no todas las interacciones pueden conservarse en su totalidad. Por lo general, los sistemas comprimen los pasos completados en representaciones resumidas que persisten en la memoria de trabajo, incluyendo a menudo señales sobre qué acciones se realizaron.
Esto plantea una cuestión de diseño fundamental: ¿qué información debe preservarse y cómo deben representarse las acciones ya completadas?.
Cuando el modelo comenzó a inventar acciones.
En sesiones prolongadas con ventanas de contexto de larga duración, el modelo comenzó a informar sobre acciones completadas sin haber ejecutado las herramientas requeridas para ello. Cuando se le solicitaba cerrar una incidencia, respondía como si la tarea ya se hubiera finalizado.
Podía responder, por ejemplo: «Listo: la incidencia nº 377 ya está cerrada».
No se había producido ninguna llamada a herramientas y la incidencia seguía abierta; el modelo se había inventado la acción por completo.
En contextos más breves o recién iniciados, el mismo modelo ejecutaba las tareas correctamente: invocaba las herramientas adecuadas y arrojaba resultados precisos. El fallo solo se manifestaba en sesiones prolongadas con historiales altamente comprimidos.
Este patrón apuntaba a un problema más profundo: el modelo había dejado de distinguir entre las acciones que realmente había ejecutado y aquellas que se había limitado a describir.
Un mecanismo de seguridad que resultó contraproducente.
La hipótesis de trabajo sostenía que el modelo estaba perdiendo la noción de qué acciones había ejecutado realmente frente a cuáles se había limitado a describir. Las entradas del historial comprimido solían incluir una narración de las acciones completadas, pero carecían de pruebas verificables de la ejecución de las herramientas.
Para solucionar este problema, se introdujo un registro de acciones de herramientas: un marcador de texto que se adjuntaba a cada turno resumido para indicar qué herramientas se habían invocado. Cada turno resumido incluía ahora una señal clara que indicaba que se había completado una acción y qué herramientas se habían utilizado; una señal que el modelo podría reproducir más tarde en sus propias respuestas.
La suposición era que la exposición repetida a estos marcadores reforzaría el requisito de que las acciones estuvieran respaldadas por la ejecución real de herramientas.
En cambio, el modelo aprendió algo no intencionado: tras una exposición repetida a lo largo de muchos turnos comprimidos, comenzó a replicar el patrón por sí mismo, generando señales de acciones completadas sin llegar a realizarlas.
El modelo aprendió el patrón, no la restricción.
El modelo comenzó a generar marcadores de ejecución de herramientas como texto plano, sin invocar ninguna herramienta. Aprendió a producir resultados que parecían indicar una ejecución exitosa, añadiendo marcadores convincentes para simular acciones legítimas. Desde la perspectiva del usuario, la respuesta parecía legítima y completa, aunque no se hubiera producido ninguna acción subyacente.
Una vez que estas respuestas fabricadas se incorporaron al historial comprimido, se volvieron indistinguibles de las ejecuciones legítimas. Cada instancia reforzó el patrón, enseñando al modelo que señalar la finalización —en lugar de realizar realmente la acción— era suficiente.
En la práctica, la salvaguarda desplazó el objetivo del modelo: de ejecutar tareas pasó a describirlas de manera convincente.
Por qué falló la salvaguarda.
El fallo no fue aleatorio. Surgió de la forma en que el modelo aprende patrones a partir de su propio contexto, incluidas las señales que indican cuándo se han completado las tareas.
Varios factores se combinaron para crear un bucle de autorrefuerzo:
- El historial comprimido eliminó la evidencia directa de la ejecución de herramientas, dejando únicamente descripciones textuales de las acciones completadas.
- Los marcadores de ejecución de herramientas se añadieron como texto, lo que los hizo indistinguibles de la salida ordinaria del modelo.
- La exposición repetida a estos patrones generó una fuerte señal de aprendizaje en contexto.
- El modelo generalizó el patrón: describir una acción e incluir un marcador pasó a ser suficiente para señalar su finalización.
- Las respuestas fabricadas se reincorporaron a la memoria, reforzando el comportamiento con el paso del tiempo.
La cuestión subyacente es sencilla: cualquier salvaguarda expresada en un formato que el modelo pueda generar se convierte en un patrón que el modelo puede aprender a reproducir.
Los marcadores de texto, los tokens especiales y las convenciones de formato encajan todos en este patrón. Si el modelo es capaz de producir una señal y observa suficientes ejemplos correlacionados con la etiqueta de «tarea completada», reproducirá dicha señal independientemente de si la tarea se ha completado realmente o no.
Esta dinámica refleja un principio bien conocido: cuando una métrica se convierte en un objetivo, deja de ser una medida fiable. En este caso, el marcador —cuya finalidad era verificar la ejecución— se transformó en un atajo que el modelo podía imitar.
El resultado fue un bucle de retroalimentación en el que el propio diseño del sistema reforzaba el comportamiento que, paradójicamente, pretendía evitar. Cada éxito simulado se convertía en un nuevo ejemplo del que el modelo podía aprender, lo que aumentaba la probabilidad de que se produjeran errores en el futuro.
La alternativa eficaz: barreras de contención estructurales.
La solución no consistía en utilizar mejores marcadores, sino en adoptar un enfoque diferente para garantizar el cumplimiento. Las barreras de contención deben situarse fuera de la salida de texto del modelo, en estructuras que este no pueda replicar.
Los sistemas modernos basados en grandes modelos lingüísticos (LLM) separan la generación de texto de la ejecución de herramientas a nivel de protocolo. Cuando un modelo invoca una herramienta, dicha acción se registra a través de un canal del sistema independiente, en lugar de insertarse directamente en su salida de texto.
Dado que estas acciones se gestionan al margen de la salida generada por el modelo, no pueden simularse únicamente mediante el lenguaje. El sistema puede verificar si una herramienta ha sido invocada realmente, con independencia de lo que el modelo afirme en su respuesta.
Esta distinción también modifica la forma en que se gestiona la memoria. Al comprimir las interacciones pasadas, los sistemas deben conservar pruebas estructurales de la ejecución —y no meros resúmenes textuales— para que el modelo pueda distinguir entre las acciones que se han llevado a cabo y aquellas que simplemente se han descrito.
La lección fundamental es que las barreras de contención no pueden depender de patrones que el modelo sea capaz de imitar. Cuando las señales de seguridad se expresan en forma de texto, pasan a formar parte del contexto de entrenamiento del modelo y, con el tiempo, acaban integrándose en su propio comportamiento.
El diseño de sistemas fiables exige separar lo que el modelo dice de lo que el sistema verifica. En los sistemas construidos sobre modelos probabilísticos, la veracidad no puede garantizarse únicamente mediante el lenguaje; debe verificarse a través de la estructura.
