Pourquoi le RAG ? Le problème fondamental des LLM génériques
Les grands modèles de langage (GPT-4, Claude, Llama, Mistral) ont une connaissance figée a leur date d'entraînement et ne connaissent pas vos documents internes, votre base de connaissances ou vos données métier spécifiques. Demandez a GPT-4 les procédures internes de votre entreprise, les specifications de votre API, ou les nouvelles reglementations de votre secteur — il inventera avec confiance. C'est le problème de la hallucination combinée a la limite de la date de coupure.
Les adapter par fine-tuning est couteux (temps GPU, données labelisées, infrastructure), lent (plusieurs jours a semaines), et rigide (un nouveau document nécessite un nouveau reentainement). Le RAG resout ce problème en augmentant le prompt du LLM avec des passages de documents pertinents retrouves en temps réel. Le LLM ne répond plus de mémoire — il répond en se basant sur les documents fournis dans son contexte immédiat. Résultat : réponses actualisées, sourcables, controlables et adaptées a votre domaine.
RAG vs fine-tuning vs long context : quand utiliser quoi ?
Trois approches permettent de specialiser un LLM sur des données spécifiques. Le prompt engineering avec long contexte consiste a charger tous les documents directement dans le prompt — possible avec les modèles a fenêtres de 128K ou 1M tokens (Gemini 1.5 Pro, Claude 3), mais couteux en tokens et en latence, et degrade les performances quand le contexte est trop long (le LLM 'oublie' les informations au milieu du contexte).
Le fine-tuning modifie les poids du modèle pour adapter son style, son comportement ou ses connaissances de façon permanente. Idéal pour adapter le ton (juridique, medical, conversationnel), injecter des formats de réponse spécifiques, ou accélérer l'inference sur des taches repetitives. Inadapte pour des données qui changent souvent : un nouveau document nécessite un nouveau cycle d'entraînement. Le RAG est généralement le choix le plus adapte pour les applications métier avec des bases de connaissances dynamiques : documentations techniques, FAQ, bases réglementaires, wikis internes. La combinaison RAG + fine-tuning est parfois utilisée : le fine-tuning adapte le comportement, le RAG fournit les connaissances spécifiques.
Utilisez le RAG quand les données changent souvent, quand la source doit être citée explicitement, quand le perimetre de connaissances est large et évolue. Utilisez le fine-tuning quand le style de réponse doit être adapte de manière permanente, quand la tache est très repetitive et bien définie, ou quand la latence d'inference est critique (un modèle fine-tune sur un domaine precis peut être plus petit et plus rapide qu'un LLM generaliste augmente). Les deux ne s'excluent pas.
Le pipeline RAG : indexation, retrieval et génération
Un pipeline RAG se compose de deux phases indépendantes : la phase d'indexation (offline, exécutée une fois ou périodiquement) qui prepare et stocke les documents, et la phase de requete (online, temps réel) qui retrouve les passages pertinents et génère la réponse.
Phase d'indexation : charger, chunker, embedder, indexer
L'indexation comporte quatre étapes. (1) Chargement : ingestion des documents sources (PDF via PyMuPDF ou pdfplumber, Markdown, HTML, bases de données, Confluence, Notion, Google Drive, emails). Des connecteurs (LlamaIndex Readers, LangChain Document Loaders) gèrent la plupart des formats courants. (2) Chunking : découpage en passages de taille appropriée (voir section dédiée). (3) Embedding : chaque chunk est transforme en vecteur numerique via un modèle d'embedding (OpenAI text-embedding-3-small, Cohere embed-v3, ou des modèles open-source sentence-transformers). (4) Indexation dans une base de données vectorielle avec les métadonnées associées (source, date, section, auteur) qui permettront le filtrage lors du retrieval.
La qualité de l'indexation détermine un plafond pour la qualité finale du RAG. Des documents mal chargés (OCR imparfait sur PDF scanne, HTML avec du bruit de navigation), des chunks mal decoupes (trop courts, trop longs, coupant des idées a mi-chemin) ou un modèle d'embedding inadequat pour la langue ou le domaine degradent irreversiblement le retrieval en aval.
Phase de requete : retrouver, reranker, générer
La phase de requete comporte trois étapes. (1) La question de l'utilisateur est embeddée avec exactement le même modèle d'embedding que lors de l'indexation — un modèle different produirait des vecteurs dans des espaces incompatibles. (2) Recherche de similarite dans la base vectorielle : les k vecteurs les plus proches (typiquement k=5 a 20 selon le contexte) sont retrouves par similarite cosinus, dot product ou distance euclidienne. (3) Les chunks correspondants sont injectes dans le prompt avec des instructions claires : 'Reponds a la question suivante en te basant uniquement sur les documents ci-dessous. Si la réponse ne figure pas dans les documents, dis-le explicitement. Documents : [chunks]. Question : [question]'. Le LLM génère alors une réponse ancrée dans les documents fournis.
Un etage de reranking optionnel (mais fortement recommande) s'intercale entre le retrieval et la génération : les k candidats initiaux sont re-scores par un cross-encoder plus precis, et seulement les top-m (m < k) sont injectes dans le prompt. Cela évite d'envoyer des passages peu pertinents qui polluent le contexte.
Hybrid search : combiner la sémantique et les mots-clés
La recherche vectorielle pure (dense retrieval) excelle pour la similarite sémantique — elle retrouve des passages conceptuellement proches même avec des mots differents. Mais elle performe moins bien pour les requetes sur des termes spécifiques : noms propres, numéros de version, codes de produit, termes techniques rares. La recherche par mots-clés (sparse retrieval — BM25 ou TF-IDF) est au contraire excellente pour ces cas mais ne comprend pas la sémantique.
Le hybrid search combine les deux : on calcule un score de pertinence dense (vectoriel) et un score sparse (BM25), on les fusionne via Reciprocal Rank Fusion (RRF) ou une combinaison pondérée, et on retrouve les passages les mieux classes dans les deux dimensions. Pinecone, Weaviate et Qdrant supportent le hybrid search nativement. Elasticsearch et OpenSearch proposent aussi cette combinaison. C'est l'approche recommandée en production : le gain de précision sur les requetes mixtes (sémantiques + termes spécifiques) est généralement significatif.
Embeddings : la représentation sémantique des textes
Un embedding est une représentation numerique (vecteur de 384 a 3072 dimensions selon les modèles) qui capture le sens sémantique d'un texte dans un espace vectoriel continu. Deux textes semantiquement proches ont des vecteurs proches dans cet espace, même s'ils n'utilisent pas les mêmes mots — et c'est ce qui permet la recherche sémantique.
Cette propriete emerge de l'entraînement du modèle sur des millions de paires de textes similaires et dissimilaires. 'Voiture' et 'automobile' sont proches dans l'espace d'embedding. 'Banque financiere' et 'banque de riviere' sont eloignées — la disambiguation contextuelle est capturée. La recherche par mots-clés (BM25, TF-IDF) ne capte pas cette sémantique : elle retrouve des documents qui contiennent exactement les mêmes termes, pas des documents conceptuellement équivalents.
Choisir son modèle d'embedding
text-embedding-3-small (1536 dimensions) et text-embedding-3-large (3072 dimensions) d'OpenAI offrent un excellent rapport qualité/prix et sont les choix les plus utilises dans les applications en production. Cohere Embed v3 est particulièrement fort sur les cas multilingues et supporte des modes query vs document (les vecteurs de requete et de document sont générés avec des instructions differentes pour maximiser la précision du retrieval).
Les modèles open-source Hugging Face (sentence-transformers) permettent un déploiement on-premise sans dépendance a une API externe. Pour le francais et le multilingue : paraphrase-multilingual-mpnet-base-v2, multilingual-e5-large (Microsoft), ou les modèles CamemBERT-based pour le francais pur. Le MTEB Leaderboard (Massive Text Embedding Benchmark) de Hugging Face est la référence pour comparer les performances des modèles selon la langue et le type de tache.
Métriques de similarite : cosine, dot product, euclidean
La métrique de similarite détermine comment on mesure la 'proximite' entre deux vecteurs. La similarite cosinus mesure l'angle entre deux vecteurs — elle est insensible a la norme (la magnitude) et excelle pour comparer des textes de longueurs differentes. C'est la métrique par defaut pour les embeddings de texte. Le dot product (produit scalaire) mesure la magnitude et la direction — il est équivalent a la cosinus similarity si les vecteurs sont normalisés (norme = 1), ce qui est souvent le cas des modèles modernes. La distance euclidienne mesure la distance geometrique entre deux points — moins utilisée pour le texte car elle depend de la norme des vecteurs.
En pratique : pour les modèles OpenAI et la plupart des modèles commerciaux, les vecteurs sont normalisés et les trois métriques donnent des résultats similaires. Vérifier la documentation du modèle choisi pour la métrique recommandée et configurer la base vectorielle en conséquence.
Le MTEB (Massive Text Embedding Benchmark) de Hugging Face evalue les modèles d'embedding sur 56 taches dans 112 langues (retrieval, classification, clustering, semantic similarity). C'est la référence pour choisir un modèle selon sa langue cible et son type de tache. Les classements varient significativement : un modèle excellent en anglais peut être mediocre en francais.
Muennighoff et al. - MTEB: Massive Text Embedding Benchmark, 2023Bases de données vectorielles : index, outils et choix
Une base de données vectorielle stocke des vecteurs et permet la recherche par similarite a grande échelle (millions a milliards de vecteurs) avec des temps de réponse milliseconde, en utilisant des index spécialisés qui rendent la recherche exacte approximative mais extremement rapide.
Index HNSW vs IVF : comment ca marche
HNSW (Hierarchical Navigable Small World) est l'index vectoriel le plus populaire pour les applications RAG. Il construit un graphe hiérarchique ou les noeuds proches sont connectes a plusieurs niveaux — la recherche navigue du niveau le plus grossier au plus fin, eliminant rapidement les vecteurs eloignes. HNSW offre d'excellents compromis précision/vitesse et supporte les insertions incrementales sans reconstruction de l'index. Pinecone, Weaviate, Qdrant et pgvector utilisent HNSW.
IVF (Inverted File Index) divise l'espace vectoriel en clusters (cellules Voronoi) et assigne chaque vecteur a son cluster le plus proche lors de l'indexation. La recherche ne parcourt que les n cellules les plus proches du vecteur requete. IVF est très efficace pour les très grands volumes (milliards de vecteurs) mais moins precis que HNSW sur des volumes plus petits, et ne supporte pas bien les insertions incrementales (nécessite une reindexation périodique). FAISS (Facebook AI Similarity Search) est la librairie de référence pour l'IVF a très grande échelle.
Solutions managées : Pinecone, Weaviate Cloud, Qdrant Cloud
Pinecone est le service vectoriel manage le plus repandu en production : API simple, scalabilite automatique, filtrage par métadonnées, support hybrid search natif (dense + sparse). Sa limitation est le coût a grande échelle et l'absence de self-hosting. Weaviate est open-source avec une offre cloud managée : il supporte le multi-tenancy (important pour les applications SaaS avec plusieurs clients), une API GraphQL, et des modules d'embedding intègres (possibilité de deleguer l'embedding a Weaviate). Qdrant est une alternative open-source en Rust, très performante sur les benchmarks ANN et particulièrement efficace en mémoire.
pgvector et Chroma : integrations et prototypage
pgvector est une extension PostgreSQL qui ajoute un type de colonne vector et des operateurs de similarite (cosine, dot product, L2). Son avantage majeur est architectural : pas de nouvelle infrastructure — les embeddings et les données relationnelles coexistent dans la même base PostgreSQL, permettant des requetes SQL hybrides qui combinent filtres métadonnées et recherche vectorielle. Supabase, Neon et Timescale proposent pgvector nativement. Sa limite est la performance au-dela de quelques millions de vecteurs — l'index HNSW de pgvector reste moins optimise que les bases vectorielles dédiées.
Chroma est la base vectorielle open-source la plus légère et la plus simple a mettre en oeuvre : une API Python en quelques lignes, persistance sur disque ou en mémoire, idéal pour le prototypage et les applications de faible volume. LanceDB est une alternative récente (format Lance, conçu pour les Lakehouses) qui stocke les vecteurs en fichiers Lance sur disque ou S3 et offre de très bonnes performances sans serveur.
Chunking et reranking : les deux leviers qualité du RAG
La qualité d'un système RAG depend autant du chunking et du reranking que du LLM de génération. Un chunking inadequat produit des passages incoherents qui degradent irreversiblement la réponse finale, quand bien même le modèle de génération serait excellent.
Stratégies de chunking : fixed-size, sémantique, hiérarchique
Fixed-size chunking (500-1000 tokens avec overlap de 10-20 %) est la stratégie la plus simple : on découpe le texte en fenêtres de taille fixe avec un chevauchement pour éviter de couper des phrases. Simple a implementer, fonctionnel sur des textes homogènes, mais peut couper des raisonnements a mi-chemin. L'overlap permet de retrouver les passages coupes quelle que soit la fenêtre qui les contient.
Semantic chunking détecte les frontieres naturelles du texte (fins de paragraphes, changements de sujet mesures par la distance cosinus entre phrases consecutives) et découpe a ces frontieres — les chunks respectent la cohérence logique du document. Parent-child chunking (ou Small-to-Big retrieval) indexe des chunks fins (enfants) mais injecte dans le prompt des chunks larges (parents) qui contiennent les enfants retrouves — on retrouve de la précision avec les petits chunks mais on injcete le contexte complet. Propositional chunking découpe le document en propositions atomiques (une idée par chunk) — très précise pour les documents factuels.
Reranking : cross-encoder pour une pertinence fine
La recherche vectorielle retrouve les k passages les plus proches semantiquement du vecteur requete, mais la proximite sémantique dans l'espace d'embedding ne garantit pas la pertinence spécifique pour répondre a la question. Un passage sur 'les voitures electriques' peut être semantiquement proche d'une question sur 'les batteries des vehicules autonomes' sans répondre a la question.
Le reranking passe les top-k candidats dans un cross-encoder — un modèle plus puissant qui prend en entrée la paire (question, passage) et produit un score de pertinence directe. Les cross-encoders voient les deux textes simultanément et capturent les interactions fines entre la question et le passage, contrairement aux bi-encoders (modèles d'embedding) qui encodent les deux séparément. Cohere Rerank, Jina Reranker v2 et les cross-encoders de sentence-transformers (ms-marco-MiniLM-L-6-v2, bge-reranker-v2-m3) sont les solutions les plus utilisées. Le coût est justifie : le reranking s'applique seulement aux k candidats pre-sélectionnés (typiquement 10 a 20), pas a toute la base.
Le RAG réduit mais n'élimine pas les hallucinations. Le LLM peut inventer des details non présents dans les documents fournis, creer des syntheses incorrectes entre plusieurs passages, ou ignorer des passages pertinents retrouves. Des garde-fous sont nécessaires : prompts avec instruction explicite 'ne reponds que sur les documents fournis', citation obligatoire des sources, score de confiance, et évaluation automatisée avec RAGAS (Faithfulness, Answer Relevancy, Context Precision, Context Recall).
RAG avance : GraphRAG, Self-RAG, HyDE et Agentic RAG
Le RAG de base (naive RAG) présente des limites bien documentées : la recherche vectorielle rate des passages pertinents si la question est ambigue ou très differente dans sa formulation du texte des documents, le contexte injecte peut être insuffisant pour les questions multi-hop (qui nécessitent plusieurs passages relies), et le LLM ne vérifie pas la pertinence de ce qu'il recoit. Les patterns RAG avances répondent a ces limites.
Transformation de la requete : HyDE, décomposition et reformulation
HyDE (Hypothetical Document Embeddings) inverse la logique du retrieval : au lieu d'embedder la question et chercher les passages proches, on demande d'abord au LLM de générer un document hypothetique qui repondrait a la question, puis on embede ce document hypothetique pour chercher les passages réels les plus proches. Le document hypothetique a un style et un vocabulaire similaires aux documents de la base, ce qui améliore la précision du retrieval sur des questions formulées très différemment du corpus.
La décomposition de requete (Query Décomposition) divise les questions complexes multi-hop en sous-questions simples, retrouve des passages pour chaque sous-question indépendamment, puis combine les réponses. Step-Back Prompting demande au LLM de reformuler la question en une question plus generale avant le retrieval — utile pour les questions très spécifiques qui ne matchent pas de passages directs. Ces techniques sont disponibles dans LangChain et LlamaIndex.
GraphRAG : le retrieval sur des graphes de connaissances
GraphRAG (popularise par Microsoft Research en 2024) remplace la base vectorielle par un graphe de connaissances extrait automatiquement des documents via LLM. Les entités (personnes, concepts, produits, événements) et leurs relations sont extraites et stockées dans un graphe, puis le retrieval parcourt ce graphe pour retrouver les informations liées a la question — au lieu de faire une similarite vectorielle sur des passages bruts.
L'avantage est majeur pour les questions qui nécessitent de synthetiser des informations dispersées dans le document : 'Quels sont tous les partenaires mentionnes dans les rapports des 3 derniers trimestres ?' est une question difficile en RAG vectoriel (il faut retrouver et aggreger des passages sur 3 périodes) mais naturelle en GraphRAG (on parcourt le graphe d'entités 'Partenaire'). La limite est le coût de construction du graphe (extraction LLM couteuse) et la maintenance quand les documents changent.
Self-RAG et Agentic RAG
Self-RAG (Asai et al. 2023) est un LLM fine-tune pour decider dynamiquement s'il doit retrouver des documents ou non pour chaque sous-question, et pour auto-evaluer la pertinence et la fidelite de sa propre réponse via des tokens speciaux (Retrieve, IsRel, IsSup, IsUse). Il est plus precis et moins couteux que le RAG systématique car il ne retrouve des documents que quand nécessaire.
L'Agentic RAG transforme le pipeline en boucle agentique : un orchestrateur LLM decide dynamiquement des outils a utiliser (recherche vectorielle, recherche web, exécution SQL, API tierces), peut refaire un retrieval si le premier est insuffisant, et itere jusqu'a obtenir une réponse satisfaisante. LangGraph, LlamaIndex Workflows et AutoGen sont les frameworks les plus utilises pour implementer des Agentic RAG. C'est l'approche des systèmes RAG les plus sophistiques en production (assistants IA d'entreprise, agents de recherche autonome).
Le papier 'From Local to Global: A Graph RAG Approach to Query-Focused Summarization' (Edge et al., Microsoft Research, 2024) a formalise l'approche GraphRAG et montre des gains significatifs sur les questions nécessitant une synthese globale d'un corpus (global sensemaking). L'implementation open-source de Microsoft est disponible sur GitHub sous microsoft/graphrag.
Edge et al. - From Local to Global: A Graph RAG Approach, Microsoft Research, 2024Ancrer les concepts RAG avec la répétition espacée
Le RAG combine des concepts de NLP (embeddings, similarity search, cross-encoder), d'infrastructure (bases vectorielles, index HNSW/IVF, latence) et d'architecture système (pipeline, hybrid search, orchestration agentique). La multiplicite des composants et des patterns avances rend la memorisation par relecture peu efficace — les flashcards sont particulièrement adaptées pour maintenir une vision claire de chaque brique et de leurs interactions.
Les decks Memia 'RAG et architectures LLM', 'Embeddings et bases vectorielles' et 'IA Générative et LLM' couvrent les définitions, les distinctions subtiles (HNSW vs IVF, cosine vs dot product, RAG vs fine-tuning) et les questions d'architecture système les plus fréquentes en entretien ML Engineer et Data Engineer.
Les concepts les plus fréquents en entretien : (1) Différence RAG vs fine-tuning vs long context (avec les trade-offs). (2) Les 4 étapes du pipeline RAG (indexation, embedding, retrieval, génération). (3) HNSW vs IVF : quand utiliser chacun. (4) Hybrid search dense + sparse : pourquoi et comment. (5) Reranker cross-encoder vs bi-encoder. (6) HyDE : inverser la requete pour améliorer le retrieval. (7) RAGAS : les 4 métriques d'évaluation (Faithfulness, Answer Relevancy, Context Precision, Context Recall).
Approfondir le cluster Data & IA
Questions fréquentes sur le RAG et la génération augmentée
Qu'est-ce que le RAG (Retrieval Augmented Generation) ?
Le RAG est une architecture qui augmente les réponses d'un LLM en lui fournissant des passages de documents pertinents retrouves en temps réel. Plutot que de répondre de mémoire (avec le risque d'hallucination et de données perimées), le LLM base sa réponse sur les documents injectes dans son prompt. Cela permet d'interroger un LLM sur des données internes spécifiques sans reentainement couteux.
Quelle est la différence entre RAG et fine-tuning ?
Le RAG ajoute du contexte au moment de l'inference — les documents sont retrouves et injectes dans le prompt a chaque requete. Flexible, les données peuvent être mises a jour sans reentainement. Le fine-tuning modifie les poids du modèle pour adapter son comportement de façon permanente — couteux, rigide, adapte pour le style ou les connaissances très stables. Pour des données qui changent souvent : RAG. Pour adapter le comportement permanent du modèle : fine-tuning.
Qu'est-ce qu'un embedding et pourquoi est-il utile pour le RAG ?
Un embedding est une représentation vectorielle numerique d'un texte qui capture son sens sémantique. Deux textes semantiquement proches ont des vecteurs proches dans l'espace d'embedding, même avec des mots differents. Le RAG utilise les embeddings pour retrouver les passages conceptuellement proches de la question — ce que la recherche par mots-clés exacte ne permet pas.
Quelles sont les principales bases de données vectorielles ?
Pinecone (service manage, API simple, hybrid search natif), Weaviate (open-source + cloud, multi-tenancy, GraphQL), Qdrant (open-source haute performance en Rust), pgvector (extension PostgreSQL, idéal si vous etes deja sur Postgres/Supabase), Chroma (léger, open-source, idéal pour prototypage) et LanceDB (format Lance, sans serveur, bon pour les Lakehouses). Le choix depend du volume, de l'infrastructure existante et des besoins de filtrage.
Qu'est-ce que le hybrid search dans un RAG ?
Le hybrid search combine la recherche vectorielle (dense retrieval — sémantique, capte les synonymes et la sémantique) et la recherche par mots-clés (sparse retrieval — BM25, excellente pour les termes spécifiques, noms propres, codes de produit). Les scores sont fusionnes via Reciprocal Rank Fusion (RRF). En production, le hybrid search surpasse systématiquement le vectoriel pur pour les requetes métier qui melangent sémantique et termes spécifiques.
Qu'est-ce que le chunking et comment choisir sa stratégie ?
Le chunking est le découpage des documents en passages de taille appropriée avant l'indexation. Fixed-size chunking (500-1000 tokens avec overlap) est simple et fonctionnel. Semantic chunking respecte les frontieres naturelles (paragraphes, changements de sujet). Parent-child chunking indexe des chunks fins mais injecte des chunks larges dans le prompt — combine précision du retrieval et richesse du contexte. La taille optimale depend du type de contenu et de la fenêtre de contexte du LLM.
Qu'est-ce que le reranking dans un pipeline RAG ?
Le reranking est une étape d'affinage après le retrieval initial. La recherche vectorielle retrouve les k candidats les plus proches semantiquement. Un cross-encoder (modèle plus precis qui voit la paire question+passage simultanément) re-score chaque candidat pour la pertinence spécifique a la question. Seuls les top-m passages re-classes sont envoyes au LLM. Cohere Rerank, Jina Reranker et les cross-encoders sentence-transformers sont les solutions les plus utilisées.
Le RAG élimine-t-il les hallucinations des LLM ?
Non, le RAG réduit mais n'élimine pas les hallucinations. Le LLM peut inventer des details non présents dans les documents fournis, creer des syntheses incorrectes, ou ignorer des passages pertinents retrouves. Des mesures supplémentaires sont nécessaires : prompts avec instruction 'ne reponds que sur les documents fournis', citation obligatoire des sources, et évaluation automatisée avec RAGAS (Faithfulness, Answer Relevancy, Context Precision, Context Recall).
Qu'est-ce que HyDE (Hypothetical Document Embeddings) ?
HyDE est une technique qui inverse la logique du retrieval : au lieu d'embedder la question et chercher les passages proches, on demande d'abord au LLM de générer un document hypothetique qui repondrait a la question, puis on embede ce document hypothetique pour retrouver les passages réels les plus proches. Le document hypothetique a un style proche des documents du corpus, ce qui améliore la précision du retrieval quand la question est formulée très différemment.
Qu'est-ce que le GraphRAG ?
GraphRAG (Microsoft Research, 2024) remplace la base vectorielle par un graphe de connaissances extrait automatiquement des documents via LLM. Les entités et leurs relations sont stockées dans un graphe, et le retrieval parcourt ce graphe pour retrouver les informations liées. L'avantage est pour les questions nécessitant une synthese de multiples entités liées ('tous les partenaires mentionnes dans 3 rapports') — difficiles en RAG vectoriel mais naturelles en GraphRAG.