Resumen Técnico: Memoria en el Bucle

Planteamiento del Problema

Los agentes de lenguaje operan en un bucle estándar: observar, razonar, actuar, repetir. Sin embargo, la memoria sobre la cual razonan se trata típicamente como un recurso externo consultado, como máximo, una vez por turno (recuperación por turno). Este diseño está impulsado por la suposición de que la latencia de recuperación es prohibitiva. Los almacenes de vectores en red suelen responder en 50–200 ms; si un agente consulta dicho almacén en cada paso de razonamiento, la latencia de extremo a extremo puede inflarse hasta 83 veces. En consecuencia, la orientación actual de la industria ("memoria primero") y los diseños de sistemas racionan la recuperación a una vez por turno o esconden los costes en la capa de servicio mediante la programación.

El artículo argumenta que esta restricción de latencia no es una ley fundamental del diseño de agentes, sino un artefacto de dónde reside el almacén. La latencia de red (decenas a cientos de milisegundos) hace que la recuperación dentro del bucle sea costosa, mientras que un almacén en proceso puede responder en ~100 µs. El problema central es si mover la memoria dentro del bucle de razonamiento —leyéndola y escribiéndola en cada paso— es factible y beneficioso cuando se elimina la barrera de la latencia.

Metodología

Arquitectura Central

Los autores instancian la "Memoria en el Bucle" utilizando un almacén semántico efímero y en proceso (vxdb) envuelto como una primitiva de WorkingMemory (Memoria de Trabajo). Este almacén soporta operaciones de add (añadir), recall (recordar) y match (coincidir). Crucialmente, el almacén se asigna por agente/tarea y no está conectado a un servicio de red, con el objetivo de lograr tiempos de respuesta de microsegundos.

Configuración Experimental

El estudio emplea dos regímenes experimentales primarios:

1. Tarea de Recuerdo Ventanado (Rendimiento de Extremo a Extremo):

   • Escenario: Una conversación de planificación de viajes de seis turnos donde el usuario establece cinco restricciones duraderas al inicio de la conversación. El agente debe enumerar todas las cinco restricciones al final.
   • Restricción: La ventana de contexto está limitada a $w=4$ mensajes, lo que provoca que las restricciones iniciales salgan de la ventana de visibilidad.
   • Condiciones:
     • Baseline/Aware (Base/Consciente): Sin herramientas de memoria (se le informa a Aware que su historial es corto).
     • Notes (Notas): Instruido para reestatizar todas las restricciones en cada respuesta (un límite superior de "sin herramientas").
     • Memory (Memoria): Equipado con herramientas de remember/recall respaldadas por el almacén en proceso.
   • Modelos: Probado a través de una "escalera GPT-5" (gpt-5-nano, gpt-5-mini, gpt-5, gpt-5.5).

2. Tarea de Guardia de Bucle Causal (Latencia vs. Resultado):

   • Escenario: Un agente procesa un flujo de alertas de seguridad, decidiendo si realizar una INVESTIGATE (investigar) o SKIP (omitir) duplicados.
   • Mecanismo: Un guardia de código comprueba el almacén antes de cada acción para evitar investigaciones redundantes.
   • Variable: La latencia del almacén se manipula inyectando retrasos de ida y vuelta (0 µs a 200 ms) manteniendo fijo el presupuesto de memoria por turno (100 ms).
   • Brazos:
     • In-process (En proceso): Velocidad en tiempo real (~17.5–85 µs).
     • Delayed Ladder (Escalera con Retraso): Lógica idéntica con retrasos inyectados (+5, +15, +30, +50, +110 ms).
     • Per-turn RAG (RAG por turno): El estándar de la industria (recuperación una vez por turno).
   • Métrica: Acciones redundantes ejecutadas (de un total de 12 duplicados).

Modelado de Costes

Los autores definen una frontera de factibilidad donde la memoria en el bucle es viable si el coste de la recuperación ($f \cdot c$) es insignificante en relación con el tiempo del paso de razonamiento ($r$). Miden el coste de la operación completa (embedding + almacén) para determinar si el acceso por paso es "gratuito" respecto a un paso de LLM.

Resultados Clave

1. Factibilidad y Tasa de Latencia

• Velocidad en Proceso: El almacén en proceso opera con una latencia media de 80–165 µs.
• Tasa de Latencia: Con 20 recuperaciones en el bucle por turno, el tiempo de bloqueo total es de ~1.7 ms para el almacén en proceso. En contraste, un almacén de vectores en la nube (RTT de 110 ms) incurre en una tasa de 2.2 segundos por turno.
• Factibilidad: A velocidades en proceso, un agente puede permitirse ~953 recuperaciones por paso (asumiendo un presupuesto de latencia del 10%), mientras que los almacenes en red permiten menos de 1 búsqueda por paso, forzando el racionamiento.

2. Rendimiento de la Tarea (Recuerdo Ventanado)

