Le flux RAG complet
Mis à jour le 30 juillet 2026
Découpage, embeddings : les briques sont posées. Avant d’écrire le code du pipeline (leçon suivante), déroulons une fois le flux RAG complet sur un exemple miniature — un rapport annuel à deux sections — pour que chaque étape trouve sa place dans le tableau d’ensemble. Six étapes, dont trois se jouent à l’indexation et trois à chaque question.
Étape 1 : Découper le texte source
On divise le document en segments gérables, selon la stratégie choisie précédemment. Notre rapport imaginaire en donne deux : une section « Recherche médicale » et une section « Ingénierie logicielle ». Deux segments suffisent pour l’exemple — le vrai pipeline en manipulera des centaines.
Étape 2 : Générer les embeddings
Chaque segment est converti en embedding numérique. Pour visualiser, imaginons un modèle à deux dimensions seulement — « médical » et « logiciel » :
- Section médicale :
[0.97, 0.34](très médical, un peu logiciel à cause du mot « bug ») - Section logicielle :
[0.30, 0.97](très logiciel, mais « vecteurs d’infection » a des connotations médicales)
Ce petit exemple dit une vérité importante : les scores ne sont jamais purs. Le vocabulaire ambigu — un « bug » informatique, des « vecteurs d’infection » système — tire chaque vecteur vers l’autre dimension. Les vrais modèles travaillent en centaines de dimensions, mais le principe reste : l’embedding capture tout ce que le texte évoque, pas une étiquette unique.
Normalisation
Avant le stockage, les embeddings sont normalisés pour avoir une magnitude de 1.0 — opération gérée automatiquement par l’API. L’intérêt : une fois tous les vecteurs ramenés à la même longueur, seule leur direction les distingue, et c’est précisément ce que la similarité cosinus mesurera.
Étape 3 : Stocker en base vectorielle
Les embeddings normalisés rejoignent une base de données vectorielle — un stockage optimisé pour une seule opération : comparer des listes de nombres et retrouver les plus proches, vite, même parmi des millions. Ici s’achève la phase d’indexation, exécutée une fois par document.
Étape 4 : Traiter la requête utilisateur
Commence la phase de question, répétée à chaque interaction. « Combien de bugs les ingénieurs ont-ils corrigés cette année ? » — la question passe dans le même modèle d’embedding que les segments. Même modèle, c’est la règle absolue : deux modèles différents produiraient des espaces incompatibles, où les distances n’auraient aucun sens.
Étape 5 : Trouver les embeddings similaires
La base vectorielle compare le vecteur de la question à ceux des segments via la similarité cosinus — le cosinus de l’angle entre deux vecteurs :
- 1.0 : vecteurs dans la même direction (très similaires)
- 0.0 : vecteurs perpendiculaires (sans rapport)
- -1.0 : vecteurs opposés (très différents)
La distance cosinus en découle : simplement 1 - similarité cosinus — 0 pour identiques, 2 pour opposés. Notre question sur les bugs pointe nettement vers la dimension « logiciel » : c’est la section d’ingénierie qui gagne, malgré l’absence du mot « corrigés » dans le texte.
Étape 6 : Construire le prompt final
Reste à faire parler Claude. On combine la question de l’utilisateur et le segment le plus pertinent dans un prompt :
Reponds a la question de l'utilisateur sur le document financier.
<question_utilisateur>
Combien de bugs les ingenieurs ont-ils corriges cette annee ?
</question_utilisateur>
<rapport>
## Section 2 : Ingenierie logicielle
Cette division a consacre des efforts significatifs a l'etude
des vecteurs d'infection dans nos systemes distribues
</rapport>
Les balises XML séparent la question des extraits — la technique de structuration appliquée à son cas d’usage idéal. Claude répond alors à partir du document, pas de sa mémoire d’entraînement : c’est toute la promesse du RAG, tenue. Et ce processus — vectoriser la question, chercher, assembler le prompt — se répète automatiquement à chaque question, sur un index construit une seule fois.
Points clés à retenir
- Trois étapes d’indexation (découper, vectoriser, stocker) exécutées une fois ; trois étapes par question
- Les embeddings capturent tout ce qu’un texte évoque — le vocabulaire ambigu teinte les scores
- Normalisation à magnitude 1.0 : seule la direction compte, ce que mesure la similarité cosinus
- Question et segments doivent passer par le même modèle d’embedding
- Le prompt final combine question et segments retrouvés, balisés en XML — Claude répond depuis le document