Mettre en place un RAG : architecture, chunking, bases vectorielles et évaluation

Qu'est-ce que mettre en place un RAG, et comment cela fonctionne-t-il ?

Mettre en place un RAG consiste à connecter un grand modèle de langage à vos propres connaissances, afin qu'il réponde à partir de vos documents plutôt que de sa mémoire. Au moment de la requête, le système cherche dans votre contenu indexé, sélectionne les passages les plus pertinents, les insère dans le prompt et demande au modèle de répondre avec des citations.

Une architecture RAG de production comporte deux pipelines :

1. Pipeline d'ingestion : connecter les sources, analyser les fichiers, nettoyer le texte, le découper en chunks, créer les embeddings, stocker les chunks avec leurs métadonnées et leurs règles d'accès, et tout garder synchronisé.
2. Pipeline de requête : comprendre la question, lancer une recherche hybride, reclasser les résultats, assembler le prompt, générer la réponse, joindre les citations et tout journaliser pour l'évaluation.

La plupart des échecs de RAG viennent du premier pipeline, pas du modèle. Si un tableau est analysé comme du bruit ou si une politique est coupée en deux, aucun modèle ne peut retrouver la réponse. Ce guide passe en revue chaque étape telle que nous l'abordons chez Lytvynov Production. Pour la partie réalisation, consultez nos services de développement RAG.

Comment ingérer et analyser les documents ?

L'ingestion doit transformer chaque source en texte propre, doté de structure et de métadonnées : titre, intertitres, URL source, auteur, dates, type de document, langue et personnes autorisées à le lire. Consacrez-y un vrai temps, car la qualité de l'analyse fixe le plafond de la qualité des réponses.

Sources courantes et ce qu'elles demandent :

• PDF et fichiers Office : une analyse qui tient compte de la mise en page et conserve intertitres, listes et tableaux ; de l'OCR pour les pages scannées.
• Wikis et centres d'aide (Confluence, Notion, Zendesk, Intercom) : des connecteurs API qui récupèrent aussi les permissions et les dates de mise à jour.
• Tickets, conversations et e-mails : reconstitution des fils, déduplication des réponses citées et suppression des signatures.
• Bases de données et catalogues produits : convertir les enregistrements en textes courts et lisibles, ou les interroger directement via des outils au lieu de les vectoriser.

Normaliser de nombreux formats désordonnés en une seule table propre est souvent la partie la plus difficile. Dans le projet AI Grief Companion, nous avons écrit des parseurs pour dix formats d'export de conversations (WhatsApp, Messenger, Instagram, Discord, iMessage depuis une sauvegarde d'iPhone, SMS Android et d'autres) et les avons tous normalisés dans une seule table de messages avant la moindre étape IA. La même leçon vaut pour les données d'entreprise : investissez d'abord dans un modèle normalisé unique. Notre plateforme de calendrier sportif montre la même rigueur hors IA, avec un moteur d'analyse qui unifie les données de centaines de calendriers externes.

Quelle stratégie de chunking adopter ?

Découpez d'abord selon la structure du document, puis selon la taille. Coupez sur les intertitres, les sections, les éléments de liste ou les fils de messages, puis plafonnez les chunks à une taille qui contient une idée complète, généralement 200 à 800 tokens avec un léger chevauchement.

Ajoutez du contexte à chaque chunk : faites-le précéder du titre du document et du chemin de section ("Politique de remboursement > Clients UE > Biens numériques") pour qu'il ait du sens isolément. Cette seule étape améliore souvent la recherche davantage qu'un changement de modèle d'embeddings.

Comment choisir un modèle d'embeddings ?

Choisissez un modèle d'embeddings qui gère vos langues et le vocabulaire de votre domaine, puis testez deux ou trois candidats sur votre propre jeu de référence. Les API d'embeddings hébergées d'OpenAI et d'autres fournisseurs sont un choix par défaut raisonnable ; les modèles d'embeddings à poids ouverts sont un bon choix lorsque les données doivent rester dans votre infrastructure.

