RAG : ce qui marche vraiment en production

Le RAG (retrieval-augmented generation) est devenu le pattern par défaut dès qu'un LLM doit connaître autre chose que ce qu'il a appris à l'entraînement. Au lieu de tout miser sur la mémoire du modèle, on va chercher l'information au moment de la requête.

Pourquoi RAG

Les LLM ont une date de coupure. Ils inventent des faits avec assurance (les hallucinations). Et ils ignorent tout de tes données internes. RAG répond aux trois en récupérant l'info pertinente dans tes propres sources avant de générer une réponse. Le modèle ne devine plus, il s'appuie sur des faits.

Traiter les documents

Traitement des documents

Il faut découper les documents en chunks recherchables. Le chunking fixe (256 à 512 tokens, 10 à 20 % de chevauchement) reste un point de départ correct. Le chunking sémantique fait mieux : il coupe aux frontières naturelles du texte, paragraphes ou sections, plutôt qu'à un compte de tokens arbitraire. Stocke les métadonnées, source, date, section. Elles servent à filtrer à la récupération.

Pour les embeddings, des modèles comme BGE-M3 (dense + sparse + multi-vecteur) ou Qwen3-Embedding offrent une bonne qualité quand le projet est multilingue. BGE-large et E5 restent solides pour du monolingue. Un point à ne pas rater : versionne tes embeddings. Changer de modèle veut dire tout ré-indexer.

Base vectorielle

Ça dépend de tes contraintes.

• pgvector : une extension Postgres. Si tu es déjà sur Postgres, tes vecteurs vivent à côté de tes données relationnelles, sans nouvelle brique
• Qdrant : rapide, on-premise. Pour qui veut une base vectorielle dédiée avec un contrôle total
• Weaviate : open source, recherche hybride native. Bon compromis contrôle/fonctionnalités
• Chroma : simple, embarquée. Pour prototyper vite
• Pinecone : managé, scale tout seul. Le choix si tu ne veux rien héberger

Stratégie de récupération

La recherche sémantique seule laisse filer des résultats évidents en mots-clés. Combine-la avec une recherche lexicale (hybride). Un reranking avec des cross-encoders redresse ensuite l'ordre. Pour la diversité, on écarte les chunks redondants. Et les métadonnées filtrent selon la logique métier du produit.

Patterns avancés

Récupération itérative

Pour une requête complexe, une seule passe ne suffit pas. On récupère un contexte large, on décompose la question en sous-questions, on récupère pour chacune, puis on synthétise. Plus d'appels, mais nettement plus précis.

Auto-requête

Plutôt que d'envoyer la question brute de l'utilisateur, on laisse le LLM construire la requête. Il en extrait des filtres de métadonnées, reformule, et la recherche tape plus juste.

HyDE, ou chercher avec une réponse qui n'existe pas

Contre-intuitif mais ça marche : on demande au LLM une réponse hypothétique à la question, puis on cherche avec l'embedding de cette réponse plutôt qu'avec celui de la question. L'embedding de la réponse hypothétique tombe souvent plus près des vrais documents pertinents.

Les problèmes qu'on retrouve partout

Pertinence contre couverture

Les meilleurs résultats se ressemblent tous. Maximum Marginal Relevance (MMR) force la diversité dans ce qui est récupéré.

Contexte trop long

Trop de chunks dépassent la fenêtre du modèle. Résume les chunks secondaires, passe à une récupération hiérarchique, ou compresse le contexte.

Données qui vieillissent

La base vectorielle se périme. Mises à jour incrémentales, filtrage par date, ré-indexation complète planifiée : les trois sont nécessaires.

Coûts qui grimpent

Embeddings et appels LLM s'additionnent vite. Le semantic caching, mettre en cache les réponses à des requêtes sémantiquement proches et pas seulement identiques, fait chuter coûts et latence d'un coup. Génère les embeddings par lots. Utilise un modèle plus petit quand la tâche le permet. Un classifieur en amont peut aussi éviter RAG entièrement sur les questions simples que le LLM sait déjà traiter.

En production

Ce qu'il faut surveiller

Quatre métriques à suivre : la précision de récupération (les chunks sont pertinents ?), la qualité des réponses (retours utilisateurs), la latence de bout en bout, le coût par requête.

Tests

Pour les tests, il faut une suite qui valide à la fois les sources récupérées et le contenu généré. RAGAS automatise ça en mesurant la fidélité (la réponse colle aux sources ?), la précision du contexte et la pertinence de la réponse. Sans ça dans ta CI, tu pilotes à l'aveugle.

Optimisation

Côté optimisation : cache les embeddings des documents statiques et les résultats des requêtes fréquentes. Parallélise récupération et génération. Groupe les requêtes proches. Chaque milliseconde compte pour un utilisateur qui attend.

Après le RAG classique

RAG bouge vite. Le GraphRAG ajoute des relations entre entités pour les requêtes multi-hop, utile quand tes données ont une vraie structure relationnelle. L'agentic RAG va plus loin : l'agent décide lui-même quand et comment récupérer, critique ses propres résultats, relance la recherche si besoin. Le RAG classique en une passe montre ses limites sur les cas complexes.

Sur la sécurité : pense à la redaction de PII avant l'indexation et à des gardes contre l'injection de prompt dans les documents sources. Tes chunks, ce sont du contenu non contrôlé injecté dans le prompt. Traite-les comme une entrée utilisateur.

Et maintenant ?

Detective searching

Si tu construis des agents IA qui utilisent RAG, mon article sur les agents IA pose les bases. Et pour l'infrastructure, je détaille les options dans auto-héberger l'IA.