Panorama RAG avril 2026 — vectoriel, vectorless et approches émergentes

En bref

On appelle RAG (Retrieval-Augmented Generation, génération augmentée par la recherche) la famille de techniques qui consiste à faire chercher des documents pertinents dans une base de connaissances, puis à les donner à lire à un grand modèle de langage pour qu’il formule une réponse. En avril 2026, trois grandes familles coexistent : le RAG vectoriel dense (on transforme les textes en listes de nombres et on cherche les plus proches), le RAG vectorless, sparse ou hybrid (on combine la recherche par mots-clés et la recherche sémantique), et les approches émergentes (GraphRAG, Self-RAG, Adaptive, Agentic). L’arrivée des très grands contextes (1 million de tokens chez Gemini, 200 000 chez Claude Opus) n’a pas tué le RAG : elle a délimité son terrain.

Comprendre le problème : pourquoi chercher dans une base avant de répondre

Imaginez un bibliothécaire qui connaît par cœur tout ce qu’il a lu pendant ses études, mais rien de ce qui a été publié depuis. Si vous lui demandez « que dit le dernier rapport trimestriel de telle entreprise ? », il ne peut pas répondre. Les grands modèles de langage (LLM) sont dans cette situation : ils ont appris une fois pour toutes, et ne connaissent pas vos documents internes, les mises à jour récentes, ou les détails d’un corpus métier spécifique.

Le RAG résout ce problème avec un réflexe de bibliothécaire : aller chercher avant de parler. Le principe se décompose en trois rôles, qu’on retrouve dans presque toutes les variantes :

• Le retriever (le chercheur) : reçoit la question, va fouiller dans la base, et rapporte un petit paquet de documents candidats. C’est le bibliothécaire qui court dans les rayons.
• Le reranker (le critique) : reçoit la pile de documents candidats et les réordonne du plus pertinent au moins pertinent. C’est un lecteur plus attentif mais plus lent, qu’on n’utilise que sur les documents déjà pré-sélectionnés.
• Le generator (le rédacteur) : reçoit la question et les documents retenus, et produit la réponse finale. C’est le LLM qui met en mots.

En clair : un pipeline RAG, c’est « question → recherche → tri → rédaction ». Chaque étape peut être implémentée avec des techniques très différentes, et le choix des techniques à chaque étape définit la famille de RAG.

Avant de comparer les familles, un vocabulaire transversal :

Vocabulaire de base

• Corpus : l’ensemble des documents dans lesquels on cherche (base de connaissances).
• Chunking : on découpe chaque document en morceaux de taille digeste, typiquement 200 à 800 tokens. Un chunk est un morceau. On cherche sur les chunks, pas sur les documents entiers, parce qu’un LLM a une fenêtre de contexte limitée et qu’un paragraphe pertinent noyé dans 100 pages dilue l’information.
• Token : un morceau de mot (environ 0,75 mot en anglais, un peu moins en français). C’est l’unité que manipulent les LLM.
• Requête (query) : la question posée, telle qu’elle est envoyée au retriever.

Pourquoi le long contexte ne tue pas le RAG

En 2024-2026, l’argument « les modèles prennent maintenant 1 million de tokens en contexte, le RAG devient inutile » a circulé. La réalité est plus nuancée. Passer tout le corpus en contexte à chaque requête pose quatre problèmes concrets :

• Coût : facturer 1 million de tokens en entrée coûte cher. Sur Claude Opus en 2026, charger 1 million de tokens à chaque question revient à plusieurs dollars par requête ; un pipeline RAG qui ne retient que les 10 chunks les plus pertinents (≈ 10 000 tokens) coûte cent fois moins.
• Latence : plus on envoie de tokens, plus le modèle met de temps à commencer sa réponse (métrique dite TTFT, time-to-first-token). Un long contexte ajoute des secondes.
• Fraîcheur : un index (structure de recherche) se met à jour document par document. Repasser un million de tokens à chaque requête signifie tout recharger à chaque ajout.
• « Perdu au milieu » : même quand le contexte tient, les LLM peinent à extraire une information précise quand elle est perchée au centre d’un très long texte (phénomène documenté par Liu et al. 2023, « Lost in the Middle » ; confirmé par RecaLLM en 2026). Concrètement, la même question se résout mieux avec 5 chunks ciblés qu’avec 500 pages brutes.

