Le RAG (Retrieval Augmented Generation) est devenu la technique standard pour donner à un modèle de langage l’accès à vos propres données sans le réentraîner. En 2026, la grande majorité des applications IA en entreprise utilisent une forme de RAG : chatbots de documentation, assistants de support, moteurs de recherche internes, analyse de documents. Mais entre un prototype qui fonctionne sur dix documents et un système RAG fiable en production sur des milliers de documents, l’écart est considérable. Ce guide couvre le pipeline RAG complet, de l’ingestion des données à l’optimisation en production, avec du code concret et les pièges qui font échouer la plupart des projets.
Le pipeline RAG en quatre étapes
Un pipeline RAG standard fonctionne en quatre étapes. L’ingestion charge vos documents (PDF, HTML, Markdown, base de données) et les découpe en chunks, des morceaux de texte de taille optimale. L’embedding convertit chaque chunk en vecteur numérique via un modèle d’embedding spécialisé.
Vient ensuite le retrieval : quand un utilisateur pose une question, celle-ci est convertie en vecteur, et le système recherche les chunks les plus similaires dans la base vectorielle. Enfin, la génération envoie les chunks pertinents accompagnés de la question au LLM, qui produit une réponse contextualisée et sourcée.
Ce découpage en quatre étapes est trompeusement simple. Chacune cache des décisions techniques qui déterminent la qualité finale : comment découper les documents, quel modèle d’embedding choisir, combien de chunks récupérer, comment formuler le prompt final. C’est l’accumulation de bonnes décisions à chaque étape qui distingue un RAG médiocre d’un RAG excellent.
# Pipeline RAG complet avec LlamaIndex
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.llms.anthropic import Anthropic
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
Settings.llm = Anthropic(model='claude-sonnet-4-6')
Settings.embed_model = HuggingFaceEmbedding('BAAI/bge-m3')
Settings.chunk_size = 512
Settings.chunk_overlap = 50
documents = SimpleDirectoryReader('./docs').load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine(similarity_top_k=10, response_mode='compact')
reponse = query_engine.query('Comment optimiser un site WordPress ?')
print(reponse)
print('Sources:', [n.metadata for n in reponse.source_nodes])Le chunking : la clé sous-estimée de la qualité
Le chunking, c’est-à-dire le découpage du texte, est l’étape la plus sous-estimée du pipeline RAG, et pourtant la cause principale des mauvaises réponses. Un chunk trop petit perd son contexte : le LLM reçoit des fragments isolés et incompréhensibles. Un chunk trop grand dilue l’information pertinente dans du bruit, ce qui réduit la précision de la recherche.
La taille optimale dépend du type de contenu. Pour de la documentation technique dense, 256 à 512 tokens fonctionnent bien. Pour des articles de blog, 512 à 1024 tokens préservent mieux le fil du raisonnement. Pour des FAQ courtes, le document entier peut tenir dans un seul chunk. Il n’existe pas de valeur universelle : il faut tester sur vos données réelles.
Le chevauchement entre chunks consécutifs (chunk overlap) de 50 à 100 tokens évite de couper une idée en deux. Sans ce chevauchement, une information à cheval sur deux chunks devient irrécupérable. Les techniques avancées comme le chunking sémantique (découper aux frontières naturelles du sens plutôt qu’à un nombre fixe de tokens) améliorent encore la pertinence, au prix d’une complexité accrue.
Choisir le bon modèle d’embedding
Le modèle d’embedding détermine directement la qualité de la recherche sémantique. Pour du contenu en français, BGE-M3 de BAAI est l’un des meilleurs modèles multilingues open source en 2026 : il gère le français nativement avec d’excellentes performances et peut être auto-hébergé gratuitement.
Pour de l’embedding via API, text-embedding-3-large d’OpenAI offre une qualité de pointe pour un coût modéré, et les embeddings d’Anthropic via Voyage AI constituent une alternative solide. Le choix entre open source auto-hébergé et API dépend de vos contraintes de coût, de volume et de confidentialité des données.
Un conseil crucial : choisissez un modèle qui gère bien le français et produit des vecteurs de dimension raisonnable (768 à 1024) pour un bon compromis entre qualité et performance. Évitez les anciens modèles comme ada-002 ou les sentence-transformers basiques : la qualité des embeddings a doublé en deux ans, et un mauvais modèle d’embedding plombe tout le pipeline en aval.
Base vectorielle et reranking
Le choix de la base vectorielle est moins critique que le chunking ou l’embedding, mais il compte. Pour un projet de taille modérée (moins de 100 000 documents), Chroma est gratuit, simple et local. Pour la production avec scaling automatique, Pinecone est performant et managé. Si vous utilisez déjà PostgreSQL, pgvector évite d’ajouter une nouvelle infrastructure.
Le reranking est l’étape qui change tout, et pourtant souvent oubliée. Un modèle de reranking (Cohere Rerank, bge-reranker) réévalue la pertinence des chunks récupérés par la recherche vectorielle. Sans reranking, la recherche retourne les chunks sémantiquement proches, qui ne sont pas toujours les plus pertinents pour répondre précisément à la question.
Le pattern recommandé consiste à récupérer une vingtaine de chunks par recherche vectorielle, à les reranker, puis à n’envoyer que les cinq meilleurs au LLM. Cette étape supplémentaire améliore la précision des réponses de 15 à 25 % dans la plupart des cas. C’est l’un des meilleurs rapports effort/gain de tout le pipeline RAG.
Évaluer la qualité d’un RAG
Un pipeline RAG sans évaluation est un pipeline cassé que vous n’avez pas encore identifié comme tel. Trois métriques clés permettent de mesurer la qualité. La fidélité (faithfulness) évalue si la réponse reste fidèle aux sources fournies, ce qui mesure le risque d’hallucination. La pertinence du retrieval évalue si les chunks récupérés étaient réellement utiles.
L’exactitude de la réponse (answer correctness) mesure la qualité globale du résultat par rapport à une réponse attendue. Des outils comme RAGAS (open source, le plus utilisé), LlamaIndex Evaluation ou DeepEval automatisent ces mesures. L’idée est de constituer un jeu de test de 50 à 100 questions avec leurs réponses attendues, et de le rejouer à chaque modification du pipeline.
Cette discipline d’évaluation est ce qui distingue un projet RAG amateur d’un projet professionnel. Sans elle, chaque modification est un pari à l’aveugle : vous ne savez pas si vous améliorez ou dégradez le système. Avec un jeu de test, vous mesurez objectivement l’impact de chaque changement (taille des chunks, modèle d’embedding, prompt) et vous progressez de manière mesurable.
Optimisations avancées en production
Une fois le pipeline de base en place, plusieurs optimisations améliorent significativement les résultats. La recherche hybride combine recherche vectorielle (similarité sémantique) et recherche lexicale BM25 (correspondances exactes de mots-clés), capturant ainsi à la fois le sens et les termes précis comme les noms propres ou les références techniques.
L’indexation hiérarchique crée un résumé de chaque document, recherche d’abord dans les résumés, puis affine dans les chunks du document pertinent. L’expansion de requête reformule la question de l’utilisateur en plusieurs variantes pour améliorer le rappel. Le filtrage par métadonnées (date, catégorie, auteur) restreint la recherche avant même l’étape vectorielle, gagnant en précision et en performance.
Ces optimisations ne sont pas toutes nécessaires d’emblée. La bonne approche est itérative : démarrez avec un pipeline simple, mesurez sa qualité avec votre jeu de test, identifiez les faiblesses, et ajoutez les optimisations qui répondent à des problèmes réels. Empiler des techniques sophistiquées sans mesurer leur impact ajoute de la complexité sans garantie de gain.
Les pièges à éviter en production
Les erreurs les plus fréquentes en production sont prévisibles. Ne pas mettre à jour l’index quand les documents changent produit des réponses obsolètes qui érodent la confiance des utilisateurs. Ne pas gérer le cas où aucun chunk n’est pertinent conduit le LLM à halluciner une réponse plausible mais fausse — un comportement particulièrement dangereux.
Ne pas surveiller les coûts est un autre piège classique : un pipeline avec reranking et gros chunks peut coûter 0,05 à 0,10 $ par requête, ce qui devient considérable à l’échelle. Ne pas limiter la longueur du contexte envoyé au LLM dégrade la qualité au-delà de 10 000 tokens de contexte, car le modèle se perd dans le bruit.
Enfin, le piège le plus courant est de ne tester qu’avec ses propres questions. Les questions réelles des utilisateurs sont souvent très différentes de celles imaginées par les développeurs : formulations ambiguës, fautes de frappe, questions hors périmètre. Un RAG ne se valide vraiment qu’avec de vrais utilisateurs et de vraies questions, pas en laboratoire.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.