Le RAG, pour Retrieval-Augmented Generation ou génération augmentée par récupération, permet d'aider une IA à répondre à des questions à partir de documents internes. L'idée n'est pas d'envoyer toute la documentation au modèle, mais de récupérer en amont les informations réellement utiles pour répondre au questionnement de l'utilisateur.
Cette approche est particulièrement intéressante quand on veut interroger une base documentaire d'entreprise : procédures internes, règles RH, documentation produit, articles, PDF ou contenus structurés. On limite le volume envoyé au modèle et on réduit le risque qu'il se perde dans un contexte trop large.
Sommaire
00:00 Présentation
00:22 Pour quel besoin ?
01:30 Exemple
02:20 Comment ça marche ?
02:38 Le chunking
03:34 Embedding
04:33 Indexing / Stockage
05:35 Prompt final
06:11 Plusieurs types de RAG
07:35 Exemple de code
12:57 Conclusion
Pourquoi utiliser un RAG ?
On pourrait se dire qu'avec les modèles capables d'accepter des contextes de plus en plus grands, il suffit d'envoyer tous les documents à chaque question. En pratique, ce n'est pas idéal pour deux raisons principales :
- Le coût, en envoyant un contexte très important on augmente la consommation de token.
- un contexte trop large augmente le risque d'hallucination ou de réponse moins précise.
Toutes les questions ne mobilisent pas les mêmes documents. Une question sur les jours de télétravail et une question sur la facturation n'ont pas besoin du même contexte. Le rôle du RAG est justement de retrouver les informations pertinentes avant de solliciter le modèle conversationnel.
Le principe général
Un RAG simple fonctionne en deux grandes phases :
- une phase d'indexation, où l'on prépare les documents pour construire une base de données de connaissance.
- une phase de recherche et de génération, où l'on récupère les contenus qui ont un rapport avec la question pour construire la réponse finale.
Découper les contenus
La première étape est le chunking. Elle consiste à découper les documents en morceaux plus petits, appelés chunks. L'objectif n'est pas d'indexer un document entier d'un seul bloc, mais de créer des sections cohérentes qui portent chacune une idée ou une notion précise.
Quand les contenus sont déjà structurés avec des titres et des sections, le découpage est plus simple. Pour des contenus moins structurés, comme des transcriptions, il faut prévoir une étape supplémentaire pour repérer les séparations sémantiques (avec un classifier).
Cette étape est importante, car elle conditionne directement la qualité de la recherche. Des morceaux trop longs risquent de mélanger plusieurs sujets. Des morceaux trop courts peuvent manquer de contexte pour être utiles au modèle.
Transformer le texte en vecteurs
Une fois les contenus découpés, on génère un embedding pour chaque chunk. Un embedding est un vecteur qui représente la sémantique d'un texte. Deux textes proches en sens doivent produire des vecteurs proches. Cette représentation vectorielle permet ensuite de faire une recherche sémantique. On ne cherche pas seulement des mots-clés identiques, on cherche des morceaux de texte qui correspondent au sens de la question posée.
Le choix du modèle d'embedding a son importance, certains modèles peuvent être plus adaptés à des domaines particuliers (du texte juridique, du code ou de la documentation métier). Il faut donc tester et affiner selon le type de contenu à indexer.
Stocker les vecteurs dans une base adaptée
Les vecteurs générés doivent être stockés dans une base capable de retrouver rapidement les vecteurs proches. C'est le rôle d'une base de données vectorielle.
Il existe plusieurs solutions possibles et l'écosystème évolue rapidement (mais on peut siter Qdrant, Pinecone et pgvector par exemple). On peut aussi utiliser PostgreSQL avec une extension permettant de gérer les vecteurs.
À ce stade, la phase d'indexation est terminée : les documents sont découpés, transformés en vecteurs et stockés.
La recherche
Quand l'utilisateur pose une question, on applique le même principe que pendant l'indexation :
- on transforme la question en vecteur.
- on cherche dans la base les chunks dont les vecteurs sont les plus proches.
- on récupère les textes correspondants.
- on construit un prompt avec la question et les sources trouvées.
- on demande au modèle conversationnel de générer une réponse à partir de ces sources.
Cette étape crée un système de recherche sémantique. Le modèle reçoit uniquement les éléments liés à la question, ce qui rend la réponse plus ciblée et limite le bruit. On pourra aussi renvoyer les sources avec la réponse finale (cela permet de les afficher dans l'interface ou de demander au modèle de les citer dans sa réponse).
Affiner la pertinence
Un RAG simple donne déjà une bonne base, mais il faut souvent affiner les résultats. On peut par exemple ajouter un seuil de pertinence pour éviter de remonter des documents parasites (mais attention un seuil trop strict peut aussi retirer des éléments utiles). La bonne approche consiste à tester sur des questions réalistes et à ajuster progressivement : qualité du chunking, modèle d'embedding, nombre de résultats récupérés, seuil de pertinence et forme du prompt final.
Aller plus loin
Le RAG est plus un concept qu'une stack technique. L'implémentation peut varier selon les technologies, les bases de données, les modèles d'embedding et la manière de découper les documents. On peut aussi ajouter des couches supplémentaires :
- un branching RAG pour découper une question complexe en plusieurs sous-questions.
- un adaptive RAG pour décider si la recherche documentaire est vraiment nécessaire.
- un système de routing pour orienter la demande vers le bon outil.
- un RAG multimodal pour gérer d'autres types de données, comme des images ou des PDF.
Pour répondre à des questions simples, il n'est pas toujours nécessaire de complexifier. Le plus important est d'avoir une base claire : un bon découpage, des embeddings pertinents, une recherche vectorielle fiable et un prompt final construit avec les bonnes sources.