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 desmoronan 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 llamada se divide en varias vueltas:

Una conversación de un solo giro (izquierda) obtiene los mejores resultados, pero es antinatural para el usuario final. Una conversación de varios giros (derecha) encuentra que incluso los modelos LLM más altos y mejor rendimiento 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 llamadas completamente especificadas en fragmentos más pequeños y los libera uno a la vez en una conversación.

En los términos más 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 tal vez pone al cliente en una luz negativa. Pero la idea central representada en la segunda columna es la de un intercambio transaccional que aclara 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 nuevo trabajo con un enfoque de sharded para la interacción con LLM. Los autores observan que los LLM a menudo generan respuestas demasiado largas y luego continúan confiando en sus propias ideas incluso después de que esas ideas han sido demostradas como incorrectas o irrelevantes. Esta tendencia, combinada con otros factores, puede hacer que el sistema pierda completamente el intercambio.

De hecho, los investigadores observan lo que muchos de nosotros hemos encontrado de manera anecdótica – que la mejor manera de volver a encarrilar la conversación es iniciar una nueva conversación con el LLM.

‘Si una conversación con un LLM no condujo a resultados esperados, iniciar una nueva conversación que repita la misma información podría 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 agenciales como Autogen o LangChain pueden mejorar los resultados potencialmente al actuar como capas interpretativas entre el usuario final y el LLM, comunicándose solo con el LLM cuando hayan recopilado suficientes respuestas sharded 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 integrada directamente en el LLM de origen:

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

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 podría ser limitante, y argumentamos que los LLM deberían admitir nativamente la interacción de varios giros’

Este interesante nuevo artículo se titula Los LLM se pierden en conversaciones de varios giros, y proviene de cuatro investigadores de MS Research y Salesforce,

Conversaciones fragmentadas

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

Cada instrucción original es una sola llamada 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 sharded 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 llamada completa entregada en un solo giro y (b) su versión sharded utilizada para simular una interacción de varios giros 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 proporcionan detalles aclaratorios. Juntos, entregan el mismo contenido que la llamada original, pero distribuido naturalmente a lo largo de varios giros 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 sharded; y el sistema, que vigila y califica el intercambio.

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

Si el modelo intenta una respuesta, un componente separado extrae solo el span relevante para la evaluación, ignorando cualquier texto circundante. En cada nuevo giro, el usuario revela un fragmento adicional, provocando otra respuesta. El intercambio continúa hasta que el modelo obtenga la respuesta correcta o no queden fragmentos por revelar:

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

Pruebas tempranas mostraron que los modelos a menudo preguntaban sobre información que no se había compartido todavía, 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, basándose en cómo se desarrollaba la conversación.

El simulador de usuario, implementado utilizando GPT-4o-mini, se le dio acceso completo a la instrucción completa y a la historia de la conversación, y se le encomendó la tarea de decidir, en cada giro, qué fragmento revelar a continuación, basándose en 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 preservaba 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 llamada será incompleta o actualizada 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 lo suficientemente 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 variante de cómo y cuándo se revelan partes de la instrucción.

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

El entorno Sharded divide la instrucción en varias partes y las entrega una a la vez, simulando una conversación más realista y subespecificada. Este es el entorno principal utilizado para probar cómo manejan los modelos la entrada de varios giros.

En el entorno Concat, los fragmentos se vuelven a unir como una lista única, preservando su redacción pero eliminando la estructura de giro por giro. Esto ayuda a aislar los efectos de la fragmentación conversacional de la reexpresión o la pérdida de contenido.

El entorno Resumen se ejecuta como Sharded, pero agrega un giro final donde se restablecen todos los fragmentos anteriores antes de que el modelo dé una respuesta final. Esto prueba si un prompt de resumen puede ayudar a recuperar el contexto perdido.

Finalmente, Nieve de bola va más allá, repitiendo todos los fragmentos anteriores en cada giro, 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 giros.

