Comment gérer le contexte des agents ? RAG, LLM Wiki et GraphRAG

Je me souviens très bien de mon enfance, vers 10 ou 11 ans, quand nous vivions à Ponta Delgada et que je rentrais à la maison, surexcité à l’idée de regarder les documentaires de History Channel et de Discovery. Tous les jours, sans exception, ma tête mémorisait des milliers de détails : « Oh, les Grecs de l’Antiquité avaient, dans certains temples, des machines qui distribuaient de l’eau bénite contre des pièces ! » Il m’a fallu des années et des années pour acquérir une habitude que j’ai encore aujourd’hui. Au cours de ces (presque) 36 dernières années, j’ai dû regarder des dizaines de milliers de documentaires et de vidéos de vulgarisation scientifique, d’histoire, de philosophie et d’autres sujets. Et la vérité (évidente), c’est que 99,9 % de ce que j’ai entendu, vu et lu n’est resté nulle part dans ma tête.

Certains faits sont restés, parce qu’ils étaient aussi curieux que ces machines grecques, ou parce que je les ai notés puis relus, ou parce que je les ai tellement assimilés qu’ils font désormais partie de ma culture générale, ou parce qu’ils sont associés à d’autres souvenirs marquants, ou simplement parce que le souvenir est encore frais.

On peut en tirer une analogie intéressante, sans pour autant parler d’équivalence. Les foundation models (des modèles d’AI entraînés sur de grands volumes de données variées et adaptables à différentes tâches) n’ont pas non plus tout à leur disposition à chaque instant. Mais il faut distinguer les connaissances acquises pendant l’entraînement du contexte actif, les informations qu’ils reçoivent pour un appel donné au modèle.

Pendant l’entraînement, ils sont exposés à plus de données qu’un humain ne pourrait en consommer durant toute sa vie. Une partie de ce contenu rejoint l’amalgame des connaissances de base du modèle. Et, tout comme les humains, les modèles peuvent assimiler des fake news et des idées fausses.

Dans leur utilisation quotidienne, les modèles associent ces connaissances de base à plusieurs sources de contexte. Si je veux qu’un agent d’AI automatise le filtrage et la priorisation de ma boîte email, il utilisera ses connaissances de base, les connaissances du processus (instructions) que je lui ai données et les données des emails eux-mêmes (connaissances propres à la tâche). Mais on se heurte alors à l’une des plus grandes limites de cette technologie : les modèles ont une fenêtre de contexte limitée. Certains modèles de pointe disposent de fenêtres de l’ordre de 1 million de tokens. Un token correspond, en moyenne et à titre d’approximation pour un texte anglais, à environ quatre caractères. Un million de tokens représente donc approximativement une fois et demie le texte des trois volumes du Seigneur des anneaux, dans leur version originale anglaise.

Je définis ici un agent comme un programme qui utilise un foundation model (FM) pour prendre des décisions et se servir d’outils. Chaque fois qu’il doit recevoir des informations et prendre une décision, il appelle le modèle. Les informations qui ne figurent pas dans cet appel ne seront pas disponibles comme contexte, même si elles étaient présentes lors d’un appel précédent. Le secteur a évolué pour contourner cette limite. J’appelle ici techniques de gestion du contexte l’ensemble des pratiques qui permettent de fournir à l’agent le contexte nécessaire, au moment nécessaire. L’une des idées de base est la progressive disclosure of information, autrement dit la manière de fournir progressivement le contexte, accompagnée d’outils permettant à l’agent d’aller chercher les informations dont il a besoin.

Ce domaine étant relativement récent, il n’existe pas de solution one-size-fits-all. Plusieurs heuristiques sont courantes dans le secteur, et l’une des plus utilisées est la Retrieval-Augmented Generation (RAG). Avec cette technique, les documents sont généralement découpés en segments selon différents critères, comme une taille fixe, le contexte sémantique ou la hiérarchie du document. Ces segments sont souvent convertis en représentations numériques, les embeddings.¹ Lorsque c’est nécessaire, l’agent effectue une recherche dans ces informations, reçoit les segments jugés pertinents pour sa tâche et s’en sert pour générer sa réponse. Il peut généralement effectuer une recherche lexicale (qui cherche des termes précis), sémantique (qui cherche des segments dont le sens ressemble à ce que demande la tâche) ou hybride (les deux). C’est excellent lorsqu’il faut trouver des informations précises dans des documents très volumineux, comme dans l’exemple classique de l’extraction d’informations pertinentes d’un contrat de 500 pages. Pourtant, même si l’agent formule bien sa recherche, il peut ne pas recevoir tous les segments nécessaires pour traiter la tâche et se retrouver avec un contexte incomplet. Cette technique reste néanmoins très présente dans les discussions, aussi bien dans l’industrie que dans la recherche, et elle a été utilisée dans pratiquement tous les cas d’implémentation que j’ai vus.

