7 min leer
Tu agente de IA pierde un 39% de precisión en conversaciones reales. El artículo destacado de ICLR 2026 explica por qué.

By submitting, you consent to our use of your data. Privacy Policy.
Categoría
El mundo de la IA
Compartir artículo
Todos los principales benchmarks de LLM realizan las pruebas de la misma manera: un prompt de entrada, una respuesta de salida. Limpio, controlado y totalmente especificado. El problema es que prácticamente ninguna aplicación de IA en el mundo real funciona así. Los agentes de IA empresariales ejecutan conversaciones multiturno. Recopilan requisitos a lo largo de los mensajes, llaman a herramientas, procesan resultados intermedios y sintetizan la información que se revela paso a paso a lo largo de docenas de turnos.
El destacado artículo científico de ICLR 2026, LLMs Get Lost In Multi-Turn Conversation, analizó qué sucede cuando se evalúan los LLM de la forma en que los agentes los utilizan realmente. La respuesta: una caída media del 39% en la precisión en todos los modelos probados.
El experimento
Los investigadores Philippe Laban, Hiroaki Hayashi, Yingbo Zhou y Jennifer Neville desarrollaron un framework para convertir los benchmarks estándar de un solo turno en conversaciones multiturno. Tomaron instrucciones totalmente especificadas, las dividieron en fragmentos atómicos de información llamados "shards" y utilizaron un simulador basado en LLM para revelar un fragmento por turno en un flujo conversacional natural.
La escala fue considerable: más de 200.000 conversaciones simuladas en 15 modelos de ocho proveedores, incluidos GPT-4.1, Claude 3.7 Sonnet, Gemini 2.5 Pro, DeepSeek-R1 y Llama 4-Scout. Seis tipos de tareas cubrieron programación, consultas SQL, llamada a funciones, matemáticas, generación de datos a texto y resumen de múltiples documentos.
Los resultados fueron consistentes. GPT-4.1 cayó del 91,7% al 70,7%. Claude 3.7 Sonnet bajó del 85,4% al 70,0%. Gemini 2.5 Pro pasó del 90,2% al 64,3%. Los modelos más grandes y capaces no mostraron ninguna ventaja significativa a la hora de resistir la degradación. La caída fue estructural, no una brecha de capacidad.
Un experimento de control crítico descartó la explicación obvia. Cuando la misma información se concatenaba en un solo mensaje en lugar de dividirse en varios turnos, el rendimiento se recuperaba hasta el 95% del valor de referencia de un solo turno. La información en sí no era el problema. El patrón de interacción multiturno sí lo era.

