Por qué los modelos de lenguaje se pierden en la conversación

Un nuevo artículo de investigación de Microsoft Research y Salesforce encuentra que incluso los modelos de lenguaje más capaces (LLM) se descomponen cuando se les dan instrucciones de manera gradual en lugar de todas a la vez. Los autores encontraron que el rendimiento disminuye en un promedio de 39 por ciento en seis tareas cuando una instrucción se divide en varias partes:

Una conversación de un solo turno (izquierda) obtiene los mejores resultados, pero es antinatural para el usuario final. Una conversación de varios turnos (derecha) encuentra que incluso los modelos LLM más altamente clasificados y performantes pierden el impulso efectivo en una conversación. Fuente: https://arxiv.org/pdf/2505.06120

Más sorprendentemente, la confiabilidad de las respuestas se desploma, con modelos prestigiosos como ChatGPT-4.1 y Gemini 2.5 Pro oscilando entre respuestas casi perfectas y fracasos manifiestos, dependiendo de cómo se formula la misma tarea; además, la consistencia de la salida puede disminuir más de la mitad en el proceso.

Para explorar este comportamiento, el artículo introduce un método llamado sharding*, que divide las instrucciones completamente especificadas en fragmentos más pequeños y los libera uno a la vez en una conversación.

En términos básicos, esto es equivalente a dar una orden cohesiva y completa en un restaurante, dejando al mesero con nada que hacer sino reconocer la solicitud; o decidir abordar el asunto de manera colaborativa:

Dos versiones extremas de una conversación en un restaurante (no del nuevo artículo, solo para ilustración).

Para enfatizar, el ejemplo anterior quizás coloque al cliente en una luz negativa. Pero la idea central representada en la segunda columna es la de un intercambio transaccional que clarifica un conjunto de problemas, antes de abordar los problemas – aparentemente una forma racional y razonable de abordar una tarea.

Este montaje se refleja en el enfoque de sharding del nuevo trabajo, que divide las instrucciones convencionales de un solo turno en fragmentos más pequeños, diseñados para ser introducidos en momentos clave durante una interacción con un LLM, una estructura que refleja el estilo de exploración y diálogo visto en sistemas como ChatGPT o Google Gemini.

In fact, los investigadores observan lo que muchos de nosotros hemos encontrado de manera anecdótica – que la mejor manera de recuperar la conversación es iniciar una nueva conversación con el LLM.

‘Si una conversación con un LLM no condujo a los resultados esperados, iniciar una nueva conversación que repita la misma información puede generar resultados significativamente mejores que continuar una conversación en curso.

‘Esto se debe a que los LLM actuales pueden perderse en la conversación, y nuestros experimentos muestran que persistir en una conversación con el modelo es ineficaz. Además, dado que los LLM generan texto con aleatoriedad, una nueva conversación puede conducir a mejores resultados.’

Los autores reconocen que los sistemas agénticos como Autogen o LangChain pueden mejorar los resultados al actuar como capas interpretativas entre el usuario final y el LLM, comunicándose solo con el LLM cuando hayan recopilado suficientes respuestas sharding para coagular en una sola consulta cohesiva (que el usuario final no estará expuesto a).

Sin embargo, los autores sostienen que una capa de abstracción separada no debería ser necesaria, o debería estar construida directamente en el LLM de origen:

‘Se podría argumentar que las capacidades de varios turnos no son una característica necesaria de los LLM, ya que se puede externalizar al marco del agente. En otras palabras, ¿necesitamos un soporte nativo de varios turnos en los LLM cuando un marco de agente puede orquestar interacciones con los usuarios y aprovechar los LLM solo como operadores de un solo turno?…’

Pero después de probar la proposición a través de su serie de ejemplos, concluyen:

‘[Depender] de un marco de agente para procesar información puede ser limitante, y argumentamos que los LLM deben admitir de forma nativa la interacción de varios turnos’

Este interesante nuevo artículo se titula Los LLM se pierden en la conversación de varios turnos, y proviene de cuatro investigadores de MS Research y Salesforce,

Conversaciones fragmentadas

El nuevo método primero divide las instrucciones convencionales de un solo turno en fragmentos más pequeños, diseñados para ser introducidos en momentos clave durante una interacción con un LLM, una estructura que refleja el estilo de exploración y diálogo visto en sistemas como ChatGPT o Google Gemini.

