Memory Engineering: qué debe recordar, corregir y olvidar un agente

Un asistente recuerda el nombre de un proyecto durante la conversación y parece tener memoria. Al cerrar la sesión y abrir otra, el dato ha desaparecido. La solución inmediata suele ser guardar el historial entero.

Al cabo de unos meses aparece el problema contrario. El asistente recupera una preferencia antigua como si siguiera vigente, mezcla el acuerdo de una persona con el de otra o muestra a la vez un dato y su corrección sin saber cuál es el actual.

El primer sistema no recordaba nada entre sesiones. El segundo almacenaba mucho, pero tampoco tenía una memoria bien diseñada.

La ingeniería de memoria no busca que una IA recuerde más. Decide qué puede

recordar, para quién, durante cuánto tiempo y cómo se corrige o se olvida.

La diferencia importa porque cualquier recuerdo recuperado vuelve al contexto del modelo como información para la tarea actual. Si está equivocado, desactualizado o pertenece a otra persona, el modelo puede utilizarlo con la misma naturalidad que un dato correcto. Hacer persistente un error permite que se repita en conversaciones futuras.

Sesión, contexto y memoria

Durante una conversación, la aplicación conserva mensajes, resultados de herramientas y variables para poder continuar. Ese es el estado de la sesión. Puede durar unas horas o recuperarse después de un fallo, pero no todo lo que contiene merece sobrevivir.

La documentación del Agent Development Kit distingue la sesión, que registra la conversación actual, del servicio de memoria, que mantiene información consultable entre conversaciones. Para pasar de una a otra hace falta una decisión explícita.

El contexto es la selección que recibe el modelo en un momento concreto. Puede incluir algunos mensajes recientes, fuentes recuperadas y recuerdos. La ingeniería de contexto decide cómo se compone esa entrada. La ingeniería de memoria decide qué puede persistir y bajo qué condiciones volverá a ser candidato.

La separación evita dos errores: creer que todo lo visto se recordará o cargar todos los recuerdos en cada petición.

No todos los recuerdos tienen la misma vida

Un agente que reanuda una tarea necesita saber qué pasos terminó y si produjo algún efecto. Un asistente personal puede conservar una preferencia que la persona confirmó. Un sistema de soporte quizá deba recordar un compromiso pendiente, pero no una sospecha surgida durante el diagnóstico.

Antes de escoger una base de datos conviene distinguir:

El mismo texto puede pertenecer a categorías distintas. «Prefiere respuestas breves» puede ser una preferencia personal confirmada. «El informe debe ser breve» puede ser una condición para una tarea concreta. Si se guardan igual, será fácil recuperar una cuando correspondía la otra.

Guardar es una decisión del producto

Si se conserva cada mensaje, la memoria terminará llena de preguntas, errores, datos copiados, instrucciones antiguas y afirmaciones inventadas por el propio modelo. Antes de escribir un recuerdo, la aplicación debe decidir si merece persistir.

Para cada entrada hace falta saber:

• a qué persona, organización, proyecto o tarea pertenece;
• si la declaró alguien, procede de un sistema autorizado o la infirió el modelo;
• qué fuente permite comprobarla;
• cuándo se creó y cuándo se confirmó por última vez;
• para qué puede utilizarse;
• cuándo caduca y qué dato anterior sustituye.

Una puerta decide qué se guarda y otra qué recuerdo puede volver al contexto. Corregir y olvidar forman parte del mismo ciclo.

Ver a tamaño originalCerrar

Resumir tampoco es una operación inocente. Si una persona dijo «creo que el proveedor cambiará la fecha», la memoria no puede convertirlo en «el proveedor cambiará la fecha». Al quitar la duda, el origen o el momento, el resumen ocupa menos y dice otra cosa.

La tecnología puede extraer recuerdos de una sesión o reunir entradas parecidas. La documentación de ADK muestra varias opciones. El producto todavía debe decidir cuándo esa unión combina información compatible y cuándo esconde una contradicción.

Recuperar un recuerdo exige volver a comprobarlo

Un tutor prepara la respuesta a una duda sobre la práctica final de Programación II. Encuentra un recuerdo muy parecido a la consulta: la práctica pesa un 40 % y se entrega en la semana doce.

El recuerdo es correcto, pero no dice a qué edición del curso pertenece. La asignatura se imparte de nuevo, el curso actual procede de una copia del anterior y el peso de la práctica cambió al revisar la guía. Las dos ediciones tienen casi el mismo contenido y dos rúbricas que también se llaman igual. Nada marcó el recuerdo como caducado porque no perdió vigencia por el paso del tiempo: dejó de servir cuando se creó la nueva edición.

Moodle 5.1 conserva datos que permiten distinguir las ediciones, aunque no todo el linaje de una rúbrica restaurada. Solo course.id identifica de forma inequívoca el curso; los índices de shortname e idnumber no son únicos en la base de datos. Al restaurar el curso, la rúbrica recibe un areaid nuevo, pero Moodle pone su copiedfromid a nulo. El curso nuevo sí conserva originalcourseid cuando la restauración procede de otro curso del mismo sitio. La relación entre las dos rúbricas no puede reconstruirse a partir de copiedfromid ni de timecopied: si hace falta conservarla, el sistema de memoria debe registrarla al incorporar el dato.

El estado de la rúbrica añade otra condición: grading_definitions.status distingue las definiciones en borrador de las que están listas para usarse. El texto y el origen del curso no bastan para saber cuál gobierna la actividad; la memoria también debe conservar el course.id, el areaid y el estado. La cercanía entre los textos no resuelve ninguna de estas diferencias.

