Presupuestar una ventana de contexto para una tarea larga

Qué es

La ventana de contexto es todo lo que el modelo ve en una llamada: el prompt del sistema, las definiciones de herramientas, la conversación hasta el momento, incluidos los resultados de herramientas, y los tokens que genera. La documentación del proveedor sobre ventanas de contexto describe cómo cuentan estos componentes para el límite y señala la compactación en el servidor como la estrategia para las conversaciones que se acercan a él. Dos propiedades convierten la ventana en un presupuesto y no en un contenedor. El artículo citado sobre contextos largos informa de que el rendimiento suele ser más alto cuando la información relevante aparece al principio o al final de la entrada, y se degrada cuando está en medio. La publicación técnica de Anthropic citada llama al mismo efecto «context rot»: a medida que aumentan los tokens en la ventana, disminuye la capacidad del modelo para recuperar información de ella.

Por qué importa

Una tarea larga (una refactorización de varios archivos, un informe de investigación, una migración) produce mucho más texto del que se necesita en un momento dado. Sin un presupuesto, la ventana se llena de resultados de herramientas antiguos, la instrucción dada al principio queda ahora en medio, y la respuesta se corta por el límite de salida. Cada uno de estos es un fallo silencioso: nada da error, el resultado simplemente es peor.

Cómo aplicarlo

• Dividir el presupuesto en cuatro partes y asignar un tamaño a cada una: fijo (prompt del sistema, definiciones de herramientas), material de la tarea (la especificación, los archivos dentro del alcance), conjunto de trabajo (resultados recientes de herramientas, como mucho unos pocos pasos de profundidad) y reserva (la respuesta más larga que pueda requerir la tarea más margen para una ronda más de herramientas).
• Colocar la especificación y los criterios de aceptación al principio; reformular el subobjetivo actual al final de cada turno, de modo que los dos extremos lleven lo que importa.
• Mantener el plan, el progreso y las decisiones en un archivo de borrador que el agente reescribe, y recargarlo después de cada compactación; los resúmenes de compactación tienen pérdida de información y no deberían ser la única copia.
• Fijar un punto de compactación bastante por debajo del límite y compactar por intención (qué se decidió, qué queda pendiente) en lugar de por cronología.
• Rastrear el uso a partir de los recuentos de tokens del proveedor en cada llamada, y detenerse para entregar o dividir la tarea cuando el conjunto de trabajo ya no quepa tras la compactación.
• Preferir varias tareas concretas con contextos nuevos a un único contexto que lo lleve todo.

Trampas

Llenar la ventana porque es grande. Compactar y perder los criterios de aceptación. Fijar el límite de salida por costumbre y truncar la respuesta final. Confiar en un resumen de compactación que descartó una incógnita, la cual luego se lee como resuelta.