RAG : arrêtez de chercher, commencez à classer

Pourquoi votre RAG devrait être une bibliothèque, pas un moteur de recherche

Le constat : la similarity search ne suffit pas

Vous avez un corpus, des embeddings, un vector store, un top-k à 5. Ça marche sur les démos. En production, ça casse.

Le problème n’est pas l’implémentation — c’est le paradigme. La similarity search repose sur une hypothèse implicite : le chunk le plus proche sémantiquement est le plus pertinent. C’est souvent faux.

Cinq échecs récurrents en production

Le point commun : on demande à un outil de similarité de faire un travail de compréhension structurelle. C’est comme demander à un correcteur orthographique de vérifier la logique d’un argument.

Les améliorations incrémentales : reranking et hybrid search

Deux techniques sont devenues des réflexes pour améliorer le retrieval. Elles aident — mais elles ne changent pas le paradigme.

Le reranking ajoute un cross-encoder après le top-k pour mieux trier les résultats. La precision s’améliore, parfois significativement. Mais le problème fondamental reste : si le bon chunk n’est pas dans le lot remonté par la recherche initiale, aucun reranker ne le fera apparaître. On optimise le tri, pas la couverture.

La hybrid search combine recherche lexicale (BM25/keywords) et recherche vectorielle. Le gain est réel — environ 20% d’amélioration du recall dans les benchmarks courants. Mais on reste dans le même paradigme : flat search → tri → espérer que le bon chunk est dans le lot. C’est un quick win, pas un changement d’architecture.

Ces deux techniques sont utiles. Elles devraient être le minimum. Mais les traiter comme la solution finale, c’est comme ajouter un meilleur moteur à une voiture dont le problème est la direction.

L’analogie : bibliothèque vs moteur de recherche

Pour comprendre le changement nécessaire, prenons une analogie simple.

Un moteur de recherche, c’est : tu tapes des mots, tu reçois des résultats “proches”. Pas de structure, pas de navigation, pas de contexte. C’est du matching statistique.

Une bibliothèque, c’est : un index, des catégories, des rayons, des fiches, des cotes Dewey, des renvois entre sujets. Le bibliothécaire ne cherche pas par similarité — il navigue dans une structure organisée. Il sait que la stimulation vestibulaire est au rayon neurosciences, sous-catégorie neurophysiologie, et que les publications récentes sont classées par date.

Le RAG actuel, c’est quelqu’un qui entre dans une bibliothèque, ignore les rayons et les index, et feuillette les livres au hasard en cherchant des phrases qui “ressemblent” à sa question.

Le changement de paradigme tient en une phrase : passer de “chercher le plus proche” à “naviguer vers le plus pertinent”.

La donnée n’est pas un tas de vecteurs — c’est un corpus organisable. La structure coûte à construire. Mais elle rend le retrieval fiable, explicable, et auditable.

De quoi a-t-on réellement besoin ?

Avant de choisir un outil ou un framework, il faut poser les besoins. Six capacités définissent un retrieval robuste.

Le besoin #6 mérite qu’on s’y arrête. En production, le coût par requête et la qualité de réponse dépendent directement du volume de tokens envoyés au LLM. La récupération progressive — récupérer d’abord une fiche, évaluer la pertinence, puis aller chercher le détail — ce n’est pas un nice-to-have. C’est ce qui rend le système viable. Le bibliothécaire ne te donne pas 15 livres entiers. Il te donne une fiche. Tu décides si tu veux le livre.

Le fil rouge : un corpus de publications scientifiques

Pour rendre ces besoins concrets, prenons un scénario réaliste : un corpus de 500 publications scientifiques sur la stimulation vestibulaire galvanique (GVS), couvrant neurophysiologie, applications cliniques, et réalité virtuelle.

Voici les questions que des chercheurs posent réellement — et pourquoi le flat search échoue sur chacune :

Chaque solution de la section suivante sera illustrée par sa capacité à répondre à l’une de ces questions.

Les solutions documentées

Quatre approches, chacune ciblant des besoins différents. Aucune n’est universelle — le choix dépend de la complexité réelle des requêtes.

Hierarchical Indexing — l’index à niveaux

Le principe est simple : organiser le corpus en niveaux, comme une table des matières. Résumés de documents → sections → chunks détaillés. Le retrieval navigue du général au spécifique.

Sur notre fil rouge, quand un chercheur demande un aperçu puis les détails de la méthode, le système retourne d’abord le résumé du document (niveau macro), évalue la pertinence, puis descend au chunk “méthode” (niveau micro). Pas de gaspillage de tokens, pas de bruit.

Besoins couverts : #1 Navigation par abstraction, #6 Récupération progressive.

Le trade-off est frontal : la hiérarchie doit être construite en amont, et elle doit refléter la structure réelle du contenu. Un mauvais découpage hiérarchique produit des résultats pires que du flat search.

