Guía10 min

Memoria para agentes de IA: cuándo usar historial, memoria larga o RAG

Resumen

La memoria de un agente no es una sola base vectorial. Esta guía separa historial de conversación, estado operativo, hechos durables y RAG documental; explica qué guardar, cómo recuperarlo y qué borrar, con una arquitectura mínima, criterios de decisión y pruebas para evitar recuerdos incorrectos o cruces de datos entre usuarios.

LangChainOpenAIGemini
Capas de contexto, estado, recuerdos y documentos conectadas a un agente de inteligencia artificial

Qué resuelve

Esta pieza se queda en la decisión práctica: qué instalar, qué riesgo agrega y cómo aplicarlo sin romper operación.

Un agente que conserva todo el chat no tiene buena memoria: tiene un contexto cada vez más caro, lento y ruidoso. Y un índice vectorial tampoco resuelve por sí solo el problema. Para que un agente recuerde bien debes separar lo que ocurre en esta conversación, el estado de la tarea, los hechos que seguirán siendo útiles mañana y los documentos que puede consultar cuando los necesite.

La decisión importante no es “¿qué base vectorial compro?”, sino qué información merece persistir, durante cuánto tiempo, bajo qué identidad y cómo comprobarás que sigue siendo correcta. Esta guía ordena esas capas y propone una implementación mínima. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

Arquitectura por capas que separa contexto inmediato, estado de ejecución, memoria durable y conocimiento recuperable

Cuatro capas que no conviene mezclar

LangChain distingue memoria de corto plazo, limitada a un hilo, y memoria de largo plazo, compartida entre sesiones mediante espacios de nombres. Para producción conviene añadir dos separaciones más: estado operativo y RAG.

CapaQué guardaAlcanceEjemplo
Contexto cortoMensajes recientes y resultados de toolsUn hiloLa pregunta actual y la respuesta anterior
Estado operativoPasos, artefactos y decisiones de una tareaUna ejecución reanudablePR abierto, archivo generado, aprobación pendiente
Memoria largaHechos o preferencias verificadasUsuario, equipo o agenteIdioma preferido, formato de reporte, restricción estable
RAGDocumentos externos consultablesCorpus con permisosManuales, políticas, contratos, documentación técnica

El contexto corto mantiene coherencia durante una conversación. Puede guardarse con checkpoints para reanudar el hilo, pero no debes enviar indefinidamente todo el historial al modelo. Recorta turnos viejos, resume lo necesario y conserva aparte los artefactos que una tarea todavía usa.

El estado operativo no es prosa para recordar: es información estructurada. Si un agente procesa un pedido, guarda orderId, etapa, reintentos y resultado de cada herramienta; no le pidas al modelo que reconstruya esos valores leyendo veinte mensajes.

La memoria larga contiene hechos durables y acotados: preferencias confirmadas, reglas de una organización o aprendizajes reutilizables. Debe tener propietario, fecha, fuente y mecanismo de corrección. “El usuario prefiere respuestas breves” puede servir; una inferencia como “seguramente siempre compra los viernes” no debería persistirse como hecho.

RAG recupera conocimiento desde documentos. OpenAI documenta vector stores como índices para búsqueda semántica; Google describe el flujo completo como ingestión, transformación, embeddings, indexación, retrieval y generación. RAG ayuda a encontrar evidencia, pero no reemplaza el estado de una tarea ni convierte cada fragmento recuperado en un recuerdo verdadero.

La regla práctica: escribe poco, recupera con intención

Antes de guardar algo, pasa este filtro:

  1. ¿Seguirá siendo útil fuera del turno actual? Si no, déjalo en contexto corto.
  2. ¿Es un dato exacto de una tarea? Guárdalo como estado con schema, no como memoria narrativa.
  3. ¿Lo afirmó el usuario o proviene de una fuente confiable? Solo entonces considera memoria larga.
  4. ¿Ya vive en un documento mantenido por otra persona? Indexa ese documento para RAG en vez de copiarlo a la memoria.
  5. ¿Tiene fecha de caducidad o forma de borrado? Si no puedes responder, todavía no está listo para persistir.

Esta disciplina reduce un fallo frecuente: el agente recupera una preferencia antigua, una aplica a otro usuario o un resumen que omitió la excepción importante. Más memoria no significa más precisión; significa más superficie que gobernar.

Arquitectura mínima que sí puedes operar

Empieza con cuatro almacenes lógicos, aunque dos compartan la misma base de datos:

thread:{threadId}              -> mensajes recientes y checkpoint
run:{taskId}                   -> estado, tool calls y artefactos
memory:{tenantId}:{userId}     -> hechos durables con fuente y caducidad
knowledge:{tenantId}:{corpus}  -> documentos, chunks, permisos y versión