El calendario académico también cambia la vigencia

La caducidad educativa no siempre llega después de un número fijo de días. El inicio de una nueva edición, el cierre de actas, el final de un periodo de reclamaciones o un cambio de matrícula pueden alterar para qué sirve un dato y quién puede utilizarlo. No todos esos hitos exigen borrar lo mismo. Una nota de trabajo puede dejar de estar disponible para el tutor mientras la calificación oficial permanece en el sistema responsable de custodiar el expediente.

El principio de limitación del plazo de conservación del RGPD impide mantener datos identificables durante más tiempo del necesario para su finalidad. El derecho de supresión también tiene excepciones. Por eso un tiempo de vida uniforme no resuelve el problema: la memoria operativa debe vincular cada dato con su finalidad y con el calendario de conservación aplicable, sin confundirse con el expediente académico oficial.

Antes de añadir un recuerdo al contexto hay que comprobar:

1. que pertenece a la persona, la organización y el proyecto correctos;
2. que quien pregunta puede utilizarlo para esa finalidad;
3. que no ha caducado ni existe una corrección posterior;
4. que ayuda a esta tarea y no solo comparte palabras;
5. que no hay una fuente actual más fiable;
6. que llega al modelo con el origen y la fecha necesarios para interpretarlo.

La memoria puede cargarse al principio de cada turno o consultarse solo cuando el agente la necesita. La primera opción reduce el riesgo de omitir un dato, pero ocupa contexto y puede sesgar todas las respuestas. La segunda ahorra espacio, aunque depende de que el agente sepa cuándo buscar. Hay que probar ambas para el caso real.

Memoria no es RAG ni entrenamiento

RAG es un mecanismo para recuperar información de un conjunto de fuentes. La memoria define el ciclo de vida de aquello que persiste: cómo se crea, se actualiza, se recupera y se borra. Una memoria puede usar búsqueda vectorial y seguir necesitando todas esas reglas.

El capítulo sobre RAG Engineering se ocupa de preparar y recuperar las fuentes. Aquí la pregunta es otra: por qué un dato debe sobrevivir a la conversación y volver a influir más adelante.

Tampoco se trata de entrenamiento. Guardar que una persona corrigió un dato no modifica los pesos del modelo. Precisamente por eso el recuerdo puede leerse, rectificarse y eliminarse sin volver a entrenar nada.

Corregir y olvidar

Un recuerdo correcto al crearse puede dejar de serlo. Cambian los proyectos, las preferencias, los puestos y las políticas. Cuando aparece información nueva, la aplicación debe decidir si confirma, amplía, contradice o sustituye la anterior.

Sobrescribir sin dejar rastro impide explicar respuestas pasadas. Conservar todas las versiones sin señalar cuál está vigente provoca el problema inverso: la búsqueda puede elegir la equivocada. Hace falta un historial suficiente para entender los cambios y una versión actual clara para el uso diario.

Olvidar también puede significar varias cosas: dejar que caduque el estado de una tarea, impedir que un recuerdo vuelva al contexto, eliminarlo al terminar su finalidad o borrar sus datos identificativos. La acción debe alcanzar índices, resúmenes y cachés. Ocultar la entrada original no sirve si una copia todavía puede llegar al modelo.

La memoria también puede mantener un ataque

Una instrucción maliciosa dentro de un documento puede desviar a un agente durante una ejecución. Si el sistema la guarda como recuerdo, el ataque puede reaparecer en sesiones posteriores.

El trabajo AgentPoison, publicado en NeurIPS 2024 demuestra este riesgo al introducir contenido malicioso en memorias duraderas o bases de conocimiento recuperadas mediante RAG. El hallazgo no significa que todas las memorias sean vulnerables de la misma forma, pero sí que el almacén y la búsqueda forman parte de la seguridad del agente.

Un recuerdo aporta información; no puede conceder permisos ni reescribir las reglas del sistema. Si influye en una acción sensible, la aplicación debe contrastar de nuevo la identidad, la autorización y la fuente.

Cómo probar una memoria

Preguntar al agente si recuerda un dato demuestra muy poco: podría obtenerlo del historial actual o de su conocimiento general. Una prueba útil identifica qué se guardó, qué consulta lo recuperó y cómo cambió el resultado.

Conviene probar por separado:

• la escritura de un hecho, una conjetura, una corrección y un dato sensible;
• dos personas o proyectos con información parecida;
• recuerdos vigentes, caducados y sustituidos;
• varias memorias compitiendo por el espacio disponible;
• la misma tarea con y sin el recuerdo correcto;
• el borrado de la entrada, sus índices, resúmenes y cachés;
• un cambio de modelo, extractor o esquema.

Así se podrá saber si falla la decisión de guardar, la búsqueda, la separación entre usuarios o el efecto sobre la tarea. Una sola puntuación escondería esa diferencia.

Qué debe quedar decidido

Antes de llamar memoria al sistema debe quedar claro qué hechos pueden guardarse, quién puede corregirlos, cuánto duran, cómo se resuelven las contradicciones, qué permisos se aplican al recuperarlos y cómo se eliminan sus copias.

Cuando intervienen varios agentes aparece otra pregunta: ¿el recuerdo pertenece a la persona, al trabajo, al especialista o al sistema que los coordina? El capítulo sobre Agent Engineering desarrolla esa frontera.

La memoria está bien diseñada cuando permite continuar sin convertir el pasado en una autoridad automática. Cada dato necesita una razón para guardarse, una regla que decida cuándo recuperarlo y una forma real de perder vigencia.