Architecture RAG : meilleures pratiques

La génération augmentée par récupération (RAG) est devenue le pattern de référence pour créer des applications LLM qui nécessitent un accès à des informations à jour ou spécifiques à un domaine. Plutôt que de tout confier à la mémoire du modèle, on va chercher l'information pertinente au moment de la requête.

Pourquoi RAG ?

Les grands modèles de langage sont impressionnants mais ils ont des limites concrètes. Leur connaissance s'arrête à la date d'entraînement. Ils peuvent générer des informations plausibles mais fausses (les fameuses hallucinations). Et ils ne connaissent rien de vos données internes.

RAG résout ces problèmes en récupérant des informations pertinentes dans vos propres sources avant de générer une réponse. Le modèle ne devine plus : il s'appuie sur des faits.

Les composants clés

Traitement des documents

Transformez vos documents en chunks recherchables. Le chunking fixe (256-512 tokens avec 10-20 % de chevauchement) reste un bon point de départ, mais le chunking sémantique donne de meilleurs résultats : il découpe aux frontières naturelles du texte (paragraphes, sections) plutôt qu'à un nombre de tokens arbitraire. Stockez les métadonnées (source, date, section) : elles permettent de filtrer efficacement à la récupération.

Pour les embeddings, des modèles comme BGE-M3 (multi-récupération : dense + sparse + multi-vecteur) ou Qwen3-Embedding offrent une qualité solide dans toutes les langues. BGE-large et E5 restent de bons choix de production pour les cas monolingues. Versionnez vos embeddings : quand vous changez de modèle, il faut tout ré-indexer.

Base de données vectorielle

Le choix dépend de vos contraintes :

• pgvector : extension PostgreSQL. Si vous utilisez déjà Postgres, pas besoin d'ajouter une base de données : vos vecteurs vivent à côté de vos données relationnelles
• Qdrant : rapide, option on-premise. Idéal si vous voulez une base vectorielle dédiée avec un contrôle total
• Weaviate : open source, recherche hybride. Bon compromis entre contrôle et fonctionnalités
• Chroma : simple, option intégrée. Parfait pour le prototypage
• Pinecone : managé, s'adapte automatiquement. Le plus simple si vous ne voulez rien héberger

Stratégie de récupération

La recherche sémantique seule ne suffit pas. Combinez-la avec une recherche par mots-clés (recherche hybride). Ajoutez un reclassement avec des cross-encodeurs pour améliorer la pertinence. Évitez les chunks redondants en favorisant la diversité des résultats. Et utilisez les métadonnées pour filtrer selon votre logique métier.

Patterns avancés

Récupération itérative

Pour les requêtes complexes, une seule passe de récupération ne suffit pas. On commence par récupérer un contexte large, puis on décompose la requête en sous-questions, on récupère des informations ciblées pour chacune et on synthétise les résultats. C'est plus coûteux en appels mais nettement plus précis.

Auto-requête

Plutôt que d'utiliser la question brute de l'utilisateur comme requête de recherche, on laisse le LLM générer une requête structurée. Il peut extraire des filtres de métadonnées, reformuler la question et produire une recherche plus pertinente.

HyDE (embeddings de documents hypothétiques)

Une technique contre-intuitive : on demande au LLM de générer une réponse hypothétique à la question, puis on utilise cette réponse comme requête de recherche. L'embedding de la réponse hypothétique est souvent plus proche des vrais documents pertinents que l'embedding de la question originale.

Défis courants

Pertinence vs couverture

Les meilleurs résultats de recherche peuvent tous être similaires. Utilisez Maximum Marginal Relevance (MMR) pour forcer la diversité dans les résultats récupérés.

Contexte long

Trop de chunks dépassent la fenêtre de contexte du modèle. Résumez les chunks moins pertinents, utilisez une récupération hiérarchique ou implémentez la compression de contexte.

Fraîcheur des données

Les informations dans la base vectorielle deviennent obsolètes. Mettez en place des mises à jour incrémentales, filtrez par date et planifiez une ré-indexation complète périodique.

Maîtrise des coûts

Les embeddings et les appels LLM s'additionnent. Le semantic caching (mettre en cache les réponses de requêtes sémantiquement proches, pas juste identiques) réduit drastiquement les coûts et la latence. Générez les embeddings par lots et utilisez des modèles plus petits quand la tâche le permet. Un classifieur en amont peut aussi court-circuiter RAG 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-ils pertinents ?), la qualité des réponses (via les retours utilisateurs), la latence de bout en bout et le coût par requête (embeddings + LLM).

Tests

Construisez une suite de tests avec des cas qui valident à la fois la pertinence des sources récupérées et le contenu des réponses générées. Des frameworks comme RAGAS automatisent ça en mesurant la fidélité (la réponse colle-t-elle aux sources ?), la précision du contexte et la pertinence de la réponse. Intégrez ces métriques dans votre CI : sans évaluation automatisée, vous pilotez à l'aveugle.

Optimisation

Cachez les embeddings des documents statiques et les résultats des requêtes fréquentes. Parallélisez récupération et génération, groupez les requêtes similaires. Chaque milliseconde compte quand vos utilisateurs attendent une réponse.

Et après RAG ?

RAG évolue vite. Le GraphRAG ajoute des relations entre entités pour les requêtes multi-hop (utile quand vos données ont une structure relationnelle forte). L'agentic RAG va plus loin : l'agent décide lui-même quand et comment récupérer, critique ses résultats et relance la recherche si nécessaire. Le RAG "basique" d'un seul passage de récupération commence à montrer ses limites sur les cas complexes.

Côté sécurité, pensez à la redaction de PII avant l'indexation et aux gardes contre l'injection de prompts dans les documents sources. Vos chunks sont du contenu non contrôlé injecté dans le prompt : traitez-les comme une entrée utilisateur.

Et maintenant ?

Detective searching

Si vous construisez 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.