Mémoriser les historiques de session n’est pas utile aux agents
(12gramsofcarbon.com)- Dans les tâches de SWE, si un agent peut déjà consulter le contexte comme la documentation, les PR et les commits, la recherche dans les historiques de sessions passées n’a apporté aucun gain de performance
- Une implémentation courante consiste à stocker tous les transcripts dans une base de données, puis à y ajouter de la recherche vectorielle, Elasticsearch, de la recherche SQL ou un graphe, et à l’exposer via MCP ou une skill CLI ; mais lors de tests comparatifs sur plusieurs mois, cela n’a fait aucune différence et a parfois pu dégrader la qualité du modèle
- Dans un environnement où subsistent de bons messages de commit, messages de PR, documents et métadonnées, les informations importantes sont déjà structurées dans les artefacts de code ; les historiques de session amènent surtout à relire sous forme de tokens des informations redondantes et des notes temporaires
- Les agents ne savent pas bien effectuer la suppression de contexte nécessaire à la mémoire à long terme ; comme ils n’ont pas d’état, ils peuvent traiter tout le code, les notes et les tokens du contexte d’entrée comme une intention, ce qui peut accumuler de l’intent drift
- Les historiques de session peuvent être utiles pour l’observabilité d’équipe, mais sont négatifs comme levier d’amélioration des performances ; les propositions de changements hebdomadaires des nori bots devaient elles aussi être vérifiées par des humains via le diff, avec un taux d’acceptation réel inférieur à 20 %
Pourquoi la recherche dans les historiques de session n’a pas amélioré les performances
- Dans les tâches de SWE, même en permettant de rechercher dans les historiques de sessions passées, le gain de performance est nul dès lors qu’un autre contexte est disponible
- Les tentatives visant à parcourir automatiquement les historiques de session pour améliorer le contexte de l’agent n’ont pas non plus apporté de bénéfice important sans revue humaine
- Une architecture mémoire courante basée sur les sessions suit le flux suivant
- Stocker tous les transcripts de toute l’organisation dans une base de données
- Ajouter par-dessus des couches de recherche vectorielle, Elasticsearch et recherche SQL
- Les équipes plus ambitieuses utilisent les trois et y ajoutent aussi un graphe
- Exposer le tout à l’agent via MCP ou une CLI dotée de skills
- Après plusieurs mois de comparaison avec et sans approche de recherche dans les sessions, ce travail supplémentaire n’a fait aucune différence et a même pu, dans certains cas, rendre le modèle moins bon
- Les informations utiles sont déjà organisées dans les artefacts de code
- Les changements de code comprennent de bons messages de commit, messages de PR, une documentation complète et des métadonnées commitées avec le code
- Lorsqu’il travaille sur un code précis, l’agent reçoit l’instruction de consulter la documentation et les PR précédentes
- La recherche dans les historiques de session le fait relire des choses qu’il sait déjà, et lui fait aussi consommer des tokens pour des jugements temporaires et des scratchpads qu’on avait choisi de ne pas enregistrer dès le départ
Là où la mémoire automatique déraille
- Les agents ne font pas le nettoyage de mémoire important pour maintenir une mémoire à long terme
- Sur des milliers de sessions, aucun cas réel de suppression de contexte n’a été observé
- Ce n’est pas quelque chose que l’on peut obtenir par prompt engineering ; comme les agents sont sans état, ils traitent tout ce qui se trouve dans la fenêtre de contexte d’entrée comme une ground truth
- Le code, la mémoire existante et tous les tokens sont traités comme l’expression d’une intention, y compris lorsqu’il s’agit de décisions arbitraires d’une session d’agent précédente ou de contenus non relus par un humain
- Dans ce processus, l’intent drift s’accumule
- Plus l’agent construit de façon autonome une base de mémoire, plus les mauvaises interprétations de l’intention des entrées précédentes s’empilent
- Il n’existe pas de benchmark de codage qui suppose que les données d’entrée sont contaminées, et les modèles sont au contraire pénalisés s’ils partent du principe que les données d’entrée sont fausses
- Il n’existe pas non plus de moyen simple de satisfaire simultanément « ne supprime pas la codebase » et « supprime une partie du contexte d’entrée »
- La mémorisation automatique aboutit finalement à du contexte parasite inutile qui consomme des tokens, augmente les coûts et dégrade la qualité du modèle
- Les historiques de session peuvent être utiles pour l’observabilité d’équipe, mais il est difficile de les considérer comme un outil qui rend les agents meilleurs
La méthode de revue humaine des nori bots
- Apprendre le contexte au fil du temps n’est pas impossible en soi : chaque semaine, les nori bots examinent ce qui s’est passé dans l’entreprise — PR, Slack, Drive, etc. — et proposent des changements aux nori skillsets intégrés
- Les propositions de changement taguent l’équipe dans Slack, mais par défaut elles sont toutes rejetées
- Pour accepter un changement, il faut consulter directement le diff et vérifier qu’il correspond bien à l’intention
- Le taux d’acceptation est inférieur à 20 %, et les 80 % restants de mises à jour « automatiques » auraient probablement rendu le modèle moins bon
- Si une organisation de plusieurs centaines de personnes enregistrait toujours automatiquement ce type de mises à jour, cela pourrait devenir encore moins soutenable
1 commentaires
Avis de Hacker News
Ça me rappelle le moment où OpenAI a dit avoir ajouté à ChatGPT une fonction de mémoire entre les sessions. Au final, ça donnait l’impression d’une fonctionnalité qui va chercher toutes sortes d’infos sur moi sans mon consentement explicite, puis les copie-colle entre les prompts
Du genre : « Compare-moi ces trois voitures. Ah, au fait, je suis data engineer, le nom de jeune fille de ma mère est Joana, je suis allergique à la mauvaise poésie. Le code doit être DRY, je préfère SQL à Python, et quelle est la fleur la plus toxique de Scandinavie ? »
Le contexte mémorisé se mettait à fuiter dans des projets et conversations sans aucun rapport, produisant tellement de sorties bizarres que c’est la première fonction que je désactive
Tout à fait d’accord. Le système de mémoire de claude-code est parfois utile, mais il est bien plus souvent nuisible en ramenant de vieilles informations qui brouillent la tâche en cours. J’ai souvent vu la propre mémoire de Claude l’induire gravement en erreur
À vue de nez, ça semble lié au fait que, à cause du processus d’entraînement, le modèle ne distingue pas bien « ce qui se passe maintenant » de « ce qui s’est passé avant ». Si le processus d’inférence à partir de la mémoire faisait lui-même partie de l’entraînement, ce serait peut-être différent, mais comme c’est une fonctionnalité ajoutée seulement au moment de l’inférence, on a l’impression que ça embrouille le modèle
Les LLM ne sont pas assez intelligents pour supporter même une légère pollution du contexte
Le raisonnement ou le contexte qui l’a mené là a une inertie : si on le laisse, il reste collant
Mais quand il le ressort plus tard de sa mémoire, c’est franchement agaçant
L’idée de les entraîner avec la mémoire est intéressante
Ce qu’on « voulait faire faire » au code n’a généralement pas beaucoup d’importance. Ce qui compte, c’est ce que le code fait réellement
Les journaux de session peuvent certainement être utiles, mais pas au moment où l’on continue à développer par-dessus : plutôt quand on passe à la phase de vérification. Cet entre-deux précis entre un plan en Markdown et une CI qui passe, où 800 nouvelles lignes de code sont apparues et où, en cliquant un peu, ça a l’air globalement correct
Les journaux de session peuvent montrer quelles vérifications manuelles ont eu lieu. La CI exécute les tests existants, le code montre quels sont les nouveaux tests unitaires, mais les journaux de session montrent si l’agent a manipulé l’application lui-même avec Playwright, et s’il a lu et pris en compte non seulement la configuration dev, mais aussi la configuration prod
Ce n’est pas parfait, mais tout travail de vérification n’a pas besoin de devenir un test conservé pour toujours dans le dépôt. Nous avons obtenu beaucoup de résultats en réanalysant les sessions pour repérer les endroits où l’agent a pris des décisions sans poser de questions, puis en le forçant à envisager des vérifications pour ces décisions. C’est difficile à demander dès le départ, mais les journaux de session le révèlent facilement
Problème agaçant. À cause d’une question hypothétique posée autrefois, il continue à fabriquer de fausses prémisses
Le simple fait que je lui aie demandé de faire une recherche sur un sujet lui fait supposer que je possède un datacenter et beaucoup de GPU
J’ai l’impression que ce n’est qu’une forme de leçon apprise à la dure. Le contexte et les agents que nous construisons avec soin risquent de disparaître dès que des modèles plus grands et meilleurs arriveront
Ces historiques de conversation sont très utiles pour des modèles moins capables, mais peut-être presque inutiles pour les modèles de pointe
J’utilise un harnais personnalisé basé sur https://minimal-agent.com/, lui-même basé sur swe-mini-agent, avec une logique centrale d’environ 50 lignes. Bash suffit largement
Sur les petites tâches, il est environ 8 fois plus rapide et consomme 8 fois moins de tokens que le harnais standard de chaque modèle
Je ne l’ai pas beaucoup testé sur de grosses tâches. Ça fonctionne, mais dans ce cas il semble moins concentré et un peu moins productif. Le prompt système de 20 000 tokens des gros harnais fait peut-être quelque chose d’important pour guider le flux de développement logiciel. Par exemple, j’ai entendu dire que Fable avait un prompt système personnalisé dans Claude Code, et c’est peut-être pour cela qu’il agit de manière beaucoup plus proactive
J’aimerais donc penser que l’ingénierie du contexte garde de la valeur. Mais cette valeur semble diminuer à chaque nouvelle génération de modèles, parce que les modèles sont globalement ajustés pour moins se comporter stupidement, et ont donc moins besoin qu’on les tienne par la main
D’abord, je pense que les modèles ont toujours besoin d’une couche de contexte. Une façon de voir le contexte, c’est comme de la compression. On fournit du contexte pour aider le modèle à comprendre ce qu’il doit faire. Même dans un monde où la capacité du modèle et la longueur de contexte seraient infinies, ce serait toujours utile, car cela évite de tout redériver depuis les premiers principes à chaque fois. Tant que le modèle est plus performant avec moins de tokens, et tant que le coût des tokens nous importe, le contexte est un raccourci utile, peut-être même nécessaire
Si l’on admet qu’une couche de contexte est nécessaire sous une forme ou une autre, la question suivante devient : laquelle ? Ici, je suis d’accord qu’il vaut mieux travailler avec des formes familières au modèle, par exemple des fichiers Markdown placés à côté du code. Mais cela relève moins de la question de savoir si le contexte est nécessaire que d’un problème de solutions trop conçues qui ne comprennent pas leur utilisateur principal, à savoir l’agent
Mais je me demande vraiment si une bien meilleure prédiction du token suivant ne rendra pas toute cette construction obsolète. Quelle que soit la réponse, elle révélera beaucoup de choses
Il faut se rappeler que la structure du cerveau est elle aussi apprise. Simplement, elle l’est à une échelle de temps bien plus longue que la vie d’un individu
Je suis d’accord sur le fait qu’il n’est pas nécessaire de construire à tout prix un système de mémoire sophistiqué. Ce qui mérite d’être mémorisé doit se trouver dans les documents, guides, commentaires de code source, messages de commit et tickets
Il n’y a pas besoin d’une couche supplémentaire. Toutes les granularités imaginables sont déjà couvertes par les bonnes pratiques existantes
Cette extension fait ceci : https://github.com/gitsense/pi-brains
Pour l’instant, un « humain » doit définir les règles de routage pour l’accès à l’information, mais à l’avenir elle prendra en charge des « agents de connaissance » qui surveillent les conversations et injectent du contexte quand c’est nécessaire
~/.claude/…Dans les projets où j’avais besoin de mémoire, j’ai simplement ajouté une ligne dans AGENTS.md demandant d’écrire la mémoire dans MEMORY.md, ou de suivre l’avancement dans STATUS.md
Mais si elles sont taguées dans un journal de suivi, on peut les retrouver efficacement au besoin. En plus, la documentation se dégrade, tandis qu’un journal de suivi peut avoir une durée de vie plus claire en y attachant un hash de commit ou d’autres informations
Je suis fortement en désaccord avec ça
Je fais en sorte que Claude/Codex laisse des logs [1]. Je me contente de l’indiquer par un prompt dans AGENTS.md [0]
« Chaque session doit produire soit un journal de session, soit un plan, et y ajouter à la fin le résumé rédigé. Par défaut, c’est un journal ; les plans ne sont utilisés que pour un vrai travail de conception. »
C’est extrêmement précieux. Par exemple, aujourd’hui encore, j’ai commencé plusieurs sessions comme ça : « Où en est le travail Renovate ? », « On a travaillé récemment sur X, retrouve-le », « Est-ce qu’on a corrigé le problème de sauvegarde ? Quelle est la prochaine étape ? », « Ce bug est réapparu. On ne l’avait pas déjà corrigé ? »
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
Globalement, j’aime bien les systèmes de mémoire. Pour référence, j’utilise principalement Opus 4.8 + Max effort
Il ressort assez souvent des éléments pertinents de la mémoire. Par exemple, si je lui demande de proposer quelques candidats de fournisseurs OIDC auto-hébergés, il répond quelque chose comme : « vu la taille de l’équipe ops, celui-ci pourrait être plus adapté à cause de X et Y »
Bien sûr, ce sont peut-être des informations qui devraient être dans CLAUDE.md. Mais dans ce cas, l’idée même de les mettre dans CLAUDE.md ne m’était pas venue, et j’ai apprécié que la mémoire les fasse ressortir
Il lui arrive aussi de se tromper. Aujourd’hui, je lui ai posé une question sur un problème d’authentification, et il m’a répondu : « comme l’application est derrière haproxy, ça pourrait être lié à ce paramètre trusted proxy ». C’est vrai pour 95 % de nos applications, donc cela valait la peine de le mentionner, mais pas cette fois, et j’ai dû corriger. Cela dit, si elle avait bien été derrière un proxy, cela aurait pu faire gagner beaucoup de temps, donc j’ai trouvé utile qu’il le dise
C’est particulièrement délicat si l’on pose souvent des questions hypothétiques ou si l’on aide quelqu’un d’autre avec son problème. Un humain poserait probablement des questions de clarification sans faire de suppositions, du genre : « Est-ce que ça concerne l’équipe ops de X ? Sa taille est-elle toujours Y ? », « Cette application est-elle aussi derrière un proxy, comme les autres applications dont on a parlé avant ? »
Il y a aussi, dans ce contexte, une hiérarchie claire qu’il faut modéliser correctement. Par exemple, on peut être impliqué simultanément dans plusieurs équipes soumises à des règles différentes, et les humains comprennent naturellement ce genre de choses
Même si l’on désactive la mémoire, cela arrive au sein d’une même conversation
C’est comme un ami agaçant qui se souvient de quelque chose d’une ancienne conversation et continue à vous le ressortir, alors même que vous avez déjà grandi et changé
Fondamentalement, c’est un problème matériel. Un million de tokens ne constitue pas un contexte suffisant pour comprendre une base de code comme le ferait un humain
La capacité d’oublier sélectivement est potentiellement très précieuse. Mais pour l’instant, cela revient à remplacer la capacité humaine à se souvenir de la forme générale de quelque chose, à juger que ce n’est pas intéressant, et à se souvenir du fait que ce n’est pas intéressant
On dit que la mémoire n’est utile que lorsqu’un humain la guide, mais je pense que la bonne solution est plus profonde que cela. Peut-être qu’elle consisterait à intégrer toute la base de code et toutes les sessions d’agents dans le fine-tuning du modèle. Mais à ce stade, il faudra peut-être des consignes pour éviter d’inclure certaines sessions dans le modèle. Ou peut-être pas, et les leçons apprises s’appliqueront