La compresión de memoria en agentes de IA borra hasta un tercio de las reglas de la tarea, y los benchmarks no lo detectan

La compresión de memoria en agentes de IA borra hasta un tercio de las

reglas de la tarea, y los benchmarks no lo detectan

Cuando un agente de IA trabaja en una tarea durante horas —digamos, escribiendo código o intentando reproducir un artículo científico—, tarde o temprano llena por completo su ventana de contexto disponible: la conversación, las llamadas a herramientas y los resultados de estas. Para seguir adelante, los desarrolladores de sistemas agénticos como Claude Code, Codex CLI, Cursor u OpenCode usan una técnica llamada "compresión de contexto" (compaction): se le pide al modelo que resuma brevemente todo lo hecho, se borra el historial antiguo y se continúa trabajando con ese resumen. El problema es que un resumen, por definición, pierde detalles, y no está claro qué se pierde exactamente ni cuán crítico es.

Eso es justo lo que decidieron comprobar los investigadores del Max Planck Institute for Intelligent Systems, Sahar Abdelnabi y Maksym Andriushchenko.

Para que el experimento fuera riguroso, fijaron una misma herramienta de "arnés" para los agentes —el proyecto abierto OpenCode—, de modo que las diferencias en los resultados no se explicaran por particularidades de distintas plataformas de software. Dentro de OpenCode implementaron cinco métodos distintos de compresión de contexto y probaron cuatro modelos de primer nivel —Claude Opus 4.6, GPT-5.

3-Codex, GPT-5.4 y Gemini 3.1 Pro Preview— en tres tareas prácticas largas: PaperBench (reproducir un artículo científico de ICML a partir de su descripción, sin acceso al código de los autores), ProgramBench (escribir desde cero una utilidad de consola, teniendo solo un ejecutable de muestra y documentación) y PostTrainBench (entrenar y afinar una pequeña red neuronal en una sola tarjeta gráfica durante 10 horas).

La ventana de contexto lo decide todo; el método de compresión, casi nada

La conclusión principal concierne a los dos modelos con ventana de un millón de tokens: Claude Opus 4.6 y GPT-5.4. Su resultado prácticamente no cambiaba, ya fuera que comprimieran la memoria cada 160.000 tokens o cada 380.000; la diferencia quedaba dentro del margen de error estadístico. En cambio, GPT-5.3-Codex, con una ventana de solo 400.000 tokens, mostraba un resultado notablemente peor en PaperBench cuando la compresión era temprana y frecuente: 0,38 puntos con un umbral de 160.000 tokens frente a 0,60 con umbrales de 260.000 o más, es decir, casi la mitad. En la tarea de escritura de código (ProgramBench) no hubo tal diferencia, y en PostTrainBench los resultados variaron demasiado como para sacar conclusiones.

También comprobaron por separado si alguna estrategia de compresión "más inteligente" ayudaba frente al simple resumen con sus propias palabras. Probaron cinco variantes: un resumen normal; un resumen normal más limpieza de resultados antiguos de llamadas a herramientas; guardar el historial completo en un archivo aparte en disco antes de comprimir (para teóricamente poder volver y releerlo todo); eliminar del historial los bloques de razonamiento del modelo antes de armar el resumen; y, finalmente, encargar el resumen a un modelo más económico —Claude Haiku 4.5— en lugar del modelo principal que ejecuta la tarea.

Ninguno de los métodos avanzados superó al resumen común en ningún benchmark. Además, las variantes más agresivas —eliminar el razonamiento y transferir el resumen a un modelo más pequeño— redujeron notablemente el resultado de algunos modelos en PaperBench, hasta 20 puntos, pero no afectaron en absoluto a otros modelos. Esto significa que un método de compresión que funciona bien con un modelo no se puede trasladar sin más a otro.

A dónde se van las reglas del juego

El hallazgo más preocupante no tiene que ver con el rendimiento, sino con la seguridad. En la tarea ProgramBench, al agente se le dan al principio tres reglas estrictas: no copiar ni enlazar el código fuente del programa de referencia, no salir a internet (en particular, para no descargar el código original) y escribir una implementación realmente original, no un envoltorio sobre una solución ya hecha. Estas reglas existen únicamente en el texto del primer mensaje; y si el resumen al comprimir no las repite, el agente simplemente las olvida, a diferencia del objetivo de la tarea y de su propio progreso, que se pueden releer desde archivos en disco.

Pues bien: ya después de la primera compresión del contexto desaparece en promedio aproximadamente una de las tres reglas. Después de la décima compresión, ya faltan dos de las tres. En sesiones reales de usuarios del conjunto de datos SWE-chat el panorama es similar: al comprimir se pierden las instrucciones sobre cómo debe trabajar el agente y qué no debe hacer, y se pierden alrededor de 6 veces más a menudo que los requisitos sobre qué hay que construir.

Por qué los tests actuales no lo notan

Los autores hacen una advertencia importante: los propios benchmarks con los que suelen evaluarse los agentes están diseñados de tal forma que las pérdidas por compresión se recuperan fácilmente. El objetivo de la tarea está fijo, el usuario no cambia nada sobre la marcha, y todo el progreso del agente se guarda en archivos en disco que se pueden releer en cualquier momento. Por eso, de todo lo que borra la compresión, lo único que realmente se pierde es lo que no está registrado en ningún otro lugar, sobre todo las restricciones y reglas mencionadas una sola vez al principio.

En conversaciones reales con usuarios, donde hay muchas más instrucciones y aclaraciones que no se guardan por separado, el costo de ese olvido es mucho mayor.

La conclusión práctica para los equipos que construyen sistemas agénticos: si la tarea es larga y las restricciones estrictas importan (no tocar la base de datos de producción, no salir a la red, no borrar archivos sin confirmación), no se puede confiar en que un resumen común las vaya a conservar; conviene o bien registrar explícitamente esas reglas por separado del historial general y releerlas en cada compresión, o bien elegir un modelo con margen de contexto amplio y comprimir con la menor frecuencia posible.