Le compromis partiel, disponible chez Anthropic et Google, s’appelle prompt caching : on met en cache le bloc de contexte stable (règles, documents de référence) et les requêtes suivantes ne paient qu’une fraction (environ 10 %) du tarif normal sur ce bloc. C’est utile pour les corpus stables interrogés souvent. Mais cela ne remplace pas un index quand le corpus bouge ou dépasse le cache.

En clair : le long contexte est excellent pour lire un ou deux documents de bout en bout ; le RAG reste indispensable dès que le corpus est gros, change souvent, ou exige de citer précisément ses sources.

Famille 1 — Le RAG vectoriel dense (approche classique 2020+)

Le principe : transformer le texte en géométrie

L’idée fondatrice du RAG vectoriel : convertir chaque morceau de texte en une liste de nombres (par exemple 1024 ou 1536 valeurs), de telle sorte que deux textes qui parlent de la même chose donnent deux listes proches dans l’espace. Cette liste s’appelle un embedding dense. « Dense » parce que presque tous les nombres sont non-nuls, par opposition aux représentations « sparse » (creuses) qu’on verra plus loin.

Vocabulaire

• Embedding : représentation numérique d’un texte sous forme de vecteur (liste de nombres). « la capitale de la France » et « Paris, centre politique français » donnent deux vecteurs qui pointent dans des directions très proches.
• Similarité cosinus : mesure l’angle entre deux vecteurs. Angle petit → vecteurs proches → textes sémantiquement proches. C’est le calcul le plus courant pour dire « quel document ressemble le plus à cette question ».
• Dimension : nombre de valeurs dans le vecteur (souvent 768, 1024, 1536 ou 3072). Plus la dimension est élevée, plus on peut distinguer de nuances, mais plus c’est coûteux à stocker.

Un modèle d’embedding (OpenAI text-embedding-3, Cohere embed-v4.0, Voyage voyage-4-large, open-source BGE ou mxbai) fait ce travail de conversion texte → vecteur. On applique le modèle sur tous les chunks du corpus (une fois), puis sur chaque question (à chaque requête). Le retriever renvoie simplement les chunks dont les vecteurs sont les plus proches du vecteur de la question.

Les briques techniques

L’embedder : le modèle qui transforme texte en vecteur. Les modèles 2025-2026 intègrent deux tendances. D’abord le Matryoshka Representation Learning (MRL), qui permet d’utiliser une dimension réduite sans ré-entraînement — on peut tronquer un vecteur 1536 à 512 selon le compromis voulu. Ensuite l’extension du contexte : Cohere embed-v4.0 embedde des chunks jusqu’à 128 000 tokens, contre 512 pour la génération précédente. Côté open-source, mxbai-embed-large-v1 et BGE-large atteignent et dépassent les propriétaires sur le benchmark MTEB (un classement public de modèles d’embedding sur 56 tâches).

La vector database (base de données vectorielle) : structure optimisée pour trouver rapidement les vecteurs les plus proches d’un vecteur-cible, parmi des millions. Le plus répandu utilise l’algorithme HNSW (Hierarchical Navigable Small World), qui construit un graphe multi-niveaux facilitant la navigation. Les acteurs en 2026 : Qdrant (leader open-source, levée de 50 M$ en mars 2026), Pinecone (référence entreprise managée), pgvector (extension PostgreSQL pour les équipes déjà sur Postgres), Weaviate et Milvus (cloud-native), Chroma (prototypage local), Turbopuffer (serverless adossé à S3).

Le reranker : une fois que le retriever a rapporté 50 à 200 candidats, on passe un modèle plus lourd et plus précis (un cross-encoder) qui lit la question ET chaque candidat ensemble, pour attribuer un score de pertinence. On ne garde que le top 5 à 10 avant d’envoyer au générateur.

Vocabulaire — bi-encoder vs cross-encoder

