Récupération & RAG : chunking, hybride, RRF, reranking

Pourquoi ce module

C'est le module le plus technique du parcours, et celui où les questions d'entretien sont les plus précises. On ne vous demandera pas « qu'est-ce que le RAG ? » — on vous demandera « vos scores BM25 vont de 0 à 40, vos scores cosinus de 0 à 1. Comment les fusionnez-vous ? »

La bonne nouvelle : la chaîne est courte et chaque maillon a une seule bonne réponse. Une fois qu'on tient la chaîne, la plupart des questions se répondent en la parcourant.

Objectifs pédagogiques

1. Décrire la chaîne complète d'un RAG, de l'ingestion à la réponse
2. Justifier une stratégie de découpage et nommer ses points de rupture
3. Expliquer pourquoi la recherche hybride bat le vectoriel seul
4. Expliquer RRF et pourquoi il opère sur les rangs
5. Situer reranking et interaction tardive dans la chaîne, avec leur coût
6. Nommer la métrique adaptée à chaque étage

Plan détaillé

1. La chaîne complète
2. Ingestion et découpage
3. Les deux façons de chercher
4. Fusionner : RRF
5. Reranking et interaction tardive
6. Mesurer chaque étage
7. Les pièges d'implémentation
8. Glossaire du module

1. La chaîne complète

Retenez cette forme : la moitié du travail se fait hors ligne (ingestion), l'autre à la requête. Beaucoup de mauvaises réponses viennent de confondre les deux — l'embedding des documents est calculé une fois à l'ingestion, celui de la question à chaque requête.

2. Ingestion et découpage

Chunking (découpage) : couper les documents en passages indexables.

C'est l'étape la plus sous-estimée. Un découpage médiocre ne se rattrape à aucun étage suivant : si l'information utile est coupée en deux, aucun reranker ne la reconstituera.

🎯 La réponse d'entretien. « Il n'y a pas de bonne taille dans l'absolu, il y a une bonne taille pour un corpus. Sur des notices techniques, je découpe par élément structurel — un tableau ne se coupe pas, une procédure numérotée non plus — et je mesure le rappel avant et après. Je choisis avec un chiffre, pas avec une préférence. »

Le recouvrement (overlap) sert à limiter les coupures malheureuses : les passages se chevauchent, donc une information à cheval reste entière dans au moins un passage. Il coûte du stockage et introduit de la redondance dans les résultats.

3. Les deux façons de chercher

BM25 est une fonction de score lexicale : elle compte les occurrences de termes en pondérant par leur rareté dans le corpus et en corrigeant l'effet de longueur du document. Elle ne comprend rien, et c'est sa force : elle trouve exactement E-42, TT-104, un numéro de série, une référence.

La recherche vectorielle compare des embeddings — des vecteurs de sens. Elle trouve « procédure de redémarrage » quand le document dit « remise en service », ce que BM25 rate. Elle est en revanche mauvaise sur les identifiants : un code produit n'a pas de « sens » à capturer.

🎯 Pourquoi l'hybride. « Parce que les deux échouent sur des choses différentes et complémentaires. Le vectoriel rate les identifiants exacts — un code d'erreur, une référence pièce — parce qu'ils n'ont pas de voisinage sémantique. Le lexical rate les reformulations. Sur un corpus technique, les deux cas sont fréquents dans la même journée. »

⚠️ Le distracteur. « L'hybride est plus précis parce qu'il combine deux scores » — non, la précision ne vient pas de l'addition mais de la couverture de deux modes d'échec disjoints. Un candidat qui explique le pourquoi en ces termes se distingue immédiatement.

4. Fusionner : RRF

Voilà le problème concret : BM25 rend des scores de 0 à 40, le cosinus de −1 à 1. Ces échelles ne sont pas comparables, et les normaliser est fragile — la normalisation dépend de la distribution des scores, qui change à chaque requête.

RRF — Reciprocal Rank Fusion résout ça d'une façon élégante : il ignore les scores et n'utilise que les rangs.

score_RRF(document d) = Σ   1 / (k + rang(d, liste_i))
                      listes i

