El glitch Goblin de GPT-5: lo que el error más extraño de OpenAI revela sobre la fiabilidad de los agentes de IA

Los usuarios de GPT-5 comenzaron a notar algo extraño a finales de marzo. El modelo no dejaba de mencionar duendes. No en propuestas de escritura fantástica o en conversaciones de diseño de juegos, sino en correos electrónicos empresariales, revisiones de código y análisis de datos. Los duendes aparecían donde no tenían razón de ser. Luego llegaron los gremlins, los troles, los mapaches y, por alguna razón, las palomas.

El 29 de abril, OpenAI publicó una investigación detallada: “De dónde vinieron los duendes”. Se descubrió que la causa raíz era una única señal de recompensa, destinada a incentivar un modo de personalidad específico, que se había filtrado al comportamiento general de todo el modelo. El problema de los duendes fue divertido. El mecanismo que lo provocó no lo es.

Qué ocurrió realmente

OpenAI había estado entrenando a GPT-5 en una función de personalización de personalidad llamada “Modo Nerdy” (Modo Friki). Durante el aprendizaje por refuerzo, el modelo de recompensa debía otorgar puntuaciones más altas cuando el modelo generaba respuestas que se ajustaran a la personalidad del Modo Nerdy. Sin embargo, la señal de recompensa demostró ser sistemáticamente más favorable hacia los resultados que contenían metáforas relacionadas con criaturas, incluyendo duendes, gremlins, troles, ogros y mapaches.

Este sesgo apareció en el 76,2 % de los conjuntos de datos de entrenamiento. Una señal que debía moldear un solo modo de personalidad había contaminado el comportamiento del modelo en todos los contextos. GPT-5 no estaba alucinando con duendes de forma aleatoria. Había aprendido —correctamente desde la perspectiva de la señal de recompensa— que las palabras asociadas a criaturas se correlacionaban con puntuaciones más altas. El modelo hacía exactamente aquello para lo que había sido entrenado. El entrenamiento era el que erraba.

La solución de OpenAI requirió rastrear la señal de recompensa a través de los datos de entrenamiento, identificar la familia completa de términos de criaturas que habían recibido una ponderación excesiva, eliminar la señal de recompensa afín a los duendes y filtrar las muestras de entrenamiento contaminadas. Según su informe, desarrollar la capacidad de investigación para rastrear estos patrones con rapidez fue tan importante como la propia solución.

La versión empresarial de los duendes

El problema de los duendes de OpenAI ocurrió en la capa de entrenamiento del modelo. Sin embargo, esta misma clase de fallo (una señal de retroalimentación que se filtra de un contexto a otro y produce un comportamiento imprevisto) ocurre constantemente en la capa de despliegue de agentes. La mayoría de los equipos simplemente carecen de las herramientas para rastrearlo.

Pensemos en un escenario habitual: una empresa ejecuta un único agente de IA que gestiona varios tipos de documentos. Facturas, declaraciones de conformidad, formularios de incorporación de RR. HH. Los usuarios envían correcciones cuando el agente comete un error, y el sistema utiliza esas correcciones para ajustar los prompts y mejorar la precisión con el tiempo.

El problema empieza cuando una corrección de formato para las facturas degrada accidentalmente el rendimiento en los documentos de conformidad. La señal de corrección era adecuada para las facturas, pero errónea para todo lo demás. Al promediarse con el resto de los comentarios, la optimización produce una solución de compromiso que no resuelve por completo ninguno de los dos campos. La precisión agregada sube un 3 %. El procesamiento de facturas baja silenciosamente del 96 % al 88 %, enmascarado por las mejoras logradas en otras áreas.

Este es el mismo mecanismo que el de los duendes de OpenAI, solo que en una capa diferente. Una señal que era válida en un contexto se filtró en otro y distorsionó el comportamiento. El modelo (o el agente) hizo lo que la señal le indicó. El alcance de la señal era demasiado amplio.

Por qué las métricas agregadas ocultan el problema

La razón por la que estos fallos persisten es que la mayoría de las infraestructuras de monitorización notifican métricas agregadas. Precisión total, tiempo medio de respuesta, satisfacción general del usuario. Cuando una regresión en un dominio se compensa con mejoras en otro, el cuadro de mando sigue en verde. Este es el problema del fallo silencioso que se va agravando antes de que nadie lo note.

