RAG Cookbook

Le RAG ancre les réponses dans des chunks récupérés au moment de la requête. Adoptez-le quand le corpus est grand ou changeant et que vous avez besoin de citations. Préférez le contexte long pour un petit corpus stable qui tient dans la fenêtre, et le fine-tuning pour le style/format, pas pour les faits.

When RAG vs alternatives

Chunking recipes

Règle empirique pour l’overlap : 10–20 % de la taille du chunk. Trop peu perd le contexte de frontière ; trop gonfle l’index et duplique les hits.

Hybrid retrieval config

Le dense (embeddings) capte la paraphrase ; le sparse (BM25) capte les identifiants exacts, les codes et les termes rares. Fusionnez-les, puis effectuez un reranking.

retrieval:
  dense:
    model: text-embedding-large
    top_k: 40
  sparse:
    algorithm: bm25
    top_k: 40
  fusion:
    method: reciprocal_rank_fusion   # RRF
    k: 60                            # RRF constant
  rerank:
    model: cross-encoder-reranker
    top_n: 8                         # feed the LLM the top 8
  diversity:
    method: mmr                      # optional, reduce redundancy
    lambda: 0.5

Reciprocal Rank Fusion : score d’un doc = Σ sur les listes de 1 / (k + rank). Avec k=60, un doc classé n°1 dans les deux listes obtient 1/61 + 1/61 ≈ 0.0328 ; un doc classé n°1 en dense mais absent en sparse obtient 1/61 ≈ 0.0164. Le RRF ne nécessite aucune calibration de score entre systèmes — il classe par position.

Reranking

Un reranker cross-encoder lit la requête et chaque candidat ensemble, offrant une précision bien meilleure que le bi-encoder utilisé pour la récupération de première étape — à un coût plus élevé. Récupérez largement (top_k 40–100), effectuez un reranking vers un petit top_n (5–10) pour le LLM.

Query rewriting

Eval metrics with worked numbers

Séparez la qualité de récupération de la qualité de génération — une bonne réponse peut masquer une mauvaise récupération et inversement.

Comparaison travaillée — l’ajout d’un reranker sur une eval de 200 requêtes :

Le reranking bouge à peine le Recall@5 (mêmes candidats) mais relève nettement le MRR et la faithfulness en ordonnant le bon chunk en premier — le LLM le voit plus tôt.

Debugging playbook

1. Reproduire avec la trace. Journalisez la requête, la requête réécrite, les IDs+scores des chunks récupérés, l’ordre après reranking et le prompt final. La plupart des bugs de « mauvaise réponse » sont visibles ici.
2. Le chunk gold est-il récupéré du tout ? Si pas dans le top-k → problème de récupération : vérifiez le chunking (dérive), les embeddings (mauvais modèle/dimension) ou la réécriture de requête.
3. Récupéré mais mal classé ? Ajoutez/ajustez le reranker ; réglez le k du RRF ; vérifiez la pondération hybride.
4. Récupéré et en tête mais réponse fausse ? C’est maintenant la génération : vérifiez le prompt (les chunks sont-ils réellement transmis ?), l’ordonnancement du contexte (docs d’abord) et la faithfulness (le modèle ignore-t-il le contexte ?).
5. Confiant-mais-faux après une actualisation ? Suspectez l’index : ré-embeddé avec un modèle différent, chunker changé ou vecteurs périmés. Rejouez les evals de récupération.
6. Vérification par segment. Ventilez les métriques par type/source de document ; un agrégat de 90 % peut masquer une source à 40 %.

Idées fausses courantes

Étude de cas guidée

Un assistant de support sur 40 000 articles de KB (mis à jour chaque semaine) s’est mis cette semaine à donner des réponses confiantes mais fausses. Les utilisateurs posent à la fois des questions en langage naturel et des codes d’erreur exacts. Quelle est la PREMIÈRE étape et la bonne architecture ?

1. PREMIÈRE étape — tirez les traces et vérifiez si le chunk gold est récupéré. Il est apparu que la ré-ingestion de cette semaine a changé le chunker (dérive) — un problème de récupération, pas de prompt.
2. Chunking — structural/parent-child pour les articles : chunks enfants pour les matches précis, sections parentes pour le contexte. Versionnez la configuration.
3. Récupération — hybride (dense + BM25) : les codes d’erreur nécessitent une correspondance de terme exacte que le dense manque.
4. Reranking — cross-encoder vers top-8 ; l’article gold était récupéré mais classé n°14 avant reranking.
5. Eval — recall@k, MRR, faithfulness, par source ; conditionnez les ré-ingestions à ces métriques.
6. Citations — attachez les spans pour que les réponses soient auditables (test de provenance).

Alternatives rejetées : réécrire le prompt système (la récupération était cassée), faire du fine-tuning sur la KB (les faits changent chaque semaine — c’est le rôle du RAG), la récupération dense seule (manque les codes d’erreur) et se fier au score agrégé (a masqué la source défaillante).

À retenir

• RAG pour les corpus grands/changeants + citations ; contexte long pour un petit corpus stable ; fine-tuning pour le style, pas les faits.
• Chunkez pour correspondre à la forme des données et au motif de requête ; le parent-child équilibre hits précis et contexte ; versionnez la configuration.
• Hybride (dense + BM25) + reranking cross-encoder bat chacun seul ; le RRF fusionne sans calibration de score.
• Séparez les métriques de récupération (recall@k, MRR) des métriques de génération (faithfulness, answer relevance), et reportez par segment.
• Déboguez à partir de la trace : chunk gold récupéré ? classé ? transmis ? utilisé ? Suspectez d’abord l’index après une actualisation.