avec k = 60 par convention.

Pourquoi les rangs et pas les scores — c'est la question exacte posée en entretien :

« Parce que les rangs sont sans unité. Le rang 1 de BM25 et le rang 1 du vectoriel veulent dire la même chose — « le meilleur selon cette méthode » — alors qu'un score de 12 chez l'un et de 0,83 chez l'autre ne sont pas comparables et ne le deviennent pas par normalisation. RRF supprime le problème au lieu de le contourner. »

Le rôle de k = 60 : amortir. Sans lui, l'écart entre le rang 1 et le rang 2 serait énorme (1 contre 0,5) et un seul système dominerait la fusion. Avec k = 60, l'écart entre 1/61 et 1/62 est faible : un document bien classé par les deux méthodes remonte devant un document premier chez une seule.

5. Reranking et interaction tardive

La récupération rend 50 à 100 passages. On ne peut pas tous les mettre dans le contexte — coût, latence, et lost in the middle (module F1). Il faut re-trier finement un petit lot.

Le cross-encodeur est plus précis parce qu'il voit la paire. Le bi-encodeur doit résumer le document en un vecteur sans savoir quelle question sera posée ; le cross-encodeur lit les deux ensemble et peut faire correspondre les termes. Il est donc impossible à pré-calculer — d'où son coût, et d'où le fait qu'on ne l'applique qu'à une cinquantaine de candidats.

L'interaction tardive (ColBERT) est le compromis : on garde un embedding par token du document, calculable à l'avance, et on score par MaxSim — pour chaque token de la question, la meilleure correspondance parmi les tokens du document, puis on somme. On récupère une partie de la finesse du cross-encodeur en gardant le pré-calcul. Le coût se paie en stockage : un vecteur par token, pas un par passage.

🎯 La question piège. « Pourquoi ne pas utiliser directement le cross-encodeur sur tout le corpus ? » — Parce qu'il faudrait un passage modèle par document et par question : sur un million de documents, c'est un million d'inférences pour une seule question. Le pipeline en cascade n'est pas un compromis de qualité, c'est la seule forme calculable.

6. Mesurer chaque étage

Chaque étage a sa métrique, et les confondre est une erreur classique.

💡 Le principe à retenir : le rappel est un plafond. Si le bon passage n'est pas dans les k récupérés, aucun reranker et aucun modèle ne peut produire une bonne réponse. Quand un RAG répond mal, on mesure le rappel avant de toucher au prompt — c'est le réflexe de diagnostic le plus rentable du métier, et une excellente réponse à « votre RAG répond mal, par où commencez-vous ? ».

7. Les pièges d'implémentation

Six défauts qui ont un point commun : ils ne lèvent aucune erreur. Le système répond, simplement mal. C'est ce qui les rend redoutables — et ce qui en fait d'excellentes questions d'entretien.

7.1 Le plafond du reranker se calcule avant de le construire

Avant d'ajouter un reranker, on mesure ce qu'il peut rapporter :

gain maximal possible = recall@vivier − recall@servis

Si les deux sont égaux, le reranker ne peut améliorer que l'ordre (donc le MRR), pas le rappel. Le bon passage est déjà servi ou déjà absent ; re-trier n'y changera rien.

Mesurer d'abord dit si le travail vaut la peine — et c'est une réponse qui impressionne, parce qu'elle montre qu'on ne construit pas par réflexe.

7.2 Le corpus interlangue et le ET implicite

Symptôme : corpus anglais, questions en français, le rappel plein-texte s'effondre à presque zéro — alors que le vectoriel fonctionne.

La cause : websearch_to_tsquery construit un ET entre les termes. À travers la barrière de langue, presque toute requête contient au moins un terme absent du corpus — et un seul suffit à vider le résultat.

Seul le bras vectoriel franchit la barrière. Aucun test unitaire ne révèle ça : la fonction rend bien une liste, elle est simplement vide.

7.3 RETRIEVAL_QUERY ≠ RETRIEVAL_DOCUMENT

Les modèles d'embedding modernes attendent qu'on déclare de quel côté on se place.