En cada request, el orquestador debería cargar solo el hilo correspondiente, recuperar unas pocas memorias pertinentes y consultar RAG únicamente cuando la pregunta necesita conocimiento documental. Nunca busques en un índice global sin filtrar primero por tenantId, permisos y corpus permitido.

Un registro durable puede ser explícito y auditable:

{
  "kind": "preference",
  "subjectId": "user_123",
  "value": { "language": "es", "answerStyle": "breve" },
  "source": "user_confirmed",
  "createdAt": "2026-09-03T12:30:00Z",
  "expiresAt": null
}

Evita guardar secretos, contraseñas, tokens, datos médicos o financieros porque “podrían ser útiles”. Si el caso exige datos sensibles, cifra, minimiza, limita retención y separa autorización de recuerdo: que el agente conozca un dato no significa que tenga permiso para usarlo en una acción.

Flujo de escritura y recuperación con separación por usuario, tarea, permisos y vigencia

Cómo construir el RAG sin confundirlo con memoria

Un RAG inicial necesita menos magia y más trazabilidad:

  1. Ingiere documentos con identidad y versión. Conserva URL o archivo de origen, fecha, propietario y permisos.
  2. Divide por estructura, no solo por longitud. Respeta títulos, secciones y límites semánticos antes de aplicar un tamaño fijo.
  3. Combina búsqueda semántica y exacta cuando importe. Los embeddings capturan significado; BM25 o búsqueda léxica encuentra códigos, nombres y términos literales.
  4. Filtra antes de recuperar. Aplica tenant, producto, idioma, vigencia y permisos antes del ranking.
  5. Entrega evidencia al modelo. Incluye origen y fragmento; permite responder “no hay contexto suficiente”.
  6. Registra qué chunks influyeron. Sin trazas no podrás distinguir un fallo de retrieval de un fallo de generación.

Anthropic reportó en su experimento de Contextual Retrieval que añadir contexto específico a cada chunk, combinar embeddings con BM25 y después reranquear redujo su tasa de fallos de recuperación en el top 20. No copies esa configuración como número universal: úsala como señal de que chunking, búsqueda híbrida y reranking deben evaluarse con tu corpus.

Si tu base completa cabe cómodamente en el contexto y cambia poco, puede ser más simple enviarla directamente o aprovechar caché de prompt. RAG empieza a ganar cuando el corpus supera ese límite, cambia con frecuencia, necesita filtros o debe devolver fuentes específicas. Si todavía dudas entre recuperación y reglas deterministas, consulta RAG vs workflow automatizado.

Evals mínimas antes de llamar “memoria” al sistema

Prepara entre 20 y 50 casos reales y mide cada capa por separado:

  • recall correcto: recuperó el hecho o fragmento necesario;
  • precision: evitó traer recuerdos irrelevantes o de otra persona;
  • frescura: eligió la versión vigente cuando había contradicciones;
  • aislamiento: nunca cruzó usuarios, tenants o permisos;
  • abstención: reconoció cuándo no tenía evidencia suficiente;
  • borrado: una memoria eliminada dejó de aparecer en búsquedas y respuestas;
  • costo y latencia: cuánto añade la recuperación por tarea completada.

Incluye pruebas adversariales: dos usuarios con preferencias opuestas, un documento revocado, una política nueva que contradice a la anterior y una instrucción maliciosa dentro de un PDF. La guía de defensas contra prompt injection explica por qué el contenido recuperado debe tratarse como datos, no como instrucciones confiables.

Checklist para elegir la capa correcta

Usa solo contexto corto si la interacción termina pronto y nada debe sobrevivir. Añade estado persistente si la tarea puede reanudarse o tiene efectos externos. Añade memoria larga cuando exista identidad estable, beneficio claro entre sesiones y un proceso de corrección. Añade RAG cuando las respuestas dependan de un corpus documental demasiado grande o cambiante para el prompt.

No implementes las cuatro capas el primer día. Un camino razonable es: estado estructurado y trazas primero; resumen del hilo después; RAG con citas para un corpus pequeño; memoria larga solo cuando tengas ejemplos concretos de información que los usuarios esperan que el agente recuerde.

Esta arquitectura encaja dentro del mapa mínimo de un agente en producción. Si estás empezando desde cero, el curso gratuito de Agente IA te ayuda a montar herramientas y orquestación antes de añadir persistencia.

La prueba final es sencilla: ¿puedes explicar, para cada dato que el agente usa, de dónde salió, a quién pertenece, cuándo vence y cómo se borra? Si la respuesta es sí, tienes memoria operable. Si no, solo acumulaste contexto.