Développement RAG : des réponses IA fiables à partir des connaissances de votre entreprise

Qu'est-ce que le développement RAG et quand votre entreprise en a-t-elle besoin ?

Le développement RAG est le travail d'ingénierie qui connecte un grand modèle de langage aux connaissances de votre entreprise, afin que les réponses proviennent de vos documents et non de ce que le modèle a mémorisé pendant son entraînement. Une entreprise a besoin d'un RAG lorsque les équipes posent sans cesse des questions dont la réponse existe déjà quelque part en interne : macros de support, manuels produit, contrats, politiques, anciens tickets, un wiki dans lequel personne ne trouve rien. Au lieu de réentraîner un modèle, un système RAG retrouve les quelques passages utiles pour chaque question et les transmet au modèle avec l'instruction d'y puiser sa réponse et de les citer.

Les projets RAG en entreprise qu'on nous demande le plus souvent :

• Un assistant interne qui répond aux questions des collaborateurs à partir des politiques, des procédures et du wiki.
• Un assistant de support client fondé sur les articles du centre d'aide et les tickets résolus (voir développement de chatbot IA).
• La recherche et les questions-réponses sur des contrats, des cahiers des charges ou de la documentation technique.
• Une couche de "mémoire" pour un produit IA, afin que l'assistant se souvienne des faits concernant un utilisateur ou un compte précis.

Comment fonctionne une chaîne RAG en production ?

Une chaîne RAG en production comporte deux moitiés : une partie d'ingestion hors ligne qui prépare vos connaissances, et une partie de requête en ligne qui répond aux questions. La plupart des problèmes de précision viennent de l'ingestion, c'est pourquoi nous y consacrons un vrai temps d'ingénierie au lieu de la traiter comme un script ponctuel.

Comment découper les documents pour un RAG ?

Le découpage doit suivre la structure de vos documents, et non un nombre fixe de caractères. Un bon point de départ consiste à découper par titres et paragraphes en passages de quelques centaines de tokens, à conserver un léger chevauchement et à associer des métadonnées à chaque fragment : titre du document, chemin de section, date, langue et personnes autorisées à le consulter. Le chemin de titres est important, car un fragment qui dit "le délai est de 30 jours" ne sert à rien si l'on ignore qu'il provient de "Remboursements > Clients UE".

Certains types de contenus exigent un traitement spécifique. Les tableaux sont conservés entiers ou convertis en énoncés ligne par ligne. Les FAQ sont découpées à raison d'une question par fragment. Les contrats longs sont découpés par clause, en conservant le numéro de clause. Les historiques de chat et les tickets sont regroupés par conversation, et non par ligne. Nous testons deux ou trois stratégies de découpage sur le même jeu d'évaluation et conservons celle qui retrouve le plus souvent le bon passage, au lieu de deviner.

Quels embeddings et quelle base vectorielle utiliser ?

Le modèle d'embedding et la base vectorielle doivent être choisis selon votre volume de données, vos langues et vos règles d'hébergement, et tous deux doivent pouvoir être remplacés plus tard. Nous les plaçons derrière une petite interface dans le code, de sorte que changer de fournisseur soit une simple réindexation, pas une réécriture.

Pour les embeddings, les modèles hébergés d'OpenAI et de fournisseurs similaires permettent le démarrage le plus rapide. Des modèles d'embedding open source tournent sur vos propres serveurs lorsque les données ne peuvent pas quitter votre environnement. Un contenu multilingue (par exemple anglais plus français ou ukrainien) exige un modèle testé sur ces langues, ce que nous vérifions pendant l'évaluation au lieu de le supposer.

Comment mesurer la précision d'un RAG ?

La précision d'un RAG se mesure avec un jeu d'évaluation fixe : 50 à 200 vraies questions de vos utilisateurs, chacune avec la réponse attendue et la source dont elle doit provenir. Sans ce jeu, toute discussion sur la qualité reste une affaire d'opinion. Avec lui, chaque modification du découpage, des prompts, des modèles ou des données obtient un score comparable.

Nous suivons quatre indicateurs :

1. Taux de récupération : le bon passage figurait-il parmi les premiers résultats ?
2. Fidélité : la réponse affirme-t-elle uniquement ce que disent les passages retrouvés ?
3. Exactitude de la réponse : la réponse correspond-elle à celle attendue, selon un relecteur ou un évaluateur LLM contrôlé sur des échantillons humains ?
4. Qualité des refus : lorsque la réponse ne figure pas dans la base de connaissances, le système le dit-il au lieu d'en inventer une ?