• Un bi-encoder encode la question et le document séparément, en deux vecteurs indépendants, et compare les vecteurs. Très rapide (on peut pré-calculer les vecteurs des documents), mais moins précis.
• Un cross-encoder lit la question et le document ensemble et produit un score unique. Beaucoup plus précis, mais ne se prépare pas à l’avance : il faut le lancer à chaque requête sur chaque paire. D’où l’usage : bi-encoder pour le retrieval massif, cross-encoder pour le reranking ciblé sur une petite pile.

Références 2026 : Voyage rerank-2.5 et Cohere Rerank 3 côté propriétaire, bge-reranker-v2-m3 côté open-source.

Les limites structurelles documentées en 2025-2026

Plusieurs papiers convergent sur des faiblesses du paradigme vectoriel dense :

• Biais systématiques des retrievers denses (Goyal et al. 2026) : ils favorisent les documents courts (brevity bias), les informations en début de chunk (position bias), les matches littéraux, et les termes répétés. Réécrire la requête masque mais ne règle pas ces biais.
• Asymétrie requête-document (Maekawa et al. 2026) : la question est typiquement une phrase complexe avec des instructions, alors que le document est un fragment plat. Les vecteurs qui en résultent ne vivent pas dans la même « région » de l’espace, ce qui nécessite des adaptateurs dédiés.
• Passivité du LLM (Sun et al. 2026, « Don’t Retrieve, Navigate ») : le modèle générateur reçoit une pile de chunks sans jamais voir l’organisation du corpus. Il ne peut pas revenir en arrière, ni combiner des preuves dispersées.
• Dégradation sur corpus quasi-dupliqué (CHOP, Park et al. 2026) : quand la base contient beaucoup de documents qui se ressemblent, le retrieval se trompe plus souvent et injecte du bruit, générant des hallucinations.

Ces limites ne disqualifient pas le RAG vectoriel, qui reste le pattern dominant en production, mais elles expliquent le regain d’intérêt pour d’autres approches.

Famille 2 — Vectorless, sparse, hybrid : la revanche des mots-clés

Avant les embeddings, la recherche documentaire classique utilisait des méthodes dites sparse (creuses), basées sur les mots eux-mêmes. En 2024-2026, ces méthodes reviennent en force, seules ou combinées avec le dense.

BM25 : le bon vieux score de pertinence par mots-clés

BM25 (pour Best Matching 25, inventé dans les années 1990 par Robertson et Zaragoza) est une formule de pertinence qui ordonne les documents selon la correspondance mot-à-mot avec la requête. C’est la technique derrière la barre de recherche d’Elasticsearch, de Lucene, de la plupart des moteurs de recherche classiques.

En clair : BM25 pose trois questions à chaque document.

1. Les mots de la requête apparaissent-ils dans le document ? (term frequency, TF)
2. Ces mots sont-ils rares dans l’ensemble du corpus ? (inverse document frequency, IDF — un mot rare qui matche vaut plus qu’un mot banal)
3. Le document est-il de taille raisonnable pour ce nombre de matches ? (length normalization — un document très long qui matche 3 fois n’est pas plus pertinent qu’un document court qui matche 3 fois) La réponse combinée donne un score, on trie, on retourne le top-k.

BM25 est stupide au sens où il ignore la sémantique : « chat » et « félin » sont deux mots différents pour lui. Mais il est robuste, rapide, sans entraînement, sans dérive, et explicable (on voit exactement quels termes ont contribué au match).

Encadré pédagogique — « Sur TREC Robust04, aucun reranker neural n’améliore le MAP de plus de 0,05 sur BM25 » : qu’est-ce que ça veut dire ?

Pour évaluer objectivement des systèmes de recherche, la communauté IR (information retrieval) utilise des corpus de benchmark : un ensemble figé de documents, une liste de requêtes, et des jugements humains qui indiquent quels documents sont pertinents pour quelle requête.

• TREC Robust04 (Text REtrieval Conference, édition Robust 2004) est l’un des plus anciens : 528 155 articles de presse, 250 requêtes, des milliers d’appariements humains « requête-document pertinent ». C’est un standard public pour comparer les systèmes.
• MAP (Mean Average Precision) est la métrique principale. Pour une requête donnée, la Average Precision mesure à quelles positions dans la liste ordonnée apparaissent les documents réellement pertinents : si les documents pertinents sont en tête, le score est proche de 1 ; s’ils sont dispersés loin, le score s’effondre. On fait la moyenne sur toutes les requêtes, d’où le « Mean ». MAP = 0,3 est typique ; MAP = 0,5 est excellent.
• Une baseline est un système de référence auquel on compare toute nouvelle technique. BM25 est la baseline historique de la recherche textuelle depuis 30 ans.

