Sept architectures RAG au-delà du pipeline naïf et les cas d’usage de chacune.

Le premier pipeline RAG que la plupart des gens construisent est simple : on divise les documents en blocs, on crée des embeddings, on récupère les quelques résultats les plus pertinents, on les intégre dans la demande et on laisse le LLM répondre. La démonstration fonctionne et les réponses semblent convaincantes. Puis arrivent des questions réelles : le mauvais bloc est retourné, le bon document apparaît mais pas le passage nécessaire. Parfois, l’information se trouve bien dans la base de données, mais le modèle n’a jamais accès à elle.

Le fait étrange, c’est qu’aucun composant n’est défectueux. Le pipeline fait exactement ce pour quoi il a été conçu. Les tutoriels insistent rarement sur la leçon réelle : remplir une base de données vectorielle est facile, tandis que placer les bonnes informations devant le modèle constitue le véritable défi. Cette première conception représente un RAG naïf. Il a ses utilités, étant le point de départ naturel, mais lorsque les documents deviennent complexes, que les questions s’approfondissent ou que la fiabilité devient cruciale, un cycle de récupération et de réponse atteint ses limites. Sept architectures plus avancées suivent, chacune corrigeant un problème spécifique, présentant ses points de défaillance potentiels ainsi qu’un moyen d’évaluer si un système donné en a besoin.

Pourquoi RAG existe

Un LLM ne connaît que ce qu’il a appris pendant son entraînement. Si l’on lui pose des questions sur des documents internes de l’entreprise ou des événements récents, il admet son ignorance ou, pire encore, invente une réponse convaincante. RAG résout ce problème en permettant à un étudiant d’apporter des notes lors d’un examen : le système trouve d’abord les documents pertinents et les utilise comme référence, de sorte que le modèle n’a pas besoin de répondre uniquement en s’appuyant sur sa mémoire.

Le processus de base est décrit ci-dessous.

Lorsqu’un utilisateur pose une question, le système effectue quatre étapes :

1. Rechercher dans la base de connaissances externe des documents pertinents
2. Récupérer les extraits les plus adaptés
3. Ajouter ces extraits à la question dans le prompt
4. Envoyer tout cela au LLM, qui rédige sa réponse à partir de ce contexte

En bref : question, recherche, récupération, ajout de contexte, LLM, réponse. Cette méthode fonctionne bien pour de petits ensembles de documents bien structurés. Les données réelles se comportent rarement de cette façon, et cinq faiblesses apparaissent généralement :

• Les fragments perdent leur contexte. Un extrait indiquant que les revenus ont augmenté de 3 % ne précise pas quelle entreprise ou quel trimestre il concerne.
• Des informations sont manquantes. Les tableaux, les graphiques et les pages numérisées ne survivent souvent pas à une récupération basée sur du texte.
• La première recherche peut être erronée, et le RAG de base ne tente pas d’en effectuer une autre.
• Les conversations précédentes disparaissent. Sans mémoire, chaque session commence à zéro.
• Les faits restent isolés. Lorsque les informations sont réparties dans plusieurs documents, il peut être nécessaire de les relier avant que la réponse ne soit cohérente.

Ce ne sont pas cinq problèmes aléatoires. Ils expliquent pourquoi différentes architectures existent, et chacun d’eux vise une défaillance spécifique dans le processus de base.

1. Notes sur les blocs contextuels

Au moment où un bloc est enregistré, une courte note y est attachée indiquant de quoi il s’agit, afin qu’il reste compréhensible même une fois sorti de son document d’origine. Imaginez qu’on arrache un paragraphe d’un livre et qu’on le donne à un inconnu sans titre ni numéro de chapitre : il ne pourra pas savoir à quoi il fait référence. Il suffit donc d’ajouter d’abord une note indiquant que le texte provient du chapitre 4, concernant les résultats semestriels de l’entreprise. C’est là toute l’idée.

Le bloc brut indique simplement que les revenus ont augmenté de 3 % par rapport au trimestre précédent, sans préciser l’entreprise ni l’année. Avec une note ajoutée, on sait alors que le texte provient du rapport semestriel de ACME Corp pour 2023, suivie de la même phrase.

Raw chunk:        "revenue grew 3% over the previous quarter"
                   -> which company? which year? unclear

With a note attached:  "From ACME Corp's Q2 2023 filing.
                        Revenue grew 3% over the previous quarter."
                   -> now it makes sense on its own

L’avantage est que les fragments récupérés ont un sens par eux-mêmes, et la méthode de recherche elle-même reste inchangée, car seules les données stockées varient. L’inconvénient réside dans le coût : écrire une note pour chaque fragment demande du temps et de l’argent avant même que la recherche ne puisse commencer, et une note mal rédigée peut orienter la recherche dans la mauvaise direction tout aussi facilement qu’une bonne note ne l’oriente pas correctement.

