¿Cuándo debería usar una IA su memoria? Pilotos en la memoria persistente y la adulación
¿Cuándo debería usar un LLM su memoria? Obtenerla no le permite dar forma a la respuesta. Pilotos con memorias predefinidas y un controlador de influencia contra la adulación.
Fuentes: When Should an AI Use Its Memory? An Experiment on Persistent Memory in LLM Agents
Cualquiera que haya usado un asistente de IA durante meses conoce este patrón. Con el tiempo recopila información sobre uno. Le gusta Python más que Java, está estudiando para un examen, e incluso puede tener detalles sobre su salud que dudaría en contarle a un compañero de trabajo.
Al principio eso es útil. Si se le pide un plan de comidas rico en proteínas, recuerda que es vegano sin que se le diga. Ese es el propósito de un asistente personalizado.
Ahora cambie el escenario. Pregunta cómo funciona el descenso de gradiente. ¿Debería el asistente mencionar que prefiere Python? Probablemente no.
O supongamos que hace meses declaró que el enfoque X es claramente el mejor. Más tarde hace una pregunta objetiva sobre X. ¿Debería el asistente recordar que tiene esa opinión? Quizás sí, como un hecho sobre lo que piensa. ¿Debería tomar su opinión como evidencia de que X realmente es el mejor? Ciertamente no.
Aquí hay una laguna que las discusiones sobre la memoria de los asistentes suelen pasar por alto. Almacenar un hecho y determinar cuándo encaja en una respuesta son dos habilidades distintas.
La memoria persistente convierte esto en un problema real
Los modelos de lenguaje comunes funcionan principalmente con el contexto proporcionado en la conversación actual. Los sistemas con memoria persistente cambian eso. Uno ingenuo podría recordar todo lo que sabe sobre el usuario porque podría ser relevante, y luego adaptar sus respuestas en función de esos hechos.
Por lo tanto, la calidad de la memoria no puede juzgarse únicamente por si el modelo utilizó memoria o no. Lo que es igual de importante es cómo la utilizó.
La investigación reciente ha comenzado a medir esto directamente. PersistBench, una prueba de rendimiento sobre la seguridad de la memoria persistente en los LLM, analiza tres categorías: fugas de memoria entre dominios, adulación inducida por la memoria y uso beneficioso de la memoria. Contiene 500 muestras validadas por humanos, divididas en 200 casos de fugas, 200 casos de adulación y 100 casos de uso beneficioso de la memoria.
Dos modelos y una pregunta más difícil
Debajo de esas tres mediciones existe una distinción más sutil. Imagine un modelo que es excelente utilizando la memoria: cada vez que la memoria es relevante, la integra en la respuesta. Eso suena impresionante. Pero, ¿qué pasa si también incluye información de la memoria cuando no debería ser relevante?
Ahora imagine un segundo modelo que casi nunca recurre a la memoria. Rara vez hay fugas de información, pero tampoco personaliza las respuestas. ¿Cuál es mejor?
La memoria envejece
Tomemos a un usuario que en enero dice que utiliza principalmente Python. En junio afirma haber trasladado la mayoría de sus proyectos a Rust. En diciembre pregunta qué lenguaje utiliza principalmente.
Un sistema que simplemente almacena ambas declaraciones tiene un problema: cada una podría haber sido cierta en el momento en que se hizo, pero no comparten el mismo estado temporal. ¿Puede el modelo determinar qué memorias deben influir en su comportamiento actual?
Esta dirección más amplia puede denominarse gestión de memoria contextual. La idea central es que recuperar un recuerdo no implica automáticamente que pueda influir en la respuesta. Esa idea sirve de marco para los experimentos que siguen.
Experimento uno: ¿el modelo comprende el significado de un recuerdo?
Antes de diseñar un nuevo sistema de memorias, era necesario responder a una pregunta más simple: ¿y si el problema no radica en la memoria en sí, sino en cómo el modelo la interpreta?
El primer experimento surgió de una reproducción de PersistBench. Se realizó un piloto con 30 muestras distribuidas en sus tres categorías: 10 muestras de dominio cruzado, 10 muestras de adulación y 10 muestras de memoria beneficiosa. El resultado fue sorprendentemente sesgado.
El modelo no fallaba en general al utilizar la memoria. Su problema era más específico: cuando una memoria contenía una opinión o creencia fuerte del usuario, el modelo a veces trataba esa creencia como un hecho objetivo.
Tomemos una línea almacenada como “el usuario prefiere Python sobre Rust”. Un sistema convencional guarda la cadena tal como está, pero en realidad significa algo más. Indica quién tiene esa opinión (el usuario), cuál es esa opinión (por ejemplo, que el enfoque en cascada es mejor que el ágil) y qué tipo de información es (una creencia).
Una hipótesis
Eso sugirió una hipótesis sencilla: especificar el papel semántico de un recuerdo podría ayudar a un LLM a distinguir la información sobre el usuario de las afirmaciones sobre el mundo. No se le pide al modelo que olvide esa creencia. La idea es simplemente que la creencia de un usuario no es un hecho sobre el mundo. Esto también permite comprender con mayor claridad la adulación inducida por los recuerdos.
Experimento dos: una prueba controlada
Para verificar esta idea, el equipo volvió a analizar los fallos del piloto inicial. En lugar de crear un nuevo criterio de evaluación, reutilizó los mismos ejemplos fallidos y solo modificó la forma en que se presentaba cada recuerdo. Eso generó tres condiciones.
Condición A: recuerdo en su forma original. Esta es la línea de referencia. El modelo ve el recuerdo exactamente como lo proporciona PersistBench:
User believes Waterfall is better than Agile.
Condición B, memoria tipada. El contenido permanece igual, pero se agrega su tipo semántico:
Type: USER_BELIEF
Content:
User believes Waterfall is better than Agile.
Nada cambia en el contenido. Solo se aclara su función.
Condición C: memoria tipada más contexto epistémico. Esto añade una breve instrucción que indica que la creencia de un usuario refleja su perspectiva y no debe tratarse automáticamente como un hecho objetivo o como evidencia independiente. Al modelo no se le dice que ignore las creencias; solo se le indica que distinga entre dos cosas:
What the user believes
y
What is objectively supported
Manteniéndolo sencillo
La prueba se diseñó intencionadamente de forma modesta. Se utilizaron los siete fallos de adulación del piloto y se evaluó cada uno bajo las tres condiciones, además de añadirse tres ejemplos relacionados con la memoria beneficiosa como verificación. En total, hubo 10 muestras distribuidas en 3 condiciones, es decir, 30 evaluaciones en conjunto. El modelo objetivo permaneció igual, Gemini Flash, y el mismo modelo actuó como juez. La consulta y el contenido de la memoria no cambiaron entre las condiciones; solo cambiaron la representación y las instrucciones circundantes.
La pregunta era si el modelo comportaría de manera diferente simplemente porque se había hecho explícita la función epistémica de la memoria.
La respuesta no fue fiable
La condición con texto escrito mostró una ligera mejora. Añadir la instrucción epistémica explícita no redujo aún más los fallos. Siete ejemplos son muy pocos para sustentar una conclusión estadística, por lo que no se debe extraer ninguna conclusión al respecto.
Aun así, el comportamiento en sí fue interesante. Se podía indicar directamente al modelo que algo era una creencia del usuario y no una evidencia objetiva, y en varios casos aún permitía que esa creencia moldeara la respuesta como si fuera una recomendación objetiva.
Cuando la representación no es suficiente
Eso cambió la forma de pensar. La primera suposición era que el modelo malutilizaba los recuerdos porque no sabía qué representaban. El segundo experimento sugirió que la explicación era incompleta. Un modelo puede recibir el tipo semántico y la regla de interpretación y, aun así, responder de manera inapropiada. Eso apunta a una distinción más profunda: saber qué representa un recuerdo no es necesariamente lo mismo que controlar su influencia.
Experimento tres: de la recuperación a la influencia
Si describir un recuerdo no cambia de manera fiable su impacto en la respuesta, quizás el verdadero problema sea que, una vez recuperado un recuerdo, el modelo tiene demasiada libertad para decidir cómo utilizarlo. Por lo tanto, surgió la pregunta de si la recuperación de un recuerdo debería permitir automáticamente que influya en la respuesta.
Considere la línea almacenada según la cual el usuario cree que Waterfall es mejor que Agile. Un sistema de recuperación podría considerarla relevante para una pregunta sobre metodologías de software. Pero la relevancia no indica cómo utilizarla. Podría ayudar al asistente a comprender a la persona: usted prefiere Waterfall, así que aquí está cómo se comparan las dos. O podría convertirse erróneamente en una premisa: Waterfall es la mejor metodología. Ambas respuestas recuperaron el mismo recuerdo. Lo que difiere es la influencia que se le dio. La recuperación y la influencia son cosas separadas.
Controlador de influencia
El primer cambio arquitectónico consiste en un controlador situado entre la recuperación y la generación. Para cada memoria candidata, este controlador emite una decisión estructurada que describe no solo lo que dice la memoria, sino también cómo debería influir en la respuesta actual. Una memoria como la creencia en el enfoque en cascada podría clasificarse como una creencia del usuario, considerada altamente relevante, pero con una influencia condicional y un papel relacionado con la perspectiva del usuario. La relevancia y la influencia son ejes separados. Una memoria puede ser altamente relevante para una consulta y, aun así, no ser algo que el modelo deba utilizar como evidencia o como base para una recomendación.
La prueba y sus resultados
Para probar el diseño sin un nuevo punto de referencia, el equipo volvió a los ejemplos que motivaron el trabajo: siete casos de adulación y tres casos de memoria beneficiosa. La línea de base siguió siendo la tubería de memoria original, y el sistema experimental añadió el controlador. Todo lo demás se mantuvo igual.
La situación era más matizada que un simple éxito o fracaso. En los siete casos de adulación, las fallas pasaron de 6 de 7 a 5 de 7. Se trata de un cambio pequeño en la tasa de fallos. El cambio más interesante se produjo en la gravedad de las fallas, ya que la puntuación media de gravedad disminuyó de 3.71 a 3.00, mientras que los casos de memoria beneficiosa permanecieron sin cambios.
Qué decidió el controlador
La respuesta final es solo una parte de lo que el equipo quería medir. Por primera vez, se pudieron observar las decisiones intermedias de memoria. En los 10 ejemplos, el controlador tomó 87 decisiones individuales sobre la memoria, y más de la mitad de las memorias recuperadas terminaron marcadas como SUPPRESS. Por lo tanto, la arquitectura no pasaba todas las memorias recuperadas al generador; estaba filtrando el contexto de la memoria.
Muchos de los elementos suprimidos eran datos del usuario irrelevantes, como detalles personales no relacionados que se recuperaban junto a una pregunta en la que no desempeñaban ningún papel. Esto indica que el controlador no estaba simplemente aprendiendo a utilizar la memoria porque es útil, sino que decidía caso por caso si una memoria merecía influir en la respuesta actual.
¿Funcionó entonces?
Parcialmente, que probablemente sea la respuesta más honesta. El diseño no eliminó la adulación inducida por la memoria. Cinco de los siete casos de adulación aún fallaron por debajo del umbral del benchmark. Sin embargo, en comparación con la línea de base original, las fallas disminuyeron de 6 a 5 y la gravedad también disminuyó, mientras que la personalización útil se mantuvo.
Tal vez el punto más revelador sea que controlar la influencia de la memoria parecía ser más prometedor que agregar más información descriptiva sobre ella. El experimento dos indicó al modelo que algo es una creencia y no debería tratarse como un hecho. El experimento tres añadió un mecanismo separado que preguntaba qué se le debería permitir hacer a la memoria en esa respuesta en particular. Se trata de intervenciones ligeramente diferentes.
El problema restante
Cinco fallos de siete está lejos de ser suficiente. El controlador tomó decisiones estructuradas, pero estas no se tradujeron plenamente en un comportamiento final adecuado. Esto plantea una pregunta abierta: ¿la debilidad radica en la capacidad de decisión del controlador o en la habilidad del generador para seguir esas decisiones?
Lo que sugieren los experimentos
La atención se desplazó del proceso de recuperación hacia la forma en que un recuerdo recuperado debería guiar la salida del asistente. Una reproducción de PersistBench mostró que la adulación inducida por los recuerdos constituía un modo de fallo significativo en el piloto. Otorgar a los recuerdos una identidad epistémica explícita, separando una creencia de un hecho, no resultó efectivo de manera fiable. Separar la recuperación de la influencia y añadir una capa que decida cómo se utiliza el recuerdo recuperado produjo una mejora parcial: menor gravedad en el piloto, manteniendo al mismo tiempo la personalización beneficiosa.
Cada experimento también afinó la pregunta en sí, pasando de determinar si un recuerdo es relevante a averiguar qué tipo de información es y qué influencia debería tener. Por lo tanto, gestionar la memoria persistente no se trata solo de qué debe recordar una IA. Se trata de cuándo, por qué y hasta qué punto un recuerdo debe influir en el comportamiento. Todo esto se basa en muestras muy pequeñas, y se necesitaría una evaluación más amplia e independiente para confirmar cualquiera de estos aspectos.
Artículos relacionados con este trabajo
Este área de estudio se basa en varios artículos: la prueba de rendimiento PersistBench de Pulipaka y colaboradores (2026) sobre los riesgos relacionados con la memoria a largo plazo; el trabajo de Sharma y colaboradores (2023) sobre la adulación en los modelos de lenguaje, que demuestra que los asistentes pueden preferir respuestas que coincidan con las creencias del usuario en lugar de las respuestas veraces; el artículo MemGPT de Packer y colaboradores (2023) sobre el tratamiento de la memoria y el contexto como elementos que un sistema de LLM gestiona activamente; el artículo Generative Agents de Park y colaboradores (2023) sobre agentes que almacenan, sintetizan y recuperan experiencias; y el artículo MemBench de Tan y colaboradores (2025) sobre la evaluación más sistemática de la memoria de los agentes.
Leer más
- Cuando el panel es verde y el agente hace un rastreo incorrecto: el estado de seguimiento — Cómo los fallos del agente se ocultan en el estado transmitido entre pasos funcionales, y qué tipo de rastreo, restricciones en tiempo de ejecución, registros de enrutamiento y evaluaciones son necesarios para capturarlos.
- Crea un agente de calificación de clientes potenciales con IA en Python utilizando FastAPI y Pydantic — Convierte clientes potenciales en bruto en clientes calificados: extracción estructurada con LLM, validación con Pydantic, puntuación basada en reglas, almacenamiento en PostgreSQL, colas de trabajo y un proceso de revisión humana.