- En situaciones donde el usuario no puede escribir todos los requisitos de una sola vez, el rendimiento de 15 LLM con instrucciones incompletas y de varios turnos cae de forma marcada frente a instrucciones completas de un solo turno: el promedio en 6 tareas generativas baja de 90% a 65%.
- El experimento se armó con un método de fragmentación (sharding) que divide instrucciones existentes de benchmarks de un solo turno en varias partes, de modo que las condiciones y el contexto se revelen gradualmente a medida que avanza la conversación.
- La caída de rendimiento se debió más al aumento de la inestabilidad que a una simple falta de capacidad; en más de 200,000 conversaciones, los modelos dependieron demasiado de supuestos iniciales e intentos tempranos de dar una respuesta final.
- Los modelos evaluados van desde Llama3.1-8B-Instruct hasta Gemini 2.5 Pro, y las tareas incluyen tanto programación como generación de lenguaje natural: Code, Database, Actions, Math, Data-to-Text y Summary.
- Aunque es una simulación simplificada de conversaciones reales humano-IA, todas las conversaciones fueron diseñadas para terminar con información suficiente para resolver la tarea; por eso, la caída observada podría ser menor que la que se daría en conversaciones reales incompletas de varios turnos.
La brecha entre la evaluación de un solo turno y el uso conversacional real
- Los LLM se usan mediante interfaces conversacionales como ChatGPT, Gemini y Claude, y aunque los usuarios no puedan especificar por completo sus requisitos desde el inicio, pueden definir, explorar y modificar lo que necesitan a lo largo de varios turnos.
- Las evaluaciones tradicionales de LLM se han concentrado principalmente en entornos de instrucciones completas de un solo turno, pero en los registros de conversación con LLM es común que las instrucciones del usuario sean incompletas.
- Muchas evaluaciones existentes de varios turnos se acercan a un enfoque episodic, que trata la conversación como una secuencia de subtareas evaluables de forma independiente.
- Requieren cierta comprensión del contexto entre turnos, pero son distintas de situaciones donde hay que combinar activamente información a partir de instrucciones incompletas del usuario.
- Este tipo de tareas puede hacer que el rendimiento de los LLM en conversaciones de varios turnos parezca más alto de lo que realmente es.
Conversaciones incompletas de varios turnos creadas con sharding
- El experimento convierte instrucciones completas de benchmarks de un solo turno de alta calidad en sharded instruction.
- El primer shard presenta la intención general de la tarea.
- Los shards posteriores entregan, uno por uno, condiciones o contexto adicionales de la instrucción original.
- Al juntar todos los shards, contienen la misma información que la instrucción completa original.
- Por ejemplo, en el problema de las bolas de nieve de GSM8K, el enunciado de un solo turno entrega todas las condiciones, como “crear 20 por hora”, “grabar 2 cada 15 minutos” y “se necesitan 60 en total”, mientras que la versión sharded las revela repartidas en varios turnos.
- El proceso de sharding se hizo de forma semiautomática: GPT-4o generó y verificó candidatos, y luego los investigadores los revisaron y corrigieron.
Estructura de la simulación conversacional
- En la simulación de varios turnos hay tres actores:
- assistant evaluado: el LLM cuyo rendimiento se mide.
- user simulator: un LLM que conoce toda la sharded instruction y revela el siguiente shard en cada turno.
- system: componente que clasifica la respuesta del assistant y evalúa los intentos de respuesta.
- En el primer turno, el user simulator revela solo el primer shard, y el assistant responde con texto libre.
- La respuesta del assistant se clasifica en una de 7 estrategias:
- clarification
- refusal
- hedging
- interrogation
- discussion
- missing
- answer attempt
- Si se clasifica como answer attempt, un answer extractor extrae el rango de respuesta necesario para la evaluación, como fragmentos de código, números o SQL, y un evaluator específico por tarea le asigna una puntuación.
- La conversación termina en una de dos condiciones:
- el intento de respuesta del assistant se evalúa como correcto;
- al inicio de un nuevo turno no quedan shards por revelar.
- El user simulator, el strategy classifier y el answer extractor se implementaron con GPT-4o-mini basado en prompts.
- Tras anotar manualmente cientos de conversaciones, los errores del user simulator, classifier y extractor aparecieron en menos del 5% de las conversaciones revisadas, y los errores que perjudicaron al modelo assistant fueron menos del 2%.
Cinco tipos de simulación comparados
- FULL es una simulación de un solo turno que entrega la instrucción completa original en el primer turno, y se usa como línea base de rendimiento.
- SHARDED es una conversación incompleta de varios turnos donde los shards se revelan a lo largo de varios turnos, y es el entorno principal de evaluación.
- CONCAT une los shards en una instrucción con viñetas dentro de un solo turno.
- Como FULL, elimina la incompletitud.
- Como SHARDED, conserva la reformulación producida durante el proceso de sharding.
- Si un modelo tiene éxito en FULL y CONCAT pero falla en SHARDED, la causa podría ser la dinámica de varios turnos y la incompletitud en sí, más que la pérdida de información.
- RECAP vuelve a presentar todos los shards juntos al final de una conversación SHARDED para darle al LLM una oportunidad final de responder.
- SNOWBALL vuelve a enunciar en cada turno el shard nuevo junto con todos los shards revelados hasta ese momento, ofreciendo un resumen acumulativo en cada turno.
Tareas y benchmarks utilizados
- El experimento consta de 6 tareas generativas que incluyen casos de uso de programación y de generación de lenguaje natural.
- Para cada tarea se prepararon entre 90 y 120 sharded instructions, con un total de 600 instructions.
- Composición de las tareas:
- Code: escritura de funciones Python basadas en HumanEval y LiveCodeBench.
- Database: generación text-to-SQL basada en Spider.
- Actions: generación de llamadas a funciones de API basada en Berkeley Function Calling Leaderboard.
- Math: resolución de problemas matemáticos verbales de primaria basada en GSM8K.
- Data-to-Text: generación de oraciones descriptivas a partir de datos tabulares basada en ToTTo.
- Summary: generación de resúmenes y citas de conjuntos de documentos basada en Summary of a Haystack.
- Las métricas de evaluación reutilizan las métricas de los benchmarks originales.
- Code y Database usan exactitud basada en ejecución.
- Actions y Math usan equivalencia semántica con la respuesta de referencia o respuesta numérica correcta.
- Data-to-Text usa BLEU.
- Summary usa el “Joint Score” de LLM-as-a-judge, que mide cobertura de información y exactitud en la atribución de fuentes.
- La exactitud binaria también se mapeó a un rango de 0 a 100 para agregar las puntuaciones de todas las tareas en la misma escala.
Medición de rendimiento, capacidad e inestabilidad
- Como las salidas de los LLM son probabilísticas, cada instruction y tipo de simulación se ejecutó repetidamente N=10 veces.
- Cada ejecución se evalúa con una puntuación en el rango de 0 a 100.
- Se usan tres métricas:
- rendimiento promedio P: promedio de las puntuaciones de las ejecuciones repetidas.
- aptitude A90: percentil 90 de las puntuaciones, como estimación del rendimiento best-case en el 10% superior de ejecuciones.
- unreliability U90-10: diferencia entre el percentil 90 y el percentil 10, que mide la brecha entre best-case y worst-case.
- En un solo turno, los modelos con mayor aptitude tendían también a ser más confiables, pero en varios turnos apareció una unreliability alta en todos los LLM, independientemente de su aptitude.
Resultados del experimento a gran escala
- El experimento principal se realizó con 600 instructions, 3 tipos de simulación (FULL, CONCAT, SHARDED) y 15 LLM.
- Cada combinación se repitió 10 veces, simulando más de 200,000 conversaciones.
- Todas las simulaciones se hicieron con temperature T=1 por defecto; el efecto de la temperature sobre aptitude y reliability se aborda en un experimento auxiliar separado.
- En conjunto, el rendimiento promedio en conversaciones incompletas de varios turnos fue de 65%, 25 puntos por debajo del rendimiento de un solo turno con la instrucción completa desde el inicio, que fue de 90%.
- La caída de rendimiento en varios turnos apareció de forma generalizada, desde modelos open-weight pequeños hasta modelos de última generación.
- Los modelos evaluados incluyen modelos open-weight pequeños como Llama3.1-8B-Instruct y modelos recientes como Gemini 2.5 Pro.
- En la Figure 1 se muestran como ejemplos Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1 y Gemini 2.5 Pro.
- La caída promedio de rendimiento en las 6 tareas generativas es de 39%, y la Figure 1 muestra una degradación de rendimiento de aproximadamente -35% en la configuración de varios turnos.
Por qué se pierden
- La caída de rendimiento se divide en dos factores:
- disminución de aptitude: baja en parte el rendimiento best-case en sí.
- aumento de unreliability: crece mucho la brecha de calidad entre ejecuciones.
- Según la Figure 1, en varios turnos la aptitude baja -15% y la unreliability sube +112%.
- Los modelos tienden a crear supuestos equivocados con la información inicial incompleta y a intentar dar una respuesta final temprano en la conversación.
- Incluso cuando después se entrega información nueva, dependen demasiado de esos intentos de respuesta incorrectos previos y no logran corregir el rumbo.
- El fenómeno de no poder recuperarse tras tomar una dirección equivocada en una conversación incompleta de varios turnos se define como lost in conversation.
Limitaciones e implicaciones prácticas
- La simulación totalmente automática no representa tal cual las conversaciones reales humano-IA.
- El entorno experimental está simplificado e idealizado.
- Se garantiza que la conversación termine con información suficiente para resolver la tarea.
- Se limitan comportamientos inesperados que podrían ocurrir en entornos reales, como desviaciones de la conversación.
- Debido a este diseño, la degradación de rendimiento observada podría subestimar la que ocurre en conversaciones reales humano-IA incompletas de varios turnos.
- Las organizaciones que crean productos conversacionales basados en LLM y los usuarios finales deben evaluar la confiabilidad en varios turnos junto con la capacidad de un solo turno.
- Para usuarios principiantes a quienes les cuesta escribir requisitos completos desde el inicio, la degradación de rendimiento en varios turnos podría ser una causa que limite la adopción de sistemas de IA.
1 comentarios
Opiniones en Hacker News
Para cualquiera que haya usado herramientas de LLM, es agradable que un paper confirme heurísticamente algo que ya sabía. Mantener un contexto limpio es importante, y la “conversación” no es más que una construcción creada por la interfaz del producto; perjudica la calidad de las respuestas del propio LLM. Una vez que el contexto queda contaminado, no se recupera, así que hay que volver a empezar con un chat nuevo
Hacia el final de esas dos semanas, el LLM estaba mucho menos disperso, e incluso cuando le pegaba hilos completos de foros o posts de Stack Overflow, distinguía: “esto no es el fenómeno que estamos viendo aquí; la razón es [contexto o hallazgo anterior]”. Yo tenía que descartar lógicamente los callejones sin salida y comunicárselo, pero al final encontré la causa.
También parece encajar con la idea de que los LLM son buenos para comprimir información compleja en algo simple, y malos para expandir ideas simples en algo complejo. Cuando la entrada era más grande o más compleja que la salida, el resultado era satisfactorio.
Podría haberlo hecho sin un LLM, pero me ayudó como una especie de repositorio cuando olvidaba hechos que había introducido desde el principio o no los recordaba rápido en un contexto nuevo, y también fue útil para encontrar patrones temporales en archivos de log grandes. No solo arreglé un problema, también optimicé varias configuraciones y aprendí bastante. A veces se equivocaba sobre el estado actual de los parámetros, pero era fácil de corregir. Si sabes hacia dónde vas y lo tratas como una herramienta, ayuda; pero no hay que delegarle la toma de decisiones ni dejar que te arrastre en la dirección equivocada.
El uso total fue de unos 350k tokens. Hay un post relacionado en el blog: https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/, aunque no coincide directamente con este problema específico. No acepto recomendaciones de WireGuard
Es muy probable que alguien haya ajustado recientemente el prompt para especificar una postura sobre el genocidio blanco; para un chatbot perfecto eso no debería importar cuando se le pregunta sobre otros temas, pero en la práctica sí importa. Como forma parte del contexto, ahora termina hablando de eso
Parece un aspecto de la conocida sobreconfianza y la incapacidad de introspección. Cuando la probabilidad previa es demasiado baja, no se da cuenta de que debería pedir información más detallada. Al ver la salida de los modelos de razonamiento, casi nunca surge la idea de hacer preguntas aclaratorias; cuando están confundidos, solo especulan sin fin sobre qué habrá querido decir el usuario.
Esto también tiene implicaciones para la sensatez de la idea de “reemplazar programadores humanos”. Una de las partes difíciles de este trabajo es interactuar con stakeholders y convertir ideas ambiguas y a menudo confusas en especificaciones precisas
En la mayoría de los casos, el usuario está escribiendo las líneas del personaje User en un documento de guion cinematográfico, y el algoritmo del LLM simplemente autocompleta periódicamente las líneas incompletas del personaje Chatbot.
Puedes entrevistar a un vampiro llamado DraculaBot, pero ese personaje solo puede “introspeccionar” de la misma forma superficial y ficticia en que “ansía sangre” o “se transforma en una bandada de murciélagos”
Por eso, cuando el autocompletado empieza a empeorar, hay que empezar de nuevo. No hay ningún concepto, solo una masa gigantesca de palabras vistas en el texto de entrenamiento y posibles textos posteriores
A menudo le pido al LLM que convierta la discusión hasta ese momento en un resumen conciso en formato de prompt. Si lo edito adecuadamente y lo uso para iniciar una nueva conversación sin carga, funciona muy bien. Probablemente pronto se automatice
Por eso terminaron creando TSCE (Two-Step Contextual Enrichment). Al probarlo con 300 tareas mezcladas usando GPT-35-turbo, hubo una mejora de +30 puntos porcentuales.
Es un framework gratuito y abierto, y se puede probar directamente desde el repositorio: https://github.com/AutomationOptimization/tsce_demo
Volvieron a hacer 300 pruebas en gpt-4.1 con la tarea de eliminar los molestos “em-dash” que la gente odia. Compararon una línea base de una sola pasada contra TSCE, con las mismas instrucciones y el prompt “Remove the em-dashes from my linkedin post. . .”
De 300 ejecuciones, la línea base falló 149/300 veces al eliminar los em-dash, mientras que TSCE falló 18/300 veces. Funciona, y todos los datos y el script completo de pruebas están en el repositorio.
text.replace("—", "-").Prompt del sistema:
"Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."Prompt del usuario:
Temperature: 0.0
He estado trabajando con bastante éxito en resolver este problema y pronto compartiré más. Tengo dos sistemas: el primero es el propio LLM, y el otro funciona como una especie de curador de pensamientos.
Inserta y quita dinámicamente partes del contexto, y depende de la capacidad del LLM de “llenar los huecos”, no de definiciones explícitas. Este sistema ayuda al LLM a descomponer el problema en tareas más pequeñas, y esas tareas pequeñas finalmente se agregan para formar la tarea completa.
Creo que en adelante esta separación de capas de memoria se volverá más clara. Podría dividirse como memoria primaria en los datos de entrenamiento, memoria secundaria en el contexto y memoria terciaria en RAG.
Me sorprende que la ramificación/fork no sea una función central en las principales herramientas de chat. Se puede editar una respuesta, pero al hacerlo se pierde mucho otro contexto.
Mi flujo es más o menos: 1) planificar 2) implementar 3) ramificar (por una función o un problema raro de dependencias) 4) volver al paso 2. La poda de prompts y la ramificación deberían ser herramientas de primera clase en cualquier uso de LLM.
Hay un problema evidente cuando se diseñan interfaces de LLM centradas en conversaciones de un solo turno. La mayoría de la gente espera una conversación lineal.
Creé un bot de Telegram http://t.me/experai_bot como UI general para LLM; reduje un poco las funciones y lo diseñé alrededor de la idea de que “un mensaje que no sea respuesta inicia una conversación nueva”. Si quieres mantener el contexto, solo tienes que seguir respondiendo a las respuestas del bot. A los usuarios no avanzados les cuesta entender este concepto.
También vi que, cuando los modelos de OpenAI responden la misma pregunta, incluso un mensaje de sistema muy pequeño puede empeorar el rendimiento. Por ejemplo, la lista de opciones en la respuesta se volvía más corta. Pasaba con 3.5 y 4o; no sé con los modelos más recientes. Por eso decidí no incluir mensajes de sistema por defecto. Aun así, se pueden agregar si hace falta, y también se pueden activar, desactivar y combinar.
Siento que ahora el espacio de los LLM está lleno de gente resolviendo una y otra vez los mismos problemas.
Esta fue la razón principal por la que hice promptdown. Quería poder editar todo el historial del chat en cada turno, y en la interfaz estándar de chat, donde solo se agrega contenido, eso no es fácil.
https://github.com/t-kalinowski/promptdown
Siempre sentí que parte de la burla hacia el término “ingeniería de prompts” viene de que la gente sobreestima la importancia del prompt inicial y subestima la importancia de gestionar el contexto en curso.
Con la experiencia vas desarrollando intuición sobre cómo dirigir el modelo y cuándo empezar una conversación nueva. El prompt de sistema o el prompt inicial también importan, pero si ingenuamente alargas demasiado una conversación, nada te va a salvar.