Le RAG avancé en production : architecture, outils et compromis.

La génération augmentée par la recherche associe une étape de recherche à un modèle de langage. Les documents sont ingérés et indexés à l’avance ; les parties pertinentes sont récupérées lorsqu’une question arrive, et le modèle rédige sa réponse à partir de ces éléments. Cependant, en environnement de production, RAG n’est que rarement simplement une base de données vectorielle associée à un LLM. Les systèmes réels intègrent également une analyse structurée des documents, un découpage tenant compte de la structure, une recherche dense et par mots-clés, un réclassement, une construction de contexte, ainsi que des mécanismes d’évaluation et d’observabilité.

Ce qui suit se concentre sur les outils largement utilisés dans les systèmes réels, en omettant la grande variété de techniques expérimentales.

Aperçu du pipeline

Un pipeline avancé et pratique commence par l’ingestion, le parsing et le nettoyage, puis par la segmentation en blocs, l’ajout de métadonnées, les embeddings et l’indexation. Lors de la requête, on passe par la compréhension de celle-ci, une recherche hybride, la fusion des résultats et un réclassement, suivis de la compression du contexte, de la génération avec des citations, et enfin de l’évaluation et de l’observabilité. Le stack exact dépend des types de documents, de l’échelle, des objectifs de latence, des règles de confidentialité, du budget et des exigences de qualité.

Ingestion

Fichiers locaux. Python, avec pathlib, PyPDF, python-docx, openpyxl et pandas, permet de traiter efficacement les PDF, les fichiers Word, les feuilles de calcul, les CSV et le texte brut, et s’intègre facilement dans des tâches par lots. Le problème est que chaque format nécessite son propre analyseur ; les PDF scannés et complexes exigent une extraction spécialisée, tandis que les gros volumes de travail requièrent du parallélisme et un traitement incrémentiel.

Stockage d’objets. Amazon S3, Google Cloud Storage et Azure Blob Storage offrent un hébergement fiable et scalable pour de grandes collections, et s’intègrent naturellement à des processus d’ingestion asynchrone. Vous payez pour la mise en place dans le cloud, les mécanismes de contrôle d’accès ainsi que les coûts de stockage et de transfert qui augmentent avec l’échelle.

Sources web et API. Des outils tels que requests ou httpx, BeautifulSoup, Playwright et Firecrawl maintiennent une base de connaissances à jour en extrayant des contenus depuis des sites, des API et des pages dynamiques. Les sites modifient leur structure, les pages riches en JavaScript nécessitent une automatisation du navigateur, et le crawl entraîne des limites de vitesse, des pages dupliquées ainsi qu’une qualité de contenu inégale.

Analyse et extraction

Unstructured accepte les fichiers PDF, Word, HTML, PowerPoint, des images et bien d’autres, et extrait des éléments tels que les titres, les paragraphes et les tableaux, ce qui en fait une couche polyvalente efficace. Il est plus lent que les méthodes d’extraction de texte simples, et les documents complexes peuvent encore nécessiter un traitement personnalisé.

PyMuPDF est rapide pour extraire le texte et les métadonnées des PDF basés sur du texte, et s’intègre facilement dans du code Python. Ce n’est pas un système complet de compréhension des documents, donc les fichiers scannés nécessitent du OCR, et les mises en page ou tableaux complexes exigent des efforts supplémentaires.

Apache Tika prend en charge une très large gamme de formats et dispose d’outils avancés pour le texte et les métadonnées issus de collections mixtes. Il n’est pas optimisé pour une compréhension moderne des mises en page, ce qui oblige à utiliser d’autres outils pour les layouts visuels complexes.

OCR et extraction basée sur la vision

Tesseract est open source, s’exécute localement et fonctionne bien avec du texte imprimé ordinaire. L’écriture manuscrite et les mises en page complexes réduisent sa précision, et les scans de mauvaise qualité nécessitent un prétraitement.

PaddleOCR propose une solution efficace pour la détection et la reconnaissance de texte dans de nombreuses langues, adaptée aux documents scannés et à l’extraction structurée. Les documents complexes peuvent toutefois nécessiter un post-traitement de la mise en page, et son déploiement peut impliquer des dépendances de modèles supplémentaires.

