Un agent qui se souvient en collant tout son historique dans le prochain prompt n'a pas de mémoire. Il a une facture croissante, un plafond de tokens strict, et une courbe de latence qui empire à chaque tour. La vraie mémoire est une décision de stockage : ce que vous persistez, où vous le mettez, et comment vous en récupérez uniquement la tranche pertinente au moment de l'inférence. C'est un problème de base de données, et le traiter comme un problème de prompt est ce qui fait s'effondrer en semaine deux les agents qui font une bonne démo.

Ce qui est séduisant dans le bourrage de contexte, c'est que ça fonctionne au début. Au début d'une session, l'historique est court, tout rentre, et l'agent a l'air de se souvenir. Puis la conversation grandit, le prompt grandit avec elle, et trois choses se produisent en même temps : le coût grimpe car vous renvoyez tout à chaque tour, la latence grimpe car le modèle lit davantage à chaque fois, et finalement vous atteignez la fenêtre de contexte et les faits les plus anciens tombent silencieusement par l'avant. L'échec n'est pas un bug qu'on peut corriger. C'est l'architecture.

Deux types de mémoire, deux types de stockage

La « mémoire » est en réalité deux besoins différents, et les confondre est là où les conceptions déraillent.

Mémoire de session et de travail : un magasin clé-valeur

Les tours récents, l'état actuel de la tâche, les préférences à court terme de l'utilisateur, sont recherchés par une clé connue : un ID de session, un ID d'utilisateur, un ID de thread. Vous voulez des lectures et écritures rapides sur cette clé et un time-to-live pour que les sessions périmées expirent d'elles-mêmes. C'est une table DynamoDB, pas une recherche vectorielle. Partitionnez sur la session ou l'utilisateur, gardez l'état en cours comme un item, définissez un TTL, et relisez-le au début de chaque tour. Pas d'embeddings, pas de similarité, juste une recherche rapide par clé de « où en étions-nous ».

Mémoire sémantique à long terme : un magasin vectoriel

Les faits qu'un agent devrait rappeler entre les sessions, les décisions antérieures, les préférences apprises, les échanges passés pertinents, ne se recherchent pas par clé. Ils se recherchent par sens : « que sais-je qui est pertinent pour ce nouveau message ». C'est une recherche sémantique sur des embeddings, à quoi sert un magasin vectoriel. Sur AWS, le choix pragmatique est Aurora Serverless v2 avec pgvector : vos embeddings vivent à côté de données relationnelles, vous les interrogez en SQL, et vous n'avez pas à monter une base de données spécialisée séparée pour le faire.

Le pattern : récupérer, ne pas accumuler

Une fois que la mémoire est une base de données, chaque tour cesse d'ajouter et commence à interroger. La boucle devient :

on each turn:
  1. read session state by key      (DynamoDB: where were we)
  2. embed the new user message
  3. semantic search long-term store (pgvector: what is relevant)
  4. assemble a bounded prompt:
       system + tools
       + top-k retrieved memories
       + recent turns from session state
       + new message
  5. call the model
  6. write new facts back to the stores

Le prompt est désormais borné quelle que soit la durée de la relation avec l'utilisateur. Une conversation à son millième tour envoie un prompt de la même taille qu'à son dixième, car vous récupérez la poignée de souvenirs pertinents au lieu de tous les porter. Le coût et la latence deviennent plats au lieu de grimper. C'est la même discipline de récupération qui fait fonctionner le RAG, appliquée à l'historique propre de l'agent plutôt qu'à un corpus documentaire.

Ce que vous devez décider, et qu'un prompt cache

Déplacer la mémoire vers une base de données force des choix que le bourrage de contexte vous laissait ignorer, et ces choix sont l'ingénierie réelle :

  • Ce qui vaut la peine d'être mémorisé. Tous les tours ne sont pas un souvenir. Écrivez des faits et décisions durables, pas du bavardage, sinon votre magasin se remplit de bruit que la récupération fait ensuite remonter.
  • Quand oublier. Des TTL sur l'état de session, et une politique de vieillissement ou de remplacement des faits à long terme, pour qu'une ancienne préférence ne prime pas sur une corrigée.
  • Combien récupérer. Top-k est un curseur. Trop peu et l'agent oublie ; trop et vous retombez sur un prompt gonflé où l'étape de récupération n'ajoute aucune valeur.
  • La cohérence entre les deux magasins. La mémoire de session et la mémoire sémantique peuvent diverger. Décidez laquelle l'emporte quand c'est le cas.

À retenir

Le bourrage de contexte n'est pas de la mémoire, c'est différer une décision de stockage jusqu'à ce que la facture de tokens et le plafond de contexte la prennent à votre place. Divisez le problème : état de session rapide et par clé dans DynamoDB, rappel sémantique à long terme dans pgvector sur Aurora, et une étape de récupération par tour qui assemble un prompt borné à partir des deux. Dès que la mémoire devient une base de données avec une étape de récupération plutôt qu'un prompt sans cesse croissant, le coût et la latence cessent de dépendre de la longueur de la conversation, et vous décidez ce dont l'agent se souvient au lieu de laisser la fenêtre décider ce qu'il oublie.

À lire ensuite

Pour le côté base de données et infrastructure de faire tourner Aurora et DynamoDB à l'échelle, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.