Cada instrucción original es una sola instrucción autocontenida que entrega la tarea completa de una vez, combinando una pregunta de alto nivel, contexto de apoyo y cualquier condición relevante. La versión sharding la divide en varias partes más pequeñas, con cada fragmento agregando solo una pieza de información:

Instrucciones emparejadas que muestran (a) una instrucción completa entregada en un solo turno y (b) su versión sharding utilizada para simular una interacción multi-turno subespecificada. Semánticamente, cada versión entrega la misma carga de información.

El primer fragmento siempre introduce el objetivo principal de la tarea, mientras que el resto proporciona detalles clarificadores. Juntos, entregan el mismo contenido que la instrucción original, pero distribuido de manera natural a lo largo de varios turnos en la conversación.

Cada conversación simulada se desarrolla entre tres componentes: el asistente, el modelo bajo evaluación; el usuario, un agente simulado con acceso a la instrucción completa en forma sharding; y el sistema, que invigila y califica el intercambio.

La conversación comienza con el usuario revelando el primer fragmento y el asistente respondiendo libremente. El sistema luego clasifica esa respuesta en una de varias categorías, como una solicitud de aclaración o un intento de respuesta completa.

Si el modelo intenta responder, un componente separado extrae solo el span relevante para la evaluación, ignorando cualquier texto circundante. En cada nuevo turno, el usuario revela un fragmento adicional, lo que provoca otra respuesta. El intercambio continúa hasta que el modelo responde correctamente o no quedan fragmentos por revelar:

Diagrama de una simulación de conversación sharding, con el modelo evaluado resaltado en rojo.

Las primeras pruebas mostraron que los modelos a menudo preguntaban sobre información que no se había compartido aún, por lo que los autores abandonaron la idea de revelar fragmentos en un orden fijo. En su lugar, se utilizó un simulador para decidir qué fragmento revelar a continuación, en función de cómo se desarrollaba la conversación.

El simulador de usuario, implementado utilizando GPT-4o-mini, tenía acceso completo a la instrucción completa y al historial de la conversación, y se le encargó decidir, en cada turno, qué fragmento revelar a continuación, en función de cómo se desarrollaba el intercambio.

El simulador de usuario también reexpresó cada fragmento para mantener el flujo conversacional, sin alterar el significado. Esto permitió que la simulación reflejara el ‘dar y recibir’ del diálogo real, mientras se mantenía el control sobre la estructura de la tarea.

Antes de que comience la conversación, al asistente se le proporciona solo la información básica necesaria para completar la tarea, como un esquema de base de datos o una referencia de API. No se le dice que las instrucciones se dividirán, y no se le guía hacia una forma específica de manejar la conversación. Esto se hace a propósito: en el uso del mundo real, los modelos rara vez se les dice que una instrucción estará incompleta o se actualizará con el tiempo, y dejar fuera este contexto ayuda a que la simulación refleje cómo se comporta el modelo en un contexto más realista.

GPT-4o-mini también se utilizó para decidir cómo clasificar las respuestas del modelo y para extraer cualquier respuesta final de esas respuestas. Esto ayudó a que la simulación se mantuviera flexible, pero introdujo errores ocasionales: sin embargo, después de verificar varias conversaciones de cien a mano, los autores encontraron que menos del cinco por ciento tenían problemas, y menos del dos por ciento mostraban un cambio en el resultado debido a ellos, y consideraron que esta era una tasa de error baja dentro de los parámetros del proyecto.

Escenarios de simulación

Los autores utilizaron cinco tipos de simulación para probar el comportamiento del modelo en diferentes condiciones, cada uno una variación de cómo y cuándo se revelan partes de la instrucción.

En la configuración Completa, el modelo recibe la instrucción completa en un solo turno. Esto representa el formato de referencia estándar y sirve como la línea de base de rendimiento.

La configuración Sharding divide la instrucción en varias partes y las entrega una a la vez, simulando una conversación más realista y subespecificada. Esta es la configuración principal utilizada para probar cómo manejan los modelos la entrada de varios turnos.

En la configuración Concat, los fragmentos se vuelven a unir como una sola lista, conservando su redacción pero eliminando la estructura de turno por turno. Esto ayuda a aislar los efectos de la fragmentación conversacional de la reexpresión o la pérdida de contenido.