El colapso de la fiabilidad es peor que la caída de la precisión
La cifra principal no refleja la verdadera gravedad del problema. Los investigadores desglosaron el rendimiento en dos componentes: aptitud (la eficacia media del modelo) y fiabilidad (la consistencia de dicho rendimiento).
La aptitud disminuyó un 16%. La fiabilidad se desplomó un 112%.
Esta distinción es de vital importancia para cualquiera que gestione agentes de IA en producción. Las conversaciones multiturno no solo hacen que los modelos sean ligeramente peores de media, sino que los vuelven extremadamente inconsistentes. El mismo agente que realiza la misma tarea puede lograr un éxito brillante una vez y fallar por completo la siguiente. La diferencia de rendimiento entre el percentil 90 y el 10 fue de media de unos 50 puntos porcentuales en entornos multiturno.
Para despliegues empresariales donde la previsibilidad importa más que el rendimiento máximo, este es el hallazgo más peligroso.
Cuatro formas en que los LLM fallan en la conversación
El artículo identificó cuatro modos de fallo distintos, cada uno con implicaciones directas para el comportamiento de los agentes en producción.
1. Intentos de respuesta prematuros. Los modelos generan respuestas completas en el primer 20% de una conversación cuando disponen de información mínima. Precisión de los intentos prematuros: 30,9%, en comparación con el 64,4% cuando los modelos esperaban a tener más contexto. En los flujos de trabajo de los agentes, esto se traduce en que el sistema toma decisiones antes de recopilar suficiente información y luego construye con total seguridad sobre suposiciones erróneas.
2. Redundancia en las respuestas. La longitud de las respuestas se dispara a lo largo de los turnos. Las salidas de código pasaron de unos 700 a 1.400 caracteres. Los modelos añaden información a sus respuestas anteriores (a menudo incorrectas) en lugar de empezar de cero. Las respuestas más cortas superaron a las más largas en un 10-50% en cinco de las seis tareas. En el caso de los agentes, los resultados se degradan a medida que avanza la conversación, ya que el modelo acumula correcciones sobre errores en lugar de replantearse la tarea desde el principio.
3. Efecto de "pérdida en el medio" (Lost-in-middle). Los modelos prestan una atención desproporcionada a la información de los primeros y últimos turnos. Las referencias a los turnos intermedios cayeron por debajo del 20%. Para los agentes que recopilan requisitos, llaman a API y procesan resultados a lo largo de muchos pasos, el contexto crítico revelado en la mitad de un flujo de trabajo queda efectivamente ignorado.
4. Errores acumulativos sin recuperación. Una vez que un modelo se compromete con una suposición incorrecta al principio de una conversación, no se autocorrige. Los investigadores lo describen con claridad: "Cuando las LLM toman un camino equivocado en una conversación, se pierden y no se recuperan". Un paso erróneo al principio de un flujo de trabajo multipaso se acumula en cada paso posterior, y el agente no alertará de que algo ha fallado.
Este último modo de fallo se corresponde directamente con lo que los equipos de producción denominan fallo silencioso: un agente genera una respuesta segura, bien formateada y completamente errónea que supera una revisión superficial.
Por qué los benchmarks confunden a los compradores de agentes
El artículo científico de ICLR cuantifica una brecha que los compradores de IA empresarial han percibido pero que les ha costado articular. Un LLM obtiene una puntuación del 92% en HumanEval. Ese mismo modelo, realizando la misma tarea de programación en una conversación multiturno donde los requisitos llegan de forma incremental (la forma en que interactúa un usuario o sistema real), cae hasta la franja baja del 70%.
Los benchmarks de un solo turno evalúan un escenario que casi nunca ocurre en producción. Los agentes de nivel empresarial gestionan la ambigüedad, recopilan información a lo largo de los turnos, llaman a herramientas externas y sintetizan resultados parciales. Cada interacción añade turnos. Cada turno añade riesgo.
Por esta razón, la selección de modelos basada únicamente en las tablas de clasificación de benchmarks fracasa. El modelo que lidera un ranking de un solo turno no es necesariamente el que mejor rinde en un flujo de trabajo de agente de 15 turnos. La evaluación debe coincidir con las condiciones de despliegue, y para la mayoría de los casos de uso empresarial, el despliegue es multiturno.
Qué hacer al respecto
El estudio analizó dos estrategias de mitigación. Un enfoque de "recapitulación", donde el modelo resume toda la información acumulada antes de generar una respuesta final, mejoró el rendimiento de GPT-4o-mini del 50,4% al 66,5%. Un enfoque en "bola de nieve" con recapitulación a nivel de turno mostró mejoras más modestas. Ninguno de los dos cerró por completo la brecha con respecto al rendimiento de un solo turno.
Para los equipos que desarrollan agentes, de estos hallazgos se derivan varias decisiones de arquitectura.
Consolidación del contexto previo a la generación. En lugar de confiar en el historial de conversación bruto, comprima y resuma el contexto en puntos de control antes de solicitar al modelo que genere resultados. Esto aborda directamente el problema de la pérdida en el medio y reduce la superficie propensa a errores acumulativos.
Enrutamiento multimodelo según las características de la tarea. Algunas tareas son más vulnerables a la degradación multiturno que otras. El estudio determinó que las tareas de traducción, que pueden realizarse frase por frase, mostraron una degradación nula. Las tareas que requerían la fusión de información entre turnos se degradaron significativamente. Enrutar subtareas a diferentes modelos en función de su resiliencia multiturno produce resultados más fiables que elegir un único modelo para todo.
Evaluación en entornos multiturno. Si su agente ejecuta flujos de trabajo multiturno, su batería de pruebas debe evaluar flujos de trabajo multiturno. La precisión en un solo turno no es un indicador fiable del rendimiento en producción.
Creación de mecanismos de recuperación. Dado que los modelos no se autocorrigen cuando se desvían de su trayectoria, los agentes necesitan aplicar sistemas externos de puntos de control, puertas de validación y bucles de retroalimentación de autoaprendizaje, en lugar de confiar en que el modelo detecte sus propios errores.
La brecha entre el entrenamiento y el despliegue
El comité de ICLR seleccionó este artículo porque aborda lo que denominaron una "brecha disonante" entre cómo se entrenan los LLM y cómo se despliegan. Los datos de entrenamiento son predominantemente de un solo turno. El uso en producción es predominantemente multiturno. La brecha entre estos dos escenarios se traduce en una caída del 39% en la precisión y un colapso del 112% en la fiabilidad.
Para las organizaciones que evalúan agentes de IA, la implicación es directa: el rendimiento en los benchmarks indica lo que un modelo puede hacer en condiciones ideales. La evaluación multiturno indica lo que realmente hará en las suyas.





