Por qué los modelos lingüísticos se pierden en la conversación

Un nuevo documento de Microsoft Research y Salesforce concluye que incluso los más capaces Modelos de lenguaje grande Los LLM se desmoronan cuando se dan instrucciones en etapas en lugar de todos a la vez. Los autores descubrieron que el rendimiento disminuye un promedio del 39 % en seis tareas cuando se da una indicación. dividido en varios turnos:

Una conversación de un solo turno (izquierda) obtiene los mejores resultados, pero resulta poco natural para el usuario final. Una conversación de varios turnos (derecha) hace que incluso los LLM mejor clasificados y con mayor rendimiento pierdan el impulso efectivo de una conversación. Fuente: https://arxiv.org/pdf/2505.06120

Más sorprendente aún es que fiabilidad El número de respuestas se desploma, con modelos tan prestigiosos como GatoGPT-4.1 y Géminis 2.5 Pro oscilando entre respuestas casi perfectas y fracasos manifiestos, dependiendo de cómo se formule la misma tarea; además, la consistencia de los resultados puede caer a más de la mitad en el proceso.

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

En términos más básicos, esto equivale a dar un pedido único, coherente y completo en un restaurante, sin dejar al camarero nada que hacer más que reconocer el pedido; o bien decidir atacar el asunto de forma colaborativa:

Dos versiones extremas de una conversación en un restaurante (no del nuevo artículo, sólo con fines ilustrativos).

Para enfatizar, el ejemplo anterior quizás presenta al cliente de forma negativa. Pero la idea central que se describe en la segunda columna es la de un intercambio transaccional que aclara un conjunto de problemas, antes de abordarlos; aparentemente, una forma racional y razonable de abordar una tarea.

Esta configuración se refleja en el goteo de la nueva obra. fragmentado Enfoque de la interacción LLM. Los autores señalan que los LLM a menudo generan respuestas demasiado largas y luego siguen dependiendo de sus propias percepciones. Incluso después de que se haya demostrado que esas ideas son incorrectas o irrelevantesEsta tendencia, combinada con otros factores, puede provocar que el sistema pierda por completo la noción del intercambio.

De hecho, los investigadores señalan lo que muchos de nosotros He encontrado anecdóticamente – que la mejor manera de retomar la conversación es iniciar una nueva conversación con el LLM.

'Si una conversación con un LLM no produjo los resultados esperados, iniciar una nueva conversación que repita la misma información podría arrojar 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 demuestran que persistir en una conversación con el modelo es ineficaz. Además, dado que los LLM generan texto de forma aleatoria, una nueva conversación podría generar mejores resultados.

Los autores reconocen que los sistemas agenticos como autógeno or LangChain pueden mejorar potencialmente los resultados al actuar como capas interpretativas entre el usuario final y el LLM, comunicándose con el LLM solo cuando hayan reunido suficientes respuestas "fragmentadas" para coagularlas en una única consulta cohesiva (a la que el usuario final no estará expuesto).

Sin embargo, los autores sostienen que no debería ser necesaria una capa de abstracción separada, o que de lo contrario debería construirse directamente en el LLM fuente:

Se podría argumentar que las capacidades multiturno no son una característica necesaria de los LLM, ya que pueden transferirse al marco del agente. En otras palabras, ¿necesitamos compatibilidad multiturno nativa en los LLM cuando un marco del agente puede orquestar las interacciones con los usuarios y aprovechar los LLM solo como operadores de un solo turno?

Pero después de probar la propuesta a través de su serie de ejemplos, concluyen:

'Confiar en un marco similar a un agente para procesar información podría ser limitante, y sostenemos que los LLM deberían soportar de forma nativa la interacción multi-turno'

Esto interesante nuevo documento se titula Los LLM se pierden en conversaciones de múltiples turnos, y proviene de cuatro investigadores de MS Research y Salesforce,

Conversaciones fragmentadas

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

Cada instrucción original es una instrucción única e independiente que ejecuta la tarea completa de una sola vez, combinando una pregunta de alto nivel, contexto de apoyo y cualquier condición relevante. La versión fragmentada la divide en varias partes más pequeñas, y cada fragmento añade solo una pieza de información:

Instrucciones pareadas que muestran (a) una instrucción completa emitida en un solo turno y (b) su versión fragmentada, utilizada para simular una interacción subespecificada de varios turnos. Semánticamente, cada versión proporciona la misma información.