Tipos de simulación basados en instrucciones sharded. Una llamada completamente especificada se divide en partes más pequeñas, que luego se pueden utilizar para simular conversaciones de un solo giro (Completa, Concat) o de varios giros (Sharded, 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 dominios de programación como de lenguaje natural: las llamadas de generación de código se tomaron de HumanEval y LiveCodeBench; las consultas de Texto-a-SQL se obtuvieron de Spider; las llamadas a API se construyeron utilizando datos de la Tabla de clasificación de llamadas a funciones de Berkeley; los problemas de matemáticas elementales se proporcionaron por GSM8K; las tareas de generación de subtítulos de tablas se basaron en ToTTo; y las resúmenes de varios documentos se extrajeron del conjunto de datos Resumen de un montón 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 múltiples intentos; aptitud reflejó los mejores resultados que un modelo podía alcanzar, basándose en sus salidas con la puntuación más alta; y inestabilidad midió cuánto variaban esos resultados, con brechas más grandes entre los mejores y peores resultados indicando 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 sharded utilizadas en los experimentos, cubriendo 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 sharded. Entre 90 y 120 instrucciones se adaptaron de benchmarks establecidos para cada tarea.

Modelos y pruebas

En las simulaciones iniciales (con un costo estimado de $5000), 600 instrucciones que abarcan seis tareas se dividieron en fragmentos y se utilizaron para simular tres tipos de conversación: completa, concat y sharded. 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 medidas más profundas de aptitud y estabilidad.

Se probaron quince modelos, que abarcan 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), accesibles 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 accesibles localmente a través de Ollama o la API de Cohere; y Deepseek-R1, accesible 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 sharded. Los modelos se ordenan según su puntuación de configuración completa promedio. La sombra refleja el grado de caída de rendimiento desde la configuración completa, con las dos columnas finales informando caídas promedio para concat y sharded en relación con la completa.

Con respecto a estos resultados, los autores declaran^†:

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

Concat las puntuaciones promediaron el 95 por ciento de completa, lo que indica que la caída de rendimiento en la configuración sharded 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 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 margen para la degradación que los mejores modelos.

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

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 giros varía por 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 giro, pareció desmoronarse bajo condiciones de varios giros. Mientras que la aptitud disminuyó solo modestamente, la inestabilidad dobló en promedio. Los modelos que eran estables en llamadas de formato completo, como GPT-4.1 y Gemini 2.5 Pro, se volvieron igual de 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 quince 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 caída de 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 giros.

El artículo establece^†:

‘[Aunque] los mejores modelos tienden a tener una aptitud de varios giros ligeramente más alta, todos los modelos tienden a tener niveles similares de inestabilidad. En otras palabras, en configuraciones de varios giros subespecificadas, todos los modelos que probamos exhiben inestabilidad muy alta, con un rendimiento que se degrada 50 puntos porcentuales en promedio entre la mejor y la peor simulación para una instrucción fija.’

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

A medida que aumentaba el número de fragmentos, la inestabilidad aumentaba constantemente, confirmando que incluso pequeños aumentos en el recuento de giros 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 tanto del asistente como del simulador de usuario a través de tres valores: 1.0, 0.5 y 0.0.

En formatos de un solo giro como completa y concat, reducir la temperatura del asistente mejoró significativamente la confiabilidad, cortando la variación en hasta un 80 por ciento; pero en la configuración sharded, 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 completa, concat y sharded, con valores más bajos que indican una mayor consistencia de respuesta.

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

Implicaciones

Los autores escriben sobre las implicaciones de sus hallazgos con una longitud inusual al concluir el artículo, argumentando que un rendimiento de un solo giro sólido no garantiza la confiabilidad de varios giros, y advirtiendo en contra de confiar demasiado en benchmarks completamente especificados al evaluar la preparación para el mundo real (ya que dichos benchmarks 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 cómo los modelos actuales procesan la entrada en evolución, y sugieren que esto plantea preocupaciones para los marcos de agente, que dependen del razonamiento sostenido a lo largo de los giros.

Finalmente, argumentan que la capacidad de varios giros 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 e irrealista (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, al asistente se le evaluó inmediatamente después de cada giro, antes de que se desarrollara completamente la conversación, lo que evitó que la confusión o la autocontradicción posteriores fueran penalizadas, lo que 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 giros 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, hemos abandonado conversaciones ‘perdidas’ con LLM por nuevas conversaciones, con la esperanza de que el LLM pueda ‘volver a empezar’ y dejar de obsesionarse con material que surgió en un intercambio largo, sinuoso y cada vez más frustrante.

Es interesante observar que arrojar 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 sortear 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