Traduction : dans une étude comparant 443 systèmes sur TREC Robust04 (Chatterjee 2026), aucun reranker neural (même les plus sophistiqués) n’a amélioré le MAP de plus de 0,05 point par rapport à BM25 en évaluation open-world. Autrement dit : les gains annoncés par les techniques modernes sont souvent inférieurs à 5 % sur la métrique principale, comparés à un système des années 1990. BM25 n’est pas un vestige à remplacer, c’est une référence compétitive.

En pratique 2026, le pipeline BM25 + cross-encoder reranker reste une ligne de base forte et souvent compétitive avec des architectures beaucoup plus lourdes.

SPLADE : quand le sparse apprend la sémantique

SPLADE (SParse Lexical AnD Expansion, Formal et al., Naver Labs, 2021) est un pont entre BM25 et les embeddings denses. Le modèle, entraîné sur BERT, encode chaque texte en un vecteur creux sur le vocabulaire du tokenizer : typiquement 30 000 dimensions, dont 50 à 200 valeurs non-nulles seulement.

Comment l’interpréter : pour un document sur les chats, SPLADE active non seulement les dimensions « chat » et « félin » présentes dans le texte, mais aussi « miaou », « moustache », « chaton » — des termes sémantiquement reliés. Résultat : on conserve l’efficacité des index inversés (la structure classique des moteurs de recherche, qui permet de retrouver tous les documents contenant un terme donné en microsecondes) tout en captant une part de la sémantique.

Variantes 2025-2026 : ESPLADE (vocabulaire étendu), SPLADE-Doc (version productionisée), Sparton (kernel GPU optimisé via Triton).

ColBERT : un vecteur par token

ColBERT (Contextualized Late Interaction over BERT, Khattab & Zaharia, 2020) prend une troisième voie : au lieu d’un seul vecteur par document, ColBERT encode chaque token en un vecteur. Pour scorer une paire question-document, on calcule la similarité de chaque token de la question avec le meilleur token correspondant du document, puis on somme. Cette opération s’appelle MaxSim (late interaction), d’où le « L » du nom.

En clair : un embedding dense classique écrase tout le document en un seul point ; ColBERT garde un nuage de points (un par token). Le nuage est plus fin mais prend plus de place à stocker.

ColBERTv2 (2022) ajoute de la compression pour rendre l’approche viable en production. ColPali (Faysse et al. 2024) étend ColBERT aux images de pages PDF, permettant le retrieval sur des documents visuels sans étape d’OCR.

Limite 2026 (Ghosh et al.) : ColBERT dégrade fortement (chute de 86 à 97 %) sur les requêtes longues narratives au-delà de ~20 mots, à cause du plafonnement intrinsèque de MaxSim.

Hybrid search : combiner les deux mondes

La découverte pratique des années 2023-2025 : BM25 et dense se complètent. BM25 capte les correspondances exactes (noms propres, identifiants, termes techniques précis) ; les embeddings denses captent la sémantique et les paraphrases. Faire les deux en parallèle et fusionner les résultats gagne sur chacune prise isolément.

La fusion la plus utilisée s’appelle RRF (Reciprocal Rank Fusion). Principe : pour chaque document, on regarde son rang dans chaque liste (par exemple rang 3 en BM25, rang 7 en dense) et on lui attribue un score 1/(k + rang) par liste, puis on additionne. Le k est une petite constante (typiquement 60) qui évite que le rang 1 écrase tout. Pas de poids à calibrer, robuste par défaut.

Exemple concret — RRF sur 3 documents

Document	Rang BM25	Rang dense	Score RRF (k=60)
A	1	15	1/61 + 1/75 ≈ 0,029
B	8	2	1/68 + 1/62 ≈ 0,031
C	3	3	1/63 + 1/63 ≈ 0,032

