Recordar historiales de sesión no es útil para los agentes
(12gramsofcarbon.com)- En tareas de SWE, si el agente ya puede ver contexto como documentación, PR y commits, la búsqueda de historiales de sesiones pasadas no generó ventajas de rendimiento
- Una implementación común guarda todos los transcripts en una base de datos y luego expone búsqueda vectorial, Elasticsearch, búsqueda SQL y grafos mediante MCP o skills de CLI, pero en pruebas comparativas durante varios meses no marcó diferencia y a veces incluso pudo empeorar la calidad del modelo
- En entornos donde quedan buenos mensajes de commit, mensajes de PR, documentación y metadatos, la información importante ya está organizada en los artefactos de código, por lo que el historial de sesiones hace que se vuelvan a leer como tokens información duplicada y notas temporales
- Los agentes no son buenos para hacer la depuración de contexto necesaria para la memoria de largo plazo y, como no tienen estado, pueden tratar todo el código, las notas y los tokens del contexto de entrada como intención, acumulando intent drift
- Los historiales de sesiones pueden servir para la observabilidad del equipo, pero como medio para mejorar el rendimiento resultan negativos; incluso las propuestas semanales de cambios de nori bots requerían que una persona revisara el diff, y la tasa real de aceptación fue menor al 20%
Por qué la búsqueda en historiales de sesiones no mejora el rendimiento
- En tareas de SWE, incluso si se permite buscar historiales de sesiones pasadas, cuando existe otro contexto disponible la ventaja de rendimiento fue 0
- Los intentos de revisar automáticamente historiales de sesiones para mejorar el contexto del agente tampoco mostraron grandes beneficios sin revisión humana
- Una arquitectura común de memoria basada en sesiones sigue el siguiente flujo
- Guardar todos los transcripts de toda la organización en una base de datos
- Agregar encima capas de búsqueda vectorial, Elasticsearch y búsqueda SQL
- Los equipos más ambiciosos usan las tres e incluyen también grafos
- Exponerlo al agente mediante MCP o una CLI con skills
- Tras varios meses comparando el enfoque con y sin búsqueda de sesiones, este trabajo adicional no produjo diferencias y en algunos casos pudo empeorar el modelo
- La información útil ya está organizada en los artefactos de código
- Los cambios de código incluyen buenos mensajes de commit, mensajes de PR, documentación exhaustiva y metadatos versionados junto con el código
- A los agentes se les indica revisar la documentación y los PR anteriores cuando trabajan sobre cierto código
- La búsqueda del historial de sesiones hace que vuelvan a leer cosas que ya saben y además consuman tokens con juicios temporales y scratchpads que originalmente no se pensaron para quedar registrados
Dónde falla la memoria automática
- Los agentes no logran hacer la limpieza de memoria que es clave para mantener memoria de largo plazo
- En miles de sesiones, no se había visto un caso real en el que eliminaran contexto
- No es una propiedad que pueda resolverse con prompt engineering; como los agentes no tienen estado, tratan todo lo que entra en la ventana de contexto como ground truth
- El código, la memoria existente y todos los tokens se tratan como expresiones de intención, incluso si fueron decisiones arbitrarias de una sesión anterior del agente o contenido no revisado por personas
- En este proceso se acumula el intent drift
- Cuanto más construye un agente de forma autónoma una base de memoria, más se acumulan las interpretaciones incorrectas de intención de entradas anteriores
- No existen benchmarks de coding que asuman que los datos de entrada están contaminados, y al modelo incluso se le penaliza si asume que los datos de entrada son incorrectos
- Tampoco hay una forma sencilla de satisfacer al mismo tiempo “no borres el codebase” y “borra parte del contexto de entrada”
- La memorización automática termina convirtiéndose en contexto basura innecesario que consume tokens, eleva los costos y reduce la calidad del modelo
- Los historiales de sesiones pueden ser útiles para la observabilidad del equipo, pero es difícil verlos como una herramienta para hacer mejores a los agentes
El enfoque de revisión humana de nori bots
- No es que sea imposible aprender contexto con el tiempo; nori bots revisa cada semana lo ocurrido en la empresa —PR, Slack, Drive, etc.— y propone cambios a los skillsets integrados de nori
- Las propuestas etiquetan al equipo en Slack, pero por defecto todo se rechaza
- Para aceptar un cambio hay que revisar el diff directamente y confirmar que coincide con la intención
- La tasa de aceptación es menor al 20%, y se considera que el otro 80% de actualizaciones “automáticas” habría empeorado el modelo
- Si una organización de cientos de personas almacenara siempre estas actualizaciones de forma automática, podría volverse aún menos sostenible
1 comentarios
Opiniones en Hacker News
Me recuerda a cuando OpenAI dijo que había agregado a ChatGPT una función de memoria entre sesiones. Al final se sentía como una función que buscaba información variada sobre mí y la copiaba y pegaba entre prompts sin mi consentimiento explícito.
Algo como: “Compara estos tres autos. Ah, por cierto, soy ingeniero de datos, el apellido de soltera de mi madre es Joana, soy alérgico a la mala poesía. El código debe ser DRY, prefiero SQL a Python, ¿y cuál es la flor más tóxica de Escandinavia?”
Como el contexto recordado se filtraba a proyectos y conversaciones que no tenían nada que ver y producía demasiadas salidas raras, es lo primero que desactivo.
Totalmente de acuerdo. El sistema de memoria de claude-code a veces es útil, pero muchas más veces resulta dañino porque trae información vieja que enturbia el trabajo actual. He visto con frecuencia cómo la propia memoria de Claude lo desvía gravemente.
Si tuviera que especular, parece estar relacionado con que, por el proceso de entrenamiento, el modelo no logra distinguir entre “lo que está pasando ahora” y “lo que pasó antes”. Si el proceso de razonar a partir de la memoria hubiera sido parte del entrenamiento, quizá sería distinto, pero como es una función que solo se adjunta en el momento de la inferencia, da la impresión de que confunde al modelo.
Los LLM no son lo bastante inteligentes como para tolerar siquiera una ligera contaminación del contexto.
El razonamiento o el contexto que lo llevó hacia allá tiene inercia, y si se deja ahí, se queda pegado.
Pero si más tarde lo vuelve a sacar de la memoria, resulta bastante molesto.
La idea de entrenar incluyendo memoria es interesante.
En general no importa lo que “se intentaba que hiciera” el código. Lo importante es lo que el código hace realmente.
Los logs de sesión sin duda pueden ser útiles, pero no cuando se sigue construyendo encima de ellos, sino al entrar en la etapa de verificación. Ese tramo justo entre el plan en Markdown y el CI en verde, cuando ya aparecieron 800 líneas de código nuevo y, al hacer clic, todo parece más o menos bien.
Los logs de sesión pueden mostrar qué verificación manual hubo. El CI ejecuta las pruebas existentes, y el código muestra cuáles son las nuevas pruebas unitarias, pero el log de sesión muestra si el agente manipuló directamente la app con Playwright, o si leyó y tuvo en cuenta no solo la configuración de dev sino también la de prod.
No es perfecto, pero no todo trabajo de verificación tiene que convertirse en una prueba que quede para siempre en el repositorio. Hemos visto mucho valor en volver a analizar las sesiones para encontrar los puntos donde el agente tomó decisiones sin preguntar, y obligarlo a considerar la verificación de esas decisiones. Eso es difícil de indicar desde el principio, pero con los logs de sesión salta a la vista.
Es un problema molesto. Por una pregunta hipotética que hice antes, sigue inventando premisas falsas.
Solo porque le pedí investigar algo, asume que soy dueño de un centro de datos y que tengo muchas GPU.
Me parece que esto es simplemente una forma de lección amarga. El contexto y los agentes que armamos con tanto esfuerzo probablemente desaparezcan cuando salgan modelos más grandes y mejores.
Esos historiales de conversación son muy útiles para modelos de menor capacidad, pero quizá sean casi innecesarios para los modelos de frontera.
Uso un arnés personalizado basado en https://minimal-agent.com/, que a su vez se basa en swe-mini-agent y cuya lógica central tiene unas 50 líneas. Con Bash alcanza.
En tareas pequeñas es unas 8 veces más rápido que el arnés estándar de cada modelo y usa también 8 veces menos tokens.
En tareas grandes no lo he probado mucho. Funciona, pero en esos casos parece menos enfocado y un poco menos productivo. Es posible que el prompt de sistema de 20 mil tokens de los arneses grandes esté haciendo un trabajo importante para orientar el flujo de desarrollo de software. Por ejemplo, escuché que Fable tiene un prompt de sistema personalizado para Claude Code, y quizá por eso actúa de forma mucho más proactiva.
Por eso quiero creer que la ingeniería de contexto todavía tiene valor. Pero parece que ese valor disminuye con cada nuevo modelo, porque los modelos suelen venir ajustados para hacer menos tonterías y necesitan menos que los lleven de la mano.
Para empezar, creo que los modelos siguen necesitando una capa de contexto. Una forma de pensar el contexto es como compresión. Se ofrece contexto para que al modelo le resulte más fácil entender qué debe hacer. Incluso en un mundo con capacidad de modelo y longitud de contexto infinitas, seguiría siendo útil porque evita tener que derivarlo todo desde primeros principios cada vez. Mientras el modelo pueda rendir mejor con menos tokens y a nosotros nos importe el costo de los tokens, el contexto es un atajo útil, quizá necesario.
Si aceptamos que hace falta alguna forma de capa de contexto, la siguiente pregunta es qué capa. En esto estoy de acuerdo en que conviene trabajar con formas familiares para el modelo, por ejemplo archivos Markdown junto al código. Pero esto se parece menos a una pregunta sobre si el contexto es necesario y más a un problema donde una solución sobrediseñada no entendió a su usuario principal: el agente.
Pero me da mucha curiosidad si una predicción del siguiente token mucho mejor no volverá obsoleta toda esa configuración. Sea cual sea la respuesta, revelará mucho.
Hay que recordar que la estructura del cerebro también se aprende. Solo que se aprende en escalas de tiempo muchísimo más largas que la vida de un individuo.
Estoy de acuerdo en que no hace falta crear un sistema de memoria sofisticado. Lo que vale la pena recordar debería estar en documentos, guías, comentarios del código fuente, mensajes de commit y tickets.
No hace falta otra capa. Cualquier granularidad que se te ocurra ya está cubierta por las buenas prácticas existentes.
Esta extensión hace lo siguiente: https://github.com/gitsense/pi-brains
Por ahora el “humano” tiene que definir reglas de enrutamiento sobre cómo acceder a la información, pero más adelante planea admitir un “agente de conocimiento” que monitoree la conversación e inyecte contexto cuando sea necesario.
~/.claude/….En los proyectos donde hizo falta memoria, simplemente agregué una línea en AGENTS.md indicando que se usara MEMORY.md para guardar recuerdos o STATUS.md para seguir el avance.
Pero si se etiqueta en un registro de seguimiento, se puede encontrar de forma eficiente cuando haga falta. Además, la documentación se pudre, mientras que a los registros de seguimiento se les puede adjuntar un hash de commit u otra información para dejar más clara su vigencia.
Estoy totalmente en desacuerdo con esto.
Yo hago que Claude/Codex deje logs [1]. Solo lo indiqué con un prompt en AGENTS.md [0].
“Toda sesión debe crear un log de sesión o un plan, y al final debe anexar el resumen escrito. Por defecto se usa un log, y los planes solo se usan para trabajo de diseño sustancial”.
Esto es tremendamente valioso. Por ejemplo, hoy mismo empecé varias sesiones así: “¿En qué estado están las tareas de Renovate?”, “Hace poco trabajé en X, búscalo”, “¿Se arregló el problema de backups? ¿Cuál es el siguiente paso?”, “Este bug volvió a aparecer. ¿No lo habíamos arreglado ya?”.
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
En general me gustan los sistemas de memoria. Como referencia, uso principalmente Opus 4.8 + Max effort.
Bastante seguido recupera cosas relevantes de la memoria. Por ejemplo, si le pido que sugiera algunos candidatos de proveedores OIDC autohospedados, dice algo como: “considerando el tamaño del equipo de operaciones, este podría encajar mejor por X e Y”.
Claro, quizá esa información debería estar en CLAUDE.md. Pero en ese caso ni siquiera se me había ocurrido ponerla en CLAUDE.md, y estuvo bien que la memoria la sacara a relucir.
A veces también se equivoca. Hoy pregunté por un problema de autenticación y dijo: “como ponen la app detrás de haproxy, podría deberse a esta configuración de trusted proxy”. Eso aplica al 95% de nuestras apps, así que valía la pena mencionarlo, pero esta vez no era el caso y tuve que corregirlo. Aun así, si hubiera estado detrás de un proxy, nos podría haber ahorrado mucho tiempo, así que me pareció bien que lo dijera.
Es especialmente más difícil si haces muchas preguntas hipotéticas o ayudas a resolver problemas de otras personas. Un humano probablemente no asumiría, sino que haría preguntas de confirmación como: “¿Esto es sobre el equipo de operaciones de X? ¿Todavía tiene tamaño Y?” o “¿Esta app también está detrás de un proxy, como las otras apps que mencionaste antes?”.
En ese tipo de contexto también hay una jerarquía clara que hay que modelar correctamente. Por ejemplo, puedes estar involucrado al mismo tiempo con varios equipos sujetos a reglas distintas, y los humanos entienden eso de forma natural.
Aunque apagues la memoria, esto pasa dentro de una misma conversación.
Es como ese amigo molesto que recuerda algo de una conversación anterior y te lo sigue echando en cara aunque tú ya hayas crecido y cambiado.
En el fondo, es un problema de hardware. Un millón de tokens no es suficiente contexto para entender una base de código como la entiende un humano.
La capacidad de olvidar selectivamente es potencialmente muy valiosa. Pero por ahora apenas reemplaza la capacidad humana de recordar la forma aproximada de algo, decidir que no es interesante y recordar que no es interesante.
Se dice que la memoria solo es útil cuando la guía un humano, pero creo que la solución correcta va más profundo que eso. Quizá sea meter toda la base de código y todas las sesiones de agentes en el fine-tuning del modelo. Aunque en ese punto tal vez haga falta indicar que ciertas sesiones no se incluyan en el modelo. O quizá no haga falta, y se aplique la lección aprendida.