RAG en IA : construire un pipeline RAG qui marche en production, pas seulement en démo

Une démo de RAG se fait en un après-midi. On charge quelques PDF, on calcule les embeddings, on pose une question, la réponse est bonne. Puis les vrais utilisateurs arrivent avec de vraies questions, et les réponses se mettent à dérailler d'une façon que la démo n'avait jamais montrée.

Le RAG (génération augmentée par récupération) est simple sur le papier : chercher dans vos documents, donner les passages utiles au modèle, le laisser répondre à partir d'eux. En production, presque tous les échecs viennent de la recherche, pas du modèle. Voici, étape par étape, comment je construis un pipeline RAG qui tient.

Le pipeline RAG en un coup d'œil

Ingestion : sortir les documents de là où ils vivent et en tirer un texte propre.
Découpage : les couper en passages de la bonne taille pour la recherche.
Indexation : créer les embeddings et un index par mots-clés.
Recherche : trouver les passages candidats pour chaque question, en recherche hybride.
Reranking : remettre les meilleurs candidats en tête.
Génération : répondre à partir des passages, avec citations.
Évaluation : mesurer tout ce qui précède sur de vraies questions.

Si vous n'êtes pas sûr que le RAG soit le bon outil, commencez par RAG ou fine-tuning.

1. L'ingestion : ce qui entre décide de ce qui sort

L'essentiel de la qualité se joue ici. Les PDF sont le problème habituel : mises en page sur plusieurs colonnes, en-têtes et pieds de page répétés à chaque page, tableaux transformés en bouillie de mots, pages scannées qui demandent de l'OCR.

Ce que je fais :

Utiliser un outil de lecture adapté à chaque format, et regarder le texte extrait avant d'indexer quoi que ce soit.
Retirer les en-têtes, pieds de page et numéros de page répétés.
Garder la structure : titres, numéros de section, listes. Elle sert au découpage et aux citations.
Transformer les tableaux en texte qui dit encore quelle valeur appartient à quelle ligne et quelle colonne.
Stocker des métadonnées avec chaque document : source, titre, date, propriétaire, langue, et qui a le droit de le voir.

2. Le découpage : par le sens, pas par le nombre de caractères

Des passages trop longs noient la réponse dans le bruit. Trop courts, ils perdent le contexte qui leur donne un sens.

Découpez d'abord selon la structure du document : sections, puis paragraphes.
Gardez un léger chevauchement entre passages voisins, pour ne pas perdre une phrase coupée à la frontière.
Préfixez chaque passage avec le titre du document et de la section. Un passage qui dit « les frais sont offerts après 30 jours » ne sert à rien si la recherche ne sait pas de quel produit il parle.

Il n'y a pas de taille idéale universelle. Testez-en quelques-unes sur votre jeu d'évaluation et gardez celle qui retrouve le mieux.

3. La recherche hybride : embeddings et mots-clés

La recherche vectorielle (embeddings) trouve des passages de sens proche même quand les mots diffèrent. Elle est faible sur les termes exacts : références produit, noms, messages d'erreur, numéros d'articles de loi. La recherche par mots-clés (type BM25), c'est l'inverse.

Utilisez les deux. Passez la question dans la recherche vectorielle et dans la recherche par mots-clés, puis fusionnez les résultats, par exemple avec la fusion par rang réciproque (reciprocal rank fusion). D'expérience, ce seul changement corrige plus de mauvaises réponses que changer de modèle d'embeddings.

Ajoutez des filtres sur les métadonnées : langue, type de document, période, et surtout droits d'accès.

4. Le reranking : le meilleur passage en premier

La recherche de premier niveau est faite pour aller vite et renvoie une liste approximative. Un reranker, en général un modèle cross-encoder, lit la question et chaque candidat ensemble et note leur correspondance. On récupère quelques dizaines de candidats, on les reclasse, et on ne garde que les meilleurs pour le prompt.

Les réponses s'améliorent et le coût baisse, parce qu'on envoie au modèle moins de passages, mais meilleurs.

