CONCEPTS — DU MODÈLE AU SYSTÈME · RAG EN PROFONDEUR
Sources officielles et travaux de recherche vérifiés au 18 juillet 2026.
Un assistant interne branché sur la documentation de l'organisation répond à côté. La réponse est fluide, plausible — et fausse. Le réflexe consiste à incriminer le modèle : trop petit, mal instruit, température mal réglée. On change de fournisseur, on réécrit la consigne système. Et le problème persiste, parce qu'il n'a jamais été là : dans l'immense majorité des cas, le modèle n'a jamais vu le passage qui contenait la bonne réponse.
Une architecture de recherche augmentée est une chaîne, et elle cède à son maillon le plus faible — presque toujours en amont de la génération, dans la façon dont les documents ont été découpés, indexés, cherchés, triés, puis assemblés. Cet article ouvre cette chaîne étage par étage, montre où chacun perd la bonne réponse, et tranche le débat qui traverse le domaine : les fenêtres de contexte géantes rendent-elles tout cela inutile ?
Le maillon faible n'est pas la génération
Pour diagnostiquer une panne, il faut d'abord voir la machine. Le pipeline standard enchaîne six étages : l'ingestion convertit les fichiers sources en texte ; le découpage tranche ce texte en fragments — les chunks ; l'indexation les transforme en représentations cherchables ; la recherche interroge cet index et remonte un lot de candidats ; le re-ranking, quand il existe, les réordonne ; l'assemblage place les passages retenus dans le prompt, avant la génération.
Chaque étage peut perdre la bonne réponse, et chacun la perd autrement. Un découpage brutal coupe un tableau en deux et rend chaque moitié incompréhensible. Une indexation purement vectorielle passe à côté d'une référence produit exacte. Une recherche sans re-ranking remonte le bon document en douzième position, hors du lot transmis. Un assemblage trop généreux le noie parmi quarante autres. Le symptôme est identique — une réponse fausse — mais la cause est en amont, et différente à chaque fois.
Le pipeline de recherche augmentée, étage par étage, avec les points d'échec associés à chacun. La génération, tout à droite, hérite de toutes les pertes accumulées en amont. Diagnostiquer un RAG défaillant consiste à remonter cette frise de droite à gauche, pas à régler le modèle.
Tant que la récupération n'a pas été mesurée séparément, toute intervention sur le modèle relève du tâtonnement. Nous avions posé le cadre des trois voies d'adaptation — pré-entraînement, ajustement fin et recherche augmentée — dans « Les LLM démontés » ; il s'agit ici d'entrer dans la troisième.
Découper un document, c'est déjà décider ce qu'on saura retrouver
Le découpage passe pour une formalité technique. C'est en réalité l'endroit où l'on fige ce que le système pourra retrouver : un fragment mal taillé produit une représentation vectorielle bancale, et aucun étage ultérieur ne rattrapera cette perte.
La méthode la plus répandue découpe à taille fixe, tous les N tokens, avec un recouvrement entre fragments voisins. Simple et rapide, elle ignore la structure du texte : une clause contractuelle scindée en son milieu, une ligne de tableau séparée de son en-tête, un pronom éloigné de son antécédent. Le fragment reste lisible mais sémantiquement orphelin, et son embedding ne représente plus grand-chose de cherchable.
Trois réponses documentées s'y opposent. Le découpage hiérarchique, dit parent-document, dissocie le fragment qu'on cherche de celui qu'on lit : de petits chunks enfants servent à la recherche, mais c'est le chunk parent, plus large, qui est renvoyé au modèle — le ParentDocumentRetriever de LangChain l'implémente avec 100 tokens par défaut pour l'enfant et 500 pour le parent.
Le « late chunking » des chercheurs de Jina AI inverse l'ordre des opérations : il encode d'abord le texte long intégralement avec un modèle d'embedding à contexte étendu, puis découpe après le passage dans le transformeur, si bien que chaque fragment hérite du contexte de ses voisins. Enfin, la « recherche contextuelle » publiée par Anthropic le 19 septembre 2024 fait générer, avant indexation, un résumé de 50 à 100 tokens situant chaque fragment dans son document d'origine : le taux d'échec dans le top 20 passe alors de 5,7 % à 3,7 %, soit 35 % d'échecs en moins.
Chercher par le sens, chercher par les mots, ou les deux
Une fois les fragments taillés, il faut les rendre cherchables. Deux familles de moteurs s'opposent, et l'erreur consiste à croire qu'il faut choisir.
La recherche dense projette chaque fragment dans un espace vectoriel où la proximité géométrique traduit la proximité de sens — le mécanisme détaillé dans « Embeddings & recherche sémantique ». Elle brille sur les reformulations et rate les correspondances exactes. La recherche lexicale, dont BM25 est le représentant classique, fait l'inverse : elle compte les termes pondérés par leur rareté, retrouve un code produit à coup sûr et rate toute question posée avec un autre vocabulaire. C'est ce décalage que les auteurs de HyDE contournent en faisant d'abord générer une réponse hypothétique — même approximative, elle partage le vocabulaire des vraies réponses — dont l'embedding sert de requête.
La recherche hybride interroge les deux index et fusionne leurs classements, le plus souvent par Reciprocal Rank Fusion, introduite par Cormack, Clarke et Buettcher à SIGIR 2009 : chaque document reçoit la somme des 1/(k + rang) obtenus dans chaque système, avec une constante k fixée à 60 dans le papier original et restée quasi universelle. Elle ne compare jamais des scores hétérogènes — un cosinus et un score BM25 ne sont pas dans la même unité — mais seulement des rangs. Chez Anthropic, ajouter un index lexical contextualisé fait passer le taux d'échec de 5,7 % à 2,9 %, soit 49 % d'échecs en moins.
| Stratégie | Ce qu'elle capte | Ce qu'elle rate | Coût d'index | Quand la préférer |
|---|---|---|---|---|
| Dense (embeddings) | Le sens : paraphrases, synonymes, questions formulées autrement que le document. | Les correspondances exactes : références produit, numéros de version, acronymes rares. | Élevé : encodage du corpus, stockage vectoriel, réindexation à chaque changement de modèle. | Corpus en langage naturel, utilisateurs étrangers au jargon des documents. |
| Lexicale (BM25) | Les termes pondérés par leur rareté : codes, identifiants, citations littérales. | Toute reformulation : une question sans aucun mot du document ne remonte rien. | Faible : index inversé, pas d'inférence, mise à jour incrémentale peu coûteuse. | Corpus très codifiés, références exactes, fortes contraintes de coût. |
| Hybride (fusion RRF) | Les deux : le sens via le dense, l'exactitude via le lexical, réunis par fusion de rangs. | Ce qu'aucun des deux moteurs n'a remonté — la fusion ne crée pas de rappel, elle réordonne. | Cumul des deux index : le poste le plus lourd, mais la fusion est quasi gratuite. | Cas par défaut dès que le corpus mêle prose et références techniques. |
Le re-ranking : trier ce que la recherche a ramené
La recherche produit un lot de candidats. Elle les ordonne aussi — mal. Pour rester rapide sur des millions de fragments, elle compare des vecteurs pré-calculés indépendamment les uns des autres : le document a été encodé sans connaître la question, et réciproquement. Cette comparaison à distance suffit à ramener une short-list plausible, pas à la classer finement.
Le re-ranking par cross-encoder ajoute une seconde passe. Le principe, décrit par la documentation de Cohere sur son modèle Rerank, consiste à reprendre les 20 à 100 candidats et à faire évaluer chaque paire question-document par un modèle qui les lit ensemble, avec attention croisée. Le calcul est bien plus lourd — une inférence par candidat, rien de pré-calculable — mais ne s'applique qu'à une poignée de documents. La version 3.5 de Cohere Rerank, annoncée fin 2024, dispose d'une fenêtre de 4 096 tokens pour l'ensemble requête plus document.
La division du travail est claire : la recherche optimise le rappel, le re-ranking la précision en tête de liste. Dans les mesures publiées par Anthropic, ajouter le re-ranking à une recherche hybride contextualisée fait tomber le taux d'échec de 5,7 % à 1,9 %, soit 67 % d'échecs en moins — la meilleure configuration testée.
La génération ne peut pas répondre à partir d'un document qu'elle n'a jamais reçu. Un RAG qui échoue échoue presque toujours avant que le modèle n'écrive son premier mot.
— Principe de diagnostic d'une architecture de recherche augmentée
Trop de contexte tue le contexte
Reste le dernier étage : l'assemblage. Puisque les fenêtres sont vastes, pourquoi ne pas transmettre quarante passages en comptant sur le modèle pour faire le tri ? Parce qu'il ne le fait pas de manière uniforme. C'est le résultat central de « Lost in the Middle », de Liu et ses coauteurs, publié dans TACL en 2024 : les modèles exploitent nettement mieux l'information placée au début ou à la fin de leur contexte que celle placée au milieu. La performance suit une courbe en U, haute aux extrémités, creusée au centre. Plus dérangeant encore, le phénomène s'observe aussi sur des modèles conçus pour les contextes longs. Agrandir la fenêtre ne comble pas le creux ; cela l'allonge.
La courbe en U documentée par Liu et ses coauteurs : le taux de bonne réponse selon la position du passage utile dans le contexte. Un document enfoui au milieu d'un long assemblage est nettement moins bien exploité que le même document placé en tête ou en queue — l'argument décisif pour trier avant de transmettre.
La conséquence est contre-intuitive : au-delà d'un certain point, ajouter des passages dégrade la réponse. Chaque passage supplémentaire repousse les autres vers la zone creuse et augmente le bruit. Mieux vaut cinq passages bien classés que quarante tièdes — ce qui donne au re-ranking sa vraie justification et fait de l'assemblage un exercice de sélection, pas d'accumulation. Nous avons consacré un article à cette dégradation dans « Fenêtre de contexte longue & lost in the middle », et la discipline consistant à composer délibérément ce qu'on transmet porte un nom : le context engineering.
Le contexte long rend-il le RAG inutile ?
La question mérite une réponse franche, et cette réponse n'est pas un vainqueur universel. L'argument en faveur du contexte long est étayé : le travail comparatif de Li, Cao, Ma et Sun, « Long Context vs. RAG for LLMs », conclut qu'il surpasse généralement la recherche augmentée sur des jeux de questions-réponses, en particulier ceux fondés sur Wikipédia. Les mêmes auteurs relèvent que la récupération par résumé égale le contexte long, tandis que la récupération par fragments reste en retrait des deux. Le RAG conserve toutefois l'avantage sur les requêtes dialoguées et les questions générales : la supériorité dépend de la tâche, pas de la technologie.
L'argument économique penche dans l'autre sens. Une étude publiée par Elastic Search Labs le 11 juillet 2025 mesure, sur son propre protocole, un coût moyen de 0,00008 $ par requête en RAG contre 0,10 $ en contexte complet — un facteur d'environ 1 250 — avec une latence d'environ une seconde contre quarante-cinq. Ces chiffres valent pour un protocole particulier, non comme constante universelle ; l'ordre de grandeur rappelle qu'envoyer un corpus entier se paie à chaque requête. S'y ajoutent deux arguments qu'aucun élargissement de fenêtre ne résout : un corpus vivant change en permanence, et les droits d'accès s'appliquent document par document — un étage de récupération sait filtrer ce qu'un utilisateur a le droit de voir, un contexte injecté en bloc ne le sait pas.
La position qui domine les guides techniques récents est intermédiaire : utiliser la récupération pour réduire le corpus à un ensemble pertinent, puis laisser la fenêtre étendue du modèle raisonner dessus. Le retrieval devient un filtre de volume plutôt qu'un fournisseur de fragments minuscules. Cette convergence provient de blogs d'ingénierie plutôt que d'un résultat expérimental : une tendance observée, pas une démonstration.
Sans évaluation, vous ne saurez jamais lequel de vos réglages aide
Tout ce qui précède décrit des leviers, mais aucun ne dit lequel activer sur un corpus donné : les gains publiés l'ont été sur les jeux de données de ceux qui les publient. Sans mesure, ajuster un pipeline RAG revient à tourner des boutons dans le noir.
Le point de départ est de séparer strictement les deux moitiés. Mesurez d'abord la récupération seule : sur un jeu de questions dont vous connaissez le document-réponse, quelle proportion le voit remonter dans les k premiers passages ? Ce rappel se calcule sans appeler le modèle génératif, et isole l'étage qui échoue le plus souvent. Ensuite seulement, évaluez la génération : la réponse est-elle étayée par les passages transmis, ou le modèle a-t-il comblé les trous ? Le framework Ragas outille cette seconde question, tandis que les benchmarks BEIR et MTEB, au classement consultable en ligne, situent les modèles d'embedding entre eux — sans remplacer une mesure sur votre corpus. La méthode générale fait l'objet de notre article sur les evals.
Une architecture de recherche augmentée bien réglée retrouve la bonne information et la présente au modèle dans de bonnes conditions. Elle reste pourtant enfermée dans un seul geste : lire des documents et rédiger à partir d'eux. Elle ne consulte pas un stock en temps réel, n'ouvre pas un ticket, ne déclenche aucune opération. Le passage de « répondre à partir de documents » à « déclencher une action » repose sur un autre mécanisme — le tool calling et les sorties structurées — que le prochain article de cette série ira examiner.
Une question, un projet IA ?
Vous montez un assistant branché sur votre documentation, ou cherchez pourquoi ses réponses ratent la cible — échangeons sur votre contexte.
Prendre contact →Pour aller plus loin : côté pratique, nos décryptages d'outils IA montrent comment ces étages se retrouvent dans les plateformes du quotidien ; et sur le versant méthode, notre article sur l'évaluation d'une sortie d'IA détaille comment bâtir le jeu de questions de référence sans lequel aucun réglage n'est mesurable.