Études RAG

Introduction

Les systèmes RAG (Retrieval-Augmented Generation) sont devenus l'architecture de référence pour les applications d'IA documentaire en milieu professionnel. En combinant un moteur de recherche sémantique avec un modèle de langage génératif, le RAG permet de répondre à des questions complexes en s'appuyant sur une base de connaissances externe, sans nécessiter de fine-tuning coûteux et en garantissant que les réponses sont fondées sur des sources documentaires vérifiables. Cette approche résout deux problèmes fondamentaux des LLM : les hallucinations et l'absence de connaissance spécifique sur le domaine métier. Le RAG ancre la génération dans des faits — ceux contenus dans les documents de l'organisation — et permet de maintenir la connaissance à jour sans recycler le modèle, par simple mise à jour de la base documentaire.

Défis Techniques

La qualité d'un système RAG repose sur une chaîne de décisions architecturales interconnectées. Chaque maillon du pipeline — du découpage des documents à la génération de la réponse finale — influence directement la pertinence et la fiabilité des résultats. Un chunking trop grossier noie l'information pertinente dans un océan de contexte, diluant la capacité du LLM à extraire la réponse exacte. Un chunking trop fin fragmente le raisonnement et prive le modèle de la vue d'ensemble nécessaire à une réponse cohérente. Un modèle d'embedding inadapté à la langue ou au domaine du corpus produit des similarités vectorielles qui ne reflètent pas la proximité sémantique réelle. Une stratégie de retrieval mal calibrée retourne des documents hors sujet ou omet les passages essentiels. La génération, enfin, dépend de la qualité du contexte fourni : un LLM performant avec un mauvais contexte produit une réponse médiocre, tandis qu'un LLM modeste avec un excellent contexte peut fournir des réponses remarquables.

Ce projet de recherche propose une exploration systématique et méthodique de l'ensemble des paramètres d'un pipeline RAG, dans le but de produire des recommandations concrètes, chiffrées et reproductibles pour la conception de systèmes RAG industriels. Nous ne nous contentons pas de compiler des connaissances théoriques : chaque configuration est testée, mesurée et comparée sur des corpus métier réels, avec des métriques objectivables. Les expérimentations couvrent des corpus variés — documents techniques, textes juridiques, manuels produits, correspondances commerciales, rapports d'activité — pour garantir la généralisabilité des résultats. Les livrables du projet incluent un guide architectural, des matrices de performance par configuration, et un banc de test réutilisable pour évaluer tout nouveau composant.

Stratégie de Chunking

La stratégie de chunking — le découpage des documents en segments exploitables par le système — est le premier et peut-être le plus déterminant des paramètres d'un pipeline RAG. Un mauvais découpage compromet irrémédiablement la qualité du retrieval, quels que soient la qualité du modèle d'embedding ou la puissance du LLM. Nous étudions trois grandes familles de stratégies. Le chunking fixe est la méthode la plus simple : les documents sont découpés à intervalles réguliers, généralement entre 256 et 1024 tokens, avec ou sans chevauchement (overlap) entre les chunks adjacents pour éviter de couper une information en deux. Sa simplicité est son principal avantage : il est rapide, déterministe et facile à implémenter. Ses limites apparaissent sur des documents à structure forte : une coupe mal placée peut séparer un titre de son contenu, un tableau de sa légende, ou une question de sa réponse. Le chevauchement atténue partiellement ce problème mais augmente le volume de la base vectorielle et peut introduire de la redondance.

Le chunking sémantique améliore le découpage fixe en utilisant la segmentation naturelle du document. Au lieu de couper à une taille arbitraire, il détecte les frontières sémantiques : fins de paragraphe, changements de section, transitions thématiques. La détection de ces frontières peut reposer sur plusieurs approches : l'analyse de la similarité entre phrases consécutives (une baisse brutale de similarité indique un changement de sujet), la structure de document (titres, sous-titres, numérotation, listes), ou un modèle de segmentation entraîné spécifiquement. Le résultat est un ensemble de chunks qui respectent l'unité thématique des documents, améliorant significativement la pertinence du retrieval : chaque chunk contient un sujet cohérent, ce qui facilite la correspondance avec la requête et la compréhension par le LLM.

Le chunking hiérarchique est l'approche la plus sophistiquée. Il construit une représentation multi-niveaux des documents : une table des matières au niveau le plus haut, des sections et sous-sections au niveau intermédiaire, et le contenu détaillé au niveau le plus fin. Le retrieval s'effectue d'abord au niveau grossier pour identifier les sections pertinentes, puis au niveau fin pour extraire les passages précis. Cette stratégie est particulièrement adaptée aux documents longs et structurés : manuels techniques, rapports de recherche, documents juridiques. La hiérarchie permet de répondre aussi bien à des questions générales (quelle est la structure de ce document ?) qu'à des questions précises (quel est le seuil de tolérance mentionné à la page 47 ?). Les résultats de nos campagnes montrent que le chunking hiérarchique surpasse les approches plate de 15 à 25 % sur les métriques de précision du retrieval pour les documents de plus de 50 pages.