Les modèles vision-langage tels que ceux de la catégorie GPT-4, Gemini et la famille Qwen-VL comprennent le texte, les images, les graphiques ainsi que la mise en page des pages, ce qui est utile lorsque l’OCR seul perd le contexte visuel et permet une extraction multimodale. Ils coûtent plus cher que les OCR classiques, répondent plus lentement et génèrent des résultats non déterministes qui doivent être validés.

Chunking

Le découpage détermine quelle unité pourra être récupérée. Un mauvais découpage sépare des informations pertinentes ou rassemble du matériel non lié.

• Découpage récursif des caractères (RecursiveCharacterTextSplitter de LangChain) constitue une base fiable qui cherche à respecter les limites des paragraphes et des phrases et est facile à ajuster. Il fonctionne sur la syntaxe plutôt que sur le sens, et une taille fixe ne convient pas à tous les documents.
• Découpage basé sur des tokens divise les blocs en fonction des tokens du modèle, ce qui aide à respecter les limites de la fenêtre de contexte. Les frontières des tokens ne coïncident pas nécessairement avec celles du sens.
• Découpage sémantique cherche des changements de sujet en utilisant la similarité, ce qui permet aux idées cohérentes de rester ensemble plus efficacement qu’avec des tailles fixes. Il nécessite plus de ressources informatiques, des embeddings et dépend d’un seuil à choisir.

Chunking parent-enfant récupère de petits fragments enfants mais les agrandit pour former un fragment parent plus large afin de fournir un contexte, améliorant ainsi la précision sans perdre les éléments environnants. L’indexation et les relations de métadonnées deviennent plus complexes, et un contexte plus large augmente le coût de traitement des tokens.

Chunking conscient de la structure suit les titres, sections, tableaux et paragraphes, ce qui est avantageux pour les documents techniques et d’entreprise. Il dépend d’une analyse fiable, et différents types de documents nécessitent des règles distinctes.

Métadonnées

Les champs typiques incluent l’ID du document, le nom du fichier, le numéro de page, la section, l’auteur, l’heure de création, le type de document, l’utilisateur ou le propriétaire, les permissions d’accès, l’URL source et la version. De bons métadonnées permettent de filtrer avant ou pendant la récupération, de gérer les citations et le contrôle d’accès, ainsi que d’améliorer la précision. D’un autre côté, des métadonnées faibles réduisent directement la qualité de la récupération, et les schémas deviennent plus difficiles à maintenir dans des sources mixtes.

Embeddings

Les embeddings transforment du texte en vecteurs qui capturent le sens.

• Les embeddings d’OpenAI sont gérés, de haute qualité et faciles à utiliser, offrant une récupération polyvalente efficace. Les inconvénients sont le coût de l’API, la dépendance vis-à-vis du fournisseur, ainsi que le fait que l’envoi de données pourrait ne pas convenir aux environnements sensibles.

BGE est une famille de moteurs de recherche open source puissants que vous pouvez héberger vous-même, avec des variantes pour la recherche dense et le reranking. L’hébergement propre nécessite une infrastructure, et le choix du modèle ainsi que sa dimensionnalité influencent le stockage et la latence.

E5 est une famille open populaire offrant de solides capacités de recherche générale ainsi que des variantes basées sur des instructions ou des préfixes. Certaines variantes exigent un formatage précis des requêtes et des documents, et son exécution personnelle ajoute une charge de travail opérationnelle.

Cohere Embed est une API gérée qui assure de bonnes performances en recherche multilingue et pour les entreprises selon la version du modèle, et elle est facile à déployer. Cependant, elle entraîne des coûts liés à l’API ainsi qu’une dépendance externe.

Jina embeddings sont des modèles orientés recherche, certains prenant en charge de longs contextes et plusieurs langues. Leurs capacités varient selon la version, et les modèles open source nécessitent une infrastructure pour être hébergés.

Bases de données vectorielles