2. Récupération multimodale

Les documents ne sont souvent pas du tout du texte brut. Convertir une page PDF en texte et effectuer une recherche peut déformer les tableaux et les graphiques, c’est pourquoi une alternative consiste à permettre au système de visualiser la page en tant qu’image. Comparez lire la description d’un graphique par quelqu’un à regarder le graphique lui-même : une description peut omettre des détails ou donner de mauvaises valeurs, alors que l’original ne le peut pas.

Dans le processus ancien, une page PDF est d’abord convertie en texte, la mise en page du tableau est devinée, puis le texte est recherché, ce qui peut provoquer des perturbations dans les numéros et la structure. Dans le processus multimodal, la page est recherchée directement en tant qu’image.

Old way:  PDF page -> extract text -> guess at the table layout -> search the text
          (numbers and structure can get scrambled along the way)

Multimodal way:  PDF page -> search the page as an image directly
                 (the table stays a table, the chart stays a chart)

Cela gère les tableaux, les graphiques et les scans que l’extraction de texte déforme, et il élimine une étape fragile du processus. Les inconvénients sont des calculs plus intensifs que pour une recherche de texte simple, ainsi qu’un écosystème encore jeune disposant de moins d’outils et de connaissances communautaires limitées.

3. Recherche hybride

Deux types de recherche s’exécutent en même temps : l’une qui comprend le sens et l’autre qui cherche des mots exacts, puis leurs résultats sont combinés. Imaginez deux bibliothécaires : l’un comprend ce que vous voulez dire même si votre formulation est imparfaite, tandis que l’autre ne perçoit pas le contexte mais localisera toujours le document contenant le code spécifique que vous avez saisi. L’avantage réside justement dans l’utilisation des deux.

Prenons la requête « error E0502 borrow checker ». La recherche basée sur le sens trouve des documents traitant d’un concept similaire même en l’absence de la phrase exacte, tandis que la recherche de mots exacts localise la chaîne littérale « E0502 », et le résultat combiné fusionne les deux.

Query: "error E0502 borrow checker"

Meaning-based search:   finds docs about a similar concept, even without that exact phrase
Exact-word search:      finds the literal string "E0502"
Combined:               merges both into one final list

Une seule recherche couvre à la fois les questions conceptuelles générales et les termes techniques précis, ce qui corrige un point aveugle courant : la recherche basée uniquement sur le sens est souvent insuffisante pour les codes, identifiants et jargons. Le prix à payer est l’utilisation de deux systèmes de recherche, et il faut effectuer des ajustements précis pour déterminer le poids à accorder aux résultats de chacun.

4. Recherche de type graphe et carte

Au lieu de stocker des fragments isolés, cette approche montre comment les personnes, entreprises et idées présentes dans les documents sont liées entre elles, regroupe celles qui sont apparentées et rédige à l’avance un bref résumé pour chaque groupe. Lorsqu’une question est trop large pour être traitée par un seul fragment, le système s’appuie sur ces résumés de groupes et peut même décider seul quels groupes méritent d’être examinés.

Supposons que quelqu’un souhaite connaître les grands thèmes présents dans tout ce qui a été publié cette année. Aucun article individuel ne répond à cette question. Si l’organisation était divisée en départements, chacun disposant d’un résumé d’une page sur son travail, lire uniquement ces pages permettrait de trouver rapidement la réponse. C’est ce que représente la carte. Une version plus intelligente agit comme un assistant qui détermine d’abord quels départements sont pertinents pour la question, plutôt que de lire tous les résumés sans distinction.

Le processus comporte deux étapes. D’abord, la carte est créée une fois à l’avance : on identifie comment les personnes et les idées sont liées, on regroupe les éléments similaires, puis on rédige un résumé pour chaque groupe. Ensuite, une question générale est répondue à partir de ces résumés.

Step 1, build the map (done once, ahead of time):

  Documents -> find how people/ideas connect -> group related ones
            -> write a short summary for each group

Step 2, answer a broad question:

  "What are the big themes here?"
  -> pick the relevant groups (a smart version does this pick automatically)
  -> read just their summaries -> combine into one answer

Avantages : les questions thématiques complexes trouvent des réponses lorsque aucun seul élément ne peut y répondre, il est possible de tracer les liens entre de nombreux documents en même temps, et la version auto-sélective omet les résumés sans importance. Inconvénients : la création de cette carte nécessite un projet concret, certaines parties doivent être reconstruites chaque fois que les documents changent considérablement, et l’étape de sélection des groupes représente un autre point où le système peut faire de mauvais choix.

5. Recherche itérative et agente

