La génération augmentée par récupération (RAG), expliquée aux développeurs

Un modèle de langage, à lui seul, sait beaucoup de choses sur le monde et rien sur votre entreprise. Il n'a jamais vu la documentation de vos produits, vos tickets de support ni les contrats du dernier trimestre. La génération augmentée par récupération, ou RAG, est le motif qui comble cet écart : récupérer les bons faits au moment de la requête, les transmettre au modèle et le laisser répondre en s'appuyant sur vos données plutôt que sur sa mémoire d'entraînement.

Chez Innovation T, nous construisons des systèmes RAG pour des bases de connaissances internes, des assistants de support client et la recherche documentaire dans des projets web et cloud. Le motif est simple à démontrer et étonnamment facile à rater en production. Ce guide explique comment le RAG fonctionne réellement, les décisions qui comptent et les pièges qui dégradent discrètement la qualité des réponses.

Ce qu'est le RAG et pourquoi il l'emporte sur le fine tuning dans la plupart des cas

La boucle centrale est courte. Lorsqu'un utilisateur pose une question, vous convertissez cette question en un vecteur, vous recherchez dans un magasin de votre propre contenu les passages les plus pertinents, et vous injectez ces passages dans le prompt comme contexte. Le modèle répond alors à partir de ce que vous avez récupéré au lieu de deviner à partir de sa mémoire paramétrique.

On se tourne souvent vers le fine tuning en premier, mais pour ancrer un modèle dans des faits, c'est généralement le mauvais outil. Le fine tuning enseigne le style, le ton et le format. Le RAG enseigne des connaissances qui changent. Considérez la différence :

• Le fine tuning intègre l'information dans les poids. Mettre à jour un seul fait implique de réentraîner ou de lancer un nouveau cycle de tuning.
• Le RAG conserve les connaissances dans une base de données que vous pouvez mettre à jour en quelques secondes. Modifiez un document, réindexez-le, et la réponse suivante reflète le changement.
• Le RAG vous donne des citations. Vous pouvez montrer le passage source, ce qui renforce la confiance et facilite la détection des hallucinations.

Pour la plupart des cas d'usage métier, une connaissance à jour, auditable et peu coûteuse à mettre à jour l'emporte. Réservez le fine tuning aux situations où vous avez besoin d'une voix spécifique ou d'une sortie structurée que le modèle de base rechigne à produire.

Le pipeline, étape par étape

Un système RAG en production est un petit pipeline. Chaque étape a ses propres modes de défaillance, et une faiblesse à n'importe quel endroit plafonne la qualité de l'ensemble.

1. Ingestion et découpage

Vous ne pouvez pas encoder un PDF de 40 pages en un seul vecteur et espérer une récupération précise. Vous découpez les documents en fragments (chunks), et la façon dont vous les découpez compte plus que presque tout le reste.

Le découpage à taille fixe (disons 500 à 800 tokens avec un chevauchement de 10 à 15 pour cent) est une valeur par défaut acceptable. Mais un découpage naïf coupe les phrases en deux et sépare un titre de la table qu'il décrit. De meilleurs résultats viennent d'un découpage tenant compte de la structure, qui respecte les titres markdown, les paragraphes, les blocs de code et les limites de listes. D'après notre expérience, le passage d'un découpage basé sur les caractères à un découpage tenant compte de la structure est souvent le plus grand gain de qualité isolé dans une première mise en place de RAG, devant toute amélioration de modèle.

Conservez des métadonnées avec chaque fragment : document source, titre de section, URL, date de dernière mise à jour et permissions d'accès. Vous en aurez besoin plus tard pour le filtrage, les citations et la sécurité.

2. Embeddings

Un modèle d'embedding transforme le texte en un vecteur de sorte que des sens similaires se retrouvent proches les uns des autres dans l'espace vectoriel. Le choix se résume à quelques compromis :

• Taille des dimensions. Des vecteurs plus grands peuvent capter plus de nuances mais coûtent plus cher à stocker et à rechercher. De nombreux modèles performants de 2026 offrent des dimensions variables, ce qui vous permet d'échanger le rappel contre l'empreinte mémoire.
• Adéquation au domaine. Les embeddings généralistes gèrent la plupart des contenus. Les corpus très techniques, juridiques ou multilingues justifient parfois un modèle d'embedding spécialisé ou affiné.
• Cohérence. Vous devez encoder les requêtes et les documents avec le même modèle. Mélanger les modèles détruit silencieusement la pertinence.

Quel que soit votre choix, versionnez-le. Lorsque vous changez de modèle d'embedding, vous devez tout réindexer, alors traitez le choix du modèle comme une décision de niveau schéma.

3. Stockage et recherche vectoriels

Les embeddings vivent dans un index vectoriel qui prend en charge la recherche du plus proche voisin approximatif. Vos options réalistes en 2026 :

• Postgres avec pgvector si vous exploitez déjà Postgres et voulez n'administrer qu'une seule base de données. C'est la valeur par défaut pragmatique pour la plupart des équipes.
• Une base de données vectorielle dédiée, comme celles construites autour d'index HNSW, lorsque vous avez besoin de mise à l'échelle, de recherche hybride et de filtrage par métadonnées prêts à l'emploi.
• Un service de recherche géré si vous voulez la récupération sous forme d'API et ne voulez pas exploiter d'infrastructure.

Le conseil honnête : ne vous précipitez pas d'abord sur l'option la plus exotique. Une seule instance Postgres avec pgvector gère confortablement des millions de fragments et vous évite tout un système à maintenir.

4. Récupération, recherche hybride et reranking

