Chapitre 1 — L'évolution de l'architecture RAG

Premier billet de la tournée chapitre par chapitre de LLM Primer III : Améliorer l'IA d'entreprise avec RAG. Le chapitre où les deux limites structurelles d'un modèle de base — connaissance figée et provenance manquante — se révèlent avoir une seule réponse architecturale, et où cette réponse a pris quatre visages en trois ans.

Pourquoi ce chapitre existe

Un transformeur entraîné sur un corpus fixe a deux limites qu'aucun entraînement supplémentaire n'efface complètement. Sa connaissance s'arrête au jour où s'arrête le corpus. Et il ne peut pas vous dire de quel document est venue une phrase, parce que la phrase est une moyenne statistique sur plusieurs documents, et non une citation extraite de l'un d'eux. La première défaillance produit des réponses confiantes et fausses sur tout ce qui est récent. La seconde produit des citations confiantes et fausses. Ensemble, elles produisent la pathologie désormais familière en entreprise : une réponse qui sonne comme l'autorité et qui pointe vers une clause inexistante.

RAG est la réponse architecturale aux deux à la fois. On cesse de demander au modèle de tout savoir d'avance et on commence à lui tendre le matériel pertinent au moment de l'inférence, récupéré dans un corpus qu'on contrôle. Le corpus se met à jour sans réentraînement. Les passages récupérés deviennent des citations parce qu'on les a cherchés exprès. Le travail du modèle rétrécit du rappel à la synthèse. Le reste du chapitre raconte comment ce geste simple a grandi, en trois ans, en quatre architectures de capacité croissante.

1.1 RAG Naïf : embarquer, retrouver, empiler

La forme la plus simple est celle que tout tutoriel public décrit encore. Hors ligne : découper le corpus en morceaux, embarquer chaque morceau, écrire les vecteurs dans un index. En ligne : embarquer la requête, récupérer les k plus proches morceaux, les concaténer dans un prompt, l'envoyer au modèle, retourner la réponse avec les morceaux listés comme citations. Deux appels de fonction et une recherche vectorielle.

La démo fonctionne. Le produit, rarement. La similarité du plus proche voisin est un proxy de la pertinence, non une mesure, et les modèles d'embedding entraînés sur du texte web généraliste confondent régulièrement les rendements d'un verger de pommiers avec les résultats trimestriels d'Apple. Le découpeur n'a aucun signal sur la fin des phrases ni le début des tableaux. Une seule passe de recherche ne peut pas servir une question dont la réponse est répartie sur trois documents. Et quand la recherche échoue, le modèle synthétise à partir de ce qui est revenu — les citations sont réelles, mais elles ne soutiennent rien de la réponse.

1.2 RAG Avancé : des heuristiques autour du même pipeline

La deuxième posture conserve la colonne vertébrale embarquer-retrouver-générer et ajoute du traitement avant et après l'appel de recherche. Les améliorations pré-recherche visent la requête : réécriture, expansion, décomposition, HyDE (rédiger une réponse hypothétique et embarquer celle-là comme requête). Les améliorations post-recherche visent les candidats : un reranker cross-encoder qui note ensemble requête et passage plutôt que de les embarquer séparément, déduplication, filtrage par métadonnées, compression de contexte.

Les gains ne sont pas petits. Un reranker cross-encoder posé sur un retrieveur vectoriel fait typiquement passer la pertinence top-5 de la bande 50–70 % à la bande 75–90 %. La réécriture de requête ajoute encore cinq à dix points là où la formulation initiale était ambiguë. La plupart des systèmes de production étiquetés simplement « RAG » aujourd'hui font tourner cette architecture, et pour une large classe de problèmes d'entreprise — Q&A sur la documentation interne, déviation de support, recherche dans la base de connaissances — c'est le bon niveau d'investissement. Ce qu'elle ne donne pas, c'est la souplesse. Chaque requête traverse encore le même pipeline.

1.3 RAG Modulaire : composants composables, routage explicite

En 2024, la recherche et l'outillage avaient convergé sur le RAG Modulaire. Les mêmes techniques restent présentes, mais elles sont exposées comme composants discrets, interchangeables, et le pipeline est assemblé par requête. Un routeur décide quels retrieveurs appeler — peut-être un index vectoriel dense, un index BM25, un magasin SQL, une API externe — et les résultats sont fusionnés, souvent par fusion de rangs réciproques. Le reranker est sélectionné selon le type de requête. Le générateur est sélectionné selon le niveau de qualité requis. L'architecture est devenue un graphe de composants plutôt qu'une ligne d'étapes.