RAPTOR — l’arbre récursif de résumés

RAPTOR pousse l’idée plus loin. Au lieu d’une hiérarchie imposée, il construit un arbre bottom-up : les chunks sont clusterisés, chaque cluster est résumé par un LLM, les résumés sont eux-mêmes clusterisés et résumés, et ainsi de suite. Le résultat est un arbre navigable où chaque nœud offre un niveau d’abstraction différent.

Sur notre corpus GVS, la question “Quels sont les grands thèmes de recherche ?” trouve sa réponse dans les nœuds supérieurs de l’arbre — là où les résumés capturent les macro-tendances du corpus sans qu’aucun chunk individuel n’ait besoin de contenir cette information.

Besoins couverts : #1 Navigation par abstraction, #4 Questions globales, #6 Récupération progressive.

Le coût est significatif : clustering + summarization par LLM à chaque niveau. La qualité dépend directement de la qualité des résumés générés. Un mauvais résumé au niveau intermédiaire pollue tout ce qui est au-dessus.

GraphRAG — knowledge graph + communautés

GraphRAG change de représentation. Au lieu de traiter le corpus comme une collection de chunks, il en extrait des entités et des relations pour construire un knowledge graph. Puis il applique un clustering hiérarchique (algorithme de Leiden) pour identifier des communautés d’entités et génère des résumés par communauté.

C’est la solution qui répond le mieux aux questions multi-hop. “Résume les travaux du labo de Fitzpatrick sur le GVS postural” nécessite de traverser un graphe : Fitzpatrick → University of New South Wales → publications → filtrer par GVS postural. Aucune recherche vectorielle ne peut faire ce parcours — un graph traversal le fait nativement.

Besoins couverts : #3 Relations entre entités, #4 Questions globales, #1 Navigation par abstraction.

Le trade-off est lourd : coût d’indexation élevé (extraction d’entités par LLM sur tout le corpus), complexité de maintenance, et — point souvent ignoré — GraphRAG peut sous-performer le vanilla RAG sur des questions simples et factuelles. Le overhead n’est justifié que si les requêtes sont réellement complexes.

Agentic RAG — l’agent-bibliothécaire

L’Agentic RAG ne propose pas une nouvelle structure de données — il ajoute une couche de décision. Un agent analyse la question, détermine la stratégie de recherche optimale, et orchestre les outils disponibles : vector search, filtres metadata, SQL, graph traversal, ou une combinaison.

C’est le bibliothécaire. Face à “Quelles publications post-2022 traitent du GVS en VR ?”, il ne lance pas un vector search brut — il applique d’abord un filtre temporel (date > 2022), puis un filtre thématique (domaine = VR), puis une recherche sémantique dans le sous-ensemble filtré.

Besoins couverts : #5 Stratégie adaptative — et potentiellement tous les autres, par orchestration.

Le trade-off : complexité d’implémentation, latence multi-step, et dépendance critique à la qualité du routing. Si l’agent choisit mal sa stratégie, le résultat est pire qu’un simple top-k.

Comparatif des solutions

En pratique : le custom reste souvent le meilleur choix

Les frameworks couvrent des patterns génériques

RAPTOR, GraphRAG, LlamaIndex proposent des architectures prêtes à l’emploi. Elles sont bien documentées, testées, et fournissent un bon point de départ. Mais chaque domaine a sa propre structure de connaissance. La hiérarchie d’un corpus médical n’a rien à voir avec celle d’une base réglementaire ou d’un support client.

La synthèse décisionnelle

Comment choisir entre ces approches ? Voici une matrice de décision basée sur la nature de votre corpus et de vos requêtes.

Construire sa propre couche

Le vrai travail, ce n’est pas le choix de l’outil — c’est le design de l’index. Comprendre la structure du domaine, identifier les relations clés, déterminer les niveaux d’abstraction pertinents. Construire une couche de structuration adaptée donne souvent de meilleurs résultats qu’un framework clé en main appliqué tel quel.

L’avantage du custom : contrôle total sur le coût de récupération, la granularité, et la logique de navigation. L’inconvénient : il faut savoir ce qu’on fait, et être prêt à investir le temps de conception.

Conclusion

Ce qui change

Le passage de “j’embed tout et je cherche le top-k” à “je structure, j’indexe, je catégorise, et un agent navigue” n’est pas une optimisation — c’est un changement de paradigme. La donnée structurée n’est pas un overhead. C’est un investissement. La récupération progressive n’est pas un nice-to-have. C’est ce qui rend le système viable en production.

La question à se poser

Comment un expert humain chercherait dans ce corpus ?

Si la réponse est “il feuillette au hasard et prend ce qui ressemble” — vous avez un problème. Si la réponse est “il consulte l’index, identifie la catégorie, lit le résumé, puis va au détail” — alors construisez ça.

Sources