RAG pas à pas : comment construire un agent qui cite ses sources

Dire « utilise le RAG », c'est comme dire « utilise une base de données » : ça nomme la catégorie, pas le travail. Derrière, il y a deux phases distinctes, l'une qui tourne quand personne ne demande et l'autre qui tourne à chaque fois que quelqu'un demande, et il faut construire les deux. Ce post parcourt le pipeline complet : pourquoi c'est nécessaire, ce qui s'indexe, comment on récupère, ce qui va dans le prompt et comment on mesure si cela fonctionne. Ce qui suit vient du module « Introduction to retrieval-augmented generation concepts » de Microsoft Learn.

Pourquoi un modèle tout seul ne suffit pas

Un modèle entraîné seul a trois limites. Connaissance : il ne voit pas l'information privée de l'organisation. Fraîcheur : son entraînement devient obsolète avec le temps. Vérifiabilité : il peut générer des réponses plausibles sans fondement fiable, ce qui est le cas le plus dangereux, parce qu'elles sonnent tout aussi sûres.

Le RAG (génération augmentée par récupération) combine recherche et IA générative : il cherche dans les sources sélectionnées, ajoute le résultat au prompt et le modèle répond depuis ce contexte. La réponse sort fondée et peut apporter des citations.

Le détail qui change le jeu est que le RAG ne change pas les paramètres appris. Il apporte de la connaissance au moment de l'exécution : si la politique de dépenses change, la documentation se met à jour, l'index se met à jour, et l'agent reste à jour sans réentraîner quoi que ce soit.

Phase un : indexer

Le pipeline d'indexation tourne sans utilisateur connecté et fait tout le travail lourd :

Charger les sources approuvées.
Extraire le texte et la structure des PDF, présentations, pages et tableaux.
Nettoyer les en-têtes et la navigation, qui ne font que salir.
Ajouter les métadonnées : titre, URL, catégorie, permissions et date.
Contrôler l'accès par utilisateur.
Découper le contenu en passages centrés.
Convertir chaque fragment en embedding avec un modèle d'embedding.
Indexer pour la recherche par mot-clé, vectorielle ou hybride.

La règle d'hygiène est dure : les données dupliquées, obsolètes ou contradictoires produisent une récupération médiocre et des réponses peu fiables. Une base avec deux versions de la même politique renvoie les deux, et le modèle choisit à sa manière. Les métadonnées ajoutées à cette étape (titre, URL, catégorie, permissions et date) sont celles qui permettent ensuite de filtrer, et le contrôle d'accès par utilisateur est ce qui empêche une question de ramener des documents que celui qui demande ne devrait pas voir.

Quelle taille fait chaque fragment

Le découpage est l'ajustement le plus sensible. Un fragment doit avoir assez de contexte pour être significatif et rester centré sur une idée. Trop grand consomme la fenêtre de contexte et apporte de l'information inutile ; trop petit sépare une instruction de sa définition. C'est pourquoi les fragments se chevauchent généralement un peu : ainsi le contexte ne se perd pas aux coupures.

L'exemple est une politique de voyage divisée par sections : vols, hôtels, repas et transport terrestre, avec un couple de lignes qui se chevauchent entre sections. Une question sur les limites d'hôtel ne récupère que ce fragment, sans charger toute la politique. L'autre moitié du même ajustement, ce sont les embeddings. Chaque fragment devient un vecteur avec un modèle d'embedding, et les fragments aux significations proches se retrouvent proches dans cet espace ; l'index peut chercher par mot-clé, par vecteur ou par les deux à la fois. C'est ce qui rend possible qu'une question écrite avec des mots différents du document trouve quand même le bon fragment.

