Una ventana de contexto más grande no solucionará tus problemas con el agente: presupuesto de atención y caché

Un proveedor puede promocionar una ventana de contexto de un millón de tokens, pero el modelo seguirá utilizando una cantidad mucho menor de manera fiable. La prueba de rendimiento RULER de NVIDIA verifica la longitud a la que un modelo mantiene un buen desempeño. En dos de los diecisiete modelos que probó, Yi-34B y GPT-4 (versión de previsualización 1106), la longitud fiable resultó ser aproximadamente 32K de los 200K de tokens prometidos, y 64K de los 128K anunciados. Los modelos más débiles perdían su rendimiento ya en una fracción mínima de lo que indicaban sus especificaciones. Más allá de ese punto, el tamaño promocionado no es más que una cifra en la hoja de precios y no una capacidad real de producción.

Se observa el mismo fallo subyacente en varios lugares. Un agente olvida una decisión arquitectónica tomada en la primera interacción. Un sistema RAG obtiene el documento correcto y, aun así, responde erróneamente. Un resumen automático de la sesión omite precisamente la línea de configuración que se necesitaba. El reflejo habitual es aumentar el tamaño del contexto, pero eso falla para los agentes, ya que la capacidad nunca fue el problema. El verdadero problema radica en cómo el modelo distribuye su atención entre todo lo que ya está contenido dentro de esa capacidad.

La versión breve

La ventana de contexto no es una memoria uniforme. Es un recurso con un presupuesto de atención que se agota mucho antes del límite de tokens. El material al principio o al final del contexto se utiliza mejor que el material en el medio, hasta el punto de que un modelo al que se le entrega un documento oculto en medio del prompt puede responder peor que uno al que no se le da nada. Un caso concreto: un agente que recibe un largo registro de herramientas, un montón de fragmentos recuperados y sus instrucciones todo en un mismo prompt tenderá a dar prioridad a lo que está en los extremos y a desdibujar silenciosamente el resto.

Tres herramientas gestionan ese presupuesto, y cada una pierde algo diferente:

• Compresión de prompts elimina tokens con poca información. Funciona bien en pruebas de referencia, pero las reproducciones independientes muestran problemas con contenido estructurado como numeración, cadenas exactas y fragmentos de código.

Ventanas deslizantes y compactación controlan la duración de la sesión. La primera descarta las entradas más antiguas y la segunda las reemplaza por un resumen; sus pérdidas son diferentes.

Caché de prompts puede reducir el costo de entrada en aproximadamente un 90 por ciento sin perder información, siempre y cuando el prefijo sea idéntico en bytes entre las llamadas.

Aquí está la trampa: tanto la compresión como la compactación dañan el caché, y los ahorros en caché suelen superar a los de la compresión. Utilizar la herramienta incorrecta para el problema equivocado provoca fallos silenciosos en producción que son difíciles de diagnosticar posteriormente.

El contexto es un presupuesto, no almacenamiento

Primero, dos términos. Un token es la unidad de texto con la que trabaja el modelo; equivale aproximadamente a cuatro caracteres o tres cuartos de una palabra en inglés. La ventana de contexto es la cantidad máxima de tokens que se procesan en una sola llamada; se refiere más bien al tamaño máximo de la matriz de atención en un único paso que a la memoria disponible diariamente.

Andrej Karpathy ha descrito la ingeniería de contexto como el arte de llenar la ventana con exactamente lo que necesita el siguiente paso, teniendo al modelo como procesador y a la ventana como su memoria de trabajo. Esa analogía es útil pero solo abarca la mitad del asunto. La otra mitad se refiere al presupuesto de atención. Las directrices de Anthropic sobre la ingeniería de contexto para agentes tratan el contexto como un recurso finito cuyos beneficios disminuyen con el tiempo, donde cada token adicional consume una cantidad limitada de atención. Esto es aritmética y no poesía: las parejas de atención crecen de forma cuadrática, por lo que mil tokens implican aproximadamente un millón de relaciones, y cien mil implica diez mil millones.

