Aller au contenu principal

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