5. La génération : répondre à partir des sources, et les citer

Le prompt doit demander au modèle :

de répondre uniquement à partir des passages fournis,
de dire clairement quand les passages ne contiennent pas la réponse, au lieu de deviner,
de citer le passage d'où vient chaque affirmation.

Les citations comptent plus qu'on ne le croit. Elles permettent à l'utilisateur de vérifier une réponse en un clic, et à vous de déboguer : quand une réponse est fausse, vous voyez tout de suite si la recherche a ramené le mauvais passage ou si le modèle a mal lu le bon.

6. L'évaluation : l'étape que tout le monde saute

Construisez un jeu d'évaluation avant de régler quoi que ce soit : quelques centaines de vraies questions, chacune avec les passages qui devraient être retrouvés et ce que doit contenir une bonne réponse. Prenez-les dans de vrais tickets, e-mails ou historiques de recherche, pas dans des questions inventées.

Puis mesurez séparément la recherche et la génération :

Recherche : le bon passage est-il dans les premiers résultats ?
Qualité des réponses : la réponse est-elle juste, appuyée par les passages cités, et admet-elle quand elle ne sait pas ?

Un LLM peut aider à noter les réponses à grande échelle, mais vérifiez un échantillon de ses notes à la main. Chaque changement, qu'il s'agisse de la taille des passages, du modèle d'embeddings, du reranker ou du prompt, est mesuré sur ce jeu. Sinon, vous réglez au feeling.

7. Droits d'accès et fraîcheur

Deux sujets que les démos n'abordent jamais :

Les droits d'accès. Filtrez la recherche selon ce que l'utilisateur a le droit de voir, au moment de la recherche. Ne comptez jamais sur le modèle pour taire quelque chose qu'on lui a déjà donné.
La fraîcheur. Réindexez les documents quand ils changent et supprimez de l'index ceux qui sont retirés. Un assistant qui cite la grille tarifaire de l'an dernier est pire que pas d'assistant.

Les pièges courants

La réponse est dans un tableau mal lu. Corrigez l'ingestion, pas le prompt.
La question n'utilise pas les mêmes mots que les documents. Recherche hybride, et reformulation de la requête si besoin.
Plusieurs versions presque identiques d'un document. Dédoublonnez et gardez la version actuelle, ou filtrez par date.
Le modèle répond avec ses connaissances générales. Resserrez le prompt et vérifiez qu'il refuse quand les passages ne couvrent pas la question.
Des questions qui demandent des données, pas des documents. « Combien de commandes avons-nous expédiées la semaine dernière ? » est une requête en base de données, pas une question de RAG. Envoyez-la vers un outil qui exécute la requête.

RAG multilingue : arabe et français

Pour du contenu multilingue, vérifiez que votre modèle d'embeddings gère vraiment vos langues. L'arabe demande un soin particulier : un même mot peut s'écrire avec ou sans voyelles, avec différentes formes d'alif ou de hamza, sans compter les graphies en dialecte ou en arabizi. Normaliser le texte avant l'indexation, et chercher par le sens autant que par les mots, règle l'essentiel. En français, les utilisateurs oublient souvent les accents en tapant. Je détaille le cas de l'arabe dans chatbot IA en arabe qui comprend la darija et les dialectes.

Un RAG privé

Un pipeline RAG peut tourner entièrement sur vos serveurs : modèle d'embeddings local, index local, LLM local. Pour des documents confidentiels, c'est souvent la réponse la plus simple à « où vont nos données ? ». J'en parle dans IA privée et LLM on-premise.

Travailler ensemble

Je suis Driss Briksine, ingénieur logiciel et ML basé au Maroc. Je construis des systèmes d'IA de bout en bout, des données et de la recherche documentaire jusqu'au logiciel en production. Vous pouvez voir mes études de cas.

Si vous avez un prototype de RAG qui marche en démo mais pas avec de vrais utilisateurs, envoyez-moi un court descriptif. Je vous dirai où je regarderais en premier.