Nous avons donné aux agents un million de tokens dans la fenêtre de contexte, mais ils ne fonctionnent toujours pas.
Sauvegarde ça :)
Vous donnez à un modèle capable des outils et une tâche longue. Pendant les quinze premières étapes, il est brillant. Concentré et précis. Il répond aux questions et interroge bien l'utilisateur.
Cependant, au fur et à mesure que les conversations s'allongent, l'agent commence à dériver. Il commence à contredire les décisions qu'il a prises dix étapes plus tôt. Il commence à polluer la fenêtre de contexte avec des informations inventées. Il sait que les préférences utilisateur existent, mais n'arrive pas à les récupérer de manière fiable. Pendant ce temps, vous peinez à comprendre pourquoi les choses se cassent.
Vous finissez donc par chercher plus. Un modèle avec une fenêtre de contexte plus grande pour contenir la tâche plus longtemps. Vous essayez d'optimiser le pipeline RAG. Vous parcourez Internet à la recherche de solutions de mémoire pour agents.
Et rien ne fonctionne comme vous l'attendez.
Comprendre le pourquoi derrière tout cela nous mène directement à la couche la plus précieuse et la moins comprise de toute la pile d'agents.
L'échec est une boucle
La raison pour laquelle les agents se dégradent n'est pas un manque de capacité. C'est une boucle de rétroaction, et elle a quatre maillons. Une fois que vous voyez les quatre, les solutions habituelles ne semblent plus être des solutions.
Premier maillon : un modèle ne peut pas utiliser tout son contexte de manière égale, et cela s'aggrave à mesure que le contexte se remplit.
C'est la partie que la plupart des gens n'intériorisent jamais. La capacité d'un modèle à utiliser l'information n'est pas uniforme sur toute sa fenêtre de contexte. Les modèles utilisent de manière fiable ce qui se trouve au tout début et à la toute fin, et ils négligent systématiquement le milieu, même lorsqu'ils sont spécialement conçus pour des entrées longues. Ajoutez-en plus, et la fiabilité chute encore plus. Cela se manifeste même sur des tâches aussi triviales que répéter une liste de mots. Ajoutez un seul distracteur, et les performances baissent de manière mesurable. Ajoutez plusieurs éléments composés.
Ainsi, le contexte effectif, la partie sur laquelle le modèle peut réellement raisonner de manière fiable, est bien plus petit que le nombre annoncé. Et il rétrécit à mesure que vous y entassez plus de choses.
Pensez maintenant à ce que fait un agent. Il accumule. Chaque résultat d'outil, chaque étape de l'historique, chaque note personnelle est ajoutée au contexte. Ce qui signifie que l'agent abaisse régulièrement la qualité de chaque étape qu'il effectue. Le contexte croissant fabrique des erreurs à chaque étape.
Deuxième maillon : ces erreurs par étape ne s'additionnent pas. Elles se multiplient.
Une petite erreur par étape serait acceptable si les agents effectuaient une poignée d'étapes. Ils en effectuent des dizaines. Et les échecs se multiplient plutôt que de s'accumuler. Un agent fiable à 95 % en cinq étapes ne reste pas fiable à 95 % sur une tâche de vingt étapes. Courez assez d'étapes, et vous vous rapprochez sans cesse d'un pile ou face.
C'est pire que cela, car les erreurs se renforcent elles-mêmes. Un appel d'outil qui dévie légèrement de la trajectoire rend le suivant plus susceptible de dévier aussi. Ajoutez cela au premier maillon, où le taux d'erreur de base augmente lui-même à mesure que la fenêtre se remplit, et vous obtenez le mode de défaillance emblématique des agents à long horizon. Ils ne se dégradent pas gracieusement. Ils tiennent, puis soudainement, ils chutent.
Troisième maillon : la tâche est longue, le modèle est sans état, donc vous placez l'état en dehors du modèle.
Les modèles de langage ne retiennent rien entre les appels. Chaque appel recommence à zéro. La seule chose qu'un modèle sait est ce que vous lui renvoyez. Donc, pour toute tâche longue, vous devez externaliser l'état. Des pense-bêtes. Des fichiers de progression. Des points de contrôle. Des magasins de vecteurs. Des couches de mémoire dédiées qui extraient des faits et les représentent entre les sessions.
C'est correct et nécessaire. Et cela ressemble à une solution propre. L'agent n'oublie rien d'important, car tout ce qui est important vit dans un stockage durable.
Quatrième maillon : la mémoire stockée est inerte, et la réintégrer alimente exactement le problème qu'elle était censée résoudre.
C'est là que la boucle se referme. Un modèle ne peut pas raisonner sur une base de données. Il ne peut raisonner que sur ce qui se trouve dans sa fenêtre de contexte. Donc, la mémoire n'aide qu'au moment où elle est réintégrée. Et chaque récupération ajoute des tokens. Chaque résumé que l'agent écrit pour suivre la progression est un token qu'il devra relire plus tard. Chaque étape de compaction qui condense l'historique pour faire de la place est avec perte, et le détail qu'elle jette est souvent celui, subtil, dont l'importance ne devient claire que plus tard.
Ainsi, le système de mémoire que vous avez construit pour vaincre la limite de contexte finit par l'alimenter. Plus de mémoire signifie plus de récupération, ce qui signifie plus de bruit dans la fenêtre, ce qui signifie plus d'erreur par étape, qui se multiplie, ce qui est exactement ce qui vous a poussé à chercher une mémoire en premier lieu.
La boucle est réelle. Et elle ne se soucie pas de la taille de votre fenêtre de contexte.
La capacité n'a jamais été l'axe important
Une fois que vous voyez la boucle, l'inutilité des solutions standard devient évidente.
Une fenêtre de contexte plus grande ne la brise pas. Elle ne fait que relever le plafond de la quantité de pourriture que vous pouvez accumuler avant la chute. Pendant ce temps, toutes les études sur le contexte effectif montrent la même chose : la fraction utilisable de manière fiable croît bien plus lentement que le nombre annoncé. Vous achetez une capacité que vous ne pouvez pas réellement utiliser.
Plus de mémoire ne la brise pas. Cela augmente le volume de matériel en compétition pour rentrer dans une fenêtre qui ne peut déjà pas tout contenir.
La prochaine architecture ne la brisera pas non plus. Les challengers qui se sont alignés contre l'attention, les modèles à espace d'états comme Mamba et ses hybrides, gagnent en compressant le passé dans un état de taille fixe au lieu de garder chaque token adressable. Cela permet une inférence en temps linéaire et une empreinte mémoire qui ne croît pas avec la séquence. Cela ne peut pas acheter un rappel. Un état de taille fixe ne peut pas tout contenir, donc il oublie par conception. À grande échelle, les modèles à espace d'états purs sont en retard sur les transformeurs exactement sur ce que la mémoire externe est censée fournir : récupérer un fait spécifique à partir d'un point arbitraire plus tôt dans la séquence. C'est pourquoi les efforts sérieux post-attention sont des hybrides qui conservent une minorité de couches d'attention pour faire le rappel qu'un modèle d'état ne peut pas faire. Le mur ne bouge pas quand vous changez l'architecture. Vous l'atteignez simplement de l'autre côté.
Donc la leçon n'est pas "choisissez un nombre plus grand". C'est que la capacité n'a jamais été la contrainte contraignante.
La contrainte contraignante est la qualité de la décision concernant quels tokens occupent la fenêtre à chaque étape.
C'est là tout le jeu. Non pas le plus grand contexte disponible, mais le plus petit contexte suffisant. La pertinence plutôt que le rappel. L'oubli délibéré en tant qu'opération de première classe au lieu d'un accident de troncature. La recherche soutient cela directement : la récupération ordonnée de quelques milliers de tokens bien choisis bat le fait de déverser une fenêtre complète de 128K dans le modèle. L'avantage réside dans le choix de ce qui entre, pas dans la quantité.
Et c'est le piège dans lequel tombent la plupart des équipes, car l'outil qu'elles utilisent pour faire ce choix a la mauvaise forme.
La similarité n'est pas la pertinence
La façon par défaut de décider quel contexte réintégrer est la recherche par similarité. Embarquez tout, et quand l'agent a besoin de contexte, récupérez les vecteurs les plus proches de la requête actuelle.
Mais la similarité répond à la mauvaise question. Elle renvoie ce qui est proche, pas ce qui est lié. Et ce sont deux choses très différentes.
La question à laquelle un agent a réellement besoin de répondre n'est jamais "qu'est-ce qui est similaire à cela". C'est "étant donné cette tâche et cet état en ce moment, qu'est-ce qui se connecte à ce qui compte". C'est une question relationnelle. Il s'agit de dépendances, de provenance, de ce qui a remplacé quoi, et de quelle décision a causé quel résultat. Un magasin réglé pour récupérer des vecteurs similaires remet au modèle un tas de quasi-correspondances. Et les quasi-correspondances sont exactement les distracteurs du premier maillon, ceux qui génèrent l'erreur par étape qui se multiplie jusqu'à la chute.
C'est pourquoi la solution ne peut pas être un cache mince devant un magasin d'embarquement. L'intelligence n'est pas dans la recherche. Elle est dans la structure.
La couche que personne ne valorise
La couche la plus importante à capturer dans la pile d'agents n'est pas le modèle, et ce n'est pas le magasin. C'est la couche intermédiaire. Celle qui décide à quoi le modèle doit prêter attention.
Et pour faire ce travail, elle doit avoir trois caractéristiques.
Elle doit être neutre. Les internes changent constamment sous les pieds de tout le monde. Transformeur à espace d'états à hybride. D'un modèle de pointe à l'autre, avec un nouveau leader prix-performance tous les quelques mois. Une stratégie de contexte soudée à un seul modèle est un pari sur une cible mouvante. Ce dans quoi votre organisation accumule réellement de la valeur, c'est son contexte, l'enregistrement structuré durement gagné de ce que vos agents savent et ont fait. Verrouillez cela sur les fonctionnalités de mémoire d'un seul fournisseur, et vous faites de votre actif le plus durable un otage d'une feuille de route qui n'est pas la vôtre. Une couche de sélection qui vit en dehors de tout modèle unique permet au même contexte organisé de servir chaque modèle que vous exécutez, et le prochain que vous n'avez pas encore adopté.
Elle doit être horizontale. Un point de contrôle d'un framework connaît une seule exécution. La mémoire intégrée d'un modèle connaît les conversations d'un seul modèle. Un index vectoriel connaît un seul corpus. Aucun d'eux ne détient l'image qui compte vraiment une fois que vous exécutez des charges de travail réelles : de nombreux agents, de nombreuses sessions, de nombreux modèles, ayant tous besoin d'une vue cohérente et interrogeable du contexte. Ce rôle de système d'enregistrement n'est pas quelque chose qu'une application, un framework ou un laboratoire est conçu pour détenir, car chacun ne voit que sa propre tranche. C'est une couche à part entière, située horizontalement au-dessus d'eux tous.
Elle doit être structurée. C'est ce qui la distingue d'une "simple meilleure base de données". La sélection est un problème de pertinence, et la pertinence est relationnelle. La structure sur le contexte, les relations et dépendances, la provenance et la supplantation, est ce qui transforme la récupération en sélection. C'est une primitive fondamentalement différente du stockage, et c'est celle que la boucle exige.
"Les laboratoires ne vont-ils pas simplement intégrer cela ?"
L'objection évidente est que les laboratoires de modèles vont absorber cela. Ils continuent d'intégrer des fonctionnalités de mémoire et de contexte, et ils ont un accès privilégié à l'attention du modèle lui-même.
Ils le feront, et l'objection est à moitié juste. Pour un seul modèle encapsulant une seule application, laisser le laboratoire s'en occuper est souvent suffisant. C'est bien.
Mais l'incitation des laboratoires est de rendre leur propre modèle plus collant. C'est le contraire de la portabilité. Une curation fusionnée aux internes d'un seul modèle ne peut pas servir le cas multi-modèles à l'échelle de l'organisation. Un vrai substrat de contexte n'entre pas en concurrence frontale avec ces fonctionnalités. Il existe pour la situation que les laboratoires ne sont structurellement pas enclins à servir : celle où vous exécutez plusieurs modèles sur plusieurs agents et équipes, et vous refusez de laisser la couche qui décide de ce à quoi vos agents pensent être possédée par le fournisseur dont ils exécutent le modèle aujourd'hui.
Et la tendance ne fait qu'accentuer cela. Plus les modèles deviennent capables, plus ils sont utilisés. Plus ils sont utilisés, plus une organisation exécute d'agents. Plus elle exécute d'agents, plus une couche de sélection neutre, horizontale et structurée a de la valeur.
Qui construit cela ?
C'est là qu'Hydradb entre en jeu. Neutre, horizontal et structuré. Il détient les relations, dépendances, provenance et supplantation que la recherche par similarité aplatit. Il est versionné temporellement et conscient des préférences, et donc sait non seulement ce qui est vrai mais ce qui l'a remplacé. Il déverrouille la visibilité sur ce qu'un agent a appris au fil du temps. Cette structure est ce qui transforme la récupération en sélection.
En dessous, HydraDB fonctionne sur un stockage à plusieurs niveaux : un cache chaud en mémoire pour le contexte actif, NVMe pour le chaud, stockage objet pour le froid. Le contexte est promu et rétrogradé en fonction de la récence et de l'importance, de sorte que l'ensemble de travail sur lequel le modèle raisonne reste intentionnellement petit. Entre le modèle et tout ce qu'il pourrait savoir.
La question à laquelle chaque agent doit répondre
Mettez de côté les débats architecturaux, les produits de mémoire, la course aux armements des fenêtres de contexte. En dessous de tout cela, chaque agent à long terme répond à la même question à chaque étape.
De tout ce qu'il sait, à quoi devrait-il penser en ce moment ?
Une fenêtre plus grande ne répond pas à cette question. Elle donne juste à l'agent plus de choses à ignorer. La boucle est réelle, elle est permanente, et aucune quantité de capacité ne la ferme.
L'industrie essaie encore de s'en sortir à coup de capacité. Elle ne le peut pas. Les équipes qui intériorisent que c'était toujours un problème de sélection livreront des agents qui fonctionnent, tandis que toutes les autres livreront des agents qui presque.
Ce n'a jamais été une pure limitation des modèles. Tout ce qui fonctionne sous un budget fini doit choisir à quoi il prête attention. La sélection n'est pas une solution de contournement pour les limites d'aujourd'hui. C'est ce que le raisonnement sous contraintes a toujours exigé.
Si vous avez trouvé cela utile, suivez-moi @eng_khairallah1 pour plus de contenu IA de ce type. Je publie des analyses, des cours et des outils chaque semaine.
J'espère que cela vous a été utile, Khairallah ❤️
