1 · Pourquoi le RAG
Trois limites d'un modèle de langage motivent le RAG. Ses connaissances s'arrêtent à la date de son entraînement et n'incluent rien de ce qui est propre à votre organisation. Il n'a pas de mémoire : ce qui n'est pas dans le contexte n'existe pas pour lui. Et lorsqu'il ne sait pas, il produit la suite la plus plausible plutôt que d'avouer une lacune — c'est l'hallucination. Le RAG répond aux trois d'un coup : il place dans le contexte, à chaque question, les extraits de vos documents qui la concernent, et il demande au modèle de s'y tenir et de les citer.
Par rapport au fine-tuning (voir Entraîner un modèle sur son domaine), le RAG a trois avantages décisifs pour des connaissances : elles sont à jour dès que le document change, citables (la réponse renvoie au passage source, que l'utilisateur peut vérifier), et gouvernables (on retire un document, il disparaît des réponses ; on restreint l'accès par service, le modèle ne voit que ce que l'utilisateur a le droit de voir). Sa limite est symétrique : il ne change pas la manière dont le modèle écrit ou raisonne. Un RAG n'apprend rien ; il fournit.
2 · La chaîne complète
Un RAG comporte deux chaînes distinctes. La chaîne d'indexation tourne à l'avance et à chaque mise à jour : elle transforme les documents en passages, calcule leur représentation et les range dans un index. La chaîne de requête tourne à chaque question : elle retrouve les passages pertinents, les classe, les assemble dans un contexte et fait rédiger la réponse.
3 · Découper les documents en passages
On n'indexe pas des documents entiers mais des passages (chunks), pour deux raisons : un vecteur d'embedding résume mal un texte long et hétérogène, et le contexte du modèle a une taille finie — il faut pouvoir y placer plusieurs passages de plusieurs documents. La taille courante va de 200 à 800 tokens, avec un chevauchement de 10 à 20 % entre passages consécutifs pour qu'une phrase coupée se retrouve entière dans l'un des deux.
La manière de couper compte autant que la taille. Couper à longueur fixe est simple mais sépare une question de sa réponse, un titre de son paragraphe, une ligne de tableau de son en-tête. Couper selon la structure — sections, paragraphes, cellules de tableau, avec le fil des titres reporté dans chaque passage — donne des passages qui ont un sens seuls, et c'est ce qui fait la différence sur des documents techniques. Chaque passage conserve ses métadonnées : document source, page, section, date, service propriétaire, niveau de confidentialité. Elles servent au filtrage et aux citations.
À gauche, la ligne « M12 : 85 N·m » se retrouve dans un passage sans son en-tête : retrouvée seule, elle est inintelligible. À droite, chaque passage porte le titre de sa section et sa provenance.
4 · Les embeddings : représenter le sens par des nombres
Un modèle d'embedding convertit un texte — passage ou question — en un vecteur de quelques centaines à quelques milliers de nombres (1 024 pour bge-m3, 4 096 pour qwen3-embedding:8b) tel que deux textes de sens proche donnent des vecteurs proches. Il ne génère rien ; il n'a qu'une fonction de mesure. Ces modèles sont petits (0,6 à 8 milliards de paramètres), rapides, et fonctionnent sur une station de travail sans carte graphique dédiée pour les plus légers.
La proximité se mesure par la similarité cosinus : le cosinus de l'angle entre deux vecteurs, 1 s'ils pointent dans la même direction, 0 s'ils sont orthogonaux. Chercher, c'est calculer le vecteur de la question et retrouver les passages dont le vecteur forme avec lui le plus petit angle. Deux règles pratiques en découlent. Un seul modèle d'embedding par index : les vecteurs de deux modèles ne sont pas comparables, et en changer oblige à tout réindexer. Et le modèle doit couvrir vos langues : un modèle entraîné sur l'anglais rapproche mal deux phrases françaises ; les modèles multilingues sont évalués sur le banc MMTEB (bge-m3 : 59,6 ; qwen3-embedding:8b : 70,6).
5 · Les types de recherche
La recherche vectorielle n'est qu'une des façons de retrouver un passage, et rarement suffisante seule. Cinq approches se combinent en pratique.
Recherche lexicale (BM25)
L'héritière des moteurs de recherche classiques : un passage est d'autant mieux classé qu'il contient les mots de la question, rares dans le corpus et fréquents dans le passage. Exacte sur les termes — références, codes, noms propres, numéros de pièce —, insensible au sens : « panne » ne retrouve pas « défaillance ».
Recherche vectorielle (dense)
La question et les passages sont comparés par leurs embeddings. Elle retrouve le sens malgré les mots : « la machine s'arrête toute seule » trouve « déclenchement intempestif ». En contrepartie, elle est floue sur les identifiants exacts et peut préférer un passage « qui parle du même sujet » à celui qui contient la réponse.
Recherche hybride
Les deux précédentes, exécutées en parallèle, avec fusion des classements (par exemple reciprocal rank fusion : chaque passage reçoit la somme des inverses de ses rangs dans chaque liste). C'est le réglage par défaut raisonnable sur des documents techniques, où codes et sens comptent tous deux.
Reclassement (reranking)
Un second modèle, dit cross-encoder, relit ensemble la question et chacun des 20 à 50 premiers passages, et les reclasse finement. Beaucoup plus précis que la comparaison de vecteurs, mais trop lent pour tout le corpus : il s'applique après une première sélection. Le gain sur la précision du top-5 est souvent le plus important de toute la chaîne.
Filtres et graphes
Les métadonnées restreignent la recherche avant même de comparer : ce service, cette période, ce niveau d'accès, cette version du document. Le GraphRAG ajoute un graphe d'entités et de relations extrait du corpus, utile pour les questions qui traversent de nombreux documents (« quels équipements dépendent du fournisseur X ? »), au prix d'une indexation lourde.
6 · Avantages et inconvénients, côte à côte
| Approche | Forces | Faiblesses | Quand la choisir |
|---|---|---|---|
| Lexicale (BM25) | Exacte sur les termes ; explicable ; aucune dépendance à un modèle ; passe à l'échelle de millions de documents | Ignore synonymes et paraphrases ; sensible à la langue et à l'orthographe | Codes, références, noms, corpus très volumineux ; toujours en complément |
| Vectorielle | Retrouve le sens ; multilingue avec le bon modèle ; tolère les formulations libres | Floue sur les identifiants ; dépend du modèle d'embedding (réindexation si on en change) ; index en mémoire vive | Questions en langage naturel, corpus hétérogène |
| Hybride | Cumule les deux ; le meilleur rappel en général | Deux index à maintenir ; réglage de la fusion | Réglage par défaut sur des documents techniques |
| + Reclassement | Gain de précision important sur le top-5 ; corrige les erreurs des deux recherches | Un modèle de plus ; latence proportionnelle au nombre de candidats | Dès que la précision compte plus que la latence |
| Filtres par métadonnées | Réduit le champ, applique les droits d'accès, cible une version ou une période | Suppose des métadonnées fiables | Toujours, dès qu'il y a des droits ou des versions |
| GraphRAG | Questions transversales, agrégations, relations entre entités | Indexation lourde (un LLM lit tout le corpus), maintenance, coût | Corpus stable, questions de synthèse multi-documents |
| Contexte long, sans index | Aucune infrastructure ; tout le document est vu | Plafonné par la taille du contexte ; qualité qui baisse au milieu du contexte ; coût par requête élevé | Quelques documents, questions ponctuelles |
Et ce que chaque approche coûte, à l'indexation (une fois, puis à chaque mise à jour) et à chaque question :
| Approche | Coût d'indexation | Latence par requête |
|---|---|---|
| Lexicale (BM25) | Très faible | Millisecondes |
| Vectorielle | Un passage par le modèle d'embedding pour chaque chunk | Millisecondes à dizaines de ms (index approché) |
| Hybride | Somme des deux | Dizaines de ms |
| + Reclassement | Aucun | + 100 à 500 ms pour 20 à 50 candidats |
| Filtres par métadonnées | Extraction des métadonnées | Négligeable, souvent plus rapide |
| GraphRAG | Élevé : heures à jours | Élevée |
| Contexte long, sans index | Aucun | Secondes à dizaines de secondes |
7 · Ce que la taille du corpus change
Pour raisonner sur la taille, il faut d'abord compter dans la bonne unité. L'unité n'est pas le document mais le passage, le chunk de la section 3 : un morceau de texte de 200 à 800 tokens, disons 500, soit environ 350 mots, une demi-page. Un rapport de 100 pages fait donc quelque 200 passages ; une base de 50 documents de cette taille, 10 000 passages ; 5 000 documents, un million ; les archives d'un groupe industriel, plusieurs dizaines de millions. C'est ce nombre de passages, noté N ci-dessous, qui dimensionne tout.
Ensuite, il faut savoir ce que le système garde pour chaque passage, et où. Deux choses. D'abord son texte, environ 2 Ko, qui n'est lu qu'au moment de composer la réponse : il peut rester sur le disque, comme n'importe quel fichier. Ensuite son vecteur d'embedding, la liste de 1 024 nombres de la section 4, soit 4 Ko en précision standard (32 bits). Or la recherche vectorielle consiste à comparer le vecteur de la question à ces N vecteurs — tous, ou un sous-ensemble guidé par un graphe — et cela doit se faire en quelques millisecondes. Un disque, même SSD, est cent à mille fois trop lent pour cela : les vecteurs doivent être chargés en mémoire vive (RAM) de la machine qui exécute la recherche. C'est en cela que la mémoire de l'index est structurante : elle ne se stocke pas, elle s'occupe en permanence, et c'est elle qui décide si le RAG tourne sur un portable, sur une station de travail ou sur un serveur dédié. Le graphique ci-dessous donne cette mémoire pour quatre tailles de corpus ; les trois régimes qui suivent en tirent les conséquences.
Calcul : passages × 1 024 dimensions × octets par dimension (4 en 32 bits, 1 en 8 bits). L'index HNSW ajoute 10 à 30 % pour son graphe. Ce sont des gigaoctets de mémoire vive, sur la machine qui exécute la recherche ; le texte des passages, lui, reste sur disque.
Jusqu'à 10 000 passages — une cinquantaine de gros documents
L'index pèse 40 Mo : n'importe quel ordinateur le tient en mémoire vive, et une recherche exacte — comparer la question à chacun des 10 000 vecteurs — prend quelques millisecondes. Une base SQLite ou un simple fichier suffit ; l'effort va au découpage et à l'évaluation, pas à l'infrastructure. C'est le régime d'un service, d'un projet, d'un référentiel de procédures.
De 10 000 à un million de passages — jusqu'à 5 000 documents
L'index atteint 4 Go : encore une station de travail, mais ce n'est plus négligeable, d'autant que le modèle de langage qui rédige occupe lui aussi 5 à 20 Go de mémoire à côté. Surtout, comparer la question à un million de vecteurs à chaque requête devient lent : on passe à un index approché (HNSW, IVF), qui retrouve les voisins en explorant un graphe plutôt qu'en comparant tout, au prix d'un rappel légèrement inférieur à 100 %. Un moteur dédié (pgvector, Qdrant, Weaviate, Elasticsearch/OpenSearch pour l'hybride) devient nécessaire, avec métadonnées et droits d'accès.
Plusieurs millions de passages — les archives d'un groupe
À 10 millions de passages, 40 Go de mémoire vive rien que pour les vecteurs : un serveur dédié, et des techniques pour réduire la facture — quantifier les vecteurs sur 8 bits (le quart de la mémoire, une perte de précision minime), voire en binaire ; partitionner par collection pour ne charger que ce qui sert ; s'appuyer d'abord sur les filtres et la recherche lexicale pour réduire le champ avant la recherche vectorielle. À cette échelle, la qualité dépend plus de la gouvernance du corpus — doublons, versions, documents obsolètes — que de l'algorithme.
Voilà la première limite, celle de la mémoire de l'index : combien de passages on peut chercher. La seconde est d'une autre nature : c'est le budget de contexte, combien de passages on peut montrer au modèle une fois qu'on les a trouvés. Le contexte d'un modèle de langage — le texte qu'il peut lire d'un coup — est borné, disons 16 000 tokens pour un modèle courant exécuté sur site. Ce budget doit contenir tout ce qu'on lui donne et tout ce qu'il produit : les instructions (environ 500 tokens), la question (100), la réponse attendue (500 à 1 500), et les passages. Avec des passages de 500 tokens, il resterait de la place pour une trentaine de passages au maximum ; en pratique on en retient cinq à dix, soit 2 500 à 5 000 tokens, pour deux raisons : garder de la marge pour la réponse, et parce qu'un modèle exploite mal un contexte saturé (le phénomène « perdu au milieu », section 10). Le RAG ne fait donc jamais « lire tout le corpus » au modèle : il lui montre les cinq à dix meilleurs extraits parmi les millions indexés. Si la réponse exige de croiser cinquante documents, il faut soit une étape de synthèse intermédiaire (résumer par document, puis répondre à partir des résumés), soit un GraphRAG, soit accepter que la question dépasse ce qu'un RAG simple sait faire.
8 · La génération et les citations
Les passages retenus sont assemblés dans le contexte, chacun précédé de son identifiant (« [3] Procédure P-12, §4, p. 2, révision B du 12/03/2026 »), suivis de la question et d'instructions strictes : répondre uniquement à partir des passages fournis, citer l'identifiant de chaque passage utilisé, et dire explicitement « les documents fournis ne permettent pas de répondre » lorsque c'est le cas. Cette dernière consigne est celle qui distingue un RAG utile d'un RAG dangereux : un modèle privé de la permission de ne pas savoir invente.
Le modèle de rédaction n'a pas besoin d'être un géant. Le travail d'un RAG est de lire attentivement et de restituer fidèlement, pas de mobiliser une culture générale : un modèle ouvert de 4 à 27 milliards de paramètres, avec un contexte suffisant, convient à la plupart des usages et tourne sur site. Deux réglages comptent, et il vaut la peine de comprendre pourquoi. La température règle la part de hasard dans le choix de chaque token : à 0, le modèle prend toujours le token le plus probable, la réponse est reproductible et colle au texte fourni ; à 1, il tire au sort parmi les tokens plausibles, ce qui donne des formulations variées — utile pour rédiger, néfaste pour restituer, car c'est précisément dans ces écarts que naissent les détails inventés. Un RAG se règle donc entre 0 et 0,3 : la même question, les mêmes passages, la même réponse. La taille du contexte est l'autre garde-fou : elle doit contenir les instructions, les passages retenus, la question et la réponse (section 7). Si elle est trop courte, la plupart des outils tronquent silencieusement le début du contexte — souvent les instructions ou le premier passage — et le modèle répond à partir de preuves incomplètes sans que personne ne le voie. 8 000 tokens est un minimum, 32 000 une valeur confortable, et la vérification à faire est simple : compter les tokens réellement envoyés et s'assurer qu'ils tiennent.
9 · Évaluer un RAG
Un RAG se mesure en deux temps, parce qu'il peut échouer de deux façons : ne pas retrouver le bon passage, ou le retrouver et mal répondre. On constitue un jeu de questions de référence — 50 à 200 questions réelles, avec pour chacune le ou les passages qui contiennent la réponse et une réponse attendue, écrites par des personnes du métier. C'est le premier livrable d'un projet RAG, avant toute ligne de code.
| Étape | Mesure | Question posée | Ordre de grandeur visé |
|---|---|---|---|
| Recherche | Recall@k | Dans quelle part des questions le bon passage figure-t-il parmi les k retenus ? | > 90 % à k = 5 sur un corpus bien découpé |
| Recherche | MRR (rang réciproque moyen) | À quel rang le bon passage apparaît-il ? | Le plus près possible de 1 |
| Génération | Fidélité | La réponse est-elle entièrement soutenue par les passages cités ? | > 95 % ; toute réponse non soutenue est une hallucination |
| Génération | Pertinence | La réponse répond-elle à la question posée ? | Notée par un relecteur, ou un second modèle calibré sur un échantillon relu |
| Système | Abstention | Sur les questions sans réponse dans le corpus, le RAG dit-il qu'il ne sait pas ? | > 90 % ; on ajoute exprès des questions pièges au jeu |
« Soutenue » a un sens précis : chaque affirmation de la réponse doit pouvoir être rattachée à un passage cité qui la dit, ni plus ni moins. Si le passage indique « délai de traitement : 48 heures » et que la réponse dit « 48 heures », l'affirmation est soutenue. Si la réponse dit « 48 heures ouvrées », elle ne l'est plus : le mot « ouvrées » ne vient d'aucun passage, il vient de la mémoire du modèle, et même s'il est vraisemblable, c'est une invention — une hallucination au sens strict, une affirmation que rien dans les documents fournis ne permet de faire. La fidélité se mesure en relisant, affirmation par affirmation, la réponse contre les passages ; on la fait faire à un second modèle, après avoir vérifié sur un échantillon qu'il juge comme un relecteur humain.
Le recall@k (rappel à k) est la mesure de la recherche, et la plus utile de toutes. On prend chaque question du jeu de référence, on lance la recherche, on regarde les k premiers passages retournés : le passage qui contient la réponse y figure-t-il ? Le recall@k est la proportion de questions pour lesquelles c'est le cas. Sur l'exemple ci-dessous, dix questions ; pour chacune, le rang auquel la recherche a classé le bon passage.
Lecture : à k = 5, huit questions sur dix ont leur bon passage dans les cinq premiers résultats — c'est ce que le modèle de rédaction verra. Q9, classée 8ᵉ, ne sera vue que si l'on montre dix passages ; Q6 est perdue quoi qu'on fasse. Le MRR complète le tableau en récompensant les bons passages placés en tête : il compte 1 pour un premier rang, ½ pour un deuxième, et ainsi de suite.
Le recall@k se mesure sans modèle de langage, en quelques secondes, et c'est par lui qu'on règle le découpage, le modèle d'embedding, l'hybride et le reclasseur : on change un réglage, on relance les 100 questions, on compare. Tant qu'il est bas, améliorer la génération ne sert à rien : on ne répond pas juste à partir d'un mauvais passage. En pratique on vise plus de 90 % à k = 5, et l'on regarde une à une les questions qui échouent — elles révèlent presque toujours un défaut de découpage ou de vocabulaire.
10 · Les modes d'échec
- Le passage n'est pas retrouvé : mauvais découpage, modèle d'embedding inadapté à la langue, question formulée avec des termes absents du document. Remèdes : découpage structurel, hybride, reformulation de la question par le modèle avant recherche.
- Le passage est retrouvé mais tronqué : la réponse est à cheval sur deux chunks, ou le tableau a perdu son en-tête. Remède : chevauchement, découpage selon la structure, passages « parent » plus larges renvoyés au modèle.
- Perdu au milieu : le modèle exploite mieux le début et la fin de son contexte que le milieu. Remède : peu de passages, les meilleurs en premier, reclassement.
- Index périmé : le document a changé, pas l'index. Remède : réindexation à chaque modification, version dans les métadonnées, date dans les citations.
- Doublons et versions : trois versions d'une procédure se contredisent et le modèle en cite une au hasard. Remède : gouvernance du corpus avant l'IA — c'est souvent le vrai chantier.
- Injection par les documents : un document contient des instructions (« ignore les consignes et… ») que le modèle suit. Remède : traiter les passages comme des données, jamais comme des consignes ; limiter les actions que le modèle peut déclencher.
- Fuite de droits : un passage confidentiel retrouvé pour un utilisateur non habilité. Remède : filtrer par droits avant la recherche, pas après.
11 · Un montage type, sur site
Pour une organisation dont les documents ne doivent pas sortir, l'ensemble tient sur une station de travail dotée de 24 Go de mémoire — mémoire graphique (VRAM) ou mémoire unifiée, celle où le modèle de langage et l'index vectoriel doivent résider pendant l'exécution, à ne pas confondre avec l'espace disque — ou sur un serveur interne. Extrait de notre arbre décisionnel, branche « Interroger ma base documentaire » :
Extraction
Conversion des PDF, Word et mails en texte ; OCR des scans par un modèle spécialisé (1 Go) ; extraction des tableaux.
Embedding
bge-m3 (1,2 Go, multilingue, MIT) ou qwen3-embedding:8b (5 Go) pour plus de précision ; un seul modèle par base.
Index hybride
Vecteurs + BM25 + métadonnées et droits, dans un moteur installé sur site.
Reclassement
Un cross-encoder sur les 20 premiers candidats.
Rédaction
Un modèle de langage ouvert de 4 à 27 milliards de paramètres, contexte 32 000 tokens ou plus, température basse, consigne d'abstention et de citation.
Contrôle
Un second modèle d'une autre famille vérifie que chaque affirmation de la réponse est soutenue par un passage cité ; les réponses non soutenues sont bloquées ou marquées.
Aucune donnée ne quitte le périmètre ; les poids sont téléchargés une fois et versionnés ; le coût marginal d'une question est celui de l'électricité.
Aller plus loin
Quand le RAG ne suffit pas — style, format, raisonnement propre au métier — le niveau suivant est le fine-tuning : Entraîner un modèle sur son domaine. Pour les modèles d'embedding et de rédaction adaptés à votre mémoire : l'arbre décisionnel. Pour un assistant documentaire livré chez vous : notre offre Solutions technologiques.
Références — Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020 · Robertson & Zaragoza, The Probabilistic Relevance Framework: BM25 and Beyond, 2009 · Malkov & Yashunin, HNSW, 2016 · Cormack et al., Reciprocal Rank Fusion, 2009 · Liu et al., Lost in the Middle, 2023 · Edge et al., GraphRAG, 2024 · MMTEB, benchmark d'embeddings multilingue ; scores bge-m3 et qwen3-embedding relevés dans notre arbre décisionnel au 27 août 2026.