Añadir contexto, por si acaso, nunca es gratuito. Tres ejemplos adicionales de tipo few-shot, un historial completo de conversaciones o veinte definiciones de herramientas en lugar de cinco provienen todos del mismo conjunto de datos que los hechos relevantes. La primera pregunta en una revisión de arquitectura no debería ser cuántos tokens están disponibles, sino qué parte del presupuesto realmente contribuye al logro del resultado.

La curva en forma de U

Liu y sus colegas (Stanford y Berkeley, 2023) midieron la precisión en la respuesta a preguntas con múltiples documentos y encontraron una forma de U. Las respuestas eran más fiables cuando el pasaje relevante aparecía al principio o al final, y menos fiables cuando estaba en el medio. El término “Perdido en el medio” se popularizó rápidamente, mucho antes de que surgiera cualquier explicación acordada al respecto.

Lo que realmente genera inquietud es un efecto secundario. Cuando la instrucción incluía veinte o treinta documentos, una respuesta correcta situada en medio del contexto obtenía una calificación más baja que la línea de referencia con información cerrada, en la cual el modelo no veía ningún documento. Entregar las pruebas adecuadas en el lugar incorrecto puede dejar al sistema en una situación peor que si no se le proporcionara nada.

Por qué ocurre: aún sin consenso

Años después no existe consenso sobre la causa. Coexisten varias explicaciones:

• un artefacto de los datos de entrenamiento, ya que los autores tienden a colocar los puntos clave al principio y al final,
• cómo se comportan la codificación posicional y el enmascaramiento causal,
• la geometría del decodificador que existe desde la inicialización, antes incluso de comenzar el entrenamiento,
• una adaptación que surge durante el preentrenamiento a medida que el modelo equilibra las demandas contradictorias de memoria.

Cada causa requiere un remedio diferente: otros datos de entrenamiento, otra máscara de atención, calibración de la atención o simplemente un prompt reordenado. Fusionarlos en una sola explicación clara sería engañoso.

Qué se ha resuelto y qué no

Preguntarse si el problema ya está resuelto lo presenta de manera errónea. La recuperación simple de hechos está en gran medida resuelta: los modelos más avanzados actuales pueden encontrar una información expresada literalmente en un conjunto muy grande de datos, sin importar dónde se encuentre. El razonamiento multietapa no está resuelto. Sintetizar varios documentos o editar código en un repositorio grande es una tarea diferente a localizar un solo hecho, y las evaluaciones publicadas de codificación con contexto largo muestran que las tasas de éxito disminuyen drásticamente a medida que aumenta la longitud de la entrada para el mismo modelo y tipo de tarea.

También existen pruebas en contra de que la curva sea universal. El estudio Context Rot de Chroma probó dieciocho modelos fronterizos y descubrió que un conjunto de datos mezclado e incoherente desde el punto de vista lógico superó a uno coherente en todos ellos, y sus experimentos tampoco reprodujeron una ventaja posicional consistente. La conclusión razonable es que existen más de un mecanismo de degradación, y Lost in the Middle es solo uno de ellos.

Una frase que elevó una puntuación del 27 % al 98 %

Anthropic presentó un caso ilustrativo con Claude 2.1 en una prueba de encontrar una aguja en un pajar. La precisión era del 27 por ciento hasta que se añadió una sola línea al inicio de la respuesta del modelo, indicándole que seleccionara la oración más relevante del contexto. Después de eso, la puntuación subió al 98 por ciento. No se añadió ninguna capacidad adicional; simplemente una instrucción cambió de lugar. Se trató de una sola evaluación, con una versión del modelo y un tipo de tarea específicos, por lo que debe considerarse como una ilustración y no como una regla aplicable a todos los prompts.

El mecanismo: sumideros de atención

Los tokens iniciales de una secuencia absorben una proporción desproporcionada de atención, independientemente de si contienen contenido relevante o no. La causa es la matemática básica: el algoritmo Softmax hace que las ponderaciones de atención sumen uno, por lo que el modelo debe dirigir toda su atención a algún lugar, incluso cuando nada en ese punto la merece. No existe la opción de abstenerse, y las posiciones iniciales se convierten en un lugar donde se descarta esa atención. A estos se les denomina sumideros de atención.