• pgvector ajoute la recherche vectorielle à PostgreSQL, regroupant les données relationnelles, les métadonnées et les vecteurs en un seul endroit, ce qui est idéal si l’application utilise déjà Postgres. Les charges de travail vectorielles très volumineuses peuvent nécessiter des systèmes spécialisés, et l’escalade devient plus complexe à grande échelle.
• Pinecone est une base de données vectorielle gérée qui s’adapte sans effort d’infrastructure et offre un filtrage adapté à l’environnement de production. Vous payez pour le service, dépendez du fournisseur et renoncez à une partie du contrôle.
• Qdrant est disponible en version open source ou dans le cloud, permet un bon filtrage sur les métadonnées, prend en charge la récupération dense et hybride, et convient aux solutions RAG auto-hébergées. L’auto-hébergement implique des tâches opérationnelles, et les configurations distribuées nécessitent une planification minutieuse des capacités.

Weaviate propose des fonctionnalités avancées de récupération de données, de recherche hybride et de filtrage des métadonnées, que ce soit en mode cloud ou auto-hébergé. Plus de fonctionnalités peuvent entraîner une complexité accrue du système, et les charges de travail importantes nécessitent des ajustements.

Chroma est adapté aux développeurs et pratique pour les prototypes ainsi que les applications de petite taille, grâce à une intégration simple avec Python. Il n’est généralement pas le premier choix pour les déploiements d’entreprise très importants, où l’échelle et les opérations revêtent une importance plus grande.

FAISS est une bibliothèque très populaire pour des recherches de similarité rapides et des expérimentations locales sans base de données externe. Il s’agit d’une bibliothèque de recherche et non d’une base de données distribuée, ce qui exige des développements supplémentaires en matière de persistance, de filtrage, de multi-tenancy et de distribution.

Récupération des données

Recherche vectorielle dense : elle associe une base de données vectorielle à un modèle d’embedding pour trouver du contenu sémantiquement similaire, en gérant mieux les paraphrases que les mots-clés. Elle peut néanmoins manquer des identifiants exacts, des termes rares, des codes et des nombres, et sa qualité dépend fortement du modèle d’embedding ainsi que de la méthode de segmentation.

BM25 est une méthode lexicale puissante, excellente pour les termes exacts, les noms, les IDs et les mots-clés techniques ; elle est en outre simple et facile à interpréter. Cependant, elle ne prend pas en compte la similarité sémantique, ce qui fait que les synonymes et les paraphrases échappent à sa détection.

Recherche hybride : elle combine généralement BM25 avec la recherche dense, associant précision lexicale et portée sémantique afin d’obtenir des résultats plus fiables pour différents types de requêtes. Elle nécessite une fusion des scores ou des rangs, ainsi que des infrastructures et des ajustements supplémentaires par rapport à un seul moteur de recherche.

Transformation de la requête

• Réécriture de la requête transforme des entrées conversationnelles ou vagues en quelque chose adapté à la recherche, ce qui facilite les questions ultérieures. Une mauvaise réécriture peut éliminer des informations clés et augmente la latence ainsi que le coût du LLM.
• Rétrieval multi-requêtes fait en sorte que le modèle écrive plusieurs requêtes alternatives et effectue des recherches pour chacune, améliorant ainsi le taux de rappel et couvrant différentes formulations. Cela entraîne plus d’appels de recherche, plus de latence et de coûts, ainsi que parfois des recherches irrelevantes.
• HyDE (Hypothetical Document Embeddings) génère une réponse fictive et l’incorpore dans le processus de recherche, ce qui peut aider pour des requêtes difficiles ou lorsque le vocabulaire de la question diffère fortement de celui des documents. Cela nécessite un appel supplémentaire au LLM, et un document hypothétique de mauvaise qualité peut fausser les résultats.

Fusion

Fusion des classements réciproques combine les classements provenant de plusieurs systèmes de récupération. Elle est simple, fiable et fonctionne bien avec les méthodes dense ainsi que BM25 ; de plus, elle n’a pas besoin que les scores des différents systèmes soient comparables. Elle ajoute une étape de classement tout en conservant des paramètres à ajuster.

Fusion des scores pondérés attribue une importance différente aux signaux denses, sparses ou autres, ce qui est utile lorsque les systèmes de récupération présentent des forces différentes. Les échelles de scores doivent être normalisées et les pondérations dépendent de la charge de travail.

Réclassement