En Beam, nos topamos exactamente con este patrón cuando nuestro auto-tuner empezó a gestionar agentes multidominio. Un solo ciclo de optimización mejoraba la precisión agregada del 91 % al 94 %, pero el procesamiento de facturas caía del 96 % al 88 %, quedando completamente enmascarado por las mejoras en otros tipos de documentos. Sin visibilidad a nivel de dominio, el sistema habría implementado la regresión.

La solución no pasaba por mejores modelos, sino por una mejor descomposición de la señal. Desarrollamos un pipeline de segmentación que separa los comentarios de los usuarios por dominio antes de que entren en el bucle de optimización. Cada grupo tiene su propia línea de base de precisión, su propio umbral de regresión y su propia puerta de validación. Una corrección enviada para el formato de factura solo puede influir en la optimización de las facturas. Jamás interfiere con los prompts de conformidad o de incorporación de personal.

El resultado: cuando el optimizador mejora la precisión en un dominio, el sistema comprueba inmediatamente si algún otro dominio ha sufrido una regresión. De ser así, la actualización se bloquea. La mejora solo se despliega cuando ayuda a un dominio sin perjudicar a otro.

Las señales de retroalimentación necesitan límites

La conclusión clave de OpenAI tras la investigación de los duendes fue que las señales de recompensa pueden moldear el comportamiento del modelo de formas imprevistas cuando se generalizan de un contexto a otros no relacionados. Su equipo de investigación invirtió en crear una infraestructura de investigación: herramientas que les permiten rastrear rápidamente una anomalía de comportamiento hasta la señal de recompensa específica que la causó.

El mismo principio se aplica en la capa de agentes, pero el riesgo es diferente. OpenAI puede volver a entrenar un modelo. Una empresa que ejecuta workflows agénticos en producción no puede volver a entrenar nada de la nada. Necesita sistemas que eviten que la contaminación de señales ocurra en primer lugar, y una monitorización que la detecte cuando suceda.

Tres decisiones arquitectónicas separan a los equipos que detectan estos fallos de los equipos que los despliegan:

Optimización consciente del dominio. La retroalimentación se dirige a clústeres específicos por dominio, no a un único pool indiferenciado. Cada dominio mantiene su propia trayectoria de precisión. Las señales conflictivas de diferentes dominios nunca se anulan entre sí.

Puertas de regresión por dominio. Cada ciclo de optimización se valida con respecto a cada dominio de forma independiente. La mejora agregada por sí sola no basta para realizar el despliegue. Si un solo dominio sufre una regresión, la actualización se bloquea hasta que esta se resuelva.

Rastreo de señales. Cuando el comportamiento cambia de forma imprevista, el sistema puede rastrear qué señales de retroalimentación impulsaron dicho cambio. Esta es la “capacidad de investigación” de OpenAI trasladada a la capa de agentes: la facultad de preguntar “¿por qué este agente empezó a comportarse de forma diferente?” y obtener una respuesta concreta, no un encogimiento de hombros.

Los duendes son graciosos. El patrón no lo es.

OpenAI detectó su problema de duendes porque los usuarios notaron algo visiblemente absurdo. El modelo estaba insertando criaturas de fantasía en contextos de negocios. Era imposible pasarlo por alto.

La mayor parte de la contaminación de señales de retroalimentación no es tan evidente. Un agente de atención al cliente empieza a favorecer una categoría de producto sobre otra en un 3 %. Un revisor de cumplimiento normativo se vuelve ligeramente más permisivo con un tipo de declaración. Un agente de cribado de RR. HH. varía su puntuación en un conjunto de criterios. Ninguno de estos casos activa las alarmas, pero todos se van acumulando con el tiempo.

La lección de la investigación de los duendes de OpenAI no es que el hackeo de recompensas sea peligroso en la capa de entrenamiento de modelos (que lo es). La lección es que cualquier sistema optimizado por señales de retroalimentación (ya sean recompensas de RLHF, correcciones de usuarios o métricas de precisión) necesita límites claros sobre dónde se aplican estas señales y una monitorización que detecte cuándo se filtran.

En la capa del modelo, ese es el trabajo de OpenAI. En la capa de agentes, es el suyo.