Enregistrez le modèle d'embeddings et sa version avec chaque vecteur stocké. Changer de modèle plus tard implique de revectoriser tout le corpus : prévoyez-le comme une tâche de fond normale, pas comme une urgence. Pour un contenu multilingue, vérifiez qu'une question posée dans une langue retrouve des documents rédigés dans une autre si vos utilisateurs en ont besoin.

Quelle base vectorielle utiliser pour un RAG ?

Utilisez la base que votre équipe sait bien exploiter. Pour la plupart des systèmes RAG d'entreprise en dessous de plusieurs dizaines de millions de chunks, la qualité de la recherche dépend bien plus du chunking, de la recherche hybride et du reranking que du choix de la base vectorielle.

Notre choix par défaut pour les clients SaaS sur PostgreSQL est pgvector, car les permissions et les identifiants de tenant se trouvent à côté des vecteurs et il y a un système de moins à sécuriser. Nous passons à un moteur dédié lorsque le volume ou les besoins de filtrage le justifient.

Pourquoi utiliser la recherche hybride et le reranking ?

La recherche hybride combine la recherche par mots-clés (BM25) et la recherche vectorielle, car chacune trouve ce que l'autre manque. La recherche vectorielle comprend les reformulations ; la recherche par mots-clés capte les codes produits exacts, les messages d'erreur, les noms et les sigles. Un reranker reclasse ensuite les candidats combinés selon leur pertinence réelle pour la question.

Un flux de requête type : réécrire la question de l'utilisateur en requête de recherche autonome (en résolvant "il" et "cela" à partir de la conversation), lancer en parallèle la recherche par mots-clés et la recherche vectorielle avec les filtres de permissions, fusionner les résultats (la reciprocal rank fusion est une méthode simple), reclasser les 30 à 50 premiers candidats avec un cross-encoder ou une API de reranking, et garder les 5 à 10 premiers pour le prompt. Le reranking offre généralement l'un des plus gros gains de qualité par heure d'ingénierie dans un projet RAG.

Comment assembler le prompt et ajouter des citations ?

Assemblez le prompt en sections claires : règles système, passages récupérés étiquetés chacun avec un identifiant de source, historique de la conversation et question. Demandez au modèle de répondre uniquement à partir des passages, de citer les identifiants de source pour chaque affirmation et de dire clairement lorsque les sources ne contiennent pas la réponse.

Après la génération, validez les citations dans le code : chaque identifiant cité doit exister dans l'ensemble récupéré, et les réponses sans citation pour des affirmations factuelles peuvent être signalées ou régénérées. Affichez les citations dans l'interface sous forme de liens vers le document et la section d'origine. Les utilisateurs font confiance aux réponses qu'ils peuvent vérifier, et les équipes support peuvent corriger le document source au lieu de se disputer avec l'IA. Pour une vue plus large de l'intégration (streaming, garde-fous, coûts), consultez notre guide sur l'intégration de ChatGPT ou Claude dans votre produit.

Comment gérer les permissions et le contrôle d'accès dans un RAG ?

Appliquez les permissions au moment de la recherche, avant qu'un passage n'atteigne le modèle. Stockez les métadonnées d'accès (identifiant de tenant, équipe, rôle, ACL du document) avec chaque chunk et appliquez-les comme filtre dans la requête de recherche de l'utilisateur courant.

Ne comptez jamais sur le prompt pour masquer du contenu ("ne révèle pas les documents RH"), car on peut convaincre un modèle d'ignorer ses instructions. Synchronisez rapidement les changements de permissions depuis les systèmes sources et supprimez les chunks lorsque les documents sont supprimés. Dans un SaaS multi-tenant, un filtre par tenant sur chaque requête est obligatoire, et nous ajoutons des tests automatisés qui tentent de récupérer les données d'un autre tenant. Le contenu sensible peut aussi nécessiter un chiffrement au repos ; la plateforme AI Grief Companion chiffre chaque message dès l'ingestion en AES-256-GCM, message par message, et permet de tout supprimer en un clic.

