El tiempo que llevo trabajando con LLMs, cada vez me encuentro más en la batalla eterna entre el contexto suficiente, el contexto excesivo, el desperdicio de tokens y la guerra de compresión; al observar los sistemas de memoria agentiva, podemos ver que existen armas poderosas que ayudan en esto.
El hallazgo que sigue apareciendo en los 19 sistemas que analicé es que las ventanas más grandes intensifican el problema del presupuesto en lugar de disolverlo. Una ventana de 200 mil tokens no presta la misma atención a los 200 mil tokens. El rendimiento se degrada mucho antes de que la ventana se llene. La degradación no es uniforme: el material en medio de un contexto largo recibe menos atención de manera confiable que el material en los extremos. Y la tarea real del agente ocupa una porción fija de la ventana, sin importar el tamaño de esta, lo que significa que todo lo demás es gasto general que compite por el mismo presupuesto de atención.
Los sistemas que manejan esto bien han convergido en seis mecanismos. Ninguno de ellos es exótico. Varios son vergonzosamente simples. Pero aquellos que los omiten pagan las consecuencias.
Los seis mecanismos
Pases de compresión
El mecanismo más visible. Tomas una conversación larga o un segmento de memoria grande, lo resumes y reemplazas el original con el resumen. MemoryOS hace esto a nivel de segmento: su resumidor de segmentos se activa cuando un segmento de conversación supera un umbral, colapsándolo a una representación compacta antes de que pueda desplazar el contexto de trabajo. Las wikis del patrón Karpathy (purpose.md, overview.md) hacen una versión de esto a nivel de conocimiento: la wiki es la forma compactada de todo lo que el agente ha aprendido sobre un tema, mantenida a través de las sesiones.
La compensación es la pérdida de información. La compresión es una operación con pérdida por definición. El resumen captura lo que el resumidor consideró relevante en el momento de la compresión. Si el agente luego necesita un detalle que no se consideró relevante, desaparece. Esto no es una razón para evitar la compresión, pero sí es una razón para no tratarla como el único mecanismo.
Hay un segundo costo que es fácil pasar por alto. La compresión no es gratuita en tiempo de ejecución. MemoryOS puede pagar 20 o más llamadas al LLM en una sola interacción para mantener sus resúmenes de segmentos. Para sistemas con alta frecuencia de interacción, ese es un costo operativo real.
Truncamiento con vista previa de resultados
En lugar de devolver el contenido completo de la memoria en cada recuperación, devuelve una vista previa corta y deja que el agente decida si obtener el registro completo. Supermemory expone controles de longitud de fragmentos que permiten a los llamantes ajustar cuánto texto regresa por resultado. Mem9 va más allá: decora los turnos de origen con tres variables de entorno (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT) que brindan a los operadores un control preciso sobre cuántos turnos de origen aparecen y con qué puntuación de relevancia mínima.
La compensación es una llamada a herramienta adicional. Si el agente necesita el contenido completo, tiene que pedirlo explícitamente. Para la mayoría de los patrones de recuperación, esta es la compensación correcta: el agente obtiene suficiente señal para decidir si el registro es relevante antes de pagar el costo de tokens de leerlo completo.
Recuperación en dos pasos
Una variante específica e importante del truncamiento con vista previa. La búsqueda devuelve identificadores y vistas previas cortas. Una llamada separada de GetByID obtiene el registro completo cuando sea necesario. La interfaz MemoryRepo de Mem9 está construida alrededor de este patrón: buscar y obtener son operaciones distintas con huellas de tokens distintas.
Los números lo dejan claro. Diez coincidencias de 1,500 tokens cada una son 15,000 tokens inyectados en el contexto, los use el agente o no. La recuperación en dos pasos devuelve 10 identificadores y vistas previas cortas con aproximadamente 450 tokens en total, y luego obtiene solo los registros que el agente realmente necesita. A lo largo de 20 pasos de recuperación en una sesión, esa diferencia se acumula hasta alrededor de 200,000 tokens ahorrados.
Esta es la disciplina más económica que puedes adoptar. No requiere ningún cambio arquitectónico en el almacén de memoria, ni llamadas adicionales al LLM, ni pérdida de información. Es una decisión de interfaz de recuperación.
Descomponer y luego recordar
En lugar de enviar la consulta completa del usuario a la capa de recuperación, descompónla primero en subconsultas. El planificador de recuperación consciente de intenciones de SimpleMem divide las consultas entrantes en intenciones de recuperación atómicas antes de acceder al almacén de memoria. GitNexus hace algo similar con su descomposición de herramientas de consulta: las consultas complejas se dividen en subconsultas específicas, cada una de las cuales recupera una porción enfocada del grafo de memoria.
El beneficio es la precisión. Una consulta descompuesta recupera menos material irrelevante, lo que significa menos ruido en el contexto. La compensación es la latencia: la descomposición agrega un paso de planificación antes de que comience la recuperación. Para agentes interactivos, esto importa. Para agentes por lotes o en segundo plano, generalmente no.
Almacenamiento por niveles como filtro de presupuesto
Si ya has construido una arquitectura de memoria por niveles (el tema del artículo de la semana pasada), obtienes el filtrado de presupuesto como efecto secundario. El modelo de tres niveles de Supermemory significa que el material activo, de acceso frecuente, vive en un nivel que devuelve resultados compactos y de alta señal. El material frío está en un nivel que no se consulta por defecto. El nivel de observación de Hindsight funciona de la misma manera: las observaciones brutas no se inyectan directamente en el contexto; se promueven a niveles superiores antes de convertirse en candidatos de recuperación.
La compensación es la integridad de la recuperación. El material que no ha sido promovido puede ser relevante, pero no aparecerá en un pase de recuperación estándar. Esta es la misma compensación que la compresión, pero el modo de fallo es diferente: en lugar de perder información a través del resumen, la pierdes a través de la degradación.
Respuestas de herramientas autoguiadas
El mecanismo menos discutido, y uno de los más interesantes. En lugar de dejar que el agente decida qué hacer después de una llamada a herramienta, la respuesta de la herramienta incluye una pista sobre qué hacer a continuación. GitNexus agrega un bloque ---
**Siguiente:**\ a las respuestas de las herramientas, sugiriendo acciones de seguimiento. Mem9 decora los turnos de origen con metadatos estructurados que guían el siguiente paso de recuperación del agente.
El efecto es que el agente gasta menos tokens en planificación entre llamadas a herramientas. La respuesta de la herramienta lleva suficiente estructura para hacer obvio el siguiente paso. La compensación es el esfuerzo de ingeniería de prompts: escribir buenas respuestas autoguiadas requiere saber de antemano qué es probable que necesite el agente a continuación, lo que no siempre es posible.
El caso límite de Tolaria
Vale la pena analizar Tolaria por separado porque representa el punto final lógico de la disciplina presupuestaria llevada al extremo. ADR-0009 documenta la decisión de eliminar por completo los embeddings del sistema. Tolaria usa solo búsqueda por subcadenas. Sin índice vectorial, sin recuperación semántica, sin llamadas a embeddings.
El razonamiento es directo: el token más barato es el que nunca recuperas en primer lugar. La recuperación basada en embeddings devuelve resultados semánticamente similares, lo que significa que devuelve resultados que el agente no pidió explícitamente. Algunos de esos resultados son útiles. Muchos no lo son. Todos cuestan tokens.
La postura de Tolaria es que el costo de los resultados irrelevantes pero similares, acumulado a lo largo de una sesión, supera el beneficio de la recuperación semántica para su caso de uso. Si esa compensación se aplica a tu sistema depende de para qué sirve tu sistema. Para sistemas donde las consultas son precisas y estructuradas (navegación de código, búsqueda de documentos por identificador), la postura de Tolaria es defendible. Para sistemas donde las consultas son vagas y exploratorias, eliminar los embeddings rompe la recuperación de maneras difíciles de recuperar.
El valor del caso de Tolaria no es que debas copiarlo. Es que hace visible el costo de la recuperación semántica de una manera que la mayoría de los sistemas no lo hacen.
El caso contra los sistemas solo de compresión
Varios de los 19 sistemas dependen de la compresión como su mecanismo presupuestario principal o único. Vale la pena nombrar los modos de fallo.
El primero es que el resumen pierde detalles que no se consideraron relevantes en el momento de la compresión pero que se vuelven relevantes después. Esto no es hipotético: es el modo de fallo estándar de cualquier esquema de compresión con pérdida aplicado a información cuya relevancia futura se desconoce.
El segundo es que la compresión es un costo en la ruta crítica. Que MemoryOS pague 20 o más llamadas al LLM por interacción no es inusual para sistemas con mucha compresión. A escala, ese costo no es despreciable.
El tercero, y el más sutil, es que la compresión sin una vía de escape es olvido lento. Si la única forma de reducir el tamaño del contexto es resumir, y los resúmenes tienen pérdida, entonces el sistema está descartando información continuamente sin forma de recuperarla. La recuperación en dos pasos, el almacenamiento por niveles y el truncamiento con vista previa de resultados preservan el registro original. La compresión no.
Nada de esto significa que la compresión sea incorrecta. Significa que la compresión sola no es suficiente.
Ponderación por actualidad y la cola persistente
Dos mecanismos que no encajan claramente en las seis categorías anteriores merecen ser mencionados.
Graymatter usa fusión RRF con ponderación por actualidad a la mitad. Esto no es un mecanismo presupuestario en sentido estricto, pero funciona como tal: al reducir el peso del material más antiguo en las clasificaciones de recuperación, disminuye la probabilidad de que registros obsoletos y de baja señal desplacen a los recientes y de alta señal. El efecto es una categorización suave a través de pesos de clasificación en lugar de una promoción explícita de niveles.
La máquina de estado de cola de ingesta de 540 líneas de llm-wiki adopta un enfoque diferente. La cola serializa las operaciones de ingesta y aplica un clasificador de relevancia de cuatro señales antes de que algo entre al almacén de memoria. El control del presupuesto ocurre en el momento de escritura en lugar del momento de lectura. El material que no supera el umbral de relevancia no se almacena, lo que significa que no se puede recuperar y no puede consumir contexto. Esto es control presupuestario indirecto, pero es duradero: los ahorros se acumulan en cada sesión futura.
Lo que tienen en común los sistemas bien diseñados
Al observar los 19 sistemas, los que manejan bien los presupuestos de contexto comparten algunas propiedades.
Tratan la recuperación como una operación de dos pasos en lugar de una inyección de un solo paso. Devuelven vistas previas antes que registros completos. Preservan los registros originales en lugar de reemplazarlos con resúmenes. Brindan a los operadores control sobre el volumen de recuperación a través de parámetros explícitos en lugar de valores predeterminados codificados. Y piensan en el presupuesto tanto en el momento de escritura como en el de lectura.
Los que lo manejan mal tienden a depender de un solo mecanismo, generalmente la compresión, y tratan la ventana de contexto como un búfer que debe llenarse en lugar de un recurso que debe gestionarse.
La conclusión final de la investigación es simple. Las ventanas más grandes exigen más disciplina, no menos. No porque llenarlas sea incorrecto en principio, sino porque llenarlas con el material equivocado cuesta más que dejar el espacio vacío.
Para mi próximo artículo planeo pasar de la memoria como inyección a la memoria como herramientas, cubriendo cómo los 19 sistemas manejan el límite entre lo que se inserta automáticamente en el contexto y lo que el agente tiene que pedir explícitamente.*
Como siempre, si encontraste esto interesante, útil o simplemente quieres ayudar a difundir el conocimiento:
Por favor, Comparte
