RAG no es memoria

Meter embeddings en una vector database no le da memoria a un agente. Le da al sistema una forma de recuperar información que puede ser relevante para una solicitud. La técnica es útil; el nombre suele abarcar demasiado.

Retrieval-Augmented Generation (RAG) y memoria resuelven problemas relacionados, pero distintos. RAG pregunta: ¿qué información debo recuperar para esta ejecución? Memoria pregunta algo más difícil: ¿qué parte de la experiencia anterior debe seguir influyendo en el sistema?

La segunda pregunta introduce persistencia, identidad, tiempo, cambio, consolidación, eliminación y confianza. Un índice vectorial puede formar parte de la respuesta. No es la respuesta completa.

La similitud es una señal de recuperación; no es una política de memoria.

Qué problema resuelve realmente RAG

El trabajo original de RAG describió un modelo que combina un lenguaje paramétrico con una memoria no paramétrica accesible mediante recuperación durante la inferencia. En los sistemas actuales, el patrón suele ser más directo: representar documentos o registros, recuperar candidatos relevantes para la consulta, incorporar una selección al contexto del modelo y generar una respuesta basada en ese contexto.

flowchart TD
  A[Solicitud del usuario] --> B[Representación de consulta]
  B --> C[Retriever]
  C --> D[Documentos o registros relevantes]
  D --> E[Construcción de contexto]
  E --> F[Modelo]
  F --> G[Respuesta]

RAG es principalmente un mecanismo de relevancia y grounding. Es útil cuando el modelo necesita información externa a sus parámetros: documentación, políticas internas, un código fuente, eventos recientes o un corpus proporcionado por el usuario. El almacenamiento puede ser una vector database, un buscador, una base relacional, un grafo o una combinación. Lo esencial no son los vectores, sino seleccionar información para la ejecución actual.

Una tubería RAG puede funcionar perfectamente sin tener identidad persistente. Un servicio de preguntas y respuestas sin estado puede recuperar el mismo documento para dos usuarios distintos. El resultado es relevante para la consulta, no necesariamente significativo para la historia de un agente específico.

Recuperar no es recordar

Una vector database normalmente responde una pregunta de proximidad: ¿qué representaciones almacenadas son similares a esta consulta? Es un primitive valioso. Pero la similitud no indica si una observación fue importante, si sigue siendo verdadera o si pertenece a un episodio concreto.

Imaginemos que una persona dice: “Prefiero el modo oscuro”. Meses después dice: “Volví al modo claro”. Una implementación ingenua puede almacenar ambos mensajes y recuperar los dos cuando el tema sea relevante. Encontró evidencia similar, pero no resolvió el conflicto. Necesita identidad, timestamps, procedencia, confianza, alcance y una política de actualización. La segunda observación puede sustituir a la primera, o puede ser contextual: modo claro en el trabajo y oscuro en casa.

La diferencia no es académica. Retrieval devuelve candidatos. La memoria determina qué significan esos candidatos para el comportamiento futuro.

• Retrieval selecciona información relevante para una consulta.
• Contexto es la información que se hace disponible al modelo durante una ejecución.
• Memoria es una representación persistente y gobernada de información o experiencia que puede influir en ejecuciones posteriores.

Estas capas se relacionan, pero no deben colapsarse. Una memoria puede usar búsqueda vectorial, lexical, consultas estructuradas, recencia, relaciones o claves explícitas. Un context builder puede combinar memorias con la conversación actual, el estado de la tarea, permisos y resultados de herramientas. El runtime del agente decide qué hacer con ese estado.

Distintos tipos de memoria

Me resulta útil pensar en categorías de memoria como herramientas de diseño, siempre que no intentemos simular literalmente la cognición humana.

Working memory

Es la información necesaria para la tarea actual: objetivo activo, resultados intermedios, salidas de herramientas, restricciones y turnos recientes que todavía importan. En una aplicación con LLM, suele vivir en el context window o en un estado explícito de la tarea. Por defecto es transitoria. Persistir cada elemento introduce ruido y riesgos de privacidad.

Episodic memory

Representa eventos o interacciones: qué ocurrió, cuándo, quién participó, qué acción se tomó y cuál fue el resultado. Un episodio no es solamente un chunk de texto. Su estructura temporal y causal puede importar más que su similitud semántica. “Desplegamos la versión 3 y revertimos después de una migración fallida” puede ser útil por el evento y su resultado, no porque se parezca a una consulta futura.

Semantic memory

Es conocimiento o información más estable: la configuración de una cuenta, la arquitectura de un proyecto o una preferencia que sobrevivió a una evaluación. Puede derivarse de varios episodios. Esa derivación es una operación de consolidación: varias observaciones se convierten en una representación más durable.

Procedural y behavioral memory

Algunos sistemas también necesitan representar cómo comportarse: workflows preferidos, decisiones recurrentes o patrones de interacción. Esto no implica necesariamente fine-tuning. Puede ser una política explícita, un registro de preferencias, un procedimiento reutilizable o una estrategia rankeada. El punto es que el comportamiento no siempre se representa mejor como un embedding de texto indiferenciado.

La memoria no es una tabla con una sola columna de embeddings. Es un conjunto de representaciones con semánticas distintas de retención y recuperación.

La memoria necesita un ciclo de vida

Un subsistema de memoria útil no es simplemente WRITE + SEARCH. Necesita un ciclo de vida y políticas alrededor de ese ciclo:

