Le flux RAG complet

Maintenant que nous avons couvert les bases de la RAG, le decoupage et les embeddings, passons en revue le pipeline complet etape par etape. Cet exemple montre comment toutes les pieces s’assemblent pour recuperer l’information pertinente et generer des reponses.

Etape 1 : Decouper le texte source

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

• Section 1 — Recherche medicale : “Cette annee a vu des progres significatifs dans notre comprehension du XDR-47, un ‘bug’ que nous n’avions jamais rencontre.”
• Section 2 — Ingenierie logicielle : “Cette division a consacre des efforts importants a l’etude de divers vecteurs d’infection dans nos systemes distribues.”

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

Etape 2 : Generer les embeddings

On convertit chaque chunk en embedding numerique via un modele d’embedding. Pour simplifier l’explication, imaginons un modele parfait qui renvoie exactement deux nombres dont on connait la signification :

• Le premier nombre represente a quel point le texte parle de medecine
• Le second nombre represente a quel point le texte parle d’ingenierie logicielle

Pour la section medicale, on obtiendrait [0.97, 0.34] — tres orientee medecine, mais avec quelques elements logiciels a cause du mot “bug”. Pour la section logicielle : [0.30, 0.97] — tres orientee logiciel, avec des connotations medicales a cause du mot “infection”.

Normalisation

L’API d’embedding effectue generalement une normalisation qui met chaque vecteur a une magnitude de 1.0. Pas besoin de comprendre les maths derriere — c’est automatique. On obtient des vecteurs normalises comme [0.944, 0.331] et [0.295, 0.955].

On peut visualiser ces embeddings sur un cercle unite, ou chaque point represente un chunk.

Etape 3 : Stocker dans une base vectorielle

On stocke ces embeddings dans une base de donnees vectorielle — une base specialisee optimisee pour stocker, comparer et rechercher des listes de nombres comme nos embeddings.

A 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 requete.

Etape 4 : Traiter la requete utilisateur

Quand un utilisateur pose une question comme “Je suis curieux a propos de l’entreprise. En particulier, qu’a fait le departement ingenierie logicielle cette annee ?”, on passe sa requete dans le meme modele d’embedding.

Cette requete produit un embedding du type [0.1, 0.89] — faible score medical, fort score logiciel. Apres normalisation : [0.112, 0.993].

Etape 5 : Trouver les embeddings similaires

On envoie l’embedding de la requete a notre base vectorielle et on lui demande de trouver les embeddings stockes les plus similaires.

La base retourne la section ingenierie logicielle car c’est la correspondance la plus proche.

Comment fonctionne la similarite : la similarite cosinus

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

Points cles sur la similarite cosinus :

Dans notre exemple, la similarite cosinus entre la requete et le chunk logiciel est 0.983 (tres forte). La similarite avec le chunk medical 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 similarite
• Valeurs elevees = faible similarite

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

Etape 6 : Creer 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 a 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 voila le pipeline RAG complet ! Le systeme a reussi a recuperer l’information la plus pertinente grace a la similarite semantique et l’a fournie comme contexte pour generer une reponse precise.

Quiz : Le flux RAG

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

Reponse : La normalisation met tous les vecteurs a la meme echelle (magnitude 1.0), ce qui permet de les comparer equitablement via la similarite cosinus. Sans normalisation, un vecteur plus “long” pourrait fausser les comparaisons.

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

Reponse : Parce que la section medicale contient le mot “bug”, qui est aussi un terme courant en ingenierie logicielle. L’embedding capture cette ambiguite semantique.