Un nuevo artículo de Microsoft Research and Salesforce encuentra que incluso los modelos de idiomas grandes (LLM) más capaces se desmoronan cuando se dan instrucciones en etapas en lugar de todo a la vez. Los autores encontraron que el rendimiento cae en un promedio de 39 por ciento en seis tareas cuando un aviso es dividido en múltiples vueltas:
Una conversación de solo turno (izquierda) obtiene los mejores resultados, pero no es natural para el usuario final. Una conversación de múltiples vueltas (derecha) encuentra incluso los LLM más altos y más actuados que pierden el ímpetu efectivo en una conversación. Fuente: https://arxiv.org/pdf/2505.06120
Más sorprendentemente, el fiabilidad de las respuestas requiere una pisada, con prestigiosos modelos como ChatGPT-4.1 y Gemini 2.5 Pro balanceándose entre respuestas casi perfectas y fallas manifiestas, dependiendo de cómo se reduzca la misma tarea; Además, la consistencia de salida puede disminuir en más de la mitad en el proceso.
Para explorar este comportamiento, el documento presenta un método llamado fragmento*, que divide las indicaciones 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 un orden único cohesivo e integral en un restaurante, dejando al camarero sin nada que hacer más que reconocer la solicitud; o de lo contrario decidir atacar el asunto en colaboración:
Dos versiones extremas de una conversación en un restaurante (no del nuevo artículo, solo para fines ilustrativos).
Para enfatizar, el ejemplo anterior quizás ponga 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.
Esta configuración se refleja en el alimentado por goteo del nuevo trabajo, fragmentado Enfoque para la interacción LLM. Los autores señalan 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 se hayan demostrado ser incorrectas o irrelevantes. Esta tendencia, combinada con otros factores, puede hacer que el sistema pierda el rastreo del intercambio por completo.
De hecho, los investigadores señalan lo que muchos de nosotros hemos encontrado anecdóticamente, que la mejor manera de volver a encarrilar la conversación es comenzar una nueva conversación con el LLM.
‘Si una conversación con un LLM no condujo a los resultados esperados, comenzar una nueva conversación que repita la misma información podría producir resultados significativamente mejores que continuar una conversación continua.
‘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 de agente como Autógen o Langchain pueden mejorar potencialmente los resultados al actuar como capas interpretativas entre el usador final y el LLM, solo comunicándose con el LLM cuando se han reunido suficientes respuestas ‘desguridas’ para coagular en una sola consulta cohesiva (a la que no se expondrá el usuario final).
Sin embargo, los autores sostienen que no debe ser necesaria una capa de abstracción separada, o de lo contrario, construirse directamente en la fuente LLM:
‘Se podría argumentar que las capacidades de múltiples vueltas no son una característica necesaria de los LLM, ya que se puede descargar al marco del agente. En otras palabras, ¿necesitamos soporte múltiple nativo en LLM cuando un marco de agente puede orquestar interacciones con los usuarios y aprovechar los LLM solo como operadores de un solo cambio? … ‘
Pero después de haber probado la propuesta en su variedad de ejemplos, concluyen:
‘(Confiar) en un marco similar al agente para procesar la información podría ser limitante, y argumentamos que los LLM deberían admitir de forma nativa la interacción múltiple’
Este nuevo artículo interesante se titula LLMS se pierde en una conversación múltipley proviene de cuatro investigadores en la EM Investigación y Salesforce,
Conversaciones fragmentadas
El nuevo método primero desglosa las instrucciones convencionales de una sola vuelta en fragmentos más pequeños, diseñados para introducirse en momentos clave durante una interacción LLM, una estructura que refleja el estilo exploratorio de compromiso de ida y vuelta que se ve en sistemas como ChatGPT o Google Gemini.
Cada instrucción original es un mensaje único y autónomo que ofrece toda la tarea de una sola vez, combinando una pregunta de alto nivel, un contexto de apoyo y cualquier condición relevante. La versión fragmentada divide esto en múltiples partes más pequeñas, con cada fragmento agregando solo una información:
Instrucciones emparejadas que muestran (a) un aviso completo entregado en un solo turno y (b) su versión fragmentada utilizada para simular una interacción subestimada y múltiple. Semánticamente, cada versión ofrece la misma carga útil informativa.
El primer fragmento siempre presenta el objetivo principal de la tarea, mientras que el resto proporciona detalles de aclaración. Juntos, ofrecen el mismo contenido que el aviso original, pero se extienden naturalmente durante varios turnos en la conversación.
Cada conversación simulada 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 sistemaque vigila y anota el intercambio.
La conversación comienza con el usuario que revela el primer fragmento y el asistente que responde libremente. El sistema luego clasifica esa respuesta en una de varias categorías, como un solicitud de aclaración o intento de respuesta completa.
Si el modelo hace Intente una respuesta, un componente separado extrae solo el tramo 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 obtenga la respuesta correcta o no quedan fragmentos para 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 dejaron la idea de revelar fragmentos en un orden fijo. En cambio, se usó un simulador para decidir qué fragmento revelar a continuación, en función de cómo iba la conversación.
Por lo tanto, el simulador de usuario, implementado con GPT-4O-Mini, recibió acceso completo tanto a toda la instrucción como al historial de conversación, encargado de decidir, en cada turno, que Shard para revelar a continuación, en función de cómo se desarrollaba el intercambio.
El simulador de usuario también reformado Cada fragmento para mantener el flujo de conversación, sin alterar el significado. Esto permitió que la simulación reflejara la “toma y toma” del diálogo real, al tiempo que preservaba el control sobre la estructura de la tarea.
Antes de que comience la conversación, el asistente solo recibe la información básica necesaria para completar la tarea, como un esquema de base de datos o una referencia de API. No se dice que las instrucciones se romperán, y no se guía hacia ninguna forma específica de manejar la conversación. Esto se hace a propósito: en el uso del mundo real, los modelos casi nunca se les dice que un aviso estará incompleto o actualizado con el tiempo, y dejar de lado este contexto ayuda a la simulación a reflejar cómo se comporta el modelo en un contexto más realista.
GPT-4O-Mini también se usó para decidir cómo se deben clasificar las respuestas del modelo y para extraer cualquier respuesta final de esas respuestas. Esto ayudó a la simulación a mantenerse flexible, pero introdujo errores ocasionales: sin embargo, después de verificar varios cientos de conversaciones a mano, los autores encontraron que menos del cinco por ciento tenían problemas, y menos del dos por ciento mostraron un cambio en el resultado debido a ellos, y consideraron que esto 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 es una variación de cómo y cuándo se revelan partes de la instrucción.
En el Lleno Configuración, el modelo recibe toda la instrucción en un solo turno. Esto representa el formato de referencia estándar y sirve como la línea de base de rendimiento.
El Fragmentado La configuración divide la instrucción en múltiples piezas y las entrega una a la vez, simulando una conversación más realista y subspecificada. Esta es la configuración principal utilizada para probar qué tan bien los modelos manejan la entrada de múltiples vueltas.
En el Concatismo Configuración, los fragmentos se unen como una sola lista, preservando su redacción pero eliminando la estructura de giro a giro. Esto ayuda a aislar los efectos de la fragmentación conversacional de la reformulación o la pérdida de contenido.
El Resumen La configuración se ejecuta como Fragmentadopero agrega un giro final donde se reformulan todos los fragmentos anteriores antes de que el modelo le dé una respuesta final. Esto prueba si un aviso de resumen puede ayudar a recuperar el contexto perdido.
Finalmente, Bola de nieve va más allá, repitiendo Todos los fragmentos anteriores en cada pasomanteniendo la instrucción completa visible a medida que se desarrolla la conversación y ofrece una prueba más indulgente de habilidad múltiple.
Tipos de simulación basados en instrucciones fragmentadas. Un aviso completamente especificado se divide en partes más pequeñas, que luego se pueden usar para simular conversaciones de giro único (completo, concat) o múltiple (fragmentación, recapitulación, bola de nieve), dependiendo de qué tan rápido se revela la información.
Tareas y métricas
Se eligieron seis tareas de generación para cubrir tanto la programación como los dominios del lenguaje natural: las indicaciones de generación de código se tomaron de Humaneval y LivecodeBench; Las consultas de texto a SQL se obtuvieron de Spider; Las llamadas de API se construyeron utilizando datos de la función de calificación de la función de Berkeley; Los problemas matemáticos elementales fueron proporcionados por GSM8K; Las tareas de subtítulos tabulares se basaron en el totto; y se extrajeron resúmenes de documentos múltiples del resumen de un conjunto de datos Haystack.
El rendimiento del modelo se midió utilizando tres métricas centrales: rendimiento promedio, aptitudy no responsabilidad.
Rendimiento promedio capturó lo bien que lo hizo un modelo en general en múltiples intentos; aptitud reflejó los mejores resultados que un modelo podría alcanzar, en función de sus salidas de puntuación superior; y no responsabilidad Medió cuánto variaron esos resultados, con mayores brechas entre los mejores y peores resultados que indican un comportamiento menos estable.
Todos los puntajes se colocaron en una escala de 0-100 para garantizar la consistencia en las tareas y las métricas calculadas para cada instrucción, y luego se promediaron para proporcionar una imagen general del rendimiento del modelo.
Seis tareas fragmentadas utilizadas en los experimentos, que cubren tanto la programación como la generación de lenguaje natural. Cada tarea se muestra con una instrucción completamente especificada y su versión fragmentada. Entre 90 y 120 instrucciones se adaptaron de los puntos de referencia establecidos para cada tarea.
Contendientes y pruebas
En las simulaciones iniciales (con un costo estimado de $ 5000), 600 instrucciones que abarcaban seis tareas fueron fragmentadas y utilizadas para simular tres tipos de conversación: lleno, concatismoy fragmentado. 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 permitió capturar tanto el rendimiento general como las medidas más profundas de aptitud y confiabilidad.
Se probaron quince modelos, abarcando 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-04-16).
Los modelos antrópicos fueron Claude 3 Haiku (2024-03-07) y el soneto Claude 3.7 (2025-02-19), accedido 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 Meta Models fueron Llama 3.1-8B-Instructo y Llama 3.3-70B-Instructo, así como Llama 4 Scout-17B-16E, a través de AI juntos.
Las otras entradas fueron Olmo 2 13b, Phi-4 y Command-A, todas accedidas localmente a través de Ollama o API de Cohere; y Deepseek-R1, accedido a través de Amazon Bedrock.
Para los dos modelos de “pensamiento” (O3 y R1), los límites de tokens se elevaron a 10,000 para acomodar cadenas de razonamiento más largas:
Puntajes 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: completos, concat y fragmentos. Los modelos se ordenan por su puntaje promedio de establecimiento completo. El sombreado refleja el grado de caída de rendimiento desde la configuración completa, con las dos columnas finales que informan disminuciones promedio de concat y fragmentos en relación con el completo.
Con respecto a estos resultados, los autores indican†:
‘A un alto nivel, Cada modelo ve que su rendimiento se degrada en cada tarea al comparar un rendimiento completo y fiscadocon una degradación promedio de -39%. Nombramos este fenómeno Perdido en la conversación: Modelos que logran un rendimiento estelar (90%+) en la configuración de laboratorio de lucha de conversación de un solo cambio En exactamente las mismas tareas en un entorno más realista cuando la conversación está subestimada y de múltiples vueltas.
Concatismo Las puntuaciones promediaron el 95 por ciento de llenoindicando que la caída de rendimiento en la configuración fragmentada no puede explicarse por la pérdida de información. Modelos más pequeños como Llama3.1-8b-Instructo, OLMO-2-13B y Claude 3 Haiku mostraron una degradación más pronunciada bajo concatismosugiriendo que los modelos más pequeños son generalmente menos robustos para la reformulación que los más grandes.
Los autores observan†:
‘Asombrosamente, Los modelos más performantes (soneto Claude 3.7, Gemini 2.5, GPT-4.1) se pierden igualmente en una conversación en comparación con modelos más pequeños (Llama3.1-8b-Instructo, PHI-4), con degradaciones promedio del 30-40%. Esto se debe en parte a las definiciones métricas. Dado que los modelos más pequeños logran puntajes absolutos más bajos en LLENOtienen menos alcance para la degradación que los mejores modelos.
“En resumen, no importa cuán fuerte sea el rendimiento de un solo cambio de LLM, observamos degradaciones de gran rendimiento en el entorno múltiple”.
La prueba inicial indica que algunos modelos se mantuvieron mejor en tareas específicas: Command-A en acciones, soneto Claude 3.7 y GPT-4.1 en el código; y Gemini 2.5 Pro en datos a texto, lo que indica que la capacidad de giro múltiple varía según el dominio. Los modelos de razonamiento como O3 y Deepseek-R1 no les fue mejor en general, tal vez porque sus respuestas más largas introdujeron más suposiciones, lo que tendió a confundir la conversación.
Fiabilidad
La relación entre aptitud y confiabilidad, clara en simulaciones de un solo cambio, parecía desmoronarse en condiciones de múltiples vueltas. Mientras que la aptitud disminuyó solo modestamente, la falta de fiabilidad duplicado de término medio. 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-Instructo o OLMO-2-13B una vez que la instrucción se fragmentó.
Descripción general de la aptitud y la falta de fiabilidad como se muestra en un diagrama de caja (a), seguido de resultados de confiabilidad de experimentos con quince modelos (b), y los resultados de la prueba de fragmento 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 agregó nada nuevo, lo que sugiere que la caída en el rendimiento no se debió a la falta de habilidad, sino que el modelo se volvió cada vez más inestable en todas las curvas.
El documento dice†:
‘(Aunque) mejores modelos tienden a tener una aptitud múltiple ligeramente más alta, todos los modelos tienden a tener niveles similares de falta de fiabilidad. En otras palabras, En la configuración de múltiples vueltas y especificados, todos los modelos que probamos exhiben una falta de fiabilidad muy alta, con un rendimiento de degradación del 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 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 derecha en la imagen anterior).
A medida que aumentó el número de fragmentos, la falta de fiabilidad aumentó constantemente, confirmando que Incluso los aumentos menores a su vez el recuento hizo que los modelos fueran más inestables. La aptitud permaneció en su mayoría sin cambios, reforzando que el problema radica en consistenciano capacidad.
Control de temperatura
Un conjunto separado de experimentos probó si la falta de fiabilidad 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 en tres valores: 1.0, 0.5 y 0.0.
En formatos de una sola vuelta como lleno y concatismoreducir la temperatura del asistente mejoró significativamente la confiabilidad, reduciendo la variación hasta en un 80 por ciento; Pero en el fragmentado configuración, la misma intervención tuvo poco efecto:
Los puntajes de falta de fiabilidad para diferentes combinaciones de asistente y temperatura del usuario en configuraciones completas, concatidas y fragmentadas, con valores más bajos que indican una mayor consistencia de respuesta.
Incluso cuando tanto el asistente como el usuario se establecieron a temperatura cero, la falta de fiabilidad se mantuvo alta, con GPT-4O mostrando una variación de alrededor del 30 por ciento, lo que sugiere que la inestabilidad observada en las conversaciones múltiples no es solo un ruido estocástico, sino una debilidad estructural en cómo los modelos manejan la entrada fragmentada.
Trascendencia
Los autores escriben sobre las implicaciones de sus hallazgos con una duración inusual en la conclusión del documento, argumentando que un fuerte rendimiento de un solo cambio no garantiza la confiabilidad múltiple y la advertencia contra la relación excesiva en los puntos de referencia completamente especificados al evaluar la preparación del mundo real (desde que tales puntos de referencia enmascaran la inestabilidad en interacciones más naturales y fragmentadas).
También sugieren que la falta de fiabilidad no es solo un artefacto de muestreo, sino un 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 agentes, que dependen del razonamiento sostenido en los giros.
Finalmente, argumentan que la capacidad múltiple debe tratarse como una capacidad central de LLM, no algo descargado 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 la instrucción y podía revelar fragmentos en un orden óptimo, lo que le dio al asistente un contexto irrealmente favorable (en uso del mundo real, los usuarios a menudo proporcionan indicaciones fragmentadas o ambiguas sin saber qué debe escuchar el modelo a continuación).
Además, el asistente fue evaluado inmediatamente Después de cada turno, antes de que se desarrollara la conversación completa, evitando que la confusión posterior o la autocontradicción sean penalizadas, lo que de otro modo empeoraría el rendimiento. Estas opciones, aunque son necesarias para el control experimental, significan que las brechas de confiabilidad observadas en la práctica probablemente sean aún mayores que las reportadas.
Concluyen:
‘(Nosotros) creemos que las simulaciones realizadas representan un campo de pruebas benignas para las capacidades de múltiples vueltas 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 fiabilidad de LLM, y con qué frecuencia se pierden los LLM 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í, por experiencia práctica; Y la mayoría de nosotros, me imagino, hemos abandonado intuitivamente las conversaciones ‘perdidas’ de LLM para las frescas, con la esperanza de que el LLM pueda ‘comenzar de nuevo’ y dejar de obsesionarse con el material que surgió en un intercambio largo, sinuoso y cada vez más insensible.
Es interesante observar que lanzar más contexto al problema puede no resolverlo necesariamente; Y de hecho, observar que el documento plantea más preguntas de las que proporciona respuestas (excepto en términos de formas de saltar el problema).
* Confusamente, esto no está relacionado con el significado convencional de ‘fragmentar’ en la IA.
† Los énfasis audaces de los autores.
Publicado por primera vez el lunes 12 de mayo de 2025
