Cuanto más tiempo trabajo con LLMs, más me encuentro en la batalla eterna entre suficiente contexto, demasiado contexto, desperdicio de tokens y guerra de compactación. Al observar los sistemas de memoria agentiva, vemos que existen armas poderosas para ayudar en esto.
El hallazgo que sigue apareciendo en los 19 sistemas que revisé es que las ventanas más grandes intensifican el problema del presupuesto en lugar de resolverlo. Una ventana de 200K tokens no presta la misma atención a los 200K 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 que el material en los extremos. Y la tarea real del agente ocupa una porción fija de la ventana, sin importar cuán grande sea, lo que significa que todo lo demás es sobrecarga compitiendo por el mismo presupuesto de atención.
Los sistemas que manejan bien esto 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
Pasos de compactació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 en 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 entre sesiones.
La contrapartida es la pérdida de información. La compactació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 compactación. Si el agente luego necesita un detalle que no se consideró relevante, ese detalle se pierde. Esto no es una razón para evitar la compactación, pero sí una razón para no tratarla como el único mecanismo.
Hay un segundo costo que es fácil pasar por alto. La compactació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, eso es un costo operativo real.
Truncamiento de 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 fragmento 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 contrapartida es una llamada de herramienta adicional. Si el agente necesita el contenido completo, tiene que solicitarlo 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 de vista previa. La búsqueda devuelve identificadores y vistas previas cortas. Una llamada separada GetByID obtiene el registro completo cuando es 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 hablan por sí solos. 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. En 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 barata 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, descomponla primero en subconsultas. El planificador de recuperación consciente de intenciones de SimpleMem descompone 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 obtiene 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 contrapartida 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 y 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 crudas no se inyectan directamente en el contexto; se promueven a niveles superiores antes de convertirse en candidatos de recuperación.
La contrapartida es la integridad de la recuperación. El material que no ha sido promovido puede ser relevante, pero no aparecerá en un paso de recuperación estándar. Esta es la misma contrapartida que la compactación, pero el modo de fallo es diferente: en lugar de perder información mediante resumen, la pierdes mediante 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 una herramienta, la respuesta de la herramienta en sí misma 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 próximo paso de recuperación del agente.
El efecto es que el agente gasta menos tokens en planificación entre llamadas de herramientas. La respuesta de la herramienta lleva suficiente estructura para hacer obvio el siguiente paso. La contrapartida es el esfuerzo de ingeniería de prompts: escribir buenas respuestas autoguiadas requiere saber de antemano qué es probable que el agente necesite 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 de presupuesto 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 de embedding.
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 solicitó explícitamente. Algunos de esos resultados son útiles. Muchos no lo son. Todos cuestan tokens.
La postura de Tolaria es que el costo de 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 es válida para tu sistema depende de para qué es 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 de las que es difícil recuperarse.
El valor del caso 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 basados solo en compactación
Varios de los 19 sistemas dependen de la compactación como su mecanismo principal o único de presupuesto. Vale la pena nombrar los modos de fallo.
El primero es que la summarización pierde detalles que no se consideraron relevantes en el momento de la compactación, pero que se vuelven relevantes más tarde. Esto no es una hipótesis: es el modo de fallo estándar de cualquier esquema de compresión con pérdida aplicado a información cuya relevancia futura es desconocida.
El segundo es que la compactación es un costo en la ruta crítica. MemoryOS pagando 20 o más llamadas al LLM por interacción no es inusual para sistemas con mucha compactación. A escala, ese costo no es despreciable.
El tercero, y más sutil, es que la compactació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 posibilidad de recuperarla. La recuperación en dos pasos, el almacenamiento por niveles y el truncamiento de vista previa de resultados preservan el registro original. La compactación no.
Nada de esto significa que la compactación esté mal. Significa que la compactación por sí sola no es suficiente.
Ponderación por actualidad y la cola persistente
Dos mecanismos que no encajan perfectamente en las seis categorías anteriores merecen ser mencionados.
graymatter usa fusión RRF con actualidad con peso de la mitad. Esto no es un mecanismo de presupuesto en sentido estricto, pero funciona como uno: al reducir el peso del material más antiguo en los rankings 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 jerarquía suave a través de pesos de clasificación en lugar de 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 cualquier cosa entre en el almacén de memoria. El control del presupuesto ocurre en el momento de escritura, no en el momento de lectura. El material que no supera el umbral de relevancia no se almacena, lo que significa que no puede ser recuperado y no puede consumir contexto. Esto es control de presupuesto indirecto, pero es duradero: los ahorros se acumulan en cada sesión futura.
Lo que los sistemas bien diseñados tienen en común
Al observar los 19 sistemas, aquellos 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 en un solo paso. Devuelven vistas previas antes que los 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 momento de lectura.
Los que lo manejan mal tienden a depender de un solo mecanismo, generalmente la compactació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 empuja automáticamente al contexto y lo que el agente tiene que solicitar explícitamente.*
Como siempre, si encontraste esto interesante, útil o simplemente quieres ayudar a difundir el conocimiento:
Por favor, comparte
