Segmentation, reclassement et recherche hybride : rendre le RAG réellement efficace

La plupart des systèmes RAG fonctionnent mal. Le modèle n’est pas en cause : Claude ou GPT-5 savent répondre à partir des documents récupérés. C’est la récupération qui échoue. Le système renvoie les mauvais passages et le modèle produit avec assurance une réponse fondée sur des informations inadaptées.

Cet article explique concrètement comment corriger les trois causes d’une mauvaise récupération : stratégie de segmentation, reclassement et recherche hybride. Si vous maîtrisez ces trois aspects, la plupart des plaintes du type « le RAG ne fonctionne pas pour notre cas d’utilisation » disparaissent.

Nous passerons outre les mathématiques techniques profondes et nous concentrerons sur ce que vous devez faire concrètement.

Pourquoi la récupération échoue

Le processus RAG par défaut :

1. Diviser les documents en segments.
2. Créer un plongement vectoriel pour chaque segment.
3. À la réception d’une question, créer son plongement vectoriel et rechercher les segments les plus similaires par similarité cosinus.
4. Transmettre ces segments au grand modèle de langage.

Chaque étape a des modes d’échec :

Une mauvaise segmentation produit des passages trop courts pour être utiles, trop longs pour rester cohérents ou coupés au milieu d’une idée, de sorte qu’aucune moitié n’est correctement récupérée.

Une similarité naïve trouve des morceaux qui partagent un vocabulaire avec la requête mais ne sont pas vraiment pertinents. La requête « comment annuler mon abonnement » pourrait récupérer tout morceau mentionnant « abonnement », y compris du contenu marketing non lié.

Sans reclassement, le grand modèle de langage voit directement les résultats de la recherche par similarité. Or le segment le plus similaire n’est pas toujours le plus pertinent.

Une recherche sémantique pure manque les correspondances exactes en mots-clés qui comptent. Une requête pour « code d’erreur 503 » pourrait manquer un morceau contenant exactement le texte « code d’erreur 503 » car le plongement vectoriel de la requête ne correspond pas au sujet global du morceau.

Les trois solutions — meilleure segmentation, reclassement et recherche hybride — répondent à ces problèmes.

Solution 1 : Une meilleure segmentation

La segmentation est la décision qui influe le plus sur un processus RAG, mais beaucoup ne s’en préoccupent qu’une fois les résultats dégradés.

La valeur par défaut naïve de nombreux outils sans code consiste à segmenter selon un nombre fixe de jetons — par exemple 500 jetons avec un chevauchement de 50. Cette approche fonctionne raisonnablement, mais échoue souvent.

Meilleures stratégies :

Segmentation sémantique

Diviser les documents aux limites sémantiques — des endroits où le sujet change — plutôt qu’aux limites arbitraires de tokens. La plupart des cadres modernes (LangChain, LlamaIndex) ont des découpeurs sémantiques qui détectent les changements de sujet et les divisent là.

L’avantage : les morceaux contiennent des idées complètes. Le modèle reçoit un contexte cohérent au lieu de moitiés d’arguments.

Segmentation tenant compte de la structure

Si vos documents ont une structure naturelle (en-têtes Markdown, sections HTML, chapitres PDF, limites de fonctions de code), utilisez-la. Découpez par section, pas par token.

Pour Markdown :

• Chaque section H2 est un morceau (avec l’en-tête H1 préfixé).
• Les sections H2 longues sont sous-découpées, avec l’en-tête H2 répétée comme contexte.

Pour le code :

• Chaque fonction ou classe est un morceau.
• Le morceau inclut le chemin du fichier et toute importation.

Cela est nettement meilleur que le découpage fixe aveugle pour tout contenu structuré.

Segmentation hiérarchique

Un modèle provenant de recherches récentes sur RAG. Créez des morceaux à plusieurs niveaux :

• Morceaux petits (200-500 tokens) pour une récupération précise.
• Morceaux moyens (1000-2000 tokens) pour le contexte.
• Résumés de documents (50-100 tokens) pour un correspondance au niveau supérieur.

Lors de la récupération, correspondre aux morceaux petits mais renvoyer le morceau moyen entourant. Le LLM obtient une pertinence précise ainsi qu’assez de contexte pour en faire sens.

Choisir la taille des segments

Une heuristique approximative par type de contenu :

Si vous utilisez un outil sans code qui cache le découpage, faites un test : posez 10 questions dont vous savez que les réponses sont dans le corpus. Si la récupération manque régulièrement le bon morceau, le découpage est votre problème.

