ES
REM ajusta el momento y la duración de la memoria de los agentes de programación
REM: What to Store, When to Recall, What to Forget in Experience Memory for Coding Agents · arXiv:2610.27377
En palabras sencillas
Los agentes de programación pueden consultar registros de trabajos anteriores, pero quizá sean demasiado largos o lleguen en un momento poco oportuno. Este artículo presenta REM, un método que organiza cada ejecución pasada en una guía breve y muestra las modificaciones detalladas solo después del primer fallo de comprobación del agente actual.
En 99 tareas de reparación de errores, REM resolvió una proporción mayor que la condición sin memoria en cada una de las tres ejecuciones. La diferencia no fue estadísticamente significativa en la prueba pareada, así que el resultado es una señal prometedora en este conjunto de pruebas, no una garantía.
La investigación
Cuando un agente recupera una solución anterior pertinente, ¿cómo puede evitar distraerse con demasiados detalles o con consejos que llegan en el momento equivocado? Las necesidades del agente cambian durante una tarea, pero un sistema de recuperación por sí solo no puede observar ese avance.
REM organiza las ejecuciones de programación anteriores en guías breves y muestra las modificaciones detalladas solo tras una comprobación fallida, mientras el agente trabaja.
Los autores compararon REM con la condición sin memoria en 99 tareas de reparación de errores en repositorios, con tres ejecuciones de cada condición usando Claude Sonnet 4.5.
Una tarea se consideró resuelta cuando las pruebas del benchmark se superaban con el parche enviado. REM resolvió una media del 27.6%, frente al 24.9% sin memoria, y resolvió más tareas en cada repetición.
REM también usó menos tokens ponderados por coste por tarea. Sin embargo, la diferencia pareada en resolución no fue estadísticamente significativa. Por eso, los autores consideran que la dirección consistente entre ejecuciones es evidencia de que el ciclo de vida de la memoria podría ayudar en este contexto, no una mejora concluyente en la resolución.
La diferencia principal en la resolución no fue estadísticamente significativa en la prueba pareada, y el análisis de cinco modelos incluyó una ejecución por modelo.
Los resultados abarcan un conjunto de prueba de reparación de errores en un repositorio y un conjunto fijo de ejecuciones anteriores; no evalúan una memoria que se acumula a lo largo de ejecuciones repetidas.
Qué muestran las pruebas
- Recuperar es solo el comienzo
Reusable Experience Memory (REM) es un marco para agentes de programación que gestiona qué experiencias de tareas anteriores guardar, cuándo recuperarlas y cuándo olvidarlas. La pregunta es por qué recuperar una ejecución relacionada quizá no baste para ayudar: las trayectorias sin procesar incluyen caminos abandonados, mientras que las necesidades del agente receptor cambian a medida que trabaja. REM integra las decisiones sobre la memoria en el ciclo de trabajo del agente.
- Separar la guía de los detalles
REM convierte cada ejecución de programación terminada en un documento compacto, organizado en torno a localizar un defecto, entenderlo, corregirlo y comprobar la corrección. El documento se recupera al comenzar la siguiente tarea.
El registro detallado de implementación de esa misma ejecución se retiene hasta el primer fallo de validación del agente y, después de mostrarse una vez, se elimina. Así, la guía permanece disponible y los detalles costosos se muestran ante una señal de dificultad.
- Un resultado final que exige cautela
Los autores probaron 99 tareas de reparación de errores en repositorios con Claude Sonnet 4.5 y ejecutaron tres veces las condiciones con REM y sin memoria. Una tarea se consideró resuelta si las pruebas del benchmark se superaban con el parche del agente; una ejecución sin un parche aplicable se contó como no resuelta.
REM resolvió una media del 27.6%, frente al 24.9% sin memoria, y el número de tareas resueltas fue mayor en cada repetición. La diferencia pareada no fue estadísticamente significativa (p=0.22).
- Importa cómo se organiza la memoria
Para comprobar si bastaba con la relevancia, los autores proporcionaron resúmenes y trayectorias sin procesar de la ejecución relacionada identificada por el benchmark.
En las ejecuciones probadas, estos formatos de referencia no elevaron la resolución por encima de la condición sin memoria; en cambio, un documento por fases de esa misma ejecución identificada resolvió 26 de 99 tareas en una ejecución. Una prueba de identificadores también encontró que los identificadores del documento de REM aparecían con más frecuencia en el texto del agente y en las entradas de sus herramientas que los de los resúmenes o trayectorias de referencia, aunque su aparición no demuestra que se usaran de forma significativa.
- La memoria depende del agente que la recibe
Al mantener fijo el documento recuperado y cambiar el momento en que aparecía el registro detallado y cuándo se retiraba, no se observaron diferencias pareadas estadísticamente significativas. El documento por sí solo quedó cerca de REM completo.
Entre cinco modelos de agente, el documento por fases no redujo la resolución de los tres con tasas sin ayuda iguales o inferiores al 31.3%, pero sí la redujo en los dos por encima del 47%; cada modelo se probó una vez. Por tanto, la evidencia señala que importan tanto el formato de la memoria como el agente que la recibe, aunque el tamaño y la estabilidad de esos efectos siguen siendo inciertos.
Detalles
- Autores del paper original
- Xinyi Lisa Chen, Pedro Herrero-Vidal, Xiaohan Chen, Xiaojing Yu, Cris Liu
- Enviado a arXiv
- Licencia
- CC BY 4.0