Les modèles d'embedding constituent le cœur de la recherche sémantique dans un système RAG. Leur rôle est de transformer le texte — chunks de documents et requêtes — en vecteurs numériques dans un espace de haute dimension, où la proximité géométrique reflète la proximité sémantique. Le choix du modèle d'embedding a un impact direct sur la qualité du retrieval : un bon modèle produit des représentations où les documents pertinents sont naturellement proches de la requête, tandis qu'un mauvais modèle mélange les concepts et produit des résultats hors sujet. Nous évaluons systématiquement les modèles d'embedding les plus utilisés de l'écosystème : les text-embedding d'OpenAI (ada-002, text-embedding-3-small, text-embedding-3-large), les modèles BGE (BAAI), E5 (Microsoft), les Sentence Transformers (all-MiniLM-L6-v2, multilingual-e5-large), les modèles Cohere, et les modèles d'embedding de Mistral et Jina AI.

Les critères d'évaluation des modèles d'embedding couvrent plusieurs dimensions. La performance de retrieval mesure la capacité du modèle à classer les documents pertinents en tête des résultats : nous utilisons les métriques standard recall@k, precision@k et MRR (Mean Reciprocal Rank) sur des jeux de requêtes annotés pour chaque corpus métier. La robustesse multilingue évalue la qualité de la représentation vectorielle dans différentes langues : un modèle excellent en anglais peut dégrader de 30 à 50 % sur du français juridique ou de l'allemand technique. La résistance au domaine mesure la capacité du modèle à capturer la sémantique spécialisée : un corpus de documents d'ingénierie utilise un vocabulaire et des concepts qui diffèrent sensiblement du langage général sur lequel les modèles sont majoritairement entraînés. La dimension des vecteurs impacte la performance, le stockage et la vitesse de recherche : des vecteurs de 384 dimensions sont plus rapides à rechercher mais peuvent être moins expressifs que des vecteurs de 1536 ou 3072 dimensions.

Les résultats de nos campagnes d'évaluation révèlent des écarts significatifs entre les modèles. Sur du corpus technique en français, les modèles multilingues (multilingual-e5-large, BGE-m3) obtiennent un recall@5 de 15 à 25 % supérieur aux modèles anglais monolingues. Les modèles OpenAI text-embedding-3-large dominent sur la qualité brute mais leur coût d'inférence — proportionnel au nombre de tokens — peut être rédhibitoire pour des bases de plusieurs millions de documents. Les modèles open source comme BGE et E5 offrent le meilleur rapport qualité-coût : libres d'utilisation, exécutables localement via Ollama ou Sentence Transformers, et avec des performances proches des modèles propriétaires sur la plupart des corpus. Le choix du modèle dépend du compromis entre qualité, coût, latence et souveraineté des données : un modèle local garantit qu'aucune donnée documentaire ne quitte l'infrastructure, un critère déterminant pour les données sensibles ou soumises à des contraintes réglementaires.

La stratégie de retrieval — comment sélectionner et ordonner les chunks pertinents pour répondre à une requête — est le second paramètre critique du pipeline RAG. Nous explorons plusieurs approches combinables. La recherche vectorielle pure (top-k) est la méthode de base : la requête est vectorisée, une recherche de similarité cosine ou de distance L2 est effectuée dans la base vectorielle, et les k chunks les plus proches sont retournés. La valeur de k est un paramètre sensible : un k trop faible (1 à 3) peut omettre des passages complémentaires essentiels, tandis qu'un k trop élevé (20 à 50) noie le LLM dans un contexte volumineux et dilue l'information pertinente. Nos expérimentations montrent qu'un k entre 5 et 15 offre le meilleur équilibre pour la majorité des cas d'usage, avec une optimisation fine selon la longueur des chunks et la complexité des requêtes.

La fusion de résultats (fusion retrieval) combine plusieurs stratégies de recherche pour améliorer la couverture et la robustesse. Le principe est d'exécuter plusieurs requêtes en parallèle — avec des formulations différentes, des modèles d'embedding différents, ou des modes de recherche différents — puis de fusionner les résultats en une seule liste classée. La fusion peut s'effectuer par interpolation pondérée des scores, par rang (rank fusion, méthode RRF — Reciprocal Rank Fusion) qui donne plus de poids aux documents classés premiers dans chaque liste, ou par vote majoritaire. La méthode RRF est particulièrement efficace : elle est simple, déterministe et ne nécessite pas de calibration de poids. Nos tests montrent que la fusion de deux ou trois stratégies de retrieval améliore le rappel de 10 à 20 % par rapport à une stratégie unique, avec une réduction significative de la variance des résultats.

