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 | Coût d'indexation | Latence par requête | 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 | Très faible | Millisecondes | 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 | Un passage par le modèle d'embedding pour chaque chunk | Millisecondes à dizaines de ms (index approché) | 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 | Somme des deux | Dizaines de ms | 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 | Aucun | + 100 à 500 ms pour 20 à 50 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 | Extraction des métadonnées | Négligeable, souvent plus rapide | 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 | Élevé : heures à jours | Élevée | 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é | Aucun | Secondes à dizaines de secondes | Quelques documents, questions ponctuelles |
7 · Ce que la taille du corpus change
La bonne architecture dépend d'abord du nombre de passages. Trois ordres de grandeur, trois régimes.
Quelques milliers de passages — quelques centaines de documents
Tout tient en mémoire, une recherche exacte (comparer la question à tous les vecteurs) prend quelques millisecondes. Une base SQLite ou un simple fichier suffit ; l'effort va au découpage et à l'évaluation, pas à l'infrastructure.
Dizaines de milliers à un million de passages
La recherche exacte devient lente ; 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 des métadonnées et des droits.
Plusieurs millions de passages
La mémoire de l'index domine : on quantifie les vecteurs (8 bits, voire binaire), on partitionne par collection, on s'appuie d'abord sur les filtres et la recherche lexicale pour réduire le champ. À cette échelle, la qualité dépend plus de la gouvernance du corpus — doublons, versions, documents obsolètes — que de l'algorithme.
Calcul : passages × dimensions × octets par dimension. Un million de passages de 500 tokens représentent environ 5 000 documents de 100 pages — un corpus d'entreprise moyen tient dans quelques gigaoctets de mémoire vive. L'index HNSW ajoute 10 à 30 % pour son graphe ; le texte des passages est stocké à part.
La seconde limite est le budget de contexte : ce qu'on peut placer devant le modèle. Avec des passages de 500 tokens et un contexte utile de 16 000 tokens, on en place au plus une vingtaine, en pratique cinq à dix pour laisser la place à la question, aux instructions et à la réponse. Le RAG ne fait donc pas « lire tout le corpus » au modèle : il lui montre les cinq à dix meilleurs extraits. 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), 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 : une température basse (0 à 0,3), et un contexte assez long pour les passages retenus.
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.
| Étage | 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 |
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. 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.
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 de 24 Go ou 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.