État de l'art du RAG en 2026 :
du naive chunking au GraphRAG agentique

01 — Pourquoi le RAG ?

Les modèles de langage ont une propriété fondamentalement limitante : leur connaissance est figée à la date de leur entraînement. Mistral 7B entraîné en 2023 ignore ce qui s'est passé depuis. Mais surtout, il ignore tout de vos données internes — vos contrats, vos procédures, vos bases de connaissance métier. Même le meilleur modèle du monde est aveugle à ce qu'il n'a pas vu.

Deux solutions s'offrent alors. Le fine-tuning consiste à ré-entraîner le modèle sur vos données. Coûteux, complexe, et inadapté aux données qui changent souvent. Le RAG (Retrieval-Augmented Generation) adopte une approche différente : au lieu d'enseigner au modèle, on lui donne les documents pertinents au moment de la question. Le modèle lit, synthétise, répond.

L'avantage du RAG est sa fraîcheur : on met à jour la base documentaire, pas le modèle. Et sa traçabilité : chaque réponse peut être sourcée vers le document précis dont elle est extraite. Enfin, son coût : il est sans commune mesure avec un fine-tuning pour des cas d'usage documentaires.

02 — Architecture d'un RAG naïf

Un système RAG se décompose en deux grandes phases : une phase offline d'ingestion et d'indexation des documents, et une phase online de récupération et de génération à la demande.

Ce pipeline paraît simple. Il l'est, jusqu'à ce qu'on l'expose à des données réelles. C'est là que commencent les vrais problèmes — et les vraies optimisations.

03 — Le problème du chunking

Le chunking est l'étape la plus sous-estimée du RAG. Mal fait, il ruine le reste du pipeline, quel que soit la qualité du modèle ou de l'index. Un chunk trop grand noie l'information pertinente dans du bruit. Un chunk trop petit perd le contexte nécessaire à la compréhension.

Fixed-size chunking — le piège du débutant

La stratégie naïve : couper tous les 512 tokens. Simple à implémenter, catastrophique en pratique. Une phrase peut être coupée en plein milieu, un tableau peut être fragmenté de façon incohérente, une définition peut être séparée de l'entité qu'elle décrit.

Recursive character splitting

L'approche de LangChain par défaut. On coupe d'abord sur les sauts de paragraphe (\n\n), puis sur les sauts de ligne, puis sur les phrases, puis sur les mots — en respectant toujours la taille maximale. Meilleur que le fixed-size, mais encore aveugle à la sémantique.

Semantic chunking — l'état de l'art

On encode chaque phrase, puis on compare les embeddings de phrases consécutives. Quand la similarité chute (changement de sujet), on coupe. Cette approche préserve la cohérence thématique des chunks. Le coût est plus élevé (il faut embedder pendant le chunking), mais la qualité de retrieval s'améliore significativement.

04 — Embeddings & index vectoriel

Un embedding est une représentation numérique d'un texte — un vecteur de 768 à 4096 dimensions selon le modèle. Des textes sémantiquement proches ont des vecteurs proches dans l'espace vectoriel, mesurés par la similarité cosine. C'est ce principe qui permet au retrieval de trouver des chunks pertinents même si les mots exacts de la question ne sont pas dans le document.

Choisir son index vectoriel

L'index vectoriel stocke les embeddings et répond aux requêtes de similarité. Trois choix dominants en 2026 :

Qdrant est notre recommandation par défaut pour les projets nouveaux. Rust natif, performant, filtrage payload puissant, déploiement Docker simple. pgvector s'intègre dans votre PostgreSQL existant — excellent si vous voulez limiter les dépendances. Weaviate offre des fonctionnalités avancées (multi-tenancy, modules intégrés) mais a une courbe d'apprentissage plus raide.

05 — Hybrid Search : le vrai game changer