Comment évaluer un système RAG ?

Évaluez la recherche et la génération séparément, à l'aide d'un jeu de référence de vraies questions. Sans jeu de référence, chaque changement est un pari, et les équipes finissent par ajuster les prompts sur le dernier exemple dont quelqu'un s'est plaint.

• Jeu de référence : 100 à 300 vraies questions avec les réponses attendues et les documents sources qui devraient être trouvés. Incluez des questions dont la réponse ne figure pas dans le corpus.
• Métriques de recherche : rappel à k (le bon passage apparaît-il dans les k premiers résultats ?) et qualité du classement.
• Métriques de génération : fidélité (chaque affirmation est-elle étayée par les passages récupérés ?), pertinence de la réponse, complétude et exactitude des citations. Un second modèle peut les noter à l'aide d'une grille, avec une vérification humaine sur un échantillon.
• Signaux de production : pouces vers le bas, reformulations successives, escalades vers un humain et questions restées sans réponse.

Rejouez le jeu à chaque changement d'analyse des documents, de chunking, d'embeddings, de paramètres de recherche, de prompts ou de modèles, et bloquez les mises en production qui font baisser les scores.

Comment garder un index RAG à jour ?

Gardez l'index à jour grâce à une synchronisation incrémentale : détectez les documents nouveaux, modifiés et supprimés dans chaque source et ne mettez à jour que les chunks concernés. Stockez une empreinte du contenu et une date de mise à jour par document pour ignorer les fichiers inchangés.

Les webhooks des systèmes sources permettent des mises à jour quasi temps réel ; des tâches planifiées (toutes les heures ou chaque nuit) suffisent pour les contenus qui évoluent lentement. Ajoutez des métadonnées de fraîcheur à la recherche pour que les nouvelles versions d'une politique passent devant les anciennes, et archivez les documents remplacés au lieu de les laisser en concurrence. Surveillez les tâches de synchronisation comme n'importe quel pipeline de production, car un échec silencieux rend l'assistant sûr de lui et dans l'erreur sur les changements du mois dernier.

Quels sont les modes d'échec les plus fréquents d'un RAG ?

Les échecs les plus fréquents sont des échecs de recherche qui ressemblent à des échecs du modèle. Lorsqu'une réponse est fausse, vérifiez d'abord si le bon passage a seulement été récupéré.

RAG, fine-tuning ou contexte long : que choisir ?

Choisissez le RAG pour les connaissances, le fine-tuning pour le comportement et le contexte long pour un contenu réduit propre à chaque requête. Ces approches sont complémentaires, pas concurrentes, et beaucoup de systèmes en production en combinent deux.

La plateforme AI Grief Companion est un exemple réel de combinaison d'approches. Elle construit un profil de personnalité, un graphe de faits dans Neo4j et une préparation RAG à partir de l'historique de conversations de l'utilisateur, et entraîne des adaptateurs LoRA (SFT et CPT sur Qwen2.5-7B avec QLoRA 4 bits) pour la voix d'une personne précise, vLLM chargeant le bon adaptateur au moment de la requête. La conversation s'appuie sur l'étape déjà prête, si bien qu'on peut échanger avant la fin de l'entraînement. Le fine-tuning gère la façon dont la personne écrit ; la recherche gère ce qu'elle a dit.

Comment nous menons les projets RAG

Chez Lytvynov Production, nous commençons les projets RAG par un court appel de cadrage : nous examinons un échantillon de vos vrais documents et les questions que posent les utilisateurs, puis vous remettons un devis ferme pour le développement. Le premier jalon construit un jeu de référence et y teste l'analyse et la recherche. Nous livrons ensuite par jalons, avec les scores d'évaluation communiqués à chacun d'eux. Si vous prévoyez un assistant de connaissances ou un chatbot IA sur les données de votre entreprise, contactez-nous.