En production, nous ajoutons les retours des utilisateurs (pouce levé ou baissé avec un motif), la journalisation des sources retrouvées pour chaque réponse, le coût par requête et la latence. Le jeu d'évaluation s'exécute automatiquement avant chaque mise en production, comme des tests unitaires.

Et la confidentialité des données, les droits d'accès et le choix du modèle ?

Un système RAG ne doit jamais montrer à un utilisateur un passage qu'il ne pourrait pas ouvrir dans la source d'origine. Nous stockons les règles d'accès dans les métadonnées des fragments et filtrons au moment de la recherche, de sorte que les droits sont appliqués avant que le modèle ne voie quoi que ce soit. Les données sensibles peuvent être chiffrées dès l'ingestion ; dans notre projet AI Grief Companion, chaque message est chiffré individuellement en AES-256-GCM sous une clé d'enveloppe KMS, et un utilisateur peut tout supprimer en un clic.

Pour l'étape de génération, nous travaillons avec les API OpenAI et Anthropic Claude ainsi qu'avec des modèles open source servis sur votre propre infrastructure (le même projet exécute des adaptateurs Qwen2.5-7B via vLLM). Le choix dépend des règles sur les données, des langues, de la latence et du coût par réponse. Les prompts sont stockés en base avec un historique de versions lorsque c'est utile, afin que le ton et les instructions puissent être ajustés sans nouvelle mise en production du code.

Combien coûte le développement d'un RAG ?

Le coût d'un développement RAG dépend surtout du nombre de sources connectées, de leur état et du niveau d'exigence en matière de précision et de droits d'accès. Une preuve de concept sur une source avec un jeu d'évaluation prend généralement 3 à 6 semaines ; un assistant de production avec plusieurs sources, droits d'accès et interface demande 2 à 4 mois ; un RAG au niveau plateforme sur plusieurs produits avec des modèles sur mesure prend davantage.

Les coûts de fonctionnement sont distincts : tokens du modèle par réponse, coût des embeddings à chaque réindexation et hébergement de la base vectorielle. Nous estimons le coût pour 1 000 questions pendant la preuve de concept afin d'éviter les surprises, et nous fournissons un devis forfaitaire pour les jalons convenus après un court appel de cadrage. Chez nous, un assistant RAG sur vos connaissances démarre à 5 000 USD ; notre guide du coût de développement d'un chatbot IA couvre les périmètres plus larges.

Où avons-nous construit des systèmes RAG et LLM ?

Notre travail le plus complet en matière de recherche est AI Grief Companion pour une startup américaine : une passerelle d'ingestion en Python analyse dix formats d'export de chat vers une table de messages normalisée unique, et une chaîne ML construit un profil de personnalité, un graphe de faits dans Neo4j, une mémoire RAG et des adaptateurs LoRA. Le chat utilise toujours l'étape déjà prête, si bien que les utilisateurs peuvent échanger avec le système avant la fin de l'entraînement.

Côté produit, AI Resume Master, notre propre générateur de CV, utilise des LLM pour générer, réécrire et améliorer le contenu des CV et des lettres de motivation, et a atteint 50 000 utilisateurs actifs mensuels. Pour une vue d'ensemble de l'ajout de fonctionnalités LLM à un produit existant, consultez notre page intégration IA et notre guide de mise en place d'un RAG.

Notre façon de travailler sur les projets RAG

Nous commençons par un court appel de cadrage et une phase de découverte : nous examinons vos sources, recueillons de vraies questions et construisons le jeu d'évaluation avec votre équipe. Nous livrons ensuite une preuve de concept sur une source avec une précision mesurée, et seulement après, nous étendons à d'autres sources, aux droits d'accès et à une interface de production. Des ingénieurs seniors sont responsables de l'architecture ; en interne, nous utilisons des agents de code IA pour avancer plus vite sur la plomberie.

Si vous disposez d'une base de connaissances sur laquelle on vous pose sans cesse les mêmes questions, réservez un appel de cadrage et apportez cinq exemples de questions. Nous vous dirons honnêtement si le RAG est le bon outil.