La configuración Resumen funciona como Sharding, pero agrega un turno final donde se restablecen todos los fragmentos anteriores antes de que el modelo dé una respuesta final. Esto prueba si un resumen de la instrucción puede ayudar a recuperar el contexto perdido.

Finalmente, Nieve de bola va más allá, repitiendo todos los fragmentos anteriores en cada turno, manteniendo la instrucción completa visible a medida que se desarrolla la conversación – y ofreciendo una prueba más indulgente de la capacidad de varios turnos.

Tipos de simulación basados en instrucciones sharding. Una instrucción completamente especificada se divide en partes más pequeñas, que luego se pueden utilizar para simular conversaciones de un solo turno (Completa, Concat) o de varios turnos (Sharding, Resumen, Nieve de bola), dependiendo de la velocidad a la que se revela la información.

Tareas y métricas

Se eligieron seis tareas de generación para cubrir tanto el dominio de programación como el de lenguaje natural: se tomaron instrucciones de generación de código de HumanEval y LiveCodeBench; se tomaron consultas de texto a SQL de Spider; se construyeron llamadas a API utilizando datos de la Tabla de clasificación de llamadas de funciones de Berkeley; se proporcionaron problemas matemáticos elementales de GSM8K; se basaron tareas de captioning de tablas en ToTTo; y se tomaron resúmenes de varios documentos de la base de datos Resumen de una pila de heno.

El rendimiento del modelo se midió utilizando tres métricas básicas: rendimiento promedio, aptitud y inestabilidad.

Rendimiento promedio capturó cómo se desempeñó el modelo en general en varios intentos; aptitud reflejó los mejores resultados que un modelo podía alcanzar, basándose en sus salidas con la mejor puntuación; y inestabilidad midió cuánto variaban esos resultados, con brechas más grandes entre los mejores y los peores resultados que indicaban un comportamiento menos estable.

Todas las puntuaciones se colocaron en una escala de 0 a 100 para garantizar la coherencia en todas las tareas, y las métricas se calcularon para cada instrucción – y luego se promediaron para proporcionar una visión general del rendimiento del modelo.

Seis tareas sharding utilizadas en los experimentos, que cubren tanto la generación de código como la generación de lenguaje natural. Cada tarea se muestra con una instrucción completamente especificada y su versión sharding. Entre 90 y 120 instrucciones se adaptaron de referencias establecidas para cada tarea.

Competidores y pruebas

En las simulaciones iniciales (con un costo estimado de $5000), 600 instrucciones que abarcaban seis tareas se dividieron en fragmentos y se utilizaron para simular tres tipos de conversación: completa, concat y sharding. Para cada combinación de modelo, instrucción y tipo de simulación, se ejecutaron diez conversaciones, produciendo más de 200.000 simulaciones en total – un esquema que hizo posible capturar tanto el rendimiento general como las medidas más profundas de aptitud y confiabilidad.

Se probaron quince modelos, que abarcaban una amplia gama de proveedores y arquitecturas: los modelos de OpenAI GPT-4o (versión 2024-11-20), GPT-4o-mini (2024-07-18), GPT-4.1 (2025-04-14), y el modelo de pensamiento o3 (2025-04-16).

Los modelos de Anthropic fueron Claude 3 Haiku (2024-03-07) y Claude 3.7 Sonnet (2025-02-19), accesados a través de Amazon Bedrock.

Google contribuyó con Gemini 2.5 Flash (vista previa-04-17) y Gemini 2.5 Pro (vista previa-03-25). Los modelos de Meta fueron Llama 3.1-8B-Instruct y Llama 3.3-70B-Instruct, así como Llama 4 Scout-17B-16E, a través de Together AI.

Las otras entradas fueron OLMo 2 13B, Phi-4, y Command-A, todos accesados localmente a través de Ollama o Cohere API; y Deepseek-R1, accesado a través de Amazon Bedrock.

Para los dos modelos de ‘pensamiento’ (o3 y R1), se aumentaron los límites de tokens a 10.000 para acomodar cadenas de razonamiento más largas:

