Contexte et problématique

Dans les architectures récentes d’agents conversationnels, la capacité à conserver un état sur plusieurs tours d’interaction est souvent présentée comme indispensable. Cependant, plusieurs publications récentes soulignent que la persistance d’informations sous forme de mémoire interne entraîne des coûts de synchronisation et de mise à jour élevés, surtout lorsque le nombre d’utilisateurs simultanés dépasse quelques dizaines de milliers. L’article de Liao (2024) avance que, pour la plupart des cas d’usage, la documentation externe – c’est‑à‑dire un référentiel structuré de connaissances – suffit à répondre aux exigences de continuité.

Mécanismes de documentation

Le modèle proposé repose sur un pipeline de retrieval‑augmented generation (RAG). Un index vectoriel (par exemple FAISS ou Milvus) stocke les paragraphes de la documentation sous forme d’embeddings. À chaque requête, le système calcule l’embedding du prompt, interroge l’index, récupère les k passages les plus proches, puis les injecte dans le prompt du LLM. Cette approche évite d’allouer de la mémoire volatile à chaque session et garantit que les réponses s’appuient toujours sur la version la plus récente du texte officiel.

query = "Comment configurer le TLS sur le serveur?"
emb = model.encode(query)
results = index.search(emb, k=5)
prompt = f"Context: {results}\nQuestion: {query}"
answer = llm.generate(prompt)

Le code ci‑dessus illustre le flux complet : encodage, recherche, concaténation et génération. Aucun état persistant n’est conservé entre deux appels, ce qui simplifie le scaling horizontal.

Comparaison avec la mémoire interne

Les solutions de mémoire interne stockent généralement les faits sous forme de triples (sujet‑prédicat‑objet) ou de vectors de session. Elles nécessitent un mécanisme de garbage collection pour éviter la saturation, ainsi qu’une logique de fusion lorsqu’une même information apparaît sous plusieurs formes. En revanche, la documentation externe repose sur un single source of truth : chaque mise à jour du manuel ou du guide de l’utilisateur se répercute immédiatement dans l’index. Le coût de mise à jour est donc linéaire par rapport au nombre de documents, alors qu’avec la mémoire interne le coût est proportionnel au nombre de sessions actives.

Sur le plan de la latence, les deux approches diffèrent également. La récupération vectorielle ajoute un délai de lookup (souvent 10‑30 ms pour des index de plusieurs millions d’entrées), tandis que la lecture d’une mémoire en‑mémoire peut être quasi‑instantanée mais nécessite un accès synchronisé à un stockage partagé, ce qui devient un goulot d’étranglement à grande échelle.

Limites et perspectives

Le modèle basé sur la documentation ne convient pas aux scénarios où l’agent doit raisonner sur des faits temporaires ou des données sensibles qui ne peuvent pas être exposées dans un index public. De plus, la qualité de la réponse dépend fortement de la pertinence du système d’embeddings : un mauvais entraînement peut entraîner la récupération de passages hors‑contexte, ce qui se traduit par des hallucinations. Enfin, la stratégie ne résout pas le problème de la cohérence narrative sur de longues conversations, car chaque tour repart d’un état vierge.

En résumé, l’article montre que, pour la majorité des tâches de support technique ou de FAQ, la documentation externe offre un compromis favorable entre scalabilité, mise à jour et coût opérationnel, tandis que la mémoire interne reste pertinente pour des cas d’usage nécessitant une persistance fine‑grained des états utilisateur.