Mais ce n’est pas la seule manière de faire. L’un des noms les plus cités dans le monde de l’AI générative, Andrej Karpathy, a proposé la LLM Wiki.² Cette approche utilise des fichiers Markdown (.md), de simples fichiers texte avec une syntaxe de mise en forme particulière, pour maintenir un index et des pages interconnectées de connaissances synthétisées à partir des sources. L’agent peut consulter intégralement les pages pertinentes lorsqu’il en a besoin. C’est comme lorsque je consulte le mode d’emploi d’un nouvel objet et que je choisis, à partir de la table des matières, de ne lire que les références qui m’intéressent. C’est mon approche préférée pour plusieurs cas d’usage, pour sa cohérence et sa facilité de maintenance ou d’ajustement manuel. Dans des cas complexes, elle peut toutefois entraîner une charge de maintenance supérieure à celle qui consisterait, par exemple, à générer les embeddings d’une nouvelle version d’un document et à mettre à jour l’index. On peut créer des pipelines de distillation de l’information (je parle de réduire la quantité de texte tout en conservant sa densité d’information) pour entretenir une LLM Wiki. C’est d’ailleurs ce que propose Karpathy. D’après mon expérience, cette distillation reste cependant assez faillible chez les modèles, qui perdent souvent des nuances des informations originales et la vision d’ensemble de l’objectif du document. Et l’effort de curation devient vite lourd.

Enfin, comme ce texte commence à être long et que je ne veux pas décourager celles et ceux qui sont arrivés jusqu’ici, j’aimerais aborder brièvement GraphRAG, ou Graph Retrieval-Augmented Generation. Commençons peut-être par ce qu’est un graphe : une structure mathématique ou informatique composée d’un ensemble de sommets (nœuds) reliés par des arêtes (ou liens)... pause pour reprendre son souffle. Pour faire simple, c’est une façon de représenter des informations et les relations entre les données, comme ci-dessous. Un bon exemple est un réseau social, où plusieurs personnes peuvent être reliées entre elles, mais où les liens ont une direction : Joaquina suit Manuel, qui suit Ramiro, qui suit à son tour Joaquina. Cela ne veut pas dire que Manuel suit Joaquina, ni que Joaquina suit Ramiro. Les personnes sont des nœuds ; les liens sont les follows. L’information peut avoir une direction, et les relations sont explicites.

Une flèche de A vers B signifie « A suit B ». La relation inverse n’est pas implicite.

GraphRAG utilise un graphe de connaissances, avec des entités (concepts, objets, personnes) et leurs relations, pour créer un réseau que l’on peut interroger. Il permet à un agent de suivre plus facilement un parcours de recherche à travers ces relations afin de trouver les informations nécessaires à une tâche. Les informations trouvées sont ensuite transmises au modèle comme contexte pour produire la réponse. Cette capacité peut être particulièrement utile lorsqu’il faut croiser des informations provenant de plusieurs documents. Comme avec les autres approches, les informations et les relations doivent faire l’objet d’une curation, surtout lorsqu’elles sont produites de manière autonome par l’agent. Par exemple, si les relations sont erronées, incomplètes ou obsolètes, l’agent peut laisser de côté des informations importantes ou fonder sa réponse sur des liens qui n’ont plus de sens. Il m’est arrivé d’appliquer cette approche et de me retrouver avec un réseau si complexe que ni moi ni l’agent (shoutout au Sr. Alfredo) ne comprenions ce qu’il contenait.

Ces trois approches ne s’excluent pas mutuellement, et un projet d’implémentation en entreprise relativement complexe et mené avec maturité pourrait, à la limite, utiliser les trois selon le cas. On peut rechercher dans une wiki à l’aide du RAG, et GraphRAG est lui-même une façon d’appuyer la génération sur des informations récupérées. Voici un résumé de mon modèle mental pour savoir quand utiliser chacune :

Mais la gestion du contexte ne s’arrête pas là. Ce n’est que le premier article d’une série dans laquelle j’aborderai ce sujet. Nous parlerons ensuite de caching, de compaction, de context pruning et d’isolation du contexte avec des sous-agents. À bientôt.