La récupération en première étape doit privilégier le taux de rappel. Le réclassement améliore ensuite la précision sur un ensemble plus restreint de candidats.

Rerankers à encodeur croisé tels que BGE Reranker, Cohere Rerank et Jina Reranker évaluent conjointement chaque paire requête-document, surpassant généralement la similarité basée sur les embeddings simples, et ils fonctionnent bien après une recherche hybride. Ils sont plus coûteux que la recherche vectorielle, il convient donc de les utiliser uniquement sur une liste limitée de candidats.

Reranking par LLM demande à un modèle d’évaluer la pertinence et peut gérer des critères complexes, mais il est lent, consomme beaucoup de tokens et est moins déterministe qu’un reranker dédié.

Maximum Marginal Relevance (MMR) équilibre la pertinence et la diversité, en supprimant les doublons lorsque les résultats top-k sont des passages presque identiques. Il intègre un paramètre de diversité, mais une diversité excessive peut éliminer des éléments pertinents qui se retrouvent simplement en répétition.

Compression du contexte

Compression extractive ne conserve que les phrases ou les segments pertinents, ce qui permet d’économiser des tokens tout en préservant le texte original, mais elle peut supprimer le contexte nécessaire pour comprendre un passage. Compression basée sur des LLM résume le matériel récupéré et peut réduire considérablement le contexte pour de grands documents, au prix d’un coût et d’une latence supplémentaires, avec un risque que la compression elle-même perde des informations ou génère des hallucinations.

Génération

Les choix courants en milieu professionnel sont les modèles OpenAI, Anthropic Claude, Google Gemini, Meta Llama et Qwen. Ils offrent de fortes capacités de raisonnement, et les demandes peuvent être orientées en fonction du coût, de la latence et de la difficulté de la tâche. Les modèles API entraînent des coûts et une dépendance vis-à-vis du fournisseur, les modèles ouverts nécessitent des infrastructures, tandis que les modèles plus gros augmentent la latence et le coût d’inférence.

Frameworks

LangChain dispose d’un écosystème très vaste de chargeurs, de récupérateurs, d’intégrations avec des bases de données vectorielles et d’interfaces de modèles, utile pour composer rapidement des pipelines. Les abstractions peuvent devenir complexes, et les systèmes en production fonctionnent souvent mieux avec une structure de requête simple et explicite.

LlamaIndex se concentre sur l’ingestion, l’indexation et la récupération, offrant des abstractions utiles pour les systèmes RAG axés sur les documents. Il ajoute de la complexité au framework, et certains systèmes avancés passent finalement à des SDK de niveau inférieur.

LangGraph convient aux workflows étatiques, ramifiés et agents, avec une récupération itérative et l’exécution d’outils. Il représente plus de complexité que ce dont a besoin un pipeline simple et exige une gestion rigoureuse de l’état et des pannes.

Modèles avancés

• RAG correctif évalue le contexte récupéré et peut déclencher de nouvelles recherches, en détectant des résultats faibles et en permettant une recherche de secours, au prix d’une latence accrue et d’une complexité plus élevée.
• Self-RAG permet au modèle de décider quand effectuer des recherches et d’évaluer les résultats obtenus. Il s’adapte pour éviter des recherches inutiles, mais sa logique de contrôle est plus complexe et nécessite une évaluation minutieuse ainsi que le soutien d’un modèle adapté.
• RAG agent fait appel à un agent qui planifie les recherches, utilise des outils, récupère des informations de manière itérative et effectue des vérifications, ce qui lui permet de gérer des questions complexes en plusieurs étapes provenant de différentes sources. On peut s’attendre à une latence et des coûts plus élevés, ainsi qu’à davantage de modes de défaillance et à des difficultés accrues pour le débogage.

Graph RAG combine un graphique de connaissances avec des mécanismes de récupération, ce qui permet de gérer les relations entre entités ainsi que les questions à plusieurs étapes que les vecteurs simples ne peuvent pas traiter. La construction de ce graphique est coûteuse, l’extraction des entités entraîne des erreurs et des infrastructures supplémentaires sont nécessaires.