C, qui n’est premier nulle part mais bien placé partout, sort vainqueur. C’est exactement le genre de document que l’hybride cherche à remonter.

Résultat de référence 2026 : sur TREC-COVID (benchmark de 171 000 articles COVID), RRF(SPLADE + BGE) atteint nDCG@10 = 0,828, dépassant le dense seul (Prajapati 2026). En production, Elasticsearch 8.14+, Qdrant, Weaviate et Vespa proposent le hybrid nativement.

Vocabulaire — les autres métriques que vous croiserez

• nDCG@k (normalized Discounted Cumulative Gain) : comme MAP, mais pondère les rangs du top-k avec un logarithme. Privilégie les systèmes qui mettent les bons documents tout en haut. « @10 » = on ne regarde que les 10 premiers résultats.
• MRR (Mean Reciprocal Rank) : moyenne de 1/rang du premier document pertinent. Si le bon document est toujours en première position, MRR = 1.
• recall@k : proportion des documents vraiment pertinents qui apparaissent dans le top-k. Mesure la couverture, pas la précision.

Le cas du RAG vectorless complet

Certaines équipes poussent la logique jusqu’au bout : pas de vector database, pas d’embedding provider externe. Tout repose sur des claims structurés en Markdown, indexés par wikilinks et mots-clés, recherchés par grep lexical et similarité TF-IDF (version antérieure à BM25) en Python stdlib. Gain : pas de dépendance externe, pas de coût d’infrastructure, pas de réindexation, explicabilité totale. Coût : on rate les synonymes que les embeddings captent. Pertinent pour les bases de 1 000 à 10 000 documents à vocabulaire technique stable, avec un petit nombre d’opérateurs humains. Ne passe pas à l’échelle grand public.

Famille 3 — Approches émergentes (post-2024)

Les trois approches précédentes partagent la même structure : un retriever mécanique suivi d’un générateur. Les approches émergentes bousculent ce schéma en confiant au LLM lui-même une partie du raisonnement sur ce qu’il faut chercher, quand, et comment.

GraphRAG : construire un graphe de connaissances depuis le corpus

GraphRAG (Microsoft, Edge et al., avril 2024) remplace l’indexation par chunks par une étape préalable plus ambitieuse : parcourir le corpus, en extraire les entités (personnes, organisations, lieux, concepts) et les relations entre elles, puis construire un graphe de connaissances. Sur ce graphe, un algorithme de community detection (Leiden) regroupe les entités fortement connectées en communautés, et un LLM résume chaque communauté.

Deux modes d’usage :

• Local search : question factuelle ciblée → on identifie le sous-graphe pertinent → réponse.
• Global search : question holistique (« quelles sont les grandes tendances du corpus ? ») → on parcourt les résumés de communautés → synthèse.

GraphRAG brille sur les questions multi-hop (qui nécessitent de relier plusieurs informations dispersées) et les questions thématiques globales. Coût : la construction du graphe est lourde, chaque nouveau document nécessite une mise à jour. LightRAG (He et al., octobre 2024) offre une variante plus légère.

Paper 2026 (Fan et al., « Do We Still Need GraphRAG? ») : GraphRAG reste supérieur sur les requêtes multi-saut, mais l’écart se resserre avec des LLM plus capables qui savent recomposer depuis des chunks plats.

Self-RAG : le modèle décide lui-même quand chercher

Self-RAG (Asai et al., 2023) introduit un changement de paradigme : plutôt que d’appeler le retriever systématiquement, on fine-tune le LLM pour qu’il génère des reflection tokens (jetons de réflexion) pendant sa propre inférence :

• [Retrieve] : le modèle décide qu’il a besoin de chercher avant de répondre.
• [IsRel] : il juge si le passage récupéré est pertinent.
• [IsSup] : il juge si la réponse est bien supportée par le passage.
• [IsUse] : il juge si la réponse est utile in fine.

Avantage : on évite les retrievals inutiles sur les questions que le modèle connaît déjà, et on rend explicite le jugement de pertinence. Coût : il faut fine-tuner le modèle générateur, ce qui est lourd et spécifique.

