Un RAG qui fonctionne vraiment : les leçons de 12 systèmes en production

Ce qu’est le RAG, et où il échoue

La génération augmentée par la recherche (RAG) répond aux questions à partir de vos propres documents. Au lieu de s’appuyer sur ce qu’un modèle de langage a mémorisé, le système cherche dans votre contenu, place les passages les plus pertinents dans le prompt et demande au modèle d’y répondre à partir d’eux — idéalement avec des citations.

Quand un assistant RAG donne une réponse fausse ou floue, le modèle est rarement en cause. Le plus souvent, le bon passage n’a jamais été retrouvé, a été coupé en deux lors du découpage ou a été noyé sous du texte moins pertinent. Rendre un RAG fiable, c’est donc surtout de l’ingénierie de recherche.

La chaîne de traitement

• Ingestion : collecter les documents depuis un CMS, un centre d’aide, des PDF ou des tickets, avec leurs droits d’accès.
• Découpage : les diviser en passages qui ont du sens seuls.
• Embeddings et index : stocker vecteurs et mots-clés avec des métadonnées.
• Recherche : chercher avec la question de l’utilisateur, filtrée selon ce qu’il a le droit de voir.
• Re-ranking : réordonner les meilleurs résultats avec un modèle plus précis.
• Génération : répondre uniquement à partir des passages retrouvés et les citer.
• Évaluation : mesurer en continu la qualité de la recherche et des réponses.

Un découpage qui garde le sens

Les morceaux de taille fixe qui coupent tableaux et titres sont la première cause de mauvaises réponses. Découpez plutôt selon la structure du document : sections, titres, éléments de liste et lignes de tableau. Quelques centaines de tokens par morceau avec un léger chevauchement conviennent à la plupart des textes.

Stockez des métadonnées avec chaque morceau : titre du document, titre de section, URL, date, produit ou version, langue et droits d’accès. Ajouter le titre et l’intertitre au texte du morceau avant de calculer l’embedding améliore souvent nettement la recherche, car un paragraphe isolé dit rarement de quoi il parle.

Recherche hybride et re-ranking

La recherche vectorielle comprend le sens mais peine sur les termes exacts : références produit, messages d’erreur, noms et nombres. La recherche par mots-clés (BM25) fait l’inverse. Lancez les deux et fusionnez les résultats, par exemple avec la reciprocal rank fusion : vous obtenez les forces de chacune.

Ensuite, réordonnez. Récupérez rapidement 20 à 50 candidats et laissez un re-ranker de type cross-encoder noter chacun par rapport à la question. Ne transmettre au modèle que les cinq à huit meilleurs morceaux réduit coût, latence et confusion.

Droits d’accès et fraîcheur

Appliquez les droits au moment de la recherche avec des filtres de métadonnées, jamais en demandant au modèle de cacher des choses. Si un utilisateur ne doit pas voir un document, ce document ne doit pas atteindre le prompt.

Gardez l’index à jour par mises à jour incrémentales : réindexez un document quand il change et supprimez ses morceaux quand il disparaît. Les morceaux périmés produisent des réponses assurées mais obsolètes — les plus difficiles à repérer.

Des prompts pour des réponses sourcées

Demandez au modèle de répondre uniquement à partir des passages fournis, de les citer par identifiant et de dire clairement quand la réponse ne figure pas dans les sources. Traitez le texte retrouvé comme des données, pas comme des instructions : des documents peuvent contenir du texte qui tente d’orienter le modèle, votre prompt système doit donc préciser que les instructions présentes dans les sources sont à ignorer.

L’évaluation, c’est le produit

Avant le lancement, rassemblez 50 à 200 vraies questions avec les documents qui devraient y répondre. Mesurez la recherche (le bon document figurait-il parmi les premiers résultats ?) séparément de la qualité de réponse (était-elle correcte, complète et appuyée par les sources ?). L’évaluation automatique par un modèle aide à grande échelle, mais vérifiez-la ponctuellement à la main.

Exécutez ce jeu à chaque changement de découpage, d’embeddings, de prompts ou de modèles. Sans lui, chaque amélioration n’est qu’une supposition.

Une stack pragmatique

Pour la plupart des équipes, nous commençons simple : PostgreSQL avec pgvector (ou OpenSearch quand une recherche par mots-clés poussée est nécessaire), un modèle d’embeddings et un re-ranker d’un grand fournisseur, l’ingestion en files d’attente en arrière-plan et un petit écran d’administration qui montre les sources utilisées pour chaque réponse. Les bases vectorielles dédiées comme Qdrant ou Weaviate prennent leur sens à plus grande échelle. L’architecture compte moins que le découpage, les filtres et l’évaluation qui l’entourent.