La recherche vectorielle pure est forte sur le sens mais faible sur les termes exacts. Elle peut passer à côté d'un code d'erreur précis, d'une référence produit (SKU) ou d'un nom de famille, car ces tokens portent peu de signal sémantique. La solution est la recherche hybride : combiner la similarité vectorielle avec la recherche par mots-clés classique (BM25) et fusionner les résultats.

Ajoutez ensuite un reranker. Votre premier passage récupère 20 à 50 candidats à moindre coût. Un reranker de type cross encoder lit ensemble la requête et chaque candidat et les réordonne selon leur pertinence réelle, de sorte que les 5 premiers que vous envoyez au modèle soient les 5 meilleurs, et pas simplement les vecteurs les plus proches. Ce motif en deux étapes, récupérer puis reranker, est l'une des améliorations à plus fort levier que vous puissiez apporter, et il s'accorde naturellement avec la discipline de conception d'API que nous abordons dans concevoir des API que les développeurs adorent.

5. Génération

Enfin, vous assemblez le prompt : une instruction système, les passages récupérés clairement délimités et la question de l'utilisateur. Deux règles font ici leurs preuves. Demandez au modèle de répondre uniquement à partir du contexte fourni et de signaler lorsque la réponse n'y figure pas. Et demandez-lui de citer la source de chaque affirmation afin que les utilisateurs, et vous, puissiez vérifier.

Évaluation, ou comment savoir que ça marche

L'erreur qui coule la plupart des projets RAG est de livrer au feeling. La démonstration est superbe sur trois questions, puis échoue discrètement à la quatrième. Il vous faut de la mesure, et l'évaluation du RAG se divise en deux moitiés.

La qualité de récupération demande si les bons fragments sont revenus tout court. Suivez le rappel de contexte (avons-nous récupéré le passage qui contient la réponse) et la précision de contexte (quelle proportion de ce que nous avons récupéré était réellement pertinente). Si la récupération échoue, aucun modèle ne peut sauver la réponse.

La qualité de génération demande si la réponse est fidèle au contexte récupéré et si elle répond réellement à la question. La fidélité détecte l'hallucination : des affirmations non étayées par les passages. La pertinence de la réponse détecte le modèle qui s'égare hors sujet.

Voici une liste de contrôle que nous utilisons lors de la mise en place d'une évaluation pour un nouveau système RAG :

1. Constituez un jeu de référence (golden set) de 50 à 100 questions réelles avec des réponses correctes connues et les passages sources.
2. Mesurez le rappel et la précision de récupération séparément de la qualité des réponses, afin de savoir quelle étape corriger.
3. Utilisez un LLM comme juge pour la fidélité et la pertinence, mais contrôlez ses verdicts par échantillonnage face à une revue humaine.
4. Ajoutez des cas adverses : questions sans réponse dans le corpus, formulations ambiguës et documents quasi identiques.
5. Relancez toute la suite à chaque changement de découpage, d'embeddings, de prompts ou de modèle.
6. Surveillez les requêtes de production pour les questions qui ne récupèrent rien d'utile et réinjectez-les dans le jeu de référence.

Traitez ces chiffres comme vous traitez la vitesse des pages. Les petites régressions s'accumulent, et le même état d'esprit fondé sur les données de terrain de notre guide de terrain sur les Core Web Vitals s'applique : mesurez l'usage réel, pas seulement le scénario idéal.

Les compromis dont personne ne vous parle

Quelques décisions façonnent le coût, la latence et la confiance plus que le framework que vous choisissez.

• Taille des fragments contre contexte. Les petits fragments récupèrent avec précision mais peuvent manquer du contexte environnant. Les grands fragments portent le contexte mais diluent la pertinence et consomment des tokens. Testez les deux face à votre jeu de référence plutôt que de deviner.
• Latence contre qualité. Le reranking et des fenêtres de contexte plus grandes améliorent les réponses et ajoutent des centaines de millisecondes. Pour un bot de support, c'est acceptable. Pour de l'autocomplétion, non.
• Fraîcheur contre coût. Réindexer en permanence maintient les réponses à jour mais coûte du calcul. La réindexation par lots selon un calendrier est moins chère et généralement suffisante.
• Sécurité et permissions. C'est celle qui provoque des incidents. Si votre index mélange des documents ayant des niveaux d'accès différents, le RAG peut faire fuiter un passage restreint dans une réponse destinée à un utilisateur qui ne devrait jamais le voir. Stockez les permissions comme métadonnées de fragment et filtrez au moment de la récupération, avant la génération, à chaque fois.

Comment Innovation T peut vous aider

Le RAG est facile à prototyper et véritablement difficile à rendre fiable, rapide et sûr à grande échelle. Cet écart entre une démonstration fonctionnelle et un système que vous pouvez présenter à des clients est exactement là où nous intervenons.

Nous aidons les équipes à concevoir la stratégie d'ingestion et de découpage pour leurs documents réels, à choisir un embedding et un stockage vectoriel adaptés à leur échelle et à leur budget, et à construire une récupération hybride avec reranking qui renvoie le bon contexte plutôt que le simplement similaire. Nous intégrons l'évaluation dès le premier jour afin que la qualité soit un chiffre que vous pouvez suivre, et nous gérons les parties ingrates qui comptent en production : récupération tenant compte des permissions, supervision, mise en cache et maîtrise des coûts dans votre environnement cloud. Si vous pesez l'architecture plus large autour d'un tel système, notre réflexion sur choisir une stack technique pour le SaaS en 2026 s'accorde bien avec une mise en place de RAG.

Que vous ajoutiez un assistant à un produit existant ou construisiez de l'intelligence documentaire à partir de zéro, nos équipes d'ingénierie logicielle et cloud peuvent le mener de l'idée à la production. Explorez nos services ou contactez-nous pour discuter de ce que vous construisez.