Un LLM responde al input y olvida todo cuando termina el turno. Para preguntas aisladas es suficiente. Para cualquier tarea que requiera continuidad no lo es.<\/p>\n\n\n\n
Memory Management implementa una arquitectura doble, memoria a corto plazo dentro del context window, memoria a largo plazo en almacenamiento externo. La distinci\u00f3n no es cosm\u00e9tica. Cada capa tiene mecanismos de almacenamiento, lifetime, retrieval strategies y trade-offs distintos.<\/p>\n\n\n\n
Pero el problema real no es \u00abguardar datos\u00bb. Es gestionar tres dimensiones concurrentes: qu\u00e9 guardar, c\u00f3mo recuperarlo sin contaminar el contexto, y cu\u00e1ndo descartarlo. Gestionar mal cualquiera de esas dimensiones degrada el sistema, context overflow, information dilution, stale memory, retrieval failure.<\/p>\n\n\n\n
Memory Management en agentes LLM no es un sistema de bases de datos. No es caching. No es session management de aplicaciones web tradicionales. Es un mecanismo para que un modelo probabil\u00edstico mantenga coherencia a trav\u00e9s de interacciones discretas, sabiendo que cada interacci\u00f3n es independiente y que el modelo no \u00abrecuerda\u00bb nada por s\u00ed mismo.<\/p>\n\n\n\n
La memoria no es una caracter\u00edstica que se a\u00f1ade al final. Es una decisi\u00f3n arquitect\u00f3nica que afecta el dise\u00f1o del prompt, la estructura del estado, el retrieval, y la forma en que el modelo toma decisiones. Un sistema dise\u00f1ado sin memoria desde el principio no la puede a\u00f1adir despu\u00e9s sin reescribir la arquitectura.<\/p>\n\n\n\n
La separaci\u00f3n refleja una tensi\u00f3n real: Acceso inmediato vs persistencia. La memoria de trabajo humana tiene capacidad limitada pero acceso directo. La memoria a largo plazo tiene capacidad amplia pero requiere retrieval activo. Los agentes LLM enfrentan la misma tensi\u00f3n.<\/p>\n\n\n\n
Corto plazo<\/strong>: Vive dentro del context window. Es ef\u00edmera, delimitada a una sesi\u00f3n, y se pierde cuando la sesi\u00f3n termina. Incluye historial de mensajes, estado actual de la tarea, y cualquier dato que el modelo necesita para su pr\u00f3xima decisi\u00f3n. El recurso limitante es el espacio, un context window de 128K tokens se agota m\u00e1s r\u00e1pido de lo que parece cuando cargas system prompt, herramientas, historial y datos de contexto.<\/p>\n\n\n\n Largo plazo<\/strong>: Persiste entre sesiones. Vive en almacenamiento externo, vector databases, key-value stores, managed services. No est\u00e1 en el context window por defecto; debe ser llamada expl\u00edcitamente. El recurso limitante es la precisi\u00f3n del retrieval, puedes almacenar terabytes, pero si el retrieval no encuentra lo relevante, la memoria es in\u00fatil. Y si encuentra informaci\u00f3n irrelevante, contamina el contexto.<\/p>\n\n\n\n La literatura distingue tres tipos de memoria. Es una taxonom\u00eda \u00fatil, no una separaci\u00f3n t\u00e9cnica estricta. En producci\u00f3n, todo converge en \u00abmemory store + retrieval + heuristics\u00bb. La distinci\u00f3n ayuda a pensar en qu\u00e9 tipo de informaci\u00f3n necesitas guardar y c\u00f3mo recuperarla, pero no implica que existan tres sistemas de almacenamiento separados.<\/p>\n\n\n\n Memoria sem\u00e1ntica<\/strong>: Hechos y preferencias del usuario. \u00abEl usuario prefiere respuestas concisas\u00bb. \u00abEl proyecto usa Python 3.12\u00bb. Conocimiento factual que persiste entre sesiones. Se almacena en key-value stores para datos estructurados o vector databases para conocimiento no estructurado. Se busca por clave o por semantic search.<\/p>\n\n\n\n Memoria epis\u00f3dica<\/strong>: Secuencias de interacciones pasadas como few-shot examples. No almacena hechos aislados, sino patrones de comportamiento, \u00abcuando el usuario pregunt\u00f3 X, la respuesta Y funcion\u00f3 bien\u00bb. Se almacena en vector databases con metadatos temporales. Se recupera con semantic search + filtros de metadatos.<\/p>\n\n\n\n Memoria procedimental<\/strong>: Instrucciones del agente que puede auto-modificar mediante reflection. No es conocimiento sobre el mundo, sino conocimiento sobre c\u00f3mo el agente debe comportarse. Se almacena en key-value stores con versionado. Se carga directamente en el system prompt.<\/p>\n\n\n\n La distinci\u00f3n importa porque cada tipo tiene un patr\u00f3n de acceso distinto. La memoria sem\u00e1ntica se consulta frecuentemente y cambia poco. La epis\u00f3dica se consulta selectivamente y crece con el tiempo. La procedimental est\u00e1 siempre activa y cambia lentamente. Mezclar los tres tipos en un solo store sin distinguirlos produce recuperaci\u00f3n imprecisa.<\/p>\n\n\n\n El context window es el recurso m\u00e1s limitado. Gestionarlo mal es el error m\u00e1s com\u00fan y el m\u00e1s costoso.<\/p>\n\n\n\n Tres estrategias dominan en producci\u00f3n. No son mutuamente excluyentes, se combinan.<\/p>\n\n\n\n Sliding windows con prioridad<\/strong>: En lugar de mantener un historial lineal, se mantiene una ventana donde los mensajes se ordenan por relevancia, no por antig\u00fcedad. Las scoring functions eval\u00faan la relevancia basada en proximidad temporal a la query actual, similitud sem\u00e1ntica con el input del usuario, e importancia declarada. Las instrucciones del sistema siempre tienen prioridad m\u00e1xima.<\/p>\n\n\n\n Resumen progresivo.<\/strong> Los mensajes antiguos se comprimen. En lugar de mantener el texto completo, se mantiene un resumen. El trade-off es precisi\u00f3n vs compresi\u00f3n, un resumen agresivo pierde detalles relevantes. Un resumen conservador no ahorra suficientes tokens. Lo que suele funcionar es compresi\u00f3n adaptativa: Mensajes recientes intactos, mensajes intermedios comprimidos moderadamente, mensajes antiguos resumidos agresivamente.<\/p>\n\n\n\n Data pruning ef\u00edmero.<\/strong> Datos relevantes solo para un turno espec\u00edfico se eliminan despu\u00e9s de ese turno. El output detallado de una herramienta se necesita para generar la respuesta actual, pero no para turnos futuros. Se usa, se procesa, se descarta. Requiere que el agente distinga expl\u00edcitamente entre datos persistentes y ef\u00edmeros.<\/p>\n\n\n\n La calidad del retrieval determina si la memoria a largo plazo es \u00fatil o ruido. Recuperar demasiado contamina el contexto. Recuperar poco deja al agente sin informaci\u00f3n necesaria.<\/p>\n\n\n\n Semantic search b\u00e1sico<\/strong>: La query se convierte en embedding y se busca por similitud coseno. Simple, efectivo para conocimiento factual. Limitaci\u00f3n: No entiende contexto conversacional. Si el usuario dice \u00ab\u00bfy eso c\u00f3mo se configura?\u00bb, la b\u00fasqueda sem\u00e1ntica no sabe qu\u00e9 significa \u00abeso\u00bb sin el historial.<\/p>\n\n\n\n Hybrid retrieval<\/strong>: Combina semantic search con keyword matching y filtros de metadatos. Captura tanto similitud conceptual como coincidencia literal. Un usuario que busca \u00abconfigurar RAG\u00bb necesita resultados que contengan \u00abRAG\u00bb expl\u00edcitamente, no solo conceptos semanticamente relacionados.<\/p>\n\n\n\n Re-ranking<\/strong>: Despu\u00e9s del retrieval inicial, un modelo eval\u00faa la relevancia de cada resultado en contexto. Los resultados se reordenan por relevancia real, no por similitud vectorial. Elimina falsos positivos del retrieval inicial. El coste es una llamada adicional al modelo, pero la mejora en precisi\u00f3n justifica el overhead cuando la calidad del retrieval impacta directamente en la calidad del output.<\/p>\n\n\n\n La memoria no es est\u00e1tica. Los datos se vuelven obsoletos, las preferencias cambian, el contexto evoluciona.<\/p>\n\n\n\n Tres tipos de stale data aparecen en producci\u00f3n:<\/p>\n\n\n\n Las defensas que podemos usar: Timestamps en toda memoria, contradiction detection antes de almacenar, memory expiration con umbrales configurables por dominio.<\/p>\n\n\n\n La memoria de un usuario o sesi\u00f3n contamina la de otro. Aparece cuando el scoping es incorrecto o cuando el retrieval no filtra por contexto apropiado.<\/p>\n\n\n\n Ejemplo: Un agente almacena preferencias de usuario en memoria sem\u00e1ntica. El usuario A prefiere documentaci\u00f3n en espa\u00f1ol. El usuario B pregunta en ingl\u00e9s. El retrieval encuentra la preferencia del usuario A porque no filtr\u00f3 por user_id. El agente responde al usuario B en espa\u00f1ol.<\/p>\n\n\n\n La defensa es scoping expl\u00edcito. Cada entrada de memoria tiene un alcance, user-specific, session-specific, o global. El retrieval siempre filtra por alcance apropiado. En Google ADK, los prefixes Memory Management es un patr\u00f3n de arquitectura. LangChain, LangGraph, Google ADK o Vertex Memory Bank son implementaciones del patr\u00f3n, no el patr\u00f3n en s\u00ed mismo. Confundir herramienta con patr\u00f3n lleva a soluciones acopladas a un framework.<\/p>\n\n\n\n Memoria sem\u00e1ntica con scoping por usuario, retrieval con semantic search y filtrado por actualidad. El namespace Memoria procedimental con versionado y reflection. El versionado permite revertir si una actualizaci\u00f3n empeora el rendimiento. Sin versionado, una reflection err\u00f3nea puede degradar el comportamiento de forma irreversible.<\/p>\n\n\n\n Memory Management parece directo hasta que aparece con volumen real.<\/p>\n\n\n\n El context overflow silencioso<\/strong> no es que el contexto se llene de golpe. Crece gradualmente hasta que el modelo empieza a degradarse. Los primeros s\u00edntomas son sutiles: el modelo olvida instrucciones del system prompt, prioriza informaci\u00f3n reciente sobre informaci\u00f3n importante, o produce respuestas m\u00e1s gen\u00e9ricas. Cuando se detecta, el contexto ya lleva meses creciendo.<\/p>\n\n\n\n El retrieval drift<\/strong> aparece cuando las embeddings que funcionaban bien al inicio se vuelven menos precisas a medida que el dominio evoluciona. T\u00e9rminos nuevos aparecen, significados cambian, y el retrieval empieza a encontrar resultados cada vez menos relevantes. La precisi\u00f3n cae gradualmente, lo que hace dif\u00edcil detectar el problema hasta que el output del agente se degrada noticeably.<\/p>\n\n\n\n La memory pollution por few-shot examples mal seleccionados<\/strong> ocurre cuando la memoria epis\u00f3dica retrieva ejemplos que son semanticamente similares pero contextualmente irrelevantes. El usuario pregunta sobre \u00abconfigurar timeout en HTTP\u00bb. La memoria epis\u00f3dica recupera un ejemplo sobre \u00abconfigurar timeout en database connection\u00bb. Semanticamente similares, contextualmente distintos. El modelo aplica el patr\u00f3n de database timeout a HTTP y produce configuraci\u00f3n incorrecta.<\/p>\n\n\n\n La observabilidad de memoria requiere m\u00e9tricas espec\u00edficas que revelen c\u00f3mo el sistema usa y recupera informaci\u00f3n.<\/p>\n\n\n\n M\u00e9tricas operativas:<\/strong> Context utilization rate (porcentaje del context window usado en cada turno), memory hit rate (porcentaje de queries donde la recuperaci\u00f3n encuentra resultados relevantes), average retrieval latency (tiempo medio de recuperaci\u00f3n).<\/p>\n\n\n\n M\u00e9tricas de calidad:<\/strong> Stale memory rate (porcentaje de memorias recuperadas que superan el umbral de actualidad), contradiction rate (frecuencia de memorias contradictorias en la recuperaci\u00f3n), memory precision score (evaluaci\u00f3n peri\u00f3dica de si las memorias recuperadas son relevantes para el contexto actual).<\/p>\n\n\n\n Formato de log:<\/strong> Con Planning<\/strong>, la memoria almacena planes anteriores y sus resultados. El planificador retrieva planes exitosos para tareas similares. La memoria procedimental almacena lecciones aprendidas sobre qu\u00e9 estrategias de planificaci\u00f3n funcionan mejor en cada dominio.<\/p>\n\n\n\n Con Tool Use<\/strong>, la memoria almacena el resultado de tool calls anteriores. Si el agente ya consult\u00f3 una API hace poco, no necesita consultarla de nuevo.<\/p>\n\n\n\n Con Reflection<\/strong>, la memoria procedimental es el substrate donde la reflection escribe mejoras. Sin memoria procedimental, la reflection no persiste.<\/p>\n\n\n\n Con Routing<\/strong>, la memoria sem\u00e1ntica almacena patrones de routing exitosos como few-shot examples para futuras decisiones.<\/p>\n\n\n\n Con Multi-Agent<\/strong>, la memoria compartida permite que agentes especializados accedan al mismo conocimiento. La memoria es el canal de comunicaci\u00f3n persistente entre agentes.<\/p>\n\n\n\n Tareas one-shot: <\/strong>Si la interacci\u00f3n es una pregunta y una respuesta, la memoria es sobrecarga innecesaria. <\/p>\n\n\n\n Datos ef\u00edmeros:<\/strong> Informaci\u00f3n relevante solo para el turno actual no necesita persistencia. Dominio estable:<\/strong> Si el dominio no evoluciona y las preferencias son est\u00e1ticas, hardcodear la informaci\u00f3n en el system prompt es m\u00e1s eficiente. <\/p>\n\n\n\n Latencia cr\u00edtica:<\/strong> Cada retrieval a\u00f1ade latencia.<\/p>\n\n\n\n La prueba pr\u00e1ctica es directa, implementa sin memoria primero. Si la calidad del output es insuficiente porque el agente olvida informaci\u00f3n relevante, entonces a\u00f1ade memoria.<\/p>\n\n\n\n Memory Management es una decisi\u00f3n arquitect\u00f3nica con trade-offs expl\u00edcitos entre persistencia y latencia, precisi\u00f3n del retrieval y consumo de tokens, personalizaci\u00f3n y aislamiento de datos. Sin memoria, cada interacci\u00f3n es un arranque en fr\u00edo. Con memoria mal gestionada, el agente recuerda cosas incorrectas o desactualizadas y produce output confiante pero err\u00f3neo.<\/p>\n\n\n\n La arquitectura que funciona no es la m\u00e1s ambiciosa. Es la que distingue entre lo que necesita estar en contexto ahora y lo que puede esperar en almacenamiento externo, que recupera informaci\u00f3n relevante sin contaminar el contexto con ruido, y que descarta datos obsoletos antes de que degraden el sistema.<\/p>\n\n\n\n Un agente sin memoria olvida. Un agente con mala memoria recuerda cosas equivocadas. La diferencia es sutil, un sistema es \u00fatil y otro genera confianza en resultados incorrectos.<\/p>\n\n\n\n Cuando el agente necesita continuidad entre interacciones, conversaciones multi-turno, personalizaci\u00f3n basada en preferencias del usuario, o tareas que requieren conocimiento acumulado. Si una interacci\u00f3n es autocontenida, la memoria es sobrecoste.<\/p>\n\n\n\n La memoria a corto plazo vive en el la ventana de contexto, es inmediata pero ef\u00edmera. La memoria a largo plazo vive en almacenamiento externo, persiste entre sesiones pero requiere de recuperaci\u00f3n expl\u00edcita.<\/p>\n\n\n\n Sliding windows con prioridad, resumen progresivo de mensajes antiguos, y pruning de datos ef\u00edmeros. Monitoriza el context utilization rate, si supera consistentemente un umbral alto, ajusta la estrategia de compresi\u00f3n o recuperaci\u00f3n.<\/p>\n\n\n\n Implementa hybrid retrieval (semantic search + keyword matching + metadata filters) y re-ranking. Si el problema persiste, revisa la calidad de las embeddings, pueden estar desactualizadas o mal calibradas para tu dominio espec\u00edfico.<\/p>\n\n\n\n Depende del dominio. Un punto de razonable es un peque\u00f1o n\u00famero de episodios comprimidos por query. M\u00e1s episodios consumen tokens sin mejorar necesariamente la calidad.<\/p>\n\n\n\n S\u00ed, pero el context window es m\u00e1s limitado. La estrategia de gesti\u00f3n es m\u00e1s cr\u00edtica en modelos locales porque no puedes escalar el contexto como con APIs comerciales. Prioriza memoria sem\u00e1ntica compacta y recuperaci\u00f3n precisa sobre memoria epis\u00f3dica extensiva.<\/p>\n","protected":false},"excerpt":{"rendered":" Memoria en agentes LLM: C\u00f3mo combinar contexto corto y almacenamiento externo para mantener coherencia.<\/p>\n","protected":false},"author":1,"featured_media":718,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135,6],"tags":[121,159,123,86,85,160,156,157,158],"class_list":["post-710","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agentes","category-ia-automatizacion","tag-agentic-patterns","tag-context-window","tag-google-adk","tag-langgraph","tag-llm","tag-memoria-de-agentes","tag-memory-management","tag-vector-database","tag-vertex-memory-bank"],"_links":{"self":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts\/710","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/comments?post=710"}],"version-history":[{"count":4,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts\/710\/revisions"}],"predecessor-version":[{"id":772,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/posts\/710\/revisions\/772"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/media\/718"}],"wp:attachment":[{"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/media?parent=710"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/categories?post=710"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atlaszn.com\/blog\/wp-json\/wp\/v2\/tags?post=710"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Tipos de memoria: Taxonom\u00eda, no arquitectura<\/h2>\n\n\n\n
Context window management<\/h2>\n\n\n\n
Retrieval: El punto donde la memoria se hace \u00fatil o in\u00fatil<\/h2>\n\n\n\n
Memory decay y stale data<\/h2>\n\n\n\n
\n
Memory leakage<\/h2>\n\n\n\n
user:<\/code>, app:<\/code>, y temp:<\/code> implementan este scoping. En LangGraph, los namespaces cumplen la misma funci\u00f3n.<\/p>\n\n\n\nMemory Management en c\u00f3digo<\/h2>\n\n\n\n
Memoria dual con LangGraph<\/h3>\n\n\n\n
from langgraph.store.memory import InMemoryStore\nfrom langchain_openai import OpenAIEmbeddings\n\nembeddings = OpenAIEmbeddings(model=\"text-embedding-3-small\")\nstore = InMemoryStore(\n index={\"embed\": embeddings.embed_query, \"dims\": 1536}\n)\n\n# Memoria sem\u00e1ntica: preferencias del usuario\nstore.put(\n namespace=(\"user_prefs\", \"alice\"),\n key=\"style\",\n value={\"preference\": \"concise\", \"language\": \"python\", \"updated\": \"2026-06-17\"}\n)\n\n# Memoria epis\u00f3dica: Few-shot example\nstore.put(\n namespace=(\"episodes\", \"debugging\"),\n key=\"session_20260610\",\n value={\n \"context\": \"Error de connection timeout en API\",\n \"action\": \"Verificar timeout settings y retry logic\",\n \"result\": \"Success after increasing timeout\",\n \"timestamp\": \"2026-06-10\"\n }\n)\n\n# Retrieval con semantic search + metadata filtering\ndef retrieve_relevant_memory(store, query, user_id, max_results=3):\n results = store.search(\n namespace=(\"user_prefs\", user_id),\n query=query,\n limit=max_results\n )\n # Filter by recency\n import datetime\n cutoff = datetime.datetime.now() - datetime.timedelta(days=30)\n recent = [\n r for r in results\n if r.value.get(\"updated\", \"\") >= cutoff.strftime(\"%Y-%m-%d\")\n ]\n return recent\n\nuser_memory = retrieve_relevant_memory(store, \"coding style\", \"alice\")\nsystem_prompt = f\"\"\"Eres un asistente t\u00e9cnico.\nPreferencias del usuario: {user_memory}\nResponde seg\u00fan estas preferencias.\"\"\"<\/code><\/pre>\n\n\n\n(\"user_prefs\", \"alice\")<\/code> a\u00edsla la memoria de cada usuario.<\/p>\n\n\n\nMemoria procedimental con reflection<\/h3>\n\n\n\n
from langgraph.store.memory import InMemoryStore\nfrom langchain_openai import ChatOpenAI\nimport datetime\n\nstore = InMemoryStore()\nllm = ChatOpenAI(model=\"gpt-4o\")\n\n# Inicializar memoria procedimental\ninitial_instructions = {\n \"instructions\": \"Analiza c\u00f3digo Python y reporta bugs.\",\n \"versi\u00f3n\": 1,\n \"updated\": \"2026-06-01\"\n}\nstore.put(\n namespace=(\"procedural\",),\n key=\"code_analyzer\",\n value=initial_instructions\n)\n\n# Reflection: el agente mejora sus propias instrucciones\ndef reflect_and_update(state, store):\n current = store.get((\"procedural\",), \"code_analyzer\")\n \n reflection_prompt = f\"\"\"\nTus instrucciones actuales son:\n{current.value['instructions']}\n\nHistorial de errores recientes:\n{state.get('recent_errors', 'Ninguno')}\n\nHistorial de aciertos:\n{state.get('recent_successes', 'Ninguno')}\n\nMejora tus instrucciones bas\u00e1ndote en este historial.\nMant\u00e9n las que funcionan, ajusta las que fallaron.\nDevuelve solo las nuevas instrucciones.\n\"\"\"\n new_instructions = llm.invoke(reflection_prompt)\n \n # Actualizar con versionado\n new_version = current.value.get(\"versi\u00f3n\", 1) + 1\n store.put(\n namespace=(\"procedural\",),\n key=\"code_analyzer\",\n value={\n \"instructions\": new_instructions.content,\n \"versi\u00f3n\": new_version,\n \"updated\": datetime.date.today().isoformat()\n }\n )\n return {\"instructions_updated\": True}<\/code><\/pre>\n\n\n\nFallos reales<\/h2>\n\n\n\n
Observabilidad<\/h2>\n\n\n\n
{memory_type, operation, namespace, key, retrieval_score, age_days, tokens_consumed, hit_or_miss}<\/code>. El campo retrieval_score<\/code> es cr\u00edtico para detectar retrieval drift, si los scores bajan gradualmente, las embeddings o las queries est\u00e1n perdiendo precisi\u00f3n.<\/p>\n\n\n\nMemory Management combinado con otros patrones<\/h2>\n\n\n\n
Cu\u00e1ndo NO usar Memory Management<\/h2>\n\n\n\n
Anti-patrones<\/h2>\n\n\n\n
\n
Conclusi\u00f3n<\/h2>\n\n\n\n
\u00bfCu\u00e1ndo debo usar Memory Management?<\/h3>\n\n\n\n
\u00bfCu\u00e1l es la diferencia entre memoria a corto y largo plazo?<\/h3>\n\n\n\n
\u00bfC\u00f3mo evito que el contexto se llene?<\/h3>\n\n\n\n
\u00bfQu\u00e9 hago cuando el retrieval devuelve informaci\u00f3n irrelevante?<\/h3>\n\n\n\n
\u00bfCu\u00e1nta memoria epis\u00f3dica es demasiado?<\/h3>\n\n\n\n
\u00bfMemory Management funciona con modelos locales?<\/h3>\n\n\n\n