El primer fragmento siempre presenta el objetivo principal de la tarea, mientras que los demás proporcionan detalles aclaratorios. Juntos, ofrecen el mismo contenido que la instrucción original, pero se distribuyen de forma natural a lo largo de varios turnos de 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 fragmentada; y el te, que vigila y puntúa el intercambio.

La conversación comienza cuando el usuario revela el primer fragmento y el asistente responde libremente. El sistema clasifica esa respuesta en varias categorías, como solicitud de aclaración o intento de respuesta completa.

Si el modelo sí Al intentar una respuesta, un componente independiente extrae solo el fragmento relevante para su evaluación, ignorando el texto circundante. En cada turno, el usuario revela un fragmento adicional, lo que provoca otra respuesta. El intercambio continúa hasta que el modelo acierta la respuesta o no quedan fragmentos por revelar.

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

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

Por lo tanto, al simulador de usuario, implementado mediante GPT-4o-mini, se le dio acceso completo tanto a la instrucción completa como 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 reformulado Cada fragmento mantuvo la fluidez de la conversación sin alterar el significado. Esto permitió que la simulación reflejara la interacción del diálogo real, a la vez que se conservaba el control sobre la estructura de la tarea.

Antes de comenzar la conversación, el asistente recibe únicamente 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 indica que las instrucciones se dividirán ni se le guía hacia ninguna forma específica de gestionar la conversación. Esto se hace a propósito: en el uso real, a los modelos casi nunca se les indica que una solicitud estará incompleta o se actualizará con el tiempo, y omitir este contexto ayuda a que la simulación refleje el comportamiento del modelo en un contexto más realista.

GPT-4o-mini también se utilizó para decidir cómo clasificar las respuestas del modelo y extraer las respuestas finales de ellas. Esto contribuyó a la flexibilidad de la simulación, pero introdujo errores ocasionales. Sin embargo, tras revisar manualmente cientos de conversaciones, los autores descubrieron que menos del XNUMX % presentaba problemas y menos del XNUMX % mostraba cambios en el resultado debido a ellos, lo que consideraron una tasa de error 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 una de las cuales es una variación de cómo y cuándo se revelan partes de la instrucción.

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

La Sharded Esta configuración divide la instrucción en varias partes y las entrega una a una, simulando una conversación más realista y subespecificada. Esta es la configuración principal utilizada para evaluar la eficacia de los modelos en la gestión de entradas multiturno.

En el concat En la configuración, los fragmentos se unen nuevamente en una sola lista, conservando su redacción, pero eliminando la estructura paso a paso. Esto ayuda a aislar los efectos de la fragmentación conversacional de la reformulación o la pérdida de contenido.

La Resumen La configuración se ejecuta como Sharded, pero añade un último turno donde se replantean todos los fragmentos anteriores antes de que el modelo dé una respuesta definitiva. Esto prueba si una solicitud de resumen puede ayudar a recuperar el contexto perdido.

Finalmente, Bola de nieve 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 realizar múltiples turnos.

Tipos de simulación basados ​​en instrucciones fragmentadas. Una instrucción completa se divide en partes más pequeñas, que pueden usarse para simular conversaciones de un solo turno (Full, Concat) o de varios turnos (Sharded, Recap, Snowball), según la rapidez con la que se revele la información.

Tareas y métricas

Se eligieron seis tareas de generación para cubrir los dominios de programación y lenguaje natural: las indicaciones de generación de código se tomaron de evaluación humana y Banco de código en vivo; Las consultas de texto a SQL se obtuvieron de Spiders; Las llamadas API se construyeron utilizando datos de la Tabla de clasificación de llamadas a funciones de Berkeley; Los problemas de matemáticas elementales fueron proporcionados por GSM8K; Las tareas de subtitulado tabular se basaron en ToTTo; y los resúmenes de varios documentos se extrajeron de Resumen de un pajar conjunto de datos

El rendimiento del modelo se midió utilizando tres métricas fundamentales: rendimiento medio, aptitud y falta de fiabilidad.