Une question et le passage qui y répond ne sont pas des paraphrases : l'encodeur est entraîné à les projeter dans la même région depuis deux côtés différents. Embedder une requête comme un document est une perte de rappel silencieuse, sans aucune erreur nulle part.

7.4 Matryoshka : tronquer ne suffit pas

Les embeddings Matryoshka peuvent être tronqués — 3072 → 1536 dimensions — pour économiser du stockage. Mais :

La troncature casse la norme unitaire : cosinus et produit scalaire cessent de coïncider. Il faut renormaliser après troncature.

Et le piège qui suit : mélanger une requête en 3072 avec des documents en 1536 ne lève aucune erreur — cela compare simplement du vide.

7.5 pgvector et l'index IVFFlat

Construire un index IVFFlat sur une table vide fait s'effondrer le rappel silencieusement : la requête renvoie toujours des lignes, simplement les mauvaises.

L'index doit être construit après le chargement des données, parce qu'il apprend ses centroïdes depuis le contenu. Règle empirique : lists ≈ √(nombre de lignes). HNSW évite ce réentraînement, au prix de plus de mémoire et d'une construction plus lente.

7.6 Deux leviers sous-estimés

Le contextual retrieval — préfixer chaque passage d'un court contexte de niveau document avant de l'embedder. Ce qu'il corrige :

Un chunk est récupéré seul alors qu'il a été écrit comme partie d'un tout. Restaurer le contexte minimal le rend interprétable isolément.

Le filtrage par métadonnée avant recherche — par équipement, par tenant, par date :

Le scoping est à la fois un levier de qualité et une frontière de sécurité. En multi-tenant, c'est ce qui sépare une fonction de recherche d'une fuite de données.

C'est exactement le point du module F7 : filtrer avant la fusion, jamais après.

7.7 Le cas concret : 300 PDF scannés de qualité inégale

Une mise en situation fréquente, et la seule bonne façon d'y répondre est dans l'ordre.

1. Un sous-ensemble pilote choisi pour couvrir les pires cas — pas les plus propres. Vingt documents dont les cinq plus mauvais scans.
2. Mesurer la qualité d'extraction explicitement, ne jamais la supposer. Combien de pages sortent vides ? Combien de tableaux illisibles ?
3. Poser le principe : tout l'aval hérite de la qualité d'extraction. Un OCR à 70 % plafonne le système à 70 %, quel que soit le reranker.
4. Découpage conscient de la structure, avec la règle des tableaux (§ 2).
5. Réconciliation entre étages — compter à l'entrée et à la sortie de chaque étape (cf. F6). La perte silencieuse est réelle sur ce type de corpus.
6. Construire le jeu d'évaluation AVANT les parties sophistiquées.

🎯 La relance qui arrive toujours : « l'OCR est mauvais sur un tiers du corpus, que dites-vous au client ? » — On le dit, avec le chiffre, et on présente le choix : re-numériser ces documents, les exclure explicitement du périmètre, ou accepter un plafond de qualité connu sur cette part. Les trois sont défendables ; masquer le chiffre ne l'est pas.

8. Glossaire du module

Atelier (75 min)

1. Dessiner la chaîne de mémoire (15 min) — reproduisez le schéma du § 1 sans le regarder, en nommant ce qui est hors ligne et ce qui est en ligne.
2. L'échelle incompatible (20 min) — expliquez RRF à voix haute, en anglais, à quelqu'un qui ne connaît pas. Si vous prononcez le mot « normaliser », recommencez.
3. Le pipeline en cascade (20 min) — justifiez pourquoi on ne met pas le cross-encodeur en premier. Puis situez ColBERT et dites ce qu'il coûte.
4. Le réflexe de diagnostic (20 min) — « votre RAG répond mal » : énoncez votre ordre de vérification, en commençant par le rappel.

Pour aller plus loin

• 🎯 Parcours : F1 — Fondamentaux LLM ← → F3 — Agents & MCP
• 🛠 Entraînement : thème rag_retrieval de la banque fransys-fde — 12 QCM