Puntuaciones de rendimiento promedio para cada modelo en seis tareas: código, base de datos, acciones, datos a texto, matemáticas y resumen. Los resultados se muestran para tres tipos de simulación: completa, concat y sharding. Los modelos se ordenan según su puntuación promedio en la configuración completa. La sombra refleja el grado de disminución del rendimiento desde la configuración completa, con las dos columnas finales que informan las disminuciones promedio para concat y sharding en relación con la configuración completa.

En cuanto a estos resultados, los autores declaran^†:

‘En general, cada modelo ve su rendimiento degradarse en cada tarea cuando se compara el rendimiento Completo y Sharding, con una degradación promedio de -39%. Llamamos a este fenómeno Perdido en la conversación: los modelos que logran un rendimiento estelar (90%+) en el entorno de laboratorio de conversaciones de un solo turno y completamente especificadas luchan en las mismas tareas en un entorno más realista cuando la conversación es subespecificada y de varios turnos.’

Concat promedió el 95 por ciento de completa, lo que indica que la disminución del rendimiento en la configuración sharding no se puede explicar por la pérdida de información. Los modelos más pequeños, como Llama3.1-8B-Instruct, OLMo-2-13B y Claude 3 Haiku, mostraron una degradación más pronunciada en la configuración concat, lo que sugiere que los modelos más pequeños son generalmente menos robustos a la reexpresión que los más grandes.

Los autores observan^†:

‘Sorprendentemente, los modelos más performantes (Claude 3.7 Sonnet, Gemini 2.5, GPT-4.1) se pierden igualmente en la conversación en comparación con los modelos más pequeños (Llama3.1-8B-Instruct, Phi-4), con degradaciones promedio de 30-40%. Esto se debe en parte a las definiciones de las métricas. Dado que los modelos más pequeños logran puntuaciones absolutas más bajas en Completa, tienen menos alcance para la degradación que los mejores modelos.

‘En resumen, no importa cuán fuerte sea el rendimiento de un solo turno de un LLM, observamos grandes degradaciones del rendimiento en el entorno de varios turnos.’

La prueba inicial indica que algunos modelos se desempeñaron mejor en tareas específicas: Command-A en Acciones, Claude 3.7 Sonnet y GPT-4.1 en código; y Gemini 2.5 Pro en Datos a texto, lo que indica que la capacidad de varios turnos varía según el dominio. Los modelos de razonamiento, como o3 y Deepseek-R1, no se desempeñaron mejor en general, quizás porque sus respuestas más largas introdujeron más suposiciones, que tendían a confundir la conversación.

Confiabilidad

La relación entre aptitud y confiabilidad, clara en simulaciones de un solo turno, parecía descomponerse en condiciones de varios turnos. Mientras que la aptitud disminuyó solo modestamente, la inestabilidad se duplicó en promedio. Los modelos que fueron estables en instrucciones de formato completo, como GPT-4.1 y Gemini 2.5 Pro, se volvieron igualmente erráticos que los modelos más débiles, como Llama3.1-8B-Instruct o OLMo-2-13B, una vez que la instrucción se fragmentó.

Visión general de la aptitud y la inestabilidad, como se muestra en un gráfico de caja (a), seguido de los resultados de confiabilidad de los experimentos con 15 modelos (b), y los resultados de la prueba de fragmentación gradual donde las instrucciones se dividieron en uno a ocho fragmentos (c).

Las respuestas del modelo a menudo variaban tanto como 50 puntos en la misma tarea, incluso cuando no se agregaba nada nuevo, lo que sugiere que la disminución del rendimiento no se debió a una falta de habilidad, sino a que el modelo se volvía cada vez más inestable a lo largo de los turnos.

El artículo establece^†:

‘[Aunque] los mejores modelos tienden a tener una aptitud ligeramente mayor en varios turnos, todos los modelos tienden a tener niveles similares de inestabilidad. En otras palabras, en entornos de varios turnos y subespecificados, todos los modelos que probamos exhiben una inestabilidad muy alta, con un rendimiento que se degrada 50 puntos porcentuales en promedio entre la mejor y la peor ejecución simulada para una instrucción fija.’

Para probar si la degradación del rendimiento estaba vinculada al número de turnos, los autores realizaron un experimento de fragmentación gradual, dividiendo cada instrucción en uno a ocho fragmentos (ver la columna más a la derecha en la imagen de arriba).

