Comportamiento impredecible en GPT-4o: qué son los 'goblins' y cómo afectan a tu agente de voz

Qué publicó OpenAI y por qué importa

El 29 de abril de 2026, OpenAI publicó "Where the goblins came from", un análisis técnico post-mortem sobre cómo ciertos comportamientos erráticos —respuestas con personalidad exagerada, tono inapropiado o salidas fuera de contexto— se introdujeron en versiones recientes de sus modelos, incluyendo GPT-4o. OpenAI los llama internamente goblin outputs: respuestas que técnicamente son coherentes pero que resultan extrañas, condescendientes o directamente fuera de registro para el caso de uso.

El documento no es un comunicado de relaciones públicas. Es una autopsia de ingeniería: explica la cadena causal desde los datos de fine-tuning hasta el RLHF (Reinforcement Learning from Human Feedback), y detalla qué señales de los evaluadores humanos amplificaron sin querer ciertos rasgos de personalidad en el modelo. El resultado fueron modelos que, bajo determinadas condiciones, respondían con un tono que los usuarios describían como «demasiado entusiasta», «condescendiente» o «fuera de lugar».

Qué cambia técnicamente

El problema documentado tiene tres raíces según OpenAI:

• Sesgo en la señal de recompensa: Los evaluadores humanos puntuaban más alto las respuestas con «personalidad» sin distinguir si esa personalidad era apropiada para el contexto. El modelo aprendió a ser expresivo, no a ser útil.
• Distribución de datos de entrenamiento: Ciertos corpus de conversación incluían patrones de respuesta que reforzaban el tono excesivo. Al mezclarlos con datos de instrucción, el comportamiento se generalizó a casos donde no correspondía.
• Falta de granularidad en el feedback por dominio: El pipeline de RLHF no diferenciaba entre un chatbot de entretenimiento y un agente de atención al cliente. La misma señal de recompensa se aplicaba a ambos.

OpenAI ha aplicado correcciones en varias dimensiones: ajuste de los criterios de evaluación humana, filtros de dominio en el pipeline de fine-tuning y nuevas rúbricas para distinguir «respuesta con personalidad adecuada» de «respuesta con personalidad amplificada». El resultado esperado es un modelo más calibrado al contexto, aunque el documento advierte que la corrección completa es iterativa y no instantánea.

Para cualquier empresa que use modelos de OpenAI en producción —especialmente en flujos de voz o atención al cliente— esto tiene una implicación directa: el comportamiento del modelo puede variar entre versiones del mismo modelo base, y esa variación puede ser suficiente para cambiar la percepción del usuario final sobre la calidad del servicio.

Cómo lo gestionamos en el módulo Voz Entrantes de phoneIA

El módulo Voz Entrantes de phoneIA.es utiliza Retell AI como capa de orquestación de voz, con LLMs subyacentes configurados mediante prompts de sistema específicos por cliente. Esto introduce una capa de aislamiento respecto al problema descrito por OpenAI, pero no elimina el riesgo por completo.

Hay tres palancas concretas que aplicamos para minimizar el impacto de los goblin outputs en agentes de voz desplegados para PYMEs:

• Prompt de sistema con restricciones de tono explícitas: En lugar de dejar que el modelo infiera el tono del contexto, definimos reglas de comportamiento negativas: «no uses exclamaciones», «no añadas comentarios sobre la pregunta del usuario», «responde solo lo que se te pregunta». Esto contrarresta directamente la tendencia a la personalidad amplificada.
• Temperatura baja en llamadas de calificación: Los flujos de captación de leads y agendamiento usan temperatura ≤ 0.3. Menos variabilidad implica menos superficie para que emerjan comportamientos no deseados.
• Monitorización de transcripciones con alertas de anomalía: Retell AI genera transcripciones en tiempo real que quedan registradas en el CRM de phoneIA. Cuando una llamada tiene una duración atípica o el usuario cuelga antes del punto de captura, se marca para revisión manual. Es un sistema de detección indirecto, pero efectivo para identificar llamadas donde el agente se comportó de forma inesperada.

Ejemplo práctico: clínica dental con agente de voz 24/7

Imagina una clínica dental en Madrid que usa el módulo Voz Entrantes para atender llamadas fuera de horario. El agente tiene un objetivo concreto: confirmar si el paciente quiere una cita de urgencia o una revisión rutinaria, capturar nombre y teléfono, y crear la ficha en el CRM.

Sin las restricciones de tono, un modelo con goblin outputs podría responder a «tengo un dolor de muelas» con algo como: «¡Vaya, eso suena muy incómodo! Entiendo perfectamente cómo te sientes, los dolores de muelas son terribles. ¡Vamos a solucionarlo juntos!». Técnicamente correcto, pero en el contexto de una llamada de urgencia médica a las 11 de la noche, ese tono resulta extraño y puede generar desconfianza.

Con el prompt configurado correctamente —tono neutro, respuestas cortas, sin comentarios valorativos— el agente responde: «Entendido. ¿Es una urgencia o prefieres una cita de revisión?». Directo, apropiado, funcional. La diferencia no está en el modelo base, está en cómo se le instruye.

La lección del post de OpenAI es que no puedes asumir que el modelo se comportará igual entre actualizaciones. Por eso, cada vez que Retell AI o el LLM subyacente actualiza su versión, en phoneIA realizamos una batería de llamadas de prueba con escenarios predefinidos antes de activar el cambio en producción para los clientes.

Conclusión: la estabilidad del agente es un activo, no un accidente

El análisis de OpenAI sobre los goblin outputs es valioso precisamente porque desmitifica algo que muchos usuarios de IA asumen: que el modelo «simplemente funciona». La realidad es que el comportamiento de un LLM es el resultado de decisiones de entrenamiento, algunas de las cuales generan efectos secundarios que solo se detectan en producción.

Para una PYME que usa un agente de voz como primer punto de contacto con sus clientes, un cambio de tono inesperado no es un problema técnico abstracto: es una llamada que no convierte, un lead que no se captura, un paciente que no agenda. La respuesta correcta no es esperar a que el vendor lo corrija, sino construir capas de control propias: prompts restrictivos, temperatura controlada y monitorización de transcripciones. Eso es exactamente lo que hace el módulo de phoneIA.es; ver el módulo Voz Entrantes.