Le retrieval dense (embeddings) excelle sur les questions de sens général — mais échoue sur les recherches exactes. Si un utilisateur cherche « rapport Q3-2025-EMEA-v2.3 », l'embedding ne retrouvera pas ce document aussi bien qu'une recherche BM25 sur le nom exact. C'est le problème du lexical gap.

BM25 (Best Match 25) est un algorithme de recherche full-text probabiliste, héritier de TF-IDF. Il excelle sur les requêtes exactes, les noms propres, les codes et références. Il échoue sur les questions sémantiques où les mots de la requête ne sont pas dans le document.

La solution : fusionner les deux via Reciprocal Rank Fusion (RRF). Chaque résultat reçoit un score combiné basé sur sa position dans les deux classements. Le résultat est un ranking hybride qui capture à la fois la pertinence sémantique et la correspondance lexicale.

06 — Reranking & Query Rewriting

Le retrieval hybride retourne les k chunks les plus probables — mais "les plus proches dans l'espace vectoriel" n'est pas la même chose que "les plus utiles pour répondre". Le reranking est une seconde passe de scoring, plus précise mais plus coûteuse.

Cross-encoder vs Bi-encoder

Les embeddings utilisent un bi-encoder : la question et chaque document sont encodés séparément, puis comparés. C'est rapide, mais cela capture mal les interactions fines entre question et document. Un cross-encoder prend la paire (question, document) en entrée et produit un score de pertinence — bien plus précis, mais impossible à pré-calculer sur un large corpus. D'où l'usage en deux étapes : bi-encoder pour retriever 50-100 candidats, cross-encoder pour les re-ordonner et garder les 5-10 meilleurs.

Query Rewriting : reformuler avant de chercher

Une question utilisateur est souvent ambiguë, mal formulée, ou rédigée dans un style différent de la base documentaire. Le query rewriting fait réécrire la question par un LLM avant de lancer la recherche — en plusieurs variantes parallèles (multi-query), ou sous forme de document hypothétique (HyDE : Hypothetical Document Embeddings).

07 — GraphRAG & RAG agentique

Le RAG naïf souffre d'une limite fondamentale : il répond à des questions locales. « Quel est le CA de la filiale Bordeaux ? » — parfait. Mais « Quelle est la relation entre la performance de Bordeaux et la politique tarifaire de Lyon ? » — là, le RAG naïf retourne des chunks épars qui ne se parlent pas.

GraphRAG : raisonner sur les relations

Développé par Microsoft Research (2024), GraphRAG construit un graphe de connaissances à partir du corpus : entités (personnes, lieux, produits, événements) et relations entre elles. À la requête, au lieu de chercher des chunks similaires, on traverse le graphe pour trouver des chemins de sens qui relient les entités pertinentes.

RAG agentique : le retrieval comme outil

Dans un RAG agentique, le modèle décide lui-même quand et comment retriever. Plutôt qu'un pipeline fixe question → retrieval → génération, l'agent peut : lancer plusieurs requêtes de recherche successives, affiner en fonction des résultats intermédiaires, combiner des sources différentes, ou décider qu'il a assez de contexte et répondre directement.

08 — Évaluation avec RAGAS

Sans évaluation rigoureuse, le RAG est une boîte noire. On ne sait pas si les optimisations améliorent vraiment les choses ou si on déplace le problème. RAGAS (Retrieval Augmented Generation Assessment) est le framework de facto pour évaluer les systèmes RAG selon 4 dimensions orthogonales.

Construire un jeu d'évaluation

Le piège classique : évaluer sur des questions générées automatiquement par le LLM depuis les mêmes documents. C'est circulaire. Un bon jeu d'évaluation contient 50 à 200 questions réelles, posées par de vrais utilisateurs métier, avec les réponses de référence validées par des experts du domaine.

Une fois ce jeu en place, chaque modification du pipeline (chunking, embedding, retrieval, prompt) peut être comparée quantitativement. C'est le seul moyen de savoir si une optimisation aide vraiment.