RAG : architecture, chunking, embeddings — et pourquoi votre chatbot se trompe

RAG : architecture, chunking, embeddings — et pourquoi votre chatbot se trompe
Table des matières

Pourquoi un chatbot “RAG” peut encore halluciner

Beaucoup d’équipes mettent en place un RAG en pensant :

“On branche une base documentaire, et le chatbot devient factuel.”

En réalité, un RAG est une architecture avec des points de défaillance classiques : mauvais chunking, retrieval bruité, contexte trop long, citations absentes, etc.

Ce billet vous prend par la main : vous allez comprendre où ça casse, et surtout comment le diagnostiquer de manière “ingénieur”.

Si vous voulez une version plus longue (avec scripts et cadres d’évaluation), mon livre La Mécanique des LLM va plus loin :

RAG en une phrase (et en trois verbes)

Un pipeline RAG, c’est :

  1. transformer vos documents en chunks
  2. calculer des embeddings
  3. retrouver les passages pertinents (retrieval)
  4. injecter ces passages dans le prompt du LLM

Une façon simple de le retenir :

  • Retrieve : retrouver les passages pertinents
  • Augment : les injecter dans le contexte (comme des notes de bas de page juste avant de répondre)
  • Generate : produire la réponse en s’appuyant sur ces sources

Analogie : le RAG, c’est l’examen “à livre ouvert”. Sans RAG, le modèle répond “de mémoire” (risque d’obsolescence + hallucination). Avec RAG, il va chercher, puis synthétise.

Embeddings : quel “encodeur sémantique” ?

Le RAG repose sur un modèle d’encodage sémantique (embeddings) : Sentence‑BERT ou des dérivés modernes (E5, BGE, embeddings OpenAI…). L’erreur classique est de croire que “tous les embeddings se valent” : jargon métier, acronymes internes ou tableaux font chuter la qualité du retrieval.

Chunking : un art (avec overlap)

Un chunking naïf peut tuer le recall.

  • chunks trop gros : le retrieval devient flou
  • chunks trop petits : vous perdez le contexte
  • découpage sans chevauchement : une information clé peut tomber “entre deux chunks”

Pratique courante : introduire un overlap (par ex. 30 à 50% de recouvrement) pour augmenter la probabilité qu’un passage critique soit capturé en entier.

Retrieval en deux temps : rappel puis précision (re-ranking)

Une stratégie robuste est :

  1. sélectionner large (rappel)
  2. re-ranker finement pour ne garder que les meilleurs passages

Sans re-ranking, on injecte souvent un contexte médiocre (et le LLM est excellent pour “rendre plausible” un mauvais contexte).

Contextualiser les chunks (très efficace)

Une amélioration moderne : contextualiser chaque chunk avant indexation (titre ou mini résumé généré). Ce préambule ajoute des signaux sémantiques et améliore la pertinence quand la question est plus abstraite que les mots exacts présents dans le document.

3 erreurs très fréquentes

1) Chunking “au hasard”

Chunks trop grands : le retrieval devient imprécis. Chunks trop petits : on perd le contexte.

2) Embeddings mal adaptés

Des embeddings généralistes peuvent échouer sur : jargon métier, acronymes internes, structures tabulaires.

3) Pas de stratégie de citations

Sans citations / sources, impossible de distinguer :

  • réponse fondée sur les documents
  • réponse inventée mais “plausible”

Bonnes pratiques (simples)

  • chunking basé sur la structure (titres, sections)
  • recouvrement léger entre chunks
  • évaluer le retrieval séparément du LLM (top-k, recall)
  • forcer des citations quand c’est nécessaire

Erreur “système” très fréquente : trop de contexte, ou le mauvais contexte

À retenir : un RAG naïf noie le modèle.

  • injecter trop de chunks augmente le bruit
  • injecter des chunks incorrects ancre la génération sur de mauvaises sources

Le bon réflexe : mesurer le retrieval (recall@k) et utiliser du re-ranking.

Mise en pratique (scripts)

Deux scripts utiles pour expérimenter :

  • 04_rag_minimal.py : pipeline RAG minimal (approche simple, pédagogique)
  • 07_llamaindex_rag_advanced.py : bonus avancé (framework RAG complet + évaluation)

Dépôt : https://github.com/alouani-org/mecanics-of-llms

Méthode pas-à-pas (diagnostiquer un RAG qui se trompe)

Étape 1 : séparer le problème “retrieval” du problème “génération”

  • Commencez par afficher les chunks récupérés.
  • Posez-vous une question binaire : “Est-ce que la réponse est dans les chunks ?”

Si non : c’est (presque toujours) un problème de retrieval/chunking/embeddings.

Étape 2 : mesurer un minimum

Sans métrique, on “tune au feeling”. Minimum vital :

  • recall@k : dans combien de cas le bon passage est présent dans les k chunks récupérés ?
  • qualité des citations : est-ce que vos réponses citent réellement un passage utile ?

Étape 3 : améliorer dans le bon ordre

  1. Chunking + overlap (structure, pas au hasard)
  2. Embeddings adaptés à votre domaine
  3. Re-ranking (pour réduire le bruit)
  4. Contrainte de citation / format

Mini‑FAQ

“Pourquoi mon RAG hallucine alors que j’injecte des documents ?”

Parce qu’injecter des documents ne garantit pas qu’ils soient :

  • pertinents
  • lisibles dans la fenêtre de contexte
  • correctement utilisés (le modèle peut ignorer un contexte bruité)

“Combien de chunks faut-il injecter ?”

Il n’y a pas de nombre magique. Le bon réflexe : commencer petit (3–5) + re-ranking, puis augmenter si nécessaire.

Pour aller plus loin

Si vous voulez une version plus complète (bases de données vectorielles, choix embeddings, stratégies d’indexation, évaluation et pièges), le livre va plus loin :

Mots-clés :
Partager :

Articles similaires