Deux conséquences pratiques. D'abord, le système est testable d'une manière que les postures précédentes ne permettaient pas — chaque composant peut être évalué et remplacé indépendamment. Ensuite, le système est ajustable par classe de requête : une recherche factuelle passe par un retrieveur rapide et un petit générateur, une synthèse multi-documents passe par plusieurs retrieveurs et un grand, tous servis depuis la même bibliothèque de composants. Le prix est opérationnel. Quand une réponse est fausse, la question où est-ce que cela a déraillé ? a maintenant beaucoup de réponses possibles, et l'équipe a besoin d'une instrumentation capable de localiser la défaillance jusqu'à un composant unique. Investissez dans l'observabilité avant l'architecture modulaire, pas après.

1.4 RAG Agentique : le LLM exécute le pipeline

La quatrième posture inverse une hypothèse que les trois précédentes partageaient discrètement — que le LLM est la dernière étape. Dans le RAG Agentique, le LLM exécute le pipeline. Étant donné un catalogue d'outils (recherche vectorielle, SQL, fetch web, reranker, calculatrice), le modèle réfléchit, choisit un outil, observe le résultat, réfléchit encore, et s'arrête quand il a une réponse ou atteint une limite d'étapes. L'architecture a cessé d'être un pipeline pour devenir un petit programme que le modèle réécrit pour chaque requête.

Cela achète la planification multi-étapes, la sélection dynamique d'outils, et des patrons de coordination multi-agents comme planificateur/retrieveur/critique/rédacteur. Cela coûte de la latence, de la dépense en tokens, et de la reproductibilité — une seule requête devient un arbre de décisions plutôt qu'une séquence fixe, et des requêtes pathologiques peuvent passer beaucoup de tours à patauger avant de produire une réponse. Les systèmes agentiques de production ont besoin de contrôles de budget, de limites d'étapes et de politiques de timeout auxquels les pipelines fixes n'avaient jamais à penser. Le bon cas d'usage est celui des questions dont la profondeur est variable et imprévisible : synthèse de recherche, recherche jurisprudentielle, revue de littérature. Le mauvais cas d'usage est un bot de support statique, où la boucle agentique ajoute de la variance dont la charge n'avait pas besoin.

1.5 RAG contre affinage

La question que toute équipe finit par poser. Le cadrage honnête est qu'ils résolvent des problèmes différents. RAG s'adresse à des problèmes de connaissance — le modèle ne connaît pas X, X change, et l'utilisateur a besoin d'une citation. L'affinage s'adresse à des problèmes de comportement — le modèle connaît la réponse mais la présente dans le mauvais format, refuse de suivre le gabarit de l'entreprise, ou délaye là où il devrait être bref. RAG est peu coûteux à mettre en place et coûteux par requête. L'affinage est coûteux une fois et peu coûteux par requête. RAG itère en quelques minutes (changer un document) ; l'affinage itère en quelques jours. Une heuristique utile : si la défaillance est le modèle ne sait pas, tendez vers RAG. Si la défaillance est le modèle sait mais le fait mal, tendez vers l'affinage. Beaucoup de systèmes mûrs finissent par faire les deux, mais commencez par RAG — la plupart des échecs d'entreprise sont des échecs de connaissance, pas de comportement.

Ce que prépare le Chapitre 1

Toute architecture RAG — quelle que soit celle des quatre que vous choisissez — est en aval de la qualité avec laquelle elle sait lire ses documents sources. Un pipeline Modulaire de pointe avec un orchestrateur agentique travaille encore à partir de morceaux issus d'une étape d'analyse quelque part en amont. Si cette étape a perdu la structure des tableaux, mélangé l'ordre de lecture multi-colonnes ou remplacé les légendes de figures par un OCR confus, chaque composant en aval raisonne sur des entrées corrompues. L'architecture fixe le plafond du système. Le parseur fixe son plancher. Dans la plupart des systèmes de production, le plancher compte davantage, parce que la plupart des systèmes de production sont loin du plafond.

Prochaine étape — Chapitre 2 : L'analyse intelligente de documents. Pourquoi un utilitaire PDF-vers-texte naïf détruit silencieusement la qualité de la recherche, ce que l'analyse sensible à la mise en page préserve réellement, et l'alternative multimodale qui retrouve directement sur les images de pages.