Programación y agentes de IA

[Contexto de IA #1] ¿Por qué los agentes olvidan las instrucciones?

Al usar un agente de programación como Claude Code, aparece abajo una advertencia como «Context left until auto-compact: 8%». Es un indicador que no suele verse en la IA conversacional. Sin embargo, pocas personas pueden explicar por qué disminuye ese número o qué ocurre cuando llega a 0.

7 min de lectura
Imagen de portada de [Contexto de IA #1] ¿Por qué los agentes olvidan las instrucciones?

Al usar un agente de programación como Claude Code, aparece abajo la advertencia «Context left until auto-compact: 8%». Es un indicador que no suele verse en la IA conversacional. Pocas personas pueden explicar por qué disminuye o qué ocurre al llegar a 0. Si al principio de la sesión dejaste claro «no toques las pruebas» y una hora después el agente modifica tranquilamente un archivo de pruebas, casi seguro está relacionado con ese número.

Este artículo es la primera entrega de una serie sobre el contexto de los agentes de IA, desde sus fundamentos hasta la práctica. Cuándo usar /compact o /clear y por qué dividir el trabajo con subagentes son técnicas basadas en una misma restricción: «la ventana de contexto es finita». Por eso empezamos desde la base: qué es exactamente la ventana de contexto y por qué no puede crecer indefinidamente, explicado mediante tres claves: tokens, atención y caché KV.

Tokens, la unidad con la que la IA cuenta el texto

La unidad de la ventana de contexto no es el carácter ni la palabra, sino el token. Un LLM no lee el texto completo; recibe una secuencia de fragmentos divididos por el tokenizador. El criterio de división pertenece a la familia de algoritmos BPE (Byte Pair Encoding) y es sencillo: las combinaciones de caracteres que aparecen juntas con frecuencia en los datos de entrenamiento se agrupan en una sola pieza. Combinaciones comunes como «the» o «ing» forman un token, mientras que las palabras raras se dividen en varios fragmentos.

Aquí hay un dato importante para los usuarios de coreano. Como los datos de entrenamiento del tokenizador contienen una proporción abrumadora de inglés, el mismo contenido suele consumir entre 1,5 y 2 veces más tokens en coreano que en inglés. Una «ventana de contexto de 200.000 tokens» equivale a dos novelas largas en documentos en inglés, pero su capacidad percibida se reduce mucho al introducir documentos en coreano.

La ventana de contexto es la «cantidad máxima que el modelo puede leer de una vez», medida en tokens. El prompt del sistema, el historial de conversación, los documentos adjuntos y la respuesta que el modelo está generando deben caber dentro de ese límite.

¿Por qué el contexto de los agentes se llena tan rápido?

Lo primero que hay que saber sobre un LLM es que el modelo es una máquina sin estado (stateless). Tras procesar una solicitud, no guarda su contenido en ningún sitio. Para el modelo no existió ni la conversación de ayer ni siquiera el turno inmediatamente anterior.

Entonces, ¿cómo continúa la conversación? La respuesta es desarmantemente simple: la aplicación vuelve a enviar en cada turno todo el historial, desde el prompt del sistema hasta el momento actual. Al escribir la décima respuesta, el modelo no «recuerda» las nueve anteriores; acaba de releerlas desde el principio.

En una IA conversacional, el historial solo contiene las frases escritas por la persona y las respuestas del modelo, por lo que crece lentamente. En un agente es distinto: cada turno incluye llamadas a herramientas. Leer un archivo añade todo su contenido al contexto; ejecutar pruebas añade cientos de líneas de logs de error; buscar añade todos los resultados. El usuario solo escribió «corrige el bug», pero si el agente lee diez archivos y ejecuta la compilación tres veces, ese turno consume decenas de miles de tokens. Por eso los agentes de programación muestran el contexto restante: lo que tardaría días en agotarse en un chat puede consumirse en una o dos horas con un agente.

Un solo turno de llamadas a herramientas puede acumular decenas de miles de tokens, y cada turno vuelve a enviar el contenido completo
Un solo turno de llamadas a herramientas puede acumular decenas de miles de tokens, y cada turno vuelve a enviar el contenido completo

Cuando se alcanza el límite, la aplicación debe descartar algo. Puede recortar los turnos antiguos o comprimirlos en un resumen. Si en ese proceso queda fuera una instrucción como «no toques las pruebas», definida al inicio de la sesión, el modelo empieza el siguiente turno como si nunca hubiera hecho esa promesa. No ha empeorado su memoria: simplemente no tiene memoria y la instrucción quedó fuera de lo que puede leer.

Primera razón de la finitud: el coste cuadrático de la atención

Entonces, ¿por qué no ampliar la ventana hasta unos 100 millones de tokens? La atención (attention), operación central del Transformer, lo impide.

La atención calcula, al procesar un token nuevo, cuánto se relaciona con todos los tokens anteriores. Si en el código aparece la variable user, esta capacidad permite conectarla con su declaración 3.000 líneas atrás. Es la razón por la que un LLM parece entender el contexto y, al mismo tiempo, el origen del coste.

Como cada token observa a todos los demás, la cantidad de cómputo crece con el cuadrado de la longitud. Si el contexto se multiplica por 10, las operaciones de atención se multiplican por 100. Gracias a optimizaciones como la atención dispersa, las ventanas deslizantes y FlashAttention ya existen modelos de 1 millón de tokens, pero permanece el hecho fundamental: consultar todo el contexto tiene un coste que crece bruscamente con la longitud.

Segunda razón de la finitud: la factura de memoria de la caché KV

El cómputo no es el único problema. En memoria llega otra factura: la caché KV (Key-Value cache).

Recalcular todo el contexto desde cero cada vez que el modelo genera un token sería ineficiente. Por eso guarda en la memoria de la GPU los resultados intermedios de atención calculados para cada token (vectores Key y Value) y los reutiliza. Eso es la caché KV. El problema es que se acumula por capa y por cabeza de atención, y crece proporcionalmente a la longitud del contexto.

Como referencia, un modelo de código abierto de unos 70.000 millones de parámetros usa alrededor de 300 KB de caché KV por token incluso con GQA, una técnica de ahorro de memoria. Al llenar el contexto con 128.000 tokens, solo la caché ocupa unos 40 GB: consume por completo la memoria de una GPU avanzada, aparte de los pesos del modelo. Por eso ampliar la ventana de contexto es un problema de hardware y dinero, no solo una configuración de software.

Este coste se refleja directamente en la tarifa del usuario. La API de LLM cobra según el número de tokens de entrada y, al combinarlo con el reenvío del historial completo en cada turno, se entiende por qué las sesiones largas se vuelven más caras y lentas hacia el final.

La memoria de un modelo stateless se relee desde el principio en cada turno: cuanto más larga, más lenta y cara
La memoria de un modelo stateless se relee desde el principio en cada turno: cuanto más larga, más lenta y cara

Resumen

  • La ventana de contexto es el máximo número de tokens que el modelo puede leer de una vez. El coreano usa entre 1,5 y 2 veces más tokens que el inglés, así que no conviene tomar literalmente la cifra de la especificación.
  • Los LLM son stateless. La memoria de la conversación consiste en reenviar todo el historial en cada turno, y los agentes también acumulan los resultados de las herramientas; por eso el contexto se llena mucho más rápido que en un chat.
  • La ventana es finita porque la atención crece con el cuadrado de la longitud y la caché KV ocupa memoria de la GPU en proporción a ella. El contexto es capacidad, pero también coste.

En la próxima entrega desmontaremos una idea común: que cuanto mayor sea el contexto, mejor. Varios estudios han confirmado que el rendimiento del modelo disminuye cuando el contexto se alarga. Trataremos lost in the middle, context rot y por qué la cifra de la especificación no coincide con la capacidad efectiva.

Seguir leyendo