Rendimiento medio capturó el rendimiento general de un modelo a lo largo de múltiples intentos; aptitud reflejó los mejores resultados que un modelo podría alcanzar, con base en sus resultados con mayor puntuación; y falta de fiabilidad midieron cuánto variaban esos resultados; las brechas más grandes entre los mejores y los peores resultados 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 se calcularon métricas para cada instrucción, que luego se promediaron para proporcionar una imagen general del rendimiento del modelo.

Se utilizaron seis tareas fragmentadas en los experimentos, que abarcan tanto la programación como la generación de lenguaje natural. Cada tarea se muestra con una instrucción completa y su versión fragmentada. Se adaptaron entre 90 y 120 instrucciones a partir de parámetros establecidos para cada tarea.

Contendientes y pruebas

En las simulaciones iniciales (con un costo estimado de $5000), se fragmentaron 600 instrucciones que abarcaban seis tareas y se usaron para simular tres tipos de conversación: ser completados, concat y fragmentadoPara cada combinación de modelo, instrucción y tipo de simulación, se ejecutaron diez conversaciones, generando más de 200,000 simulaciones en total: un esquema que permitió capturar tanto el rendimiento general como medidas más profundas de aptitud y fiabilidad.

Se probaron quince modelos que abarcan una amplia gama de proveedores y arquitecturas: los modelos 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 antrópicos fueron Claude 3 Haiku (2024-03-07) y Soneto de Claudio 3.7 (2025/02/19), consultado a través de Amazon Bedrock.

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

Las otras entradas fueron OLMo 2 13B, fi-4 y Comando-A, todo al que se accede localmente a través de Ollama o Cohere API; y Búsqueda profunda-R1, al que se accede a través de Amazon Bedrock.

para los dos 'pensamiento' modelos (o3 y R1), límites de tokens Se aumentaron a 10,000 para dar cabida a cadenas de razonamiento más largas:

Puntuaciones promedio de rendimiento de cada modelo en seis tareas: código, base de datos, acciones, conversión de datos a texto, matemáticas y resumen. Se muestran los resultados para tres tipos de simulación: completa, concatenada y fragmentada. Los modelos se ordenan según su puntuación promedio en la configuración completa. El sombreado refleja el grado de disminución del rendimiento con respecto a la configuración completa; las dos últimas columnas indican las disminuciones promedio para concatenada y fragmentada en comparación con la configuración completa.

Respecto a estos resultados, los autores afirman:^†:

'A un alto nivel, Cada modelo ve cómo su rendimiento se degrada en cada tarea al comparar el rendimiento COMPLETO y PARTICULAR, con una degradación media del -39%. A este fenómeno lo llamamos Perdido en la conversación:modelos que logran un rendimiento estelar (más del 90 %) en un entorno de laboratorio de lucha conversacional de un solo turno totalmente especificado en exactamente las mismas tareas en un entorno más realista cuando la conversación es subespecificada y de múltiples turnos.

concat Las puntuaciones promediaron el 95 por ciento ser completados, lo que indica que la pérdida de información no puede explicar la disminución del rendimiento en la configuración fragmentada. 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 generalmente son menos robustos a la reformulación que los más grandes.

Los autores observan^†:

'Asombrosamente, Los modelos de mayor rendimiento (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 del 30-40 %. Esto se debe en parte a las definiciones de las métricas. Dado que los modelos más pequeños alcanzan puntuaciones absolutas más bajas en FULL, tienen menos margen de degradación que los mejores modelos.

'En resumen, sin importar cuán bueno sea el desempeño de una sola vuelta de un LLM, observamos grandes degradaciones del desempeño en el entorno de múltiples vueltas.'

La prueba inicial indica que algunos modelos se comportaron 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 Conversión de Datos a Texto, lo que indica que la capacidad de múltiples turnos varía según el dominio. Modelos de razonamiento como o3 y Deepseek-R1 no obtuvieron mejores resultados en general, quizás porque sus respuestas más largas introdujeron más suposiciones, lo que tendía a confundir la conversación.

Confiabilidad

La relación entre aptitud y fiabilidad, evidente en simulaciones de un solo turno, pareció desmoronarse en condiciones de múltiples turnos. Si bien la aptitud disminuyó solo modestamente, la falta de fiabilidad... duplicado En promedio, los modelos que eran estables en indicaciones de formato completo, como GPT-4.1 y Gemini 2.5 Pro, se volvieron tan erráticos como modelos más débiles como Llama3.1-8B-Instruct u OLMo-2-13B una vez que la instrucción se fragmentó.