Multimodal RAG récupère et analyse du texte, des images, des tableaux et des graphiques, ce qui le rend adapté aux rapports, aux scans et aux diagrammes ; toutefois, cela nécessite une ingestion et un indexage plus importants ainsi que des coûts plus élevés liés aux modèles de vision.

Données structurées

Text-to-SQL permet au modèle de transformer des questions en langage naturel en requêtes destinées à des bases de données structurées, ce qui est idéal pour l’analyse de données fraîches. Le SQL généré peut être incorrect ou peu sûr, il faut donc recourir à la récupération de schémas, à la validation et au contrôle d’accès.

Texte hybride et SQL RAG utilise la récupération vectorielle ou par mots-clés pour les connaissances non structurées et SQL pour les faits structurés, couvrant les PDF, les documents, les CSV et les bases de données dans une même architecture. Il nécessite une redirection entre les différents modes de fonctionnement, ce qui rend les tests et la sécurité plus complexes.

Évaluation

Un système en production doit faire l’objet d’une évaluation tant au niveau de la récupération que de la génération.

Les métriques de récupération (Recall@K, Precision@K, MRR, NDCG et taux de hits) permettent de déterminer si le système a trouvé les preuves appropriées. Les métriques de génération (fidélité, pertinence de la réponse, exactitude de la réponse, pertinence contextuelle, précision contextuelle et recall contextuel) permettent de vérifier si le modèle a utilisé correctement ces preuves.

Ragas a été conçu pour l’évaluation RAG, couvre les deux niveaux et est utile pour les tests de régression. Beaucoup de ses métriques s’appuient sur des juges basés sur des LLM ou des embeddings, de sorte que les scores ne remplacent pas entièrement l’évaluation humaine et que les modèles de jugement peuvent présenter des biais. L’évaluation humaine est la meilleure méthode pour évaluer la qualité dans des domaines spécifiques et permet de détecter ce que les métriques automatisées manquent, mais elle est coûteuse, lente et nécessite des directives cohérentes.

Observabilité

LangSmith permet de tracer les chaînes d’opérations, les appels de récupération, les prompts et les résultats, et aide à déboguer les pipelines ainsi qu’à comparer des expériences. Il s’agit d’une plateforme gérée qui prend en compte les coûts et la confidentialité des données. Langfuse offre des fonctionnalités de traçage, de gestion des prompts et de suivi des métriques, sous forme open source pouvant être hébergée soi-même ou dans le cloud ; cependant, l’hébergement personnel relève de votre responsabilité et nécessite des outils d’instrumentation. OpenTelemetry est la norme ouverte pour le traçage, les métriques et les journaux, et permet d’intégrer RAG dans des infrastructures existantes, mais cela exige plus de travail d’ingénierie qu’une plateforme prête à l’emploi.

Cachage et performances

Un caché sémantique réutilise les réponses pour des requêtes similaires, réduisant ainsi les appels répétés au LLM, la latence et les coûts. Cependant, des questions similaires peuvent nécessiter des réponses différentes lorsque les données changent, et l’invalidation de ces réponses s’avère difficile. Un caché d’embeddings évite de recalculer les vecteurs pour du texte répété, ce qui constitue un avantage simple, mais dont l’invalidation est obligatoire chaque fois que le modèle d’embeddings change. La récupération asynchrone et parallèle permet de lancer des outils de récupération indépendants en même temps, ce qui diminue la latence globale, bien que la gestion des erreurs devienne plus complexe et que les backends doivent supporter une charge concurrentielle.

Sécurité

• Injection de prompts. Les documents récupérés peuvent contenir des instructions visant à prendre le contrôle du modèle.
• Récupération contrôlée par l’accès. Les utilisateurs ne doivent obtenir que les documents pour lesquels ils sont autorisés à avoir accès.

Gestion des PII. Les données personnelles doivent être identifiées et masquées, ou gérées d’une autre manière, avant d’arriver dans l’index.

Isolement des locataires. Lorsqu’il y a plusieurs utilisateurs, les requêtes nécessitent des filtres de métadonnées tenant compte de ces utilisateurs, et la base de données elle-même doit être séparée.

Toxification des données. Des documents provenant de sources non fiables peuvent être ajoutés délibérément pour induire en erreur.