flowchart LR
  A[Interacción] --> B[Capturar candidato]
  B --> C[Evaluar importancia y alcance]
  C --> D[Guardar representación]
  D --> E[Recuperar cuando sea útil]
  E --> F[Actualizar o sustituir]
  F --> G[Consolidar]
  G --> H[Olvidar, expirar o borrar]

Capture pregunta qué vale la pena considerar. La mayoría de las conversaciones no es memoria durable. Evaluation considera importancia, confianza, sensibilidad, ownership y valor futuro. Storage elige la representación y registra procedencia, timestamps, alcance y relaciones. Retrieval decide cuándo una memoria es útil, no solamente cuándo es parecida. Update maneja correcciones y conflictos. Consolidation puede convertir episodios repetidos en un hecho o preferencia estable. Forgetting elimina, expira o reduce la prioridad conforme a una política.

Olvidar no es un job opcional de mantenimiento. Un sistema que conserva todo indefinidamente acumula datos obsoletos, contradictorios y potencialmente sensibles. También hace menos confiable la recuperación. El borrado debe ser una operación real sobre representaciones derivadas, índices, caches, resúmenes y backups cuando los requisitos del producto lo exijan.

El contexto tampoco es memoria

Un context window más grande cambia cuánta información puede presentarse al modelo en una ejecución. Eso ayuda, pero no crea automáticamente persistencia ni comprensión. Más contexto puede contener historial irrelevante, instrucciones obsoletas, hechos duplicados y contradicciones sin resolver.

El contexto largo también trae trade-offs de ingeniería: costo de tokens, latencia, asignación de atención y necesidad de priorizar. La investigación sobre long context muestra que el tamaño nominal de la ventana no equivale automáticamente a la capacidad práctica de utilizar cualquier información dentro de ella. La pregunta sigue siendo: ¿qué estado debe entrar en esta ejecución, en qué forma y con qué autoridad?

El historial conversacional puede ser una fuente de candidatos a memoria y, a veces, una forma de estado de trabajo. No es por sí mismo un sistema de memoria.

Una arquitectura posible para memoria persistente

Una arquitectura conceptual puede separar cuatro responsabilidades:

flowchart TD
  A[Interacción y estado del agente] --> B[Extracción de candidatos]
  B --> C[Política de memoria]
  C --> D[Memory store]
  D --> E[Consolidación y conflictos]
  E --> F[Capa de retrieval]
  F --> G[Context builder]
  G --> H[Agent runtime]
  H --> A

• Memory store: registros durables, episodios, hechos, preferencias, procedimientos, procedencia y metadata del ciclo de vida.
• Retrieval layer: planeación de consultas sobre índices semánticos, lexicales, estructurados, temporales y relacionales.
• Context builder: ranking, filtros, deduplicación, conflictos, presupuesto de tokens y formato para el modelo.
• Agent runtime: razonamiento, uso de herramientas, acciones y decisión de proponer nuevos candidatos a memoria.

No es una arquitectura universal. Una aplicación pequeña puede combinar componentes. Un sistema de producción puede usar una base relacional con índices de búsqueda en lugar de una vector database dedicada. La separación útil es conceptual: storage no es retrieval, retrieval no es context assembly y context assembly no es agent state.

Proyectos como MemGPT exploraron la memoria como una jerarquía administrada alrededor de un contexto limitado, en lugar de asumir que todo el historial pertenece al prompt. Generative Agents hizo explícitos retrieval, reflection y planning dentro de una arquitectura de agente. No son blueprints para copiar, pero apuntan a una pregunta más completa que “¿qué modelo de embeddings usamos?”.

La memoria cambia el producto

En cuanto un sistema recuerda, el problema se vuelve tanto de producto como de arquitectura.

El usuario necesita saber qué se recuerda, por qué, cómo afecta el comportamiento y cómo corregirlo o borrarlo. El sistema necesita límites entre usuarios, tenants, agentes y tareas. Las memorias sensibles requieren access control y auditoría. Las memorias incorrectas necesitan procedencia y mecanismos de corrección. Las obsoletas necesitan expiración o revalidación. Recuperar una memoria del tenant equivocado no es un bug de relevancia: es un incidente de seguridad.

La confianza también depende de evitar sorpresas. Un recuerdo técnicamente correcto puede ser un mal comportamiento si el usuario no esperaba que el sistema conservara esa información o la mostrara en otro contexto. La memoria necesita control del usuario, no solamente mejor ranking.

Lo que creo actualmente

RAG es un building block importante. El vector retrieval suele ser útil. El long context puede reducir la necesidad de algunas formas de summarization. Ninguno representa memoria por sí solo.

Para sistemas inteligentes persistentes, creo que la memoria debe tratarse como un subsistema con state, policies, storage, retrieval, updates, consolidation y deletion. Cada tipo de información merece distintas representaciones y ciclos de vida. La vector database puede ser un índice dentro del subsistema, no su identidad.

Este es uno de los problemas que estoy explorando mientras construyo sistemas inteligentes persistentes. Mi perspectiva cambiará a medida que las implementaciones sean más exigentes. Precisamente por eso importa la distinción: no deberíamos nombrar “memoria” a partir del primer primitive de almacenamiento que desplegamos.

Referencias

1. Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
2. Charles Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023.
3. Joon Sung Park et al., Generative Agents: Interactive Simulacra of Human Behavior, 2023.
4. Nelson F. Lui et al., Lost in the Middle: How Language Models Use Long Contexts, 2023.