A medida que aumentaba el número de fragmentos, la inestabilidad aumentaba constantemente, lo que confirmó que incluso pequeños aumentos en el número de turnos hacían que los modelos fueran más inestables. La aptitud permaneció en gran medida sin cambios, lo que reforzó que el problema radica en consistencia, no en capacidad.

Control de temperatura

Un conjunto separado de experimentos probó si la inestabilidad era simplemente un subproducto de la aleatoriedad. Para hacer esto, los autores variaron la configuración de temperatura de ambos, el asistente y el simulador de usuario, a través de tres valores: 1,0, 0,5 y 0,0.

En formatos de un solo turno, como completa y concat, reducir la temperatura del asistente mejoró significativamente la confiabilidad, reduciendo la variación en hasta un 80 por ciento; pero en la configuración sharding, la misma intervención tuvo poco efecto:

Puntuaciones de inestabilidad para diferentes combinaciones de temperatura del asistente y del usuario a través de configuraciones completas, concat y sharding, con valores más bajos que indican una consistencia de respuesta mayor.

Incluso cuando tanto el asistente como el usuario se configuraron con una temperatura de cero, la inestabilidad permaneció alta, con GPT-4o que mostraba una variación alrededor del 30 por ciento, lo que sugiere que la inestabilidad observada en conversaciones de varios turnos no es solo ruido estocástico, sino una debilidad estructural en la forma en que los modelos manejan la entrada fragmentada.

Implicaciones

Los autores escriben sobre las implicaciones de sus hallazgos a una longitud inusual en la conclusión del artículo, argumentando que un rendimiento de un solo turno fuerte no garantiza la confiabilidad de varios turnos, y advirtiendo contra confiar demasiado en referencias completamente especificadas cuando se evalúa la preparación para el mundo real (ya que dichas referencias enmascaran la inestabilidad en interacciones más naturales y fragmentadas).

También sugieren que la inestabilidad no es solo un artefacto de muestreo, sino una limitación fundamental en la forma en que los modelos actuales procesan la entrada en evolución, y sugieren que esto plantea preocupaciones para los marcos de agente, que dependen de un razonamiento sostenido a lo largo de los turnos.

Finalmente, argumentan que la capacidad de varios turnos debería tratarse como una capacidad central de los LLM, y no algo que se externalice a sistemas externos.

Los autores observan que sus resultados probablemente subestiman la verdadera escala del problema, y llaman la atención sobre las condiciones ideales de la prueba: el simulador de usuario en su configuración tenía acceso completo a la instrucción y podía revelar fragmentos en un orden óptimo, lo que dio al asistente un contexto favorable (en el uso del mundo real, los usuarios a menudo proporcionan instrucciones fragmentadas o ambiguas sin saber qué es lo que el modelo necesita escuchar a continuación).

Además, el asistente se evaluó inmediatamente después de cada turno, antes de que se desarrollara completamente la conversación, lo que evitó que se penalizaran posteriormente la confusión o la contradicción, lo que de otro modo empeoraría el rendimiento. Estas elecciones, aunque necesarias para el control experimental, significan que las brechas de confiabilidad observadas en la práctica probablemente sean aún mayores que las informadas.

Concluyen:

‘[Creemos que] las simulaciones realizadas representan un terreno de prueba benigno para las capacidades de varios turnos de los LLM. Debido a las condiciones de simulación excesivamente simplificadas, creemos que la degradación observada en los experimentos es probablemente una subestimación de la inestabilidad de los LLM, y con qué frecuencia los LLM se pierden en la conversación en entornos del mundo real.‘

Conclusión

Cualquiera que haya pasado una cantidad significativa de tiempo con un LLM probablemente reconocerá los problemas formulados aquí, a partir de la experiencia práctica; y la mayoría de nosotros, imagino, han abandonado conversaciones ‘perdidas’ de LLM por otras nuevas, con la esperanza de que el LLM pueda ‘volver a empezar’ y dejar de obsesionarse con el material que surgió en un intercambio largo, sinuoso y cada vez más frustrante.

Es interesante señalar que lanzar más contexto al problema puede no necesariamente resolverlo; y de hecho, observar que el artículo plantea más preguntas de las que proporciona respuestas (excepto en términos de formas de evitar el problema).

* Confusamente, esto no está relacionado con el significado convencional de ‘sharding’ en AI.

† Énfasis en negrita de los autores.

Publicado por primera vez el lunes 12 de mayo de 2025