flowchart TD
    subgraph Indexacion[Indexation : tourne une fois et se maintient]
        O[Sources approuvées] --> E[Extraire et nettoyer]
        E --> M[Métadonnées et permissions]
        M --> F[Découper en passages centrés]
        F --> V[Embeddings avec le modèle d'embedding]
        V --> I[Index interrogeable]
    end
    subgraph Ejecucion[Exécution : tourne à chaque question]
        Q[Requête de l'utilisateur] --> QV[Vectorisée avec le même modèle]
        QV --> R[Filtres, recherche hybride et ranking]
        R --> P[Prompt amplifié avec les fragments]
        P --> A[Réponse avec citations]
    end
    I --> R

En termes simples : la partie haute prépare la bibliothèque et la partie basse l'interroge ; les deux se rencontrent à l'index, où vit le matériel déjà traité.

Phase deux : récupérer et générer

La requête est vectorisée avec le même modèle d'embedding utilisé par l'indexation, ce qui permet de la comparer aux fragments. Ensuite la récupération se raffine avec quatre ajustements : filtres de métadonnées (région, produit, date, type de document, permissions), recherche hybride qui combine mot-clé et vecteurs, ranking des candidats et limite de résultats. La recherche hybride résout deux problèmes distincts : le mot-clé trouve les termes exacts qu'un vecteur estompe, et le vecteur trouve les synonymes que le mot-clé ne couvre pas.

L'objectif déclaré est le plus petit ensemble de contenu avec des preuves suffisantes, pas le maximum. Mettre dix fragments quand trois suffisent n'améliore pas la réponse : cela consomme de la fenêtre, ajoute du bruit et renchérit la requête.

Ce qui va dans le prompt

Le prompt amplifié combine quatre pièces : les instructions système, la question de l'utilisateur, les fragments récupérés et l'ordre de répondre uniquement depuis le contexte, de reconnaître quand il n'y a pas assez de preuves et d'inclure des citations.

La pièce de sécurité est la façon dont on traite les fragments : comme des données, jamais comme des instructions. Le contenu d'origine pourrait contenir du texte qui essaie de rediriger le modèle, et le prompt doit distinguer les instructions de confiance de l'application de ce que disent les documents.

Avec la politique de dépenses, le cycle ressemble à ceci : « Combien puis-je réclamer pour un taxi ? », l'application cherche, récupère le fragment « Transport terrestre », l'ajoute au prompt et le modèle répond avec la limite et la citation « Politique de dépenses, §4 ».

Comment on évalue

L'évaluation se part en deux, et les séparer est ce qui permet de savoir où est le problème.

Récupération : pertinence de ce qui est revenu, couverture, ranking, autorisation et fraîcheur du contenu.

Génération : fondement de chaque affirmation, pertinence de la réponse, intégrité, qualité des citations et incertitude appropriée.

Les tests doivent inclure les cas difficiles : questions ambiguës, questions sans réponse, documents obsolètes et tentatives d'accès non autorisé. Et tout cela s'équilibre contre deux contraintes qui resserrent toujours : la latence et le coût. Plus de fragments par requête améliorent la couverture et renchérissent la réponse ; moins de fragments la rendent moins chère et laissent des questions sans fondement. À cela s'ajoute le monitoring de l'usage réel, qui montre ce que les gens demandent vraiment et quels trous restent.

La règle qui ordonne le diagnostic : si la récupération échoue, changer le prompt de génération ne résout pas le problème.

Ce qui reste

Le RAG est un pipeline, pas un interrupteur. Le bien construire, c'est décider quatre choses avec soin : quelles sources entrent, comment on découpe, combien de fragments voyagent dans chaque prompt et comment séparer les deux évaluations. Les quatre se révisent séparément, et chacune a son effet sur la réponse. La partie la moins révisée est en général l'indexation, et c'est celle qui pèse le plus : un index sale ne se répare pas avec des instructions de prompt, il se répare en nettoyant ce qui entre.

Limite de cette source : elle décrit le processus et ses critères, et n'apporte pas de métriques de précision ni de coût par configuration, donc l'équilibre entre qualité, latence et coût reste à mesurer dans chaque cas.

*Source : le module « Introduction to retrieval-augmented generation concepts » de Microsoft Learn.*