Capítulo 9 — Administrando el presupuesto de atención

Novena entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que una ventana de contexto de un millón de tokens resulta ser un valor techo, no un punto de operación, y una parte notable de "el modelo ha empeorado" resulta ser "al modelo lo han enterrado".

Por qué existe este capítulo

Una ventana de contexto parece espacio gratis. No lo es. Cada token que un agente lee cuesta latencia, dinero y — menos obvio pero más importante — calidad. La ilusión de que una ventana de un millón significa "métele todo" es una de las malinterpretaciones más caras de la práctica actual, y explica buena parte de los fallos de producción que se diagnostican como regresiones de modelo. El modelo no empeoró. Lo enterraron. Este capítulo trata de tratar el contexto como un presupuesto finito en vez de como un recurso libre: qué se come el presupuesto, qué alternativas existen cuando el presupuesto es la herramienta equivocada, y cómo aterrizar en la zona productiva donde el agente tiene exactamente lo que necesita y nada más.

9.1 Context rot y el acantilado no lineal

La relación entre longitud de contexto y calidad no es lineal. Doblar el prompt no parte la calidad por la mitad; pasado un punto la parte por más de la mitad. El nombre técnico que ha cuajado — context rot — es informal pero exacto. El estudio clásico de Stanford de Liu y colegas mostró que los modelos a los que se les pide encontrar información en una lista de documentos rinden dramáticamente peor cuando el documento relevante está en el medio que cuando está en cualquiera de los extremos. La curva con forma de U se ha reproducido en familias de modelos y longitudes de contexto. El medio de un prompt largo es, en sentido relevante, atencionalmente más barato que los bordes, aunque la arquitectura trate cada posición de forma idéntica.

Los benchmarks de "aguja en un pajar" que se volvieron estándar en 2023 y 2024 parecieron al principio refutar esta imagen — recuperación casi perfecta a 100K, 200K, incluso 1M tokens. El trabajo de seguimiento más cuidadoso mostró que los benchmarks eran demasiado fáciles. Una aguja conspicua en un pajar homogéneo es un problema distinto a encontrar un hecho relevante enterrado entre veinte distractores temáticamente próximos. MCP-Universe y BIG-Bench-Long, publicados a finales de 2025, incorporan esa estructura adversaria, y los números desencantan: a 100K tokens, los modelos de frontera pierden de diez a veinte puntos comparados con la misma tarea a 8K, y a 500K la brecha puede alcanzar los cuarenta.

Hay una segunda forma de rot específica de los agentes MCP. A medida que las herramientas se acumulan en el system prompt, la precisión del modelo al seleccionar la herramienta correcta se degrada. MCP-Universe mostró la precisión de selección de herramienta caer de aproximadamente noventa por ciento con cinco herramientas a por debajo del sesenta con cuarenta. Los profesionales lo llaman ahora tool-loadout rot, y es la causa más común de "el agente se volvió más tonto cuando añadimos más capacidades". El mecanismo es el mismo en ambos casos: la atención es finita, y a medida que el prompt crece, la porción que cada token recibe se encoge.

9.2 Tres respuestas a la misma pregunta: MCP, RAG, fine-tuning

Cuando a un modelo le falta el conocimiento que necesita, hay tres respuestas arquitectónicas, y confundir una con otra es la causa de una porción notable del esfuerzo mal asignado. MCP encaja cuando el conocimiento es operativo — inventario actual, calendario de hoy, estado de un build. Tienen una fuente autoritativa, cambian continuamente, y ningún contexto pre-cargado puede mantenerlo al día. La victoria no es sólo frescura sino responsabilidad: cuando el modelo dice "el build está verde", el usuario puede preguntar "según qué" y la respuesta es "el servidor de build, consultado en este timestamp".

RAG encaja cuando el conocimiento es documental — un corpus demasiado grande para la ventana pero lo bastante estable como para que un índice de recuperación sea viable. Documentación interna, artículos de soporte, contratos, bases de código grandes. El Volumen III de esta serie estuvo dedicado entero a la ingeniería de RAG y sigue siendo la referencia canónica. El fine-tuning encaja cuando el hueco es de comportamiento — formato consistente, voz particular, rechazo fiable de una clase de petición. La asignación errónea que se repite en la industria es usar fine-tuning para inyectar conocimiento fáctico que cambia, lo que produce un modelo brevemente impresionante y progresivamente equivocado a medida que el mundo se aleja de su instantánea congelada.

Las tres no son excluyentes. Un agente maduro habitualmente las combina: fine-tuning para comportamiento, RAG para conocimiento documental, MCP para conocimiento operativo. El encuadre que ayuda es el sustrato correcto para el requisito de frescura correcto. El comportamiento es estable a escala de generaciones de modelo; cuécelo en los pesos. El conocimiento documental cambia a escala de días; indéxalo. El conocimiento operativo cambia a escala de segundos; alcánzalo a través de herramientas. Las arquitecturas que desencajan el sustrato — pesos congelados para hechos que cambian rápido, índices de recuperación para estado vivo — pagan un coste en corrección, latencia o ambos.

9.3 La zona Goldilocks: bastante contexto, no demasiado

La pregunta del día a día es cuánto contexto pasar en cada llamada. La zona en el medio es más estrecha de lo que la mayoría de los equipos asume al principio. La palanca más consecuente es el system prompt. Uno bueno es corto, específico, estable. Uno malo es el prompt defensivo que crece por acreción, con una cláusula añadida cada vez que el modelo se porta mal, hasta que es un documento de mil palabras de reglas que el modelo ya no puede seguir de manera fiable. Los equipos que auditan trimestralmente con la eliminación como objetivo explícito acaban con prompts más cortos que un año antes y mejor comportamiento.

La segunda palanca es el roster de herramientas. La corrección al tool-loadout rot es la revelación progresiva: registra un número pequeño de herramientas de alto nivel y deja al modelo profundizar en los detalles a través de una herramienta de descubrimiento. Cuarenta herramientas estrechas se convierten en cuatro amplias con dispatch interno, y la precisión de selección recupera la mayor parte de lo perdido. La tercera palanca es el historial de conversación — compáctalo desde el turno uno, no al noventa por ciento de capacidad de ventana. La cuarta son los resultados de herramientas: devuelve los campos que el modelo necesita, no toda la fila. La disciplina es la inclusión deliberada: para cada elemento, el equipo debería poder contestar "¿qué pasaría si esto no estuviera?". Si la respuesta es "el agente se comportaría igual", debería quitarse.

Lo que prepara el Capítulo 9

Este capítulo encuadró el contexto como presupuesto finito dentro de una sola llamada de inferencia. Lo que no cubrió es la cuestión del tiempo. Un agente que corre treinta segundos tiene un problema de presupuesto que cabe en una sola ventana. Un agente que corre treinta minutos, tres horas, tres días tiene un problema de memoria que ninguna ventana de tamaño práctico puede contener. Las estrategias para esa escala de trabajo son distintas en clase, no sólo en grado.

Próximamente — Capítulo 10: Memoria de tareas de horizonte largo. Mecanismos a corto plazo mediante ventanas deslizantes y scratchpads ReAct, mecanismos a largo plazo mediante vectores episódicos y almacenes semánticos, y las técnicas de compactación que permiten a un agente operar a lo largo de horas y días.