Descripción general de la aptitud y la falta de confiabilidad como se muestra en un diagrama 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 hasta 50 puntos en la misma tarea, incluso cuando no se añadía nada nuevo, lo que sugiere que la caída en el rendimiento no se debía 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 documento afirma:^†:

Aunque los mejores modelos tienden a tener una aptitud multi-turno ligeramente mayor, todos los modelos tienden a tener niveles similares de falta de fiabilidad. En otras palabras, En configuraciones multivuelta y subespecificadas, todos los modelos que probamos presentan una falta de confiabilidad muy alta, con un rendimiento que se degrada en un 50 por ciento 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 relacionada con la cantidad de vueltas, 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 aumentó el número de fragmentos, la falta de confiabilidad aumentó de manera constante, lo que confirma que Incluso pequeños aumentos en el número de turnos hicieron que los modelos fueran más inestablesLa aptitud se mantuvo prácticamente sin cambios, lo que refuerza que el problema radica en consistencia, no capacidad.

Control de la temperatura

Un conjunto independiente de experimentos evaluó si la falta de fiabilidad era simplemente una consecuencia de la aleatoriedad. Para ello, los autores variaron la temperatura del asistente y del simulador de usuario en tres valores: 1.0, 0.5 y 0.0.

En formatos de una sola vuelta como ser completados y concat, al reducir la temperatura del asistente mejoró significativamente la confiabilidad, reduciendo la variación hasta en un 80 por ciento; pero en el fragmentado En este contexto, la misma intervención tuvo poco efecto:

Puntuaciones de falta de confiabilidad para diferentes combinaciones de temperatura del asistente y del usuario en configuraciones completas, concatenadas y fragmentadas, donde los valores más bajos indican una mayor consistencia de respuesta.

Incluso cuando tanto el asistente como el usuario estaban configurados a temperatura cero, la falta de confiabilidad seguía siendo alta, y GPT-4o mostraba una variación de alrededor del 30 por ciento, lo que sugiere que la inestabilidad observada en conversaciones de múltiples turnos no es solo ruido estocástico, pero existe una debilidad estructural en cómo los modelos manejan la entrada fragmentada.

Implicaciones

Los autores escriben sobre las implicaciones de sus hallazgos con una extensión inusual en la conclusión del artículo, argumentando que un rendimiento sólido en una sola vuelta no garantiza la confiabilidad en múltiples vueltas y advirtiendo contra confiar excesivamente en puntos de referencia totalmente especificados al evaluar la preparación para el mundo real (ya que dichos puntos de referencia enmascaran la inestabilidad en interacciones más naturales y fragmentadas).

También sugieren que la falta de confiabilidad 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 genera inquietudes sobre los marcos de los agentes, que dependen de un razonamiento sostenido a lo largo de los turnos.

Por último, sostienen que la capacidad de realizar múltiples turnos debería considerarse una capacidad fundamental de los LLM y no algo transferido a sistemas externos.

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

Además se evaluó al asistente. inmediatamente Después de cada turno, antes de que se desarrollara la conversación completa, se evitaba penalizar confusiones o contradicciones posteriores, que de otro modo empeorarían el rendimiento. Estas opciones, si bien necesarias para el control experimental, implican que las brechas de fiabilidad observadas en la práctica probablemente sean incluso mayores que las reportadas.

Ellos concluyen:

'Creemos que las simulaciones realizadas representan un campo de pruebas benigno para las capacidades multivuelta del 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 falta de confiabilidad de los LLM y de la frecuencia con la que los LLM se pierden en las conversaciones 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, me imagino, hemos abandonado intuitivamente las conversaciones de LLM "perdidas" por otras nuevas, con la esperanza de que el LLM pueda "comenzar de nuevo" y dejar de obsesionarse con el material que surgió en un intercambio largo, tortuoso y cada vez más exasperante.

Es interesante notar que agregar más contexto al problema no necesariamente lo resolverá; y, de hecho, observar que el artículo plantea más preguntas que respuestas (excepto en términos de formas de evitar el problema).

* Confusamente, esto no está relacionado con El significado convencional de 'sharding' en IA.

† Énfasis propios y audaces de los autores.

Primera publicación: lunes 12 de mayo de 2025