Pourquoi le RAG ne suffit plus : vers des systèmes de mémoire intelligents

Le RAG naïf a rendu service, mais il plafonne vite

J'aime le RAG parce qu'il a forcé les équipes à arrêter de demander aux modèles de tout inventer. Indexer des documents, récupérer des passages, puis demander au LLM de répondre avec des sources reste une bonne base. Mais je vois trop de projets où cette base devient toute l'architecture : un vector store, quelques chunks, un top k, et l'on appelle cela un agent informé. En production, ce raccourci finit par se voir.

Le problème n'est pas que le RAG soit obsolète. Le problème est qu'un RAG naïf ne sait pas apprendre d'une interaction. Il ne distingue pas un fait durable d'une préférence temporaire, une exception métier d'une procédure standard, ou une erreur utilisateur d'un signal important. Il récupère ce qui ressemble à la question du moment. Pour un assistant documentaire, cela peut suffire. Pour un agent qui travaille dans la durée, c'est trop faible. Comme dans l'article sur les erreurs RAG en production, le retrieval n'est qu'une couche du système, pas le système lui-même.

Les limites concrètes : chunks, ranking et fenêtre de contexte

La première limite est le chunking. Découper un corpus en blocs fixes permet de lancer vite, mais la mémoire métier ne vit pas en blocs de 800 tokens. Elle vit dans des procédures, des décisions, des conversations, des corrections et des exceptions. Si le sens est réparti entre trois fragments, le modèle peut recevoir une preuve partielle et produire une réponse convaincante mais fausse. Ce n'est pas un bug du modèle ; c'est une mémoire mal représentée.

La deuxième limite est la qualité de récupération. La similarité vectorielle remonte souvent le texte le plus proche, pas le souvenir le plus utile. Dans un agent support, un vieux ticket semblable peut compter moins qu'une procédure récente. Dans un copilote commercial, une préférence client d'hier peut compter plus qu'une brochure officielle. Sans hybrid search, filtres, reranking et règles de fraîcheur, on confond proximité sémantique et importance opérationnelle.

La troisième limite est la fenêtre de contexte. Les fenêtres longues aident, mais elles ne remplacent pas une architecture de mémoire. Remplir le prompt avec plus de passages augmente le coût, la latence et le bruit. Le modèle trie à chaque tour, comme si rien n'était organisé avant lui. Pour moi, c'est le signal qu'il faut arrêter d'empiler du contexte et commencer à concevoir une mémoire.

Ce que mémoire veut dire dans un système agentique

Dans un agent, la mémoire n'est pas seulement un index vectoriel. Je la découpe en quatre couches. La mémoire court terme garde l'état de la tâche en cours : objectif, contraintes, décisions prises, outils appelés, erreurs récentes. La mémoire épisodique conserve les interactions passées : ce qui a été demandé, ce qui a marché, ce qui a échoué, ce qu'un humain a corrigé. La mémoire sémantique contient les connaissances stables : politiques, produits, vocabulaire métier, faits validés. La mémoire procédurale décrit comment agir : plans, checklists, conditions de refus et routines d'escalade.

Cette distinction change la conception. Une correction humaine ne doit pas forcément devenir une vérité dans la base de connaissances. Elle peut être un épisode pour l'évaluation, une règle à confirmer, ou un signal que le retrieval était mauvais. Une préférence utilisateur peut expirer. Une procédure peut être versionnée. Un fait peut demander validation avant d'être promu. Une architecture de mémoire sérieuse définit ce qui est écrit, où, par qui, pour combien de temps et avec quel niveau de confiance.

Les patterns que j'utilise avant de parler de mémoire complète

Je commence rarement par une grande plateforme de mémoire. Je commence par rendre le RAG moins naïf. Recherche hybride pour combiner mots-clés et embeddings. Reranking pour relire les candidats avec la question exacte. Déduplication par source. Métadonnées de version, langue, permission et fraîcheur. Traces de retrieval dans les logs. Jeux d'évaluation qui séparent rappel, précision et qualité de réponse. Ces patterns prolongent un RAG de production et montrent si une mémoire plus ambitieuse vaut le coût.

Ensuite, dans des orchestrations avec LangGraph, j'aime rendre les couches explicites. L'état du graphe porte la mémoire court terme du workflow. Un store de conversations ou de traces porte l'épisodique. Un index documentaire ou une base structurée porte le sémantique. Des noeuds dédiés décident quand écrire, quand oublier, quand demander validation, et quand utiliser un souvenir dans la prochaine action. Le point important n'est pas l'outil. C'est la séparation entre récupérer du contexte et modifier la mémoire du système.

Je garde aussi une règle simple : toute écriture en mémoire doit être observable. Si un agent apprend une préférence, résume une conversation, ou transforme une correction en règle, je veux voir l'événement, la source, la justification, la confiance et le mécanisme de suppression. Sinon, la mémoire devient un nouvel endroit où cacher des bugs.

Quand passer du RAG à une architecture de mémoire

Je ne recommande pas de passer à une mémoire complète dès le premier prototype. Le RAG suffit encore pour les cas où la tâche est stateless, le corpus est stable, les utilisateurs veulent surtout chercher, et les réponses ne doivent pas s'améliorer à partir des interactions. Un assistant qui répond à partir d'une documentation produit bien tenue peut rester sur une architecture RAG robuste pendant longtemps.

Je change d'architecture quand trois signaux apparaissent. D'abord, l'agent doit maintenir une continuité entre plusieurs sessions, utilisateurs ou décisions. Ensuite, les corrections humaines contiennent une valeur à réutiliser. Enfin, la qualité dépend autant des épisodes passés et des procédures internes que des documents sources. À ce moment-là, ajouter dix chunks ne règle rien. Il faut une mémoire avec des couches, des politiques d'écriture, de l'évaluation et de l'ops. Le RAG reste dedans, mais il cesse d'être le centre de gravité.