Aucune instruction unique ne résout les problèmes de sécurité. Il faut des contrôles à chaque étape : ingestion, stockage, récupération, autorisation, exécution des outils et génération de contenu.

Déploiement

Les éléments de base typiques sont FastAPI pour la couche API, Docker pour le packaging, Kubernetes pour l’orchestration à grande échelle, Redis pour le cache, PostgreSQL pour les métadonnées relationnelles, S3, GCS ou Azure Blob pour le stockage d’objets, Prometheus pour les métriques, Grafana pour les tableaux de bord, OpenTelemetry pour le suivi des traitements et MLflow pour le suivi des expériences. L’objectif est un système RAG reproductible, observable, scalable et facile à maintenir, et non pas un système qui ne semble juste précis dans un notebook.

Une stack pratique

Une conception polyvalente solide peut rester assez simple. Les documents passent par Unstructured, PyMuPDF ou PaddleOCR, puis par un découpage tenant compte de la structure ou récursif, ensuite par des embeddings provenant d’OpenAI, BGE, E5 ou Cohere, puis par pgvector, Qdrant ou Pinecone. La récupération s’effectue à l’aide de BM25 combiné à une recherche dense, fusionnée avec RRF, réordonnée par un cross-encoder, compressée avant d’être transmise au LLM, accompagnée de citations pour une référence fiable. Les outils Ragas et les revues humaines évaluent la qualité, tandis que LangSmith, Langfuse ou OpenTelemetry surveillent le temps d’exécution.

Tous les systèmes n’ont pas besoin de tous les composants. Une petite base de connaissances interne peut se contenter de PostgreSQL, pgvector, des embeddings et d’un LLM. Ajoutez une récupération hybride, un réclassement, des boucles agentiques, une récupération graphique et un traitement multimodal uniquement après avoir constaté que la conception plus simple ne suffit pas.

Choisir l’outil adapté

• Texte PDF simple : PyMuPDF. Types de documents mixtes : non structuré. Scans : PaddleOCR. Pages visuellement complexes : modèle vision-langage.
• Fragmentation de base : séparateur récursif. Frontières sémantiques : fragmentation sémantique. Contexte parent et enfant : récupération parent-enfant.
• Embeddings gérés : OpenAI ou Cohere. Embeddings ouverts : BGE ou E5.
• Déjà disponible sur PostgreSQL : pgvector. Stockage vectoriel géré : Pinecone. Auto-hébergé : Qdrant. Prototype : Chroma ou FAISS.
• Recherche basée sur le sens : vecteurs denses. Mots-clés exacts : BM25. Couverture fiable : hybride. Fusion des classements : RRF. Précision améliorée : réclasseur à encodeur croisé. Moins de doublons : MMR.
• Questions complexes à plusieurs étapes : RAG agent. Relations entre entités : Graph RAG. Tables et bases de données : text-to-SQL.

Évaluation : Ragas. Suivi des traces : LangSmith ou Langfuse. Telemétrie standard : OpenTelemetry. API à grande échelle : FastAPI avec Docker ou Kubernetes.

Commencez petit

La plus grande erreur architecturale consiste à considérer le LLM comme l’ensemble du système. La qualité provient de la récupération des données, du contexte fourni, de la génération, puis de l’évaluation et de l’observabilité. Un modèle plus grand ne peut pas compenser de manière fiable l’absence d’informations pertinentes.

Un cycle d’amélioration utile consiste à établir une base de référence, évaluer, identifier l’étape défaillante, modifier un composant, réévaluer, déployer et surveiller. Pour la plupart des systèmes en production, commencez par une analyse solide et un découpage tenant compte de la structure, des embeddings de qualité, une récupération hybride accompagnée d’un reranker, puis ajoutez la génération fondée sur des données concrètes et l’évaluation. Intégrez la récupération agente, Graph RAG, des pipelines multimodaux, des boucles correctives ou le fine-tuning uniquement lorsque des exigences mesurables justifient leur coût et leur complexité.

Une bonne ingénierie RAG consiste moins à collecter toutes les technologies possibles et plus à choisir l’architecture la plus concise qui répond à vos objectifs en matière de qualité, de latence, de coût, de sécurité et de maintenabilité.