CRAG (Corrective RAG, Shi et al., janvier 2024) propose une version plus légère : un évaluateur T5 classe les passages récupérés en {correct, ambigu, incorrect}, et déclenche une recherche web de secours si tout est incorrect.

Adaptive RAG : choisir la stratégie selon la requête

Adaptive RAG (Jeong et al., mars 2024) route chaque question vers une stratégie différente via un classificateur léger :

• Question simple (factuel direct) → pas de retrieval, réponse directe du LLM.
• Question mono-document → retrieval classique single-step.
• Question complexe multi-hop → retrieval itératif multi-step.

Le gain n’est pas sur la qualité de chaque type isolé, mais sur l’économie globale : on ne paie la complexité que là où elle apporte quelque chose.

Agentic RAG : un agent qui planifie ses recherches

Agentic RAG abandonne la séquence fixe « retrieve puis generate » au profit d’une boucle où un agent LLM décompose la question en sous-questions, lance plusieurs recherches successives, relit ses propres résultats intermédiaires, et décide dynamiquement quand il a assez d’information. C’est plus lent et plus cher par requête, mais traite des problèmes que les approches séquentielles ratent (investigation croisée, raisonnement en plusieurs étapes).

LangGraph et LlamaIndex sont les frameworks dominants en 2026. Extensions récentes : Doctor-RAG (Jiao et al., avril 2026) ajoute une couche de réparation failure-aware ; « Don’t Retrieve, Navigate » (Sun et al. 2026) propose un agent qui apprend la structure du corpus plutôt que de retriever passivement.

Autres variantes utiles à connaître

• LongRAG : chunks beaucoup plus gros (~6 000 tokens), pour exploiter les fenêtres de contexte étendues.
• RAPTOR : arbre hiérarchique de résumés récursifs — on indexe à la fois le niveau paragraphe, le niveau section, et le niveau document.
• HyDE (Hypothetical Document Embeddings) : au lieu d’embedder la question, on demande au LLM de produire une réponse hypothétique, puis on embedde cette réponse pour chercher les documents proches. Utile quand la question est courte et ambiguë.
• SAGE (Wang et al., 2026) : extraction sélective qui réduit de 60 % les tokens transmis au générateur, sans perdre en qualité de réponse.

Quelle famille choisir ?

Il n’y a pas de gagnant universel. Le choix dépend du corpus, du type de questions, et des contraintes opérationnelles.

Matrice de décision

Quelques règles heuristiques

• Commencer simple : un RAG vectoriel dense mature (embedder + Qdrant + reranker Voyage) couvre 80 % des cas. N’ajoutez de la sophistication que quand la métrique de succès stagne.
• Mesurer avant d’optimiser : sans un jeu d’évaluation (questions + réponses attendues), toute optimisation est à l’aveugle. RAGAS (framework open-source) automatise une partie du scoring.
• Hybrid par défaut en production : sauf corpus minuscule, le gain du hybrid sur le dense seul est documenté et le surcoût est modeste.
• GraphRAG et Agentic coûtent cher : à réserver aux cas où les approches plates échouent clairement.

Ce qu’on retient en 2026

Le RAG n’est plus une technique, c’est une famille. Plusieurs architectures coexistent et le choix est guidé par le profil du corpus et des questions, pas par une hiérarchie universelle. Le long contexte n’a pas éliminé le RAG : il a absorbé les petits corpus stables et laissé au RAG les gros, les dynamiques, et ceux qui exigent de citer leurs sources. BM25 reste une baseline compétitive trente ans après son invention — il est redevenu élégant de le combiner avec le dense plutôt que de vouloir le remplacer. Enfin, les approches émergentes (GraphRAG, Self-RAG, Agentic) ne s’imposent pas comme remplaçantes : elles s’ajoutent dans la boîte à outils pour les problèmes que le pipeline séquentiel classique ne résout pas.

Pour aller plus loin

• Article fine-tuning-vs-rag : quand choisir l’un ou l’autre, et pourquoi les deux sont complémentaires.
• Article rag : introduction pas-à-pas au pipeline le plus simple.
• Article context-engineering : ce qui se passe avant le retrieval (sélection, compression, ordonnancement du contexte).
• Article agentic-ai : les boucles d’agent qui sous-tendent l’Agentic RAG.