Le flux RAG complet

Maintenant que nous avons couvert les bases de la RAG, le découpage et les embeddings, passons en revue le pipeline complet étape par étape. Cet exemple montre comment toutes les pièces s’assemblent pour récupérer l’information pertinente et générer des réponses.

Étape 1 : Découper le texte source

On prend le document source et on le découpé en chunks. Pour cet exemple, utilisons deux sections simples :

• Section 1 — Recherche médicale : “Cette année à vu des progrès significatifs dans notre compréhension du XDR-47, un ‘bug’ que nous n’avions jamais rencontre.”
• Section 2 — Ingénierie logicielle : “Cette division à consacré des efforts importants à l’étude de divers vecteurs d’infection dans nos systèmes distribués.”

Notez comment les deux sections utilisent des termes ambigus (“bug”, “infection”) qui pourraient preter à confusion hors contexte.

Étape 2 : Générer les embeddings

On convertit chaque chunk en embedding numérique via un modèle d’embedding. Pour simplifier l’explication, imaginons un modèle parfait qui renvoie exactement deux nombres dont on connaît la signification :

• Le premier nombre représente à quel point le texte parle de médecine
• Le second nombre représente à quel point le texte parle d’ingénierie logicielle

Pour la section médicale, on obtiendrait [0.97, 0.34] — très orientée médecine, mais avec quelques éléments logiciels à cause du mot “bug”. Pour la section logicielle : [0.30, 0.97] — très orientée logiciel, avec des connotations médicales à cause du mot “infection”.

Normalisation

L’API d’embedding effectue généralement une normalisation qui met chaque vecteur à une magnitude de 1.0. Pas besoin de comprendre les maths derrière — c’est automatique. On obtient des vecteurs normalisés comme [0.944, 0.331] et [0.295, 0.955].

On peut visualiser ces embeddings sur un cercle unité, où chaque point représente un chunk.

Étape 3 : Stocker dans une base vectorielle

On stocke ces embeddings dans une base de données vectorielle — une base spécialisée optimisée pour stocker, comparer et rechercher des listes de nombres comme nos embeddings.

À ce stade, on fait une pause. Tout le travail jusqu’ici est du preprocessing qui se fait en amont. Maintenant, on attend qu’un utilisateur soumette une requête.

Étape 4 : Traiter la requête utilisateur

Quand un utilisateur pose une question comme “Je suis curieux à propos de l’entreprise. En particulier, qu’a fait le département ingénierie logicielle cette année ?”, on passe sa requête dans le même modèle d’embedding.

Cette requête produit un embedding du type [0.1, 0.89] — faible score médical, fort score logiciel. Après normalisation : [0.112, 0.993].

Étape 5 : Trouver les embeddings similaires

On envoie l’embedding de la requête à notre base vectorielle et on lui demande de trouver les embeddings stockés les plus similaires.

La base retourne la section ingénierie logicielle car c’est la correspondance la plus proche.

Comment fonctionne la similarité : la similarité cosinus

La base vectorielle utilise la similarité cosinus pour déterminer quels embeddings sont les plus proches. Elle mesure le cosinus de l’angle entre deux vecteurs.

Points clés sur la similarité cosinus :

Dans notre exemple, la similarité cosinus entre la requête et le chunk logiciel est 0.983 (très forte). La similarité avec le chunk médical n’est que de 0.398 (faible).

Distance cosinus

Vous rencontrerez souvent la distance cosinus dans la documentation des bases vectorielles. C’est simplement : distance = 1 - similarite.

Avec la distance cosinus :

• Valeurs proches de 0 = forte similarité
• Valeurs élevées = faible similarité

Ce changement rend les nombres plus intuitifs dans certains contextes (on cherche la “distance la plus courte”).

Étape 6 : Créer le prompt final

Enfin, on prend la question de l’utilisateur et le chunk le plus pertinent trouve, on les combine dans un prompt, et on envoie le tout à Claude :

Reponds a la question de l'utilisateur sur le document financier.

<user_question>
Combien de bugs les ingenieurs ont-ils corriges cette annee ?
</user_question>

<report>
## Section 2 : Ingenierie logicielle
Cette division a consacre des efforts importants a l'etude de divers
vecteurs d'infection dans nos systemes distribues
</report>

Et voilà le pipeline RAG complet ! Le système à réussi à récupérer l’information la plus pertinente grâce à la similarité sémantique et l’a fournie comme contexte pour générer une réponse précise.

Quiz : Le flux RAG

Question 1 : Pourquoi normalise-t-on les vecteurs d’embedding ?

Réponse : La normalisation met tous les vecteurs à la même échelle (magnitude 1.0), ce qui permet de les comparer equitablement via la similarité cosinus. Sans normalisation, un vecteur plus “long” pourrait fausser les comparaisons.

Question 2 : Dans notre exemple, pourquoi le chunk médical obtient-il un score logiciel non nul (0.34) ?

Réponse : Parce que la section médicale contient le mot “bug”, qui est aussi un terme courant en ingénierie logicielle. L’embedding capture cette ambiguïté sémantique.