Un modèle qui fonctionne bien : “page ou section, puis question-orienté”

Pour la plupart des cas d’utilisation personnels RAG, le modèle qui fonctionne :

1. Découper par section de document (en-tête H2 Markdown, chapitre PDF, etc.).
2. Pour les morceaux de plus de ~2000 tokens, sous-découper par paragraphe.
3. Préfixer chaque morceau avec le titre du document et l’en-tête de la section comme contexte.
4. Ajouter une brève description de quel type de questions ce morceau répond (générée automatiquement par un LLM rapide lors de l’indexation).

Le truc de générer automatiquement « quelles questions ce morceau répond » est sous-utilisé et pourtant puissant. Il fonctionne car les requêtes utilisateur sont souvent formulées comme des questions, et correspondre à la métadonnée en forme de question est plus précis que correspondre au texte brut du document.

Solution 2 : Reclassement

Après la récupération initiale (généralement renvoyant 20-50 morceaux basés sur la similarité vectorielle), utilisez un rerank pour les réordonner par pertinence réelle à la requête.

Le modèle de reclassement est distinct, généralement plus petit et spécialisé. Il reçoit des paires composées d’une requête et d’un segment, puis renvoie un score de pertinence. Appliquez-le aux 20 à 50 premiers résultats, triez-les selon ce nouveau score et transmettez les 3 à 5 meilleurs au grand modèle de langage.

L’avantage est une précision nettement supérieure. La similarité vectorielle est rapide mais approximative ; les modèles de reclassement sont plus lents, mais beaucoup plus précis. Leur combinaison offre une récupération rapide et un ordre pertinent.

Options de rerank en 2026 :

• Cohere Rerank — le rerank API basé établi. 2,00 $ par 1 000 recherches (prix listé, vérifié le 10 juillet 2026).
• Voyage AI rerank-2 — option commerciale performante, souvent meilleure que Cohere dans les domaines spécialisés.
• bge-reranker-v2-m3 — modèle à poids ouverts, exécutable localement ou sur un hébergement peu coûteux.
• Jina Reranker — autre option performante à poids ouverts.

Dans un pipeline typique :

1. La recherche vectorielle renvoie les 50 morceaux les plus élevés (bon marché, rapide).
2. Le rerank évalue tous les 50 par rapport à la requête (plus coûteux, plus lent).
3. Les 5 premiers par score de rerank sont transmis au LLM.

Latence totale ajoutée : ~200-500 ms. Amélioration de qualité : souvent 20-40 % sur les benchmarks de précision de récupération.

Pour les outils sans code qui ne comprennent pas le rerank par défaut (NotebookLM, la plupart des configurations de base n8n), c’est l’amélioration la plus impactante que vous pouvez faire. n8n a un nœud Cohere Rerank ; LangChain et LlamaIndex incluent des intégrations de rerank nativement.

Solution 3 : Recherche hybride

La similarité vectorielle capture les correspondances sémantiques. La recherche par mots-clés (BM25 ou similaire) capture les correspondances exactes. Chacun manque ce que l’autre capture.

Une requête pour « comment réparer les erreurs HTTP 503 sur notre passerelle » :

• La recherche vectorielle trouve des morceaux sur les erreurs HTTP, les problèmes de passerelle, la résolution des problèmes.
• La recherche par mots-clés trouve des morceaux qui mentionnent spécifiquement « 503 » — ce qui pourrait être la réponse réelle.

La recherche hybride exécute les deux et combine les résultats. La combinaison utilise une méthode appelée Reciprocal Rank Fusion (RRF) — étant donné les classements de chaque méthode, RRF produit un classement combiné qui prend en compte les deux signaux.

L’implémentation dans la plupart des outils est simple :

• Exécuter la recherche vectorielle → obtenir la liste A classée.
• Exécuter BM25 / recherche par mots-clés → obtenir la liste B classée.
• Pour chaque morceau, calculer son score RRF = 1/(k + rang_A) + 1/(k + rang_B) (avec k généralement 60).
• Trier par score combiné, renvoyer les résultats les plus élevés.

En 2026, la recherche hybride est prise en charge nativement par :

• Weaviate (base vectorielle) — recherche hybride intégrée.
• Qdrant — recherche hybride via le filtrage.
• Pinecone — recherche hybride via les vecteurs rares.
• Elastic / OpenSearch — recherche combinée mots-clés + vectorielle.
• La plupart des modèles RAG n8n — la recherche hybride est la norme par défaut dans les modèles modernes.