Le re-ranking constitue une étape complémentaire au retrieval initial. Après avoir récupéré un ensemble large de chunks candidats (k = 20 à 50), un modèle de re-ranking — plus performant mais plus lent que le modèle d'embedding — réévalue la pertinence de chaque chunk par rapport à la requête. Les modèles de re-ranking comme Cohere Rerank, BGE-Reranker ou Cross-Encoder sont spécialisés dans cette tâche : au lieu de comparer des vecteurs, ils prennent en entrée la paire (requête, chunk) et produisent un score de pertinence plus précis. Cette approche en deux étapes combine la rapidité de la recherche vectorielle (étape 1) avec la précision du re-ranking (étape 2). Le gain est substantiel : recall@5 amélioré de 15 à 30 % selon les corpus, avec un surcoût en latence acceptable (quelques centaines de millisecondes par requête pour re-ranking sur GPU).

L'hybrid search — combinant recherche vectorielle et recherche lexicale BM25 — est une technique puissante pour pallier les limites respectives des deux approches. La recherche vectorielle excelle pour capturer la similarité sémantique : elle trouve des documents qui parlent du même sujet même avec des mots différents. La recherche BM25 excelle pour la correspondance lexicale exacte : elle trouve des documents contenant les termes précis de la requête, ce qui est essentiel pour les identifiants, les références, les codes, les noms propres et les termes techniques rares. La combinaison des deux modes permet de couvrir l'ensemble des cas : une requête sur résiliation anticipée clause 12 trouvera à la fois les documents qui utilisent d'autres formulations (rupture anticipée, terminaison) via le vectoriel, et les documents qui mentionnent exactement clause 12 via le BM25.

L'implémentation de l'hybrid search dépend de la base vectorielle utilisée. Qdrant supporte nativement la combinaison de recherche vectorielle et de filtres, mais le BM25 doit être implémenté via un index inversé séparé ou via une fonction de scoring personnalisée. Dans notre banc de test, nous utilisons une architecture à double index : un index vectoriel Qdrant pour la recherche sémantique, et un index BM25 basé sur Tantivy ou Elasticsearch pour la recherche lexicale. Les résultats des deux index sont fusionnés via RRF avec des poids configurables. La calibration du poids entre les deux modes est un paramètre dépendant du corpus : un poids vectoriel élevé (0.7 à 0.8) est préférable pour des documents narratifs ou descriptifs, tandis qu'un poids lexical plus élevé (0.5 à 0.7) est optimal pour des documents riches en termes techniques, codes et références. Nos tests montrent que l'hybrid search améliore le recall@10 de 12 à 18 % par rapport à la recherche vectorielle pure, avec un gain particulièrement marqué sur les requêtes contenant des entités nommées spécifiques.

L'évaluation systématique de la qualité d'un pipeline RAG est un défi en soi, qui fait l'objet d'un sous-projet dédié. Contrairement à une tâche de classification où la précision se mesure directement, la qualité d'un système RAG est multidimensionnelle et partiellement subjective. Nous avons développé un framework d'évaluation complet qui couvre cinq axes : la fidélité mesure si la réponse du LLM est fidèlement fondée sur les documents retrieved — une réponse peut être correcte en soi mais non fondée sur les sources fournies, ce qui est un échec du RAG ; la pertinence évalue si les chunks retrieved sont effectivement pertinents pour la requête ; la complétude vérifie que la réponse couvre l'ensemble des aspects de la question ; l'absence d'hallucination garantit que la réponse n'introduit pas d'information non présente dans les sources ; et la qualité rédactionnelle évalue la clarté, la concision et la structure de la réponse.

Le framework utilise une combinaison de métriques automatiques et d'évaluation par LLM (LLM-as-a-judge). Les métriques automatiques incluent la similarité cosine entre la réponse et les sources (pour la fidélité), le recall des entités nommées (pour la complétude), et le taux de citation correcte (pour la traçabilité). L'évaluation par LLM utilise un modèle juge — généralement GPT-4o ou Claude — qui reçoit la requête, les chunks retrieved, la réponse générée, et évalue chaque axe selon une grille standardisée avec justification textuelle. Cette approche corrèle bien avec l'évaluation humaine (coefficient de corrélation de Spearman > 0.85 dans nos tests) tout en étant automatisable et reproductible. Chaque campagne d'évaluation produit un rapport détaillé avec les scores par axe, les exemples de réussite et d'échec, et les recommandations d'amélioration.

Cas d'Usage