• Fallo del Baseline: Todas las ejecuciones de baseline y aware puntuaron 0/5 en el recuerdo de restricciones. La limitación de la ventana de contexto causó un fallo total independientemente del tamaño del modelo.
• Baseline de Reestatización: Un baseline instruido que reestatizaba las restricciones en cada respuesta logró 5/5, demostrando que la tarea es resoluble si el agente gestiona activamente el contexto, aunque esto incurre en un "alquiler" de tokens que escala con el conjunto de trabajo.
• Memoria en el Bucle: La condición de memoria en el bucle logró un recuerdo de 3.6–4.8/5 entre los modelos.
  • Análisis de Fallos: El almacén nunca perdió un dato (244/244 escrituras preservadas). Las omisiones fueron exclusivamente fallos de política de lectura: los agentes sobreescribieron las restricciones (creando duplicados) y luego leyeron solo una vez por ejecución a través de una ventana fija de $k=8$, la cual estaba saturada por entradas redundantes. El fallo residió en el uso de herramientas del agente, no en el sustrato de la memoria.

3. Impacto Causal de la Latencia (Guardia de Bucle)

• Respuesta Monotónica de Dosis-Respuesta: Las acciones redundantes aumentaron monótonamente con la latencia del almacén bajo un presupuesto fijo.
  • En proceso (0 ms): 0.0 acciones redundantes.
  • +15 ms: 1.4–1.6 acciones redundantes.
  • +110 ms (Nube): 7.2 de 12 acciones redundantes.
• Significancia Estadística: La diferencia entre la latencia en proceso y la de 110 ms fue estadísticamente significativa ($p=0.0079$) para ambos modelos probados.
• Mecanismo: A 110 ms, el presupuesto (100 ms) no podía permitir ni una sola búsqueda, por lo que el guardia fue efectivamente desactivado. Los "errores" no fueron errores de recuperación, sino la ausencia de comprobaciones.
• RAG por Turno: El estándar de la industria de recuperación por turno funcionó bien (0.4–0.6 acciones redundantes) pero falló estructuralmente al no detectar duplicados que surgían dentro de un mismo turno, mientras que el guardia en proceso detectó todos los duplicados.

4. El Cuello de Botella de los Embeddings

• El coste dominante en la pila del bucle no es el almacén, sino el embedding. Las API de embedding en red tardan entre 200 y 400 ms.
• Al emparejar el almacén en proceso con un pequeño embedder local (32M de parámetros, 32 µs), la operación completa (embed + almacén) cae a **40 µs**. Esto elimina la última barrera para la memoria en el bucle.

Significado y Reivindicaciones

Contribución Teórica: Memoria de Trabajo Extendida

El artículo fundamenta sus hallazgos de ingeniería en la Tesis de la Mente Extendida (Clark & Chalmers, 1998). Argumenta que un recurso externo se vuelve "constitutivo" de la cognición (es decir, parte de la memoria de trabajo del agente) solo si es:

1. Constantemente disponible.
2. Directamente accesible sin dificultad.
3. Endosado automáticamente.

Los autores interpretan estos dos primeros criterios como un presupuesto de latencia. Una llamada de red de 100 ms es una herramienta que un agente consulta; un almacén en proceso de 100 µs es un recurso que el agente tiene. Cuando la latencia es lo suficientemente baja como para ser transparente al paso de razonamiento, el almacén transiciona de ser una base de datos externa a ser memoria de trabajo extendida.

Contribución de Ingeniería

• La Latencia como Variable de Diseño: El artículo desplaza la frecuencia de recuperación de una restricción de la capa de servicio a un eje de diseño del agente. Demuestra que la latencia del almacén, y no el patrón de bucle, es el factor de control.
• Vínculo Causal: Proporciona evidencia causal de que la latencia del almacén por sí sola determina los resultados de la tarea (acciones redundantes) cuando el presupuesto es fijo, independientemente de la capacidad del modelo.
• Cambio Arquitectónico: Propone que la memoria debe tratarse como una primitiva de bucle (como un bloc de notas o scratchpad) asignada por tarea, en lugar de un servicio conectado.

Modestia y Limitaciones

Los autores son explícitos sobre el alcance:

• No afirman que el almacén haga al modelo más "inteligente"; los modelos siguieron fallando al reconocer duplicados sin el guardia. El sistema tuvo éxito porque el andamiaje pudo permitirse comprobar la memoria.
• El baseline de "Notas" (reestatización) superó a las herramientas de memoria en la pequeña tarea de 5 hechos, resaltando que la reestatización paga un coste por turno que crece con el conjunto de trabajo, algo que el almacén evita a escala.
• El estudio se centra en el aspecto temporal de la memoria (cuándo participa en el razonamiento). Las cuestiones sobre qué retener, cómo organizar la información y la gestión del ciclo de vida se identifican como trabajo futuro.

En conclusión, el artículo afirma que el régimen "en el bucle" no solo es factible, sino causalmente superior para tareas que requieren consistencia de estado dentro de un turno, siempre que el sustrato de memoria sea en proceso y esté emparejado con un embedder local para eliminar la latencia de red.