Perdidos en el medio: por qué las ventanas de contexto largo fallan en silencio

Dale a un modelo un documento de cien páginas y pregúntale por algo de la página cincuenta: puede que no acierte con la respuesta, no porque el dato no esté en el contexto, sino por el lugar que ocupa.

La promesa y la trampa

Las ventanas de contexto más grandes venden una idea tentadora: basta con pegarlo todo y dejar que el modelo se las arregle. Sin recuperación, sin estructura: un único prompt gigante. Pero hay una distancia entre tener la información en la ventana y que el modelo realmente la use, y esa distancia crece con la longitud.

Lo que muestra la investigación

En Lost in the Middle: How Language Models Use Long Contexts, Liu y sus colegas midieron con qué acierto los modelos encuentran y usan la información según el lugar que ocupa en la entrada. Diseñaron dos pruebas deliberadamente controladas:

• QA multidocumento. El modelo recibe una pregunta junto a un montón de documentos —10, 20 o 30— de los cuales exactamente uno contiene la respuesta. Ese documento clave se va desplazando a todas las posiciones del montón y se mide la precisión en cada una.
• Recuperación clave-valor. Una prueba sintética despojada de todo ruido lingüístico: un objeto JSON extenso con cientos de pares clave-valor aleatorios, donde el modelo debe devolver el valor de una clave concreta, aislando así la búsqueda por posición pura de la comprensión.

En ambas tareas, y tanto en modelos abiertos como cerrados (GPT-3.5-Turbo, Claude, MPT-30B-Instruct, LongChat-13B), apareció la misma forma: la precisión es máxima cuando el elemento relevante está cerca del principio o del final del contexto y se hunde cuando el modelo tiene que buscar en el medio: una curva en forma de U.

Tres detalles lo empeoran más de lo que parece a primera vista. Se cumple incluso en modelos pensados para contexto largo: una ventana más grande no significa que el modelo la lea de manera uniforme. En el peor caso (el medio), la precisión multidocumento puede caer por debajo del punto de referencia a libro cerrado: el mismo modelo respondiendo sin ningún documento, solo con sus parámetros. Y dar a un modelo su propia versión de contexto ampliado no aportó ninguna ventaja cuando la entrada ya cabía en la ventana más pequeña: la capacidad extra no compró nada.

Una mitigación sí marcó la diferencia: la contextualización consciente de la consulta, es decir, repetir la pregunta tanto antes como después de los documentos. Casi resolvió la tarea sintética de clave-valor, pero apenas ayudó en el QA multidocumento real, así que no es una cura general. El modelo es sensible a la posición, no solo a la presencia.

Lo que significa para ti

Si dependes de pegar un historial largo, un documento extenso o un proyecto entero en un chat, la calidad de la respuesta del modelo depende en parte del azar: de dónde haya caído el pasaje relevante. A medida que el contexto crece, también crece el «medio» que se lee menos. Dos implicaciones prácticas:

• Muéstralo, no lo entierres. El material relevante debería llegar al modelo como un pasaje breve y bien situado, no escondido en el medio de un muro de texto.
• La estructura vence al volumen. Organizar y recuperar las piezas correctas supera de forma consistente a confiar en que una ventana más grande las lea todas.

Dónde encaja FocusLM

Por eso precisamente FocusLM guarda tu material como una memoria estructurada en lugar de un registro de chat que no para de crecer. En vez de amontonarlo todo en un único contexto y confiar en que el medio se lea, archiva lo que le aportas y hace aflorar las piezas relevantes y citadas cuando preguntas, de modo que la respuesta se apoya en el material adecuado, venga de donde venga.