Les cas d'usage concrets couvrent deux domaines principaux qui structureront nos recommandations. Le traitement de documents techniques — manuels d'utilisation, spécifications, documentation d'API, rapports de tests, procédures opératoires — est un terrain d'application naturel du RAG. Ces documents sont généralement bien structurés, avec des titres, des sections, des numérotations et des index, ce qui les rend particulièrement adaptés au chunking hiérarchique. Les requêtes techniques sont souvent précises et factuelles : quel est le couple de serrage recommandé pour cette vis ? Quelle version de Python est requise pour ce module ? La précision du retrieval est critique car une information erronée — une spécification incorrecte, un paramètre mal interprété — peut avoir des conséquences matérielles ou financières. Nos recommandations pour ce domaine privilégient le chunking hiérarchique avec overlap réduit (50 tokens), un modèle d'embedding multilingue de type BGE, un top-k de 8 à 12, et l'hybrid search avec un poids lexical de 0.4 pour les termes techniques.

Le traitement de documents juridiques — contrats, clauses, conditions générales, avenants, décisions de justice — présente des exigences spécifiques. Le vocabulaire juridique est précis et normé : un terme a une signification légale exacte qui ne tolère pas d'approximation sémantique. Les documents juridiques sont riches en renvois, définitions croisées, et références à d'autres articles ou contrats, ce qui nécessite une capacité de navigation entre les chunks — un point où le chunking hiérarchique avec un graphe de relations entre chunks s'avère particulièrement utile. Les requêtes juridiques sont souvent conditionnelles : que se passe-t-il si le client résilie avant la date anniversaire ? L'analyse de la condition implique de retrouver plusieurs clauses potentiellement réparties dans différents articles du contrat. La précision du retrieval est ici aussi critique, mais la tolérance aux erreurs est encore plus faible : une interprétation erronée d'une clause contractuelle peut avoir des conséquences juridiques et financières graves. Pour ce domaine, nous recommandons un chunking sémantique avec des chunks plus longs (800 à 1200 tokens) pour préserver la cohérence des raisonnements juridiques, un modèle d'embedding juridique fine-tuné (SaulLM ou LegalBERT) si disponible, un top-k de 10 à 15 pour couvrir les clauses connexes, et un re-ranking obligatoire avec un modèle cross-encoder.

Les résultats de ce projet prennent la forme d'un guide de recommandations architecturales classant les configurations par type de corpus, par contrainte métier (précision, latence, coût, souveraineté) et par volume documentaire. Chaque recommandation est étayée par les résultats chiffrés de nos campagnes de test, avec les métriques de performance attendues, les prérequis matériels, et les compromis associés. Le guide est conçu pour être utilisable par une équipe technique sans expertise préalable en RAG : il fournit des configurations prêtes à l'emploi, des arbres de décision pour le choix des composants, et des procédures de test pour valider chaque étape du pipeline. Le banc de test lui-même est livré comme un projet open source, permettant à toute organisation de reproduire nos évaluations sur ses propres corpus et de valider ses choix architecturaux avant le passage en production.

Perspectives

Les perspectives d'évolution du projet sont nombreuses. L'évaluation des architectures agentiques qui étendent le RAG classique avec des capacités de planification et d'utilisation d'outils est une piste prometteuse : un agent RAG capable de décider itérativement quels documents consulter, dans quel ordre, et comment combiner les informations, peut traiter des questions complexes qui dépassent les capacités d'un RAG à passage unique. L'intégration de la génération augmentée par graphe (GraphRAG), qui utilise un graphe de connaissances en complément de la base vectorielle pour le retrieval, ouvre des perspectives pour les corpus hautement interconnectés. L'extension à d'autres modalités — RAG sur documents contenant des images, des tableaux, des graphiques — est un axe de recherche actif. Enfin, l'étude du RAG conversationnel, où le système maintient un historique de dialogue et adapte le retrieval en fonction du contexte cumulé des échanges, préfigure la prochaine génération des systèmes d'IA documentaire.

Conclusion

Le RAG n'est pas une technologie figée mais un champ de recherche actif dont les architectures évoluent rapidement. Ce projet contribue à structurer cette évolution en documentant rigoureusement ce qui fonctionne, dans quel contexte et à quel coût. Les décisions architecturales d'un système RAG — chunking, embedding, retrieval, génération — sont interdépendantes et doivent être optimisées de manière holistique : une amélioration sur un maillon peut être annulée par une régression sur un autre. Notre approche systématique, combinant évaluation quantitative rigoureuse et cas d'usage concrets, fournit aux équipes techniques les clés pour concevoir des systèmes RAG performants, fiables et adaptés à leurs contraintes métier. La maîtrise de ces architectures est un avantage compétitif décisif pour toute organisation qui souhaite exploiter pleinement la valeur de ses bases de connaissances professionnelles.