Un pipeline RAG comporte trois étapes : l'indexation, la recherche et la génération. Pendant l'indexation, vous prenez vos documents — PDF, pages web, enregistrements de base de données, peu importe — les découpez en fragments, passez chaque fragment dans un modèle d'embedding pour obtenir un vecteur, et stockez ces vecteurs dans une base de données vectorielle comme Qdrant, Pinecone ou Weaviate. Pendant la recherche, la requête de l'utilisateur est convertie en embedding avec le même modèle, et la base de données vectorielle retourne les k fragments les plus similaires (typiquement 3 à 10). Pendant la génération, ces fragments sont insérés dans le prompt du modèle comme contexte, et le modèle génère une réponse ancrée dans ce matériel. Le cycle complet — convertir la requête en embedding, chercher, assembler le prompt, générer — prend typiquement de 1 à 3 secondes.
Le découpage est là où la plupart des systèmes RAG réussissent ou échouent, et c'est plus subtil qu'il n'y paraît. Des fragments trop petits et vous perdez le contexte ; trop grands et vous gaspillez de l'espace précieux de la fenêtre de contexte sur du texte non pertinent. Un point de départ courant est de 500 à 1 000 tokens par fragment avec un chevauchement de 10 à 20 % entre fragments adjacents (pour ne pas perdre l'information qui chevauche une frontière). Mais le découpage naïf à taille fixe coupe souvent les phrases en deux ou sépare un titre de son contenu. Les approches plus sophistiquées utilisent la structure du document — découpage sur les titres, les sauts de paragraphe ou les changements sémantiques — pour créer des fragments autonomes et significatifs. Le RecursiveCharacterTextSplitter de LangChain et le SentenceSplitter de LlamaIndex tentent tous deux de gérer cela, mais les meilleurs résultats viennent généralement de la compréhension de vos documents spécifiques et de l'écriture d'une logique de découpage personnalisée.
L'étape de recherche offre plus d'options que les gens ne le réalisent. La recherche pure par similarité vectorielle (recherche de plus proches voisins dans l'espace d'embedding) est le défaut, mais elle a du mal avec les correspondances exactes de mots-clés, les noms propres et les identifiants de code. C'est pourquoi la recherche hybride est devenue la norme dans les systèmes en production : vous exécutez à la fois une recherche vectorielle et une recherche par mots-clés traditionnelle (BM25), puis combinez les résultats avec une fusion de rangs réciproques ou un reclasseur appris. Qdrant, Weaviate et Elasticsearch prennent tous en charge la recherche hybride nativement. Le reclassement — prendre les 20 à 50 premiers résultats de la recherche et les noter avec un modèle cross-encoder — ajoute de la latence mais améliore considérablement la pertinence. Cohere Rerank et les modèles cross-encoder de Hugging Face sont les choix courants ici.
Une idée reçue courante est que le RAG élimine l'hallucination. Il la réduit significativement, mais un modèle peut toujours halluciner des détails qui ne sont pas dans les fragments récupérés, surtout si les fragments sont tangentiellement liés à la requête plutôt que d'y répondre directement. Les bons systèmes RAG atténuent cela en incluant des exigences de citation dans les instructions du prompt (« répondez uniquement à partir du contexte fourni, citez vos sources »), en filtrant les fragments de faible pertinence (en définissant un seuil de similarité minimum plutôt que de toujours retourner les top-k), et en laissant le modèle dire « je n'ai pas assez d'informations » quand le contexte récupéré ne répond véritablement pas à la question. Certaines équipes ajoutent une étape de vérification où un second appel au modèle vérifie si la réponse est réellement soutenue par les sources.
Le RAG a été introduit dans un article de 2020 par Facebook AI Research (maintenant Meta AI), mais il n'est devenu un patron de production courant qu'en 2023, quand les bases de données vectorielles et les API d'embedding ont suffisamment mûri pour le rendre pratique. Le patron a depuis évolué dans plusieurs directions : GraphRAG utilise des graphes de connaissances à la place de (ou en plus de) la recherche vectorielle pour une meilleure gestion des questions relationnelles. Le RAG agentique donne au modèle la capacité de reformuler les requêtes, chercher dans plusieurs sources et itérer sur la recherche plutôt que de faire une seule recherche. Et l'expansion des fenêtres de contexte — les modèles gèrent maintenant plus de 100 000 tokens — a conduit certaines équipes à abandonner le RAG entièrement pour les bases de connaissances plus petites, en injectant tout dans le prompt. Cette approche fonctionne pour quelques centaines de pages de documentation mais s'effondre à grande échelle, là où le RAG reste essentiel.