L’avantage : une rappel nettement meilleur sur les requêtes contenant des identifiants spécifiques, des codes, des noms ou du jargon. Pour le contenu technique (code, codes d’erreur, noms de produits, références réglementaires), la recherche hybride est essentiellement requise.

Pour votre cas d’utilisation : si vos requêtes contiennent souvent des termes spécifiques qui devraient correspondre exactement (nombres, noms, codes, phrases exactes), activez la recherche hybride. Le coût est faible et le gain est important.

Les mettre ensemble

Le processus RAG de pointe en 2026 :

Query
  ↓
Query rewriter (optional — clean up the query, expand abbreviations)
  ↓
Hybrid retrieval: vector + keyword search
  ↓
Top 30-50 results
  ↓
Reranker
  ↓
Top 5 by reranker score
  ↓
LLM with retrieved chunks + query
  ↓
Cited answer

Chaque étape est peu coûteuse individuellement. Ensemble, elles produisent une qualité de récupération qualitativement différente de « similarité vectorielle → top 5 → LLM ».

Quelques ajouts moins courants mais puissants :

Expansion de la requête. Réécrire la requête utilisateur en plusieurs variantes et effectuer une recherche pour chacune. Capte différentes formulations.

Recherche multi-étapes. Pour les questions complexes, effectuer plusieurs récupérations. La première récupération identifie les sous-questions ; la deuxième récupération récupère les réponses à chaque sous-question.

Recherche conversationnelle. Dans une conversation multi-tours, utiliser l’historique de la conversation pour guider la récupération (« ils ont demandé à propos de X plus tôt, donc pour cette question, priorisez le contenu lié à X »).

Filtrage par source. Utiliser des filtres de métadonnées pour limiter la récupération. « Ne recherchez que les documents étiquetés « réglementations européennes » et datés après 2023 ».

Ces fonctionnalités deviennent de plus en plus disponibles dans les outils RAG sans code, mais vérifiez toujours si vous obtenez les trois fondamentaux (bon découpage, rerank, recherche hybride) avant de vous tourner vers les avancées.

Comment mesurer la qualité RAG

Vous ne pouvez pas améliorer ce que vous ne mesurez pas. Quelques stratégies d’évaluation pratiques :

Le test des « questions dorées ». Choisissez 20 questions dont vous connaissez les réponses correctes. Exécutez-les via votre RAG. Notez : les bons morceaux ont-ils été récupérés ? Le modèle a-t-il produit la bonne réponse ? Faites-le mensuellement.

Rappel de récupération à K. Pour chaque question dorée, identifiez les morceaux contenant la réponse. Puis vérifiez : le système de récupération a-t-il renvoyé l’un de ces morceaux parmi les K premiers (5, 10, 20) ? Mesurez la fraction.

Évaluation LLM comme juge. Une version plus avancée : faites évaluer par un modèle fort (Claude Opus, GPT-5) si la réponse est correcte, précise, complète et bien ancrée. Exécutez sur un lot de questions représentatives. Nous avons un article entier sur les évaluations.

Qualité perçue par l’utilisateur. Pour les RAG d’équipe ou de production, ajoutez un « pouce vers le haut / pouce vers le bas » à chaque réponse. Examinez les tendances des « pouces vers le bas ». Elles se regroupent autour de types spécifiques de questions — corrigez-les.

La plus grande erreur est de ne pas mesurer du tout. « Ça semble bien » n’est pas une mesure. Vous ne saurez pas si vos améliorations fonctionnent sans cela.

Un exemple concret : améliorer un RAG défaillant

Supposons que vous ayez construit un RAG personnel pour la documentation interne de votre entreprise. La qualité est médiocre — environ 60 % des questions obtiennent une réponse utile. Les améliorations que vous appliqueriez, dans l’ordre :

Auditez d’abord la récupération. Pour dix des réponses de mauvaise qualité, examinez les morceaux récupérés. Le bon morceau a-t-il été récupéré ? Si oui, le problème est avec le modèle ou le prompt. Si non, le problème est la récupération.

Si la récupération est le problème :

1. Vérifiez le découpage. Les morceaux sont-ils cohérents ? Votre découpeur coupe-t-il au milieu d’idées importantes ? Passez à un découpage sémantique ou conscient de la structure.