Une carte permet de répondre à la question d’ensemble, mais certaines questions exigent plusieurs recherches, peu importe la qualité de la carte. Ici, le système effectue des recherches, examine les résultats obtenus, décide s’ils sont suffisants, et le répète si nécessaire. Comparez un moteur de recherche à un assistant de recherche : le moteur renvoie une seule liste et s’arrête, tandis que l’assistant lit les résultats, constate qu’ils ne sont pas suffisants, et retourne chercher plus d’informations, en utilisant ce qu’il a appris pour effectuer des recherches plus efficaces la deuxième fois.

Le cycle se déroule ainsi : une question arrive, une recherche est effectuée, et le système demande si cela suffit. Si ce n’est pas le cas, il recherche à nouveau en s’appuyant sur ce qu’il a appris, et si cela échoue encore, il essaie une autre approche.

Question comes in
     -> Search once -> "Is this enough to answer?"
     -> No: search again, using what was just learned
     -> No, still not enough: search again, from a different angle
     -> Yes: now answer

Il gère les questions qui nécessitent réellement plusieurs recherches et ne s’arrête pas après une recherche infructueuse, contrairement à un pipeline fixe. Le coût consiste en un aller-retour supplémentaire pour chaque recherche additionnelle, ce qui augmente les dépenses et le temps d’attente ; de plus, un angle de recherche mal choisi peut entraîner plusieurs tentatives avant que l’erreur ne soit détectée.

6. Recherche multi-agents

Ici, un seul système ne planifie, ne recherche, ne vérifie ni n’écrit tout seul. Ces tâches sont réparties entre des systèmes plus petits et spécialisés, chacun excellant dans une tâche précise, sous la supervision d’un coordinateur qui gère l’ensemble du processus. Une seule personne qui cherche, écrit et vérifie en même temps a tendance à obtenir des résultats médiocres dans les trois domaines. Une petite équipe, composée d’une personne pour la planification, d’une autre pour les recherches, d’une troisième pour la vérification et d’une dernière pour l’écriture, réussit généralement mieux dans chacune de ces tâches.

Une question arrive, un planificateur décide de ce qui doit être recherché, les chercheurs se chargent de le trouver, parfois dans différentes sources en même temps, et un vérificateur examine les résultats pour s’assurer de leur exactitude.

Question comes in
  -> Planner decides what needs to be looked up
  -> Searchers go look, sometimes from different sources at the same time
  -> Checker reviews what came back for accuracy
  -> Writer puts together the final answer

Toute étape du travail fait l’objet d’une attention totale, au lieu qu’un seul système doive gérer tout le processus ; de plus, les recherches parallèles permettent d’économiser du temps. D’un autre côté, plus il y a de systèmes collaboratifs, plus le coût par question augmente, et il faut beaucoup d’efforts pour retrouver une réponse finale erronée en remontant à plusieurs étapes antérieures.

7. Recherche basée sur la mémoire

Dans cette conception, le système ne cherche pas seulement dans un ensemble de documents fixe, mais aussi dans son propre historique avec l’utilisateur, considérant les conversations passées comme des éléments à consulter plutôt que de les oublier une fois terminées. Pensez à un médecin qui consulte votre dossier avant chaque visite, par opposition à celui qui vous demande de raconter toute votre histoire médicale à chaque fois. La plupart des informations que vous avez données lors de la dernière visite se trouvent toujours quelque part dans un dossier, et un bon système conserve également les éléments importants à portée de main pour les consulter lorsque c’est pertinent.

Cela permet à un système de se remémorer des éléments mentionnés il y a des jours ou des semaines sans devoir charger tout en même temps, et cela est utile pour tout ce qui est personnel ou en cours, au-delà de simples recherches de documents ponctuelles. Les inconvénients sont l’ajout d’un système de mémoire supplémentaire par-dessus la recherche de documents, ce qui entraîne plus d’éléments en mouvement, ainsi que le fait que les souvenirs anciens soient parfois compressés ou résumés pour économiser de l’espace, ce qui peut entraîner la perte de détails.

Sélection

Naive RAG échoue discrètement. Il ne plante jamais ni ne génère d’erreur. Les utilisateurs reçoivent simplement des réponses basées sur des informations erronées, et tout semble normal jusqu’à ce que quelqu’un vérifie.

Chacune des architectures mentionnées ci-dessus existe parce que quelqu’un a attribué une réponse erronée à une cause spécifique et corrigeable. Par conséquent, l’option la plus récente n’est pas automatiquement celle à choisir. Optez pour celle qui correspond au mode de fonctionnement défaillant du système de recherche. Examinez le flux de travail actuel et demandez-vous honnêtement : lorsque des réponses sont erronées, la recherche a-t-elle trouvé le mauvais élément, un fragment a-t-il perdu son contexte, ou le système n’a-t-il jamais vérifié à nouveau ? Cette seule question indique déjà l’architecture nécessaire ensuite.