Y a-t-il de la place pour les entreprises de mémoire et de base de connaissances en dehors des laboratoires ?
- Prédiction : Les entreprises qui se concentrent sur la mise à l'échelle verticale de la mémoire (c'est-à-dire aider les agents à fonctionner plus longtemps) auront du mal à être compétitives et seront écrasées par les laboratoires et autres structures agentiques. Les entreprises qui se concentrent sur la mise à l'échelle horizontale (c'est-à-dire à travers les équipes ou l'ensemble des organisations) trouveront un paysage plus favorable. En effet, les cycles de vente aux entreprises sont plus longs et les problèmes (isolation des données, sécurité, ontologie d'entreprise) ne peuvent pas être résolus par la dernière mise à jour du modèle ou la dernière idée de recherche.
Les couches de mémoire doivent-elles fonctionner dans l'espace des poids ou dans l'espace des tokens ?
- L'espace des tokens présente de nombreux avantages. Il est interprétable. Il est indépendant du modèle. Il est peu coûteux. Nous disposons de décennies d'infrastructure pour gérer le stockage, l'isolation des données, la modularité, etc.
- Cependant, l'espace des poids semble plus expressif et il pourrait exister une classe de problèmes que nous ne pouvons pas résoudre uniquement dans l'espace des tokens. En particulier, la mémoire procédurale impliquant des frontières floues et des chemins de branchement complexes ne semble pas bien adaptée à l'espace des tokens (par exemple, essayez de lire les règles d'un jeu de société par rapport au fait d'apprendre à y jouer).
- Prédiction : La plupart des mémoires fonctionneront dans l'espace des tokens (par exemple, traces d'agents, informations sémantiques, etc.), mais il y aura certains problèmes (par exemple, style d'écriture, goût, compétences procédurales, etc.) pour lesquels il existera des adaptateurs qui peuvent être intégrés aux modèles. Les techniques de Mech interp nous permettront de les interpréter.
La mémoire est-elle simplement un problème de recherche et de récupération ?
- La plupart des systèmes de mémoire actuels sont axés sur la récupération. Ils se concentrent sur la recherche des bonnes informations au bon moment pour que les agents puissent travailler (par exemple, le benchmark LoCoMo se concentre sur la recherche d'une aiguille dans une botte de foin).
- La question est de savoir si cela est suffisant pour résoudre le problème de la mémoire. Autrement dit, si vous connectez un moteur de recherche de pointe (comme Google, Exa ou Perplexity) à un entrepôt de données privé, est-ce suffisant pour considérer la mémoire comme résolue ?
- Prédiction : Il existe un consensus croissant parmi les chercheurs et les développeurs travaillant à la pointe, selon lequel la mémoire n'est pas simplement un stockage d'informations et une récupération sur ces informations. Nous appelons ce problème le « blast radius » en interne. L'utilité de l'information est limitée par sa portée (temporelle ou contextuelle). Les humains n'ont aucun problème à lire des tonnes de texte non pertinent et à n'appliquer le poids approprié qu'aux informations les plus utiles. Un système de récupération pur (même avec un reclassement intelligent) est loin d'atteindre ce niveau.
Devons-nous injecter automatiquement des informations dans le contexte ?
- L'argument contre est la détérioration du contexte ou la pollution. Injecter des informations dans un agent, surtout si ce ne sont pas les bonnes, pourrait dégrader ses performances. Cela amène également l'agent à surévaluer les connexions entre vos sessions, qui pourraient ne pas être réelles. C'est pourquoi de nombreuses personnes désactivent les fonctions de mémoire pour ChatGPT ou Claude Code.
- Prédiction : L'injection d'informations dans le contexte est essentielle car elle permet à l'agent de gérer les « inconnues inconnues ». Vous pouvez avoir un outil de mémoire parfait, mais si l'agent ne sait pas l'utiliser, le problème n'est pas résolu. Pour les humains, ce type d'« injection » se produit constamment. Les souvenirs du passé apparaissent dans votre conscience sans que vous le choisissiez activement. Les problèmes actuels avec cette approche sont probablement une conséquence du problème du « blast radius » décrit ci-dessus.
Quels sont les bons benchmarks pour la mémoire ?
- Il y a un sentiment général que les benchmarks existants comme LoCoMo et LongMemEval ne sont pas suffisants. Nous avons atteint environ 85 % de performance sur ceux-ci, et la mémoire semble toujours aussi non résolue aujourd'hui qu'il y a un an. De plus, une meilleure performance sur les benchmarks ne semble pas corrélée à une « meilleure impression » de la mémoire du point de vue de l'utilisateur.
- De plus, les benchmarks dans ce domaine sont difficiles à construire car les horizons temporels intrinsèquement longs sur lesquels la mémoire opère créent des problèmes de disponibilité des données et de coût/échelle.
- Prédiction : L'entreprise ou le laboratoire qui résoudra ce problème ne le fera probablement pas en grimpant sur un benchmark, mais en misant sur une information client ou utilisateur que les benchmarks actuels ne mesurent pas. C'est similaire à Wisprflow, où ils ont abandonné la métrique du taux d'erreur de mots sur laquelle les autres outils de transcription s'étaient fixés.
Les fenêtres de contexte plus longues résoudront-elles tout ?
- Nous avons fait une prédiction en janvier selon laquelle les fenêtres de contexte ne résoudraient pas réellement le problème, et cela s'est avéré en grande partie exact jusqu'à présent.
Des modèles puissants combinés à des intégrations de données rendent les systèmes de mémoire inutiles
- L'argument en faveur est que vous pouvez récupérer toutes les informations que vous souhaitez si vous disposez d'un modèle frontal + d'un harnais d'agent + de connecteurs de données MCP. Et il s'avère que la qualité de la récupération ne change pas beaucoup par rapport à d'autres systèmes (par exemple, LLM wiki, récupération hybride, etc.).
- Prédiction : À court terme, les systèmes de mémoire sont encore utiles car ils réduisent la latence et les coûts par rapport au fait de faire rechercher des modèles frontaux sur tout en permanence. À moyen et long terme, les systèmes de mémoire permettent une cohérence des récupérations, ce qui permet une capitalisation. Autrement dit, nous faisons encore écrire du code aux agents, qu'ils améliorent au fil du temps, plutôt que de leur faire générer directement une application, par exemple.
La recherche agentique sur les systèmes de fichiers est tout ce dont vous avez besoin
- Letta a prédit cela l'année dernière et cela s'est avéré être une prédiction assez prophétique. À court et moyen terme, les agents sont extrêmement performants pour opérer sur des systèmes de fichiers grâce au post-entraînement visant les performances de codage. Tirer parti de ce post-entraînement porte ses fruits aujourd'hui.
- Prédiction : À long terme, il est difficile d'imaginer qu'il n'existe pas un type d'index hybride en plus d'un système de fichiers. L'intuition principale derrière la nécessité de cela est que les systèmes de fichiers sont moins performants lorsqu'il y a des volumes de données plus élevés ou dans des cas d'utilisation fédérés. Les « monologues » des agents sur des données brutes deviendront également de plus en plus importants, et nous aurons besoin de moyens structurés et fondés sur des principes pour les prendre en charge.
![Perte de 6 millions par ignorance : La question unique qui sépare le « pigeon » du « client respecté » dans l'immobilier [Avec exemples concrets]](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1783878130911_13t77j_HM6aCr4b0AAhope.jpg)
![[Tanabata Sho] Pronostics finaux](/cdn-cgi/image/width=1920,quality=90,format=auto,metadata=none/https%3A%2F%2Fcms-assets.youmind.com%2Fmedia%2F1783877092411_fg196t_HM8tQzHakAAbifc.jpg)