2. Ajoutez un rerank. Si vous utilisez une recherche vectorielle basique et les 5 premiers résultats, ajoutez Cohere Rerank ou bge-reranker-v2-m3 entre la récupération et le LLM. L’amélioration est généralement visible immédiatement — mesurez-la sur votre propre ensemble d’évaluation plutôt que de faire confiance à un pourcentage universel.

3. Ajoutez une recherche hybride. En particulier si vos requêtes contiennent des termes spécifiques (noms de produits, codes d’erreur, jargon).

4. Examinez votre indexation. Les morceaux sont-ils étiquetés avec des métadonnées (type de document, section, date) ? Utilisez des filtres de métadonnées dans la récupération.

Si le problème est le modèle (bon morceau récupéré, mauvaise réponse) :

1. Resserrez le prompt. Dites explicitement au modèle : « répondez uniquement sur la base du contexte fourni. Si le contexte ne couvre pas la question, dites-le. »

2. Ajoutez des citations. Exigez que le modèle cite le morceau spécifique utilisé. Cela vous aide à déboguer et réduit les hallucinations.

3. Utilisez un modèle plus fort. Si vous utilisez un petit modèle rapide, essayez Claude Sonnet 4.5 ou GPT-5.

Après deux ou trois tours de ce type d’investigation et de correction, la plupart des implémentations RAG atteignent un taux de réponse utile de 85 à 90 %, seuil où les utilisateurs adoptent et font confiance au système.

Erreurs courantes

Voici quelques erreurs fréquentes :

Indexer le mauvais contenu. Pages de marketing, documents obsolètes, contenu de blog de faible qualité. Le modèle ne peut pas distinguer ; tout dans l’index est traité comme canon. Triez sans pitié.

Oublier de mettre à jour l’index lorsque les documents changent. Un RAG avec du contenu obsolète donne des réponses confiantes mais erronées. Réindexez régulièrement ou utilisez un système qui synchronise automatiquement.

Ignorer l’évaluation. La plupart des RAG sont déployés sans mesure et ne sont jamais améliorés. La phase « ça semble bien » dure éternellement. Intégrez l’évaluation dès le début.

Traiter la récupération comme une boîte noire. « Ça ne fonctionne pas » n’est pas un diagnostic. Ouvrez la récupération et examinez ce qui revient. Presque toujours, le problème devient évident une fois que vous le voyez.

Complexifier trop tôt. Inutile de commencer par un processus de pointe. Utilisez d’abord NotebookLM ou une recherche vectorielle simple, puis ajoutez de la complexité uniquement après avoir identifié un goulet d’étranglement précis.

Quand cela compte

Les trois solutions — meilleur découpage, reranking, recherche hybride — comptent le plus lorsque :

• Le corpus est technique, avec un vocabulaire spécifique.
• Les requêtes contiennent des exigences de correspondance exacte (codes, noms, ID).
• Les utilisateurs tiennent à la précision (juridique, conformité, support client).
• Le système est utilisé à grande échelle (un petit gain de qualité compte beaucoup lorsqu’il est atteint 10 000 fois par jour).

Ils comptent moins lorsque :

• Le corpus est petit (moins de 100 documents) et bien organisé.
• Les requêtes sont ouvertes (« quelle est notre position sur X »).
• Les utilisateurs sont indulgents et itèrent pour trouver la réponse.
• L’utilisation est exploratoire plutôt que précise.

Pour la plupart des RAG personnels et des petites équipes, simplement passer de la similarité vectorielle de base à la similarité vectorielle + rerank est l’amélioration la plus rentable. La recherche hybride est l’ajout suivant. Le découpage compte à toutes les échelles.

Le point clé

Un mauvais RAG vient presque toujours d’une mauvaise récupération, elle-même généralement liée à trois facteurs : segmentation, reclassement et méthode de recherche. Corrigez-les et la plupart des plaintes relatives à la qualité du RAG disparaissent.

Vous n’avez pas besoin d’être un ingénieur de recherche pour les appliquer. Les outils — Weaviate, Pinecone, Qdrant, modèles n8n, intégrations LangChain — ont rendu les techniques accessibles. Le goulot d’étranglement maintenant est principalement de savoir qu’ils existent et d’être délibéré dans leur application.

Si votre RAG ne fonctionne pas, ne blâmez pas le modèle. Examinez les morceaux renvoyés, corrigez la récupération, puis réévaluez.