Un equipo del MIT (Xiao y sus colegas) convirtió esta peculiaridad en una herramienta. Descubrieron que una ventana deslizante simple colapsa justo en el momento en que el primer token es eliminado del caché. Al fijar solo los primeros pocos tokens como sumideros estáticos, se mantiene la generación estable incluso con flujos de millones de tokens, lo que permite un rendimiento hasta 22.2 veces mayor que volver a calcular cada ventana. Los resúmenes populares suelen pasar por alto un límite: no se añaden tokens reales a la memoria. La salida sigue siendo fluida mientras los tokens antiguos desaparecen, y cualquier dato que se salga de la ventana se pierde para siempre. La estabilidad y la memoria son cosas distintas.

Por lo tanto, el consejo práctico es colocar la instrucción clave donde la atención sea más intensa, generalmente al final, y medir en su propia configuración. Esto no es universal: algunas investigaciones muestran que los sumideros que aparecen a mitad de la secuencia son mejor suprimidos que protegidos, y el comportamiento varía según el modelo.

Compresión, ventana y compactación

Imagínese una maleta que no cabe todo. Puede descartar los artículos menos importantes, empacar solo los más recientes o escribir una nota sobre lo que se quedó en casa. Cada opción implica perder algo diferente.

Compresión rápida

La familia LLMLingua evalúa el nivel de sorpresa de cada token con un pequeño modelo auxiliar y elimina aquellos con poca información. Las cifras son impresionantes: hasta 20 veces más compresión con LLMLingua, y en el caso de LongLLMLingua, que tiene en cuenta la consulta, se logra una mejora del 21.4 por ciento en NaturalQuestions utilizando solo una cuarta parte de los tokens. Se trata de dos variantes y no de un único resultado.

Las reproducciones independientes complican la situación. Un informe presentado contra el repositorio de referencia indicó que el prompt sin comprimir superaba claramente al comprimido, lo cual es lo opuesto a lo señalado en el artículo. Otro estudio sobre la compresión en este campo reveló que la precisión al contar fragmentos disminuía drásticamente, ya que la compresión destruye los números de secuencia y las cadenas exactas. La conclusión no es que la compresión falle, sino que su fiabilidad es cuestionable y depende del tipo de datos. El texto narrativo la tolera bien, mientras que los pasajes numerados, identificadores, código y números no lo hacen.

Tres formas de gestionar una sesión

• Ventana deslizante. Método simple de primero en entrar, primero en salir: se conservan los últimos k mensajes o N tokens y se descartan el resto. No implica costos computacionales, pero genera pérdidas significativas; así, una decisión tomada en la primera fase desaparece para la quinta y el modelo podría proponer algo que la contradiga.

Compresión. Sustituir la conversación anterior por un resumen. El riesgo es que el resumen sea tan exhaustivo que se pierdan detalles cuya importancia se hace evidente más adelante. Los umbrales varían mucho entre las herramientas, pero una recomendación común es activar la compresión cuando se alcance entre el 70 y el 75 por ciento de la capacidad, y no el 95, ya que un modelo sin espacio libre genera un resumen de peor calidad.

Memoria externa. En el estilo de MemGPT, los datos se encuentran fuera de la ventana y el modelo los recupera mediante una llamada a función cuando es necesario. Nada se pierde de forma permanente, pero cada recuperación genera latencia y una llamada adicional al modelo, además de que este debe saber de antemano si un dato en particular merece ser recuperado, lo cual también es una zona propensa a errores. Úsela para datos que deben poder recuperarse bajo demanda, como las preferencias del usuario o decisiones anteriores, y no para todo.

La trampa: la compresión anula el descuento del caché

Con el caché instantáneo, el proveedor recuerda la versión inmutable de tu consulta y cobra por las lecturas posteriores una fracción mínima de la tarifa habitual. El caché KV almacena el estado calculado de los tokens anteriores para que el modelo no tenga que volver a realizar ese trabajo.

El precio de este descuento es la rigidez: el prefijo debe ser idéntico en todos los llamados. Esto descarta el uso de una marca de tiempo variable al principio, un ID de sesión aleatorio antes de las instrucciones o claves reorganizadas en un diccionario JSON. Todo lo variable debe ir en la parte volátil. Los equipos que utilizan agentes de producción han considerado la tasa de aciertos del caché como su métrica de sistema más importante, ya que existe una diferencia de costos de aproximadamente diez veces entre un acierto y un fallo.

Aquí es cuando la trampa se cierra. La compresión reescribe el prompt en cada llamada, ya que los tokens que elimina dependen de la pregunta planteada, por lo que cada solicitud representa una falta en el caché. Un ahorro de aproximadamente el sesenta por ciento en tokens se ve compensado por la pérdida del descuento del noventa por ciento, y pierde esa ventaja con más frecuencia de lo que suponen los equipos.

En el material de marketing circula un anécdota sobre una factura mensual que pasó de unos 42,000 dólares a 2,100 dólares tras implementar la compresión, sin indicarse ninguna empresa, fecha ni método. Es imposible saber si esa comparación incluía la pérdida del caché, que es precisamente la variable que determina si se repite un resultado así.

Un plan para el lunes

Esta lista no sustituye las pruebas con sus propios datos. Evita el error más común, que es recurrir a la compresión o a un período de tiempo más largo antes de examinar opciones más económicas y seguras.

1. Clasifique la tarea. ¿Es una simple recuperación de datos o un razonamiento en múltiples pasos con un contexto extenso? Eso determina cuán grave es realmente la degradación posicional.
2. Verifique dónde se encuentra la instrucción clave. Si está oculta en medio del prompt, muévala al final y mida los resultados. Se trata de un cambio de una sola oración y es la única opción disponible en este caso.
3. Verifique la estabilidad del prefijo. Cuando el prompt del sistema difiere aunque sea en un byte entre una llamada y otra, el caché no sirve de nada, por lo que reparar eso es lo primero. Se aborda con menos frecuencia en las revisiones que la elección del modelo, aunque puede influir más en los resultados.

Nombrar el problema antes de elegir una herramienta. Los problemas relacionados con los costos implican verificar la caché antes de realizar la compresión. Una calidad que empeora a lo largo de una sesión larga sugiere una compresión al nivel del 70 al 75 por ciento. Olvidar hechos específicos indica la necesidad de un sistema de ventana deslizante o de memoria externa, dependiendo de si esos hechos deben recuperarse bajo demanda.

Si aún utiliza la compresión, pruébela con sus propios datos, en particular con datos que contengan números exactos, identificadores y código, ya que los resultados publicados con frecuencia no se reproducen en esos casos.

Qué llevarse como conclusión

Una ventana más grande no soluciona los problemas de un agente, ya que solo aumenta la capacidad de un recurso cuyo problema nunca fue la falta de capacidad.

• La ventana representa un presupuesto de atención y no almacenamiento; cada token añadido por precaución resta recursos del conjunto destinado a los elementos importantes.

El debate sobre los modelos “Lost in the Middle” se plantea de forma errónea: la recuperación de datos se maneja en gran medida con modelos de vanguardia, mientras que el razonamiento multietapa sobre contextos extensos sigue mostrando una degradación notable.

La posición geográfica es la herramienta más económica que se tiene, así que verifica primero esta opción antes de invertir en algo más costoso.

La compresión presenta debilidades documentadas en pruebas independientes, especialmente para contenidos que deben conservarse tal cual.

El almacenamiento en caché y la compresión se anulan económicamente, por lo que primero debes calcular los ahorros que generan cada uno.

El verdadero cambio en el trabajo diario radica en el orden de las preguntas durante una revisión de diseño. Primero, pregunte qué contiene el contexto y dónde se encuentra cada elemento, y solo después cuán grande es. Si invierte el orden, terminará teniendo un espacio mayor que simplemente hace que los hechos importantes desaparezcan en un área más amplia. Una regla práctica a recordar: primero inspeccione la posición, luego la estabilidad del prefijo, después el volumen, y únicamente al final considere la compresión.