RAG expliqué : comment les systèmes d’IA récupèrent des connaissances fraîches sur demande.
Apprenez comment fonctionne la génération augmentée par récupération, des blocs de données et des embeddings à la recherche vectorielle, afin que les modèles d’IA puissent répondre aux questions sans être réentraînés.
Imaginez un assistant IA qui a terminé son entraînement il y a longtemps.
Vous lui demandez :
« Qu’y a-t-il dans ce document que je viens de télécharger ? »
Le modèle n’a jamais rencontré ce fichier pendant son entraînement.
Alors comment pourrait-il répondre ?
Une solution est une technique appelée Retrieval-Augmented Generation, souvent abrégée en RAG.
RAG permet à un système IA de récupérer des informations pertinentes provenant d’sources externes et d’intégrer ces données dans la réponse qu’il génère.
Voici ce qui est intéressant :
Le modèle n’a pas besoin d’être réentraîné chaque fois que de nouvelles informations apparaissent.
Examinons comment cela fonctionne.
Le problème : l’IA ne peut pas tout savoir
Les grands modèles de langage apprennent à partir des données sur lesquelles ils ont été entraînés.
Training Data
↓
Model Training
↓
Model Parameters
↓
AI Model
↓
Generate Answers
Lorsque l’entraînement est terminé, le modèle ne dispose d’aucun moyen automatique pour intégrer de nouveaux documents, sites web, rapports d’entreprise ou fichiers privés qui apparaissent par la suite.
Supposons que vous terminiez l’entraînement d’un modèle aujourd’hui.
Demain, quelqu’un créera :
new_report.pdf
Ce PDF n’existait tout simplement pas au moment où le modèle a été entraîné.
Alors comment le modèle répondrait-il à :
« Quelles sont les trois principales conclusions de ce rapport ? »
C’est précisément cette lacune que RAG a été conçu pour combler.
Qu’est-ce que RAG ?
RAG = Retrieval-Augmented Generation
Le nom même explique le mécanisme :
- Retrieval → localiser les informations pertinentes
Au lieu du flux simple suivant :
Question
↓
LLM
↓
Answer
on peut construire un pipeline comme ceci :
Question
↓
Retrieve relevant information
↓
Add information to context
↓
LLM
↓
Answer
Ce changement architectural peut avoir un impact majeur.
RAG contre l’IA traditionnelle
Sans RAG, le flux est direct :
┌──────────────┐
Question ───→│ LLM │
└──────┬───────┘
↓
Answer
Avec l’ajout de RAG :
┌─────────────────┐
│ External Data │
│ PDFs / Docs │
│ Database / Web │
└────────┬────────┘
↓
Question → Retrieval → Relevant Context
↓
LLM
↓
Answer
Le modèle n’a plus besoin de mémoriser tout ce qu’il faut à l’avance.
Au lieu de cela, il peut récupérer des faits pertinents sur demande.
Comment fonctionne réellement RAG ?
Une configuration standard de RAG passe par plusieurs étapes distinctes :
Documents
↓
Document Processing
↓
Chunking
↓
Embeddings
↓
Vector Database
↓
← User Question
↓
Query Embedding
↓
Similarity Search
↓
Relevant Chunks
↓
LLM
↓
Final Answer
Examinons chacune d’elles.
Rassemblez vos données
Le point de départ consiste à collecter du matériel source. Cela peut inclure :
- Fichiers au format PDF
- Documents créés avec Word
- Pages extraites de sites web
- Articles académiques ou de recherche
- Dossiers internes de l’entreprise
- Manuels décrivant un produit
- Fichiers de texte brut
- Données stockées dans une base de données
- Entrées provenant d’une base de connaissances
Pour faire un exemple, imaginez un dossier contenant :
company_policy.pdf
research_paper.pdf
employee_handbook.pdf
product_manual.pdf
Un pipeline RAG est capable d’ingérer et de traiter tous ces éléments.
Décomposer les documents en blocs
Fournir un modèle tout un document d’un seul coup n’est généralement pas pratique en raison des contraintes de taille.
C’est pourquoi les documents sont divisés en unités plus petites appelées blocs.
Voici une illustration simple :
Document
│
├── Chunk 1
├── Chunk 2
├── Chunk 3
├── Chunk 4
├── Chunk 5
└── ...
Imaginez un document de 100 pages contenant plusieurs milliers de phrases.
Au lieu de scanner l’ensemble du texte à chaque requête, vous pouvez le diviser en sections plus faciles à gérer :
Chunk 1 → Introduction
Chunk 2 → Architecture
Chunk 3 → Security
Chunk 4 → Performance
Chunk 5 → Limitations
La manière de diviser le contenu varie en fonction de sa nature et de ce que vous développez.
Convertir du texte en embeddings
C’est là que les choses deviennent vraiment intéressantes.
Les ordinateurs ne peuvent pas comprendre le sens des textes de la même manière que les humains, du moins pas de façon native.
Pour contourner ce problème, le texte est traduit en vecteurs numériques appelés embeddings.
Prenons cet exemple :
"Machine learning is a branch of AI"
↓
Embedding Model
↓
[0.21, -0.14, 0.73, ...]
Et une deuxième phrase :
"Artificial intelligence includes machine learning"
↓
[0.19, -0.11, 0.70, ...]
Puisque ces deux phrases ont un sens similaire, leurs vecteurs résultants ont tendance à se trouver proches l’un de l’autre dans l’espace des embeddings.
Visualisé de manière approximative :
AI
●
/ \
/ \
ML ● ● Robotics
\
\
Cooking ●
L’objectif n’est pas de trouver une superposition littérale des mots.
À la place, l’objectif est de capturer une similitude sémantique — c’est-à-dire une proximité dans le sens.
Qu’est-ce que la recherche sémantique ?
"voiture"
et chercherait des documents contenant littéralement le mot voiture.
La recherche sémantique, quant à elle, tente de comprendre ce que signifie réellement la requête.
Par exemple, une requête comme :
"Comment les véhicules électriques stockent-ils de l’énergie ?"
pourrait faire apparaître un passage expliquant que les véhicules électriques s’appuient sur des cellules lithium-ion pour conserver leur charge électrique.
Les formulations ne coïncident que très peu, mais la correspondance reste pertinente.
Cela fonctionne parce que les embeddings codent des relations de sens, et non seulement l’orthographe.
Stocker les embeddings dans une base de données vectorielle
Lorsque les embeddings existent, ils ont besoin d’un endroit où être stockés.
C’est là que intervient une base de données vectorielle, qui contient :
Chunk
+
Embedding
+
Metadata
D’une structure approximativement comme celle-ci :
Vector Database
ID Vector Text
-------------------------------------
1 [0.21,...] Chunk A
2 [0.78,...] Chunk B
3 [0.34,...] Chunk C
4 [0.91,...] Chunk D
Lorsqu’une personne soumet une question, le système parcourt ces vecteurs stockés pour trouver un contexte correspondant.
Parmi les outils largement utilisés pour ce type de recherche vectorielle, on trouve :
- FAISS
- pgvector
- Pinecone
- Weaviate
- Milvus
- Chroma
Le choix de la base de données spécifique n’est pas l’élément essentiel.
Ce qui compte, c’est ceci :
Gardez les informations sous une forme qui permet une récupération rapide et basée sur le sens.
L’utilisateur pose une question
Supposons qu’un utilisateur tape :
"Quels mécanismes de sécurité le système utilise-t-il ?"
Cette question est alors convertie en son propre embedding.
User Question
↓
Embedding Model
↓
Query Vector
À ce stade, le système possède une empreinte numérique de la question.
Recherche d’informations pertinentes
Ce vecteur de requête est ensuite comparé à tous les vecteurs déjà présents dans la base de données.
En termes généraux :
Query
●
/ \
/ \
● ●
Relevant Relevant
Chunk Chunk
●
Unrelated
Les fragments les plus similaires sont extraits.
Par exemple, étant donné :
Question:
"What security mechanisms does the system use?"
Le système peut retourner :
Retrieved:Chunk 17 → Authentication
Chunk 42 → Encryption
Chunk 51 → Access control
Avec cela, le modèle dispose désormais d’un contexte significatif et pertinent sur lequel travailler.
Ajout des informations récupérées au prompt
Lorsque les fragments pertinents sont trouvés, ils sont transmis au LLM en tant que contexte accompagnant la question originale.
Conceptuellement, la structure du prompt ressemble à ceci :
System Instructions
+
User Question
+
Retrieved Context
↓
LLM
↓
Answer
Par exemple :
Context:
"The system uses AES-GCM encryption
for protecting stored data..."Question:"What encryption method does the
system use?"
Avec cette configuration, le modèle peut répondre par quelque chose comme :
"Le système utilise le chiffrement AES-GCM pour protéger les données stockées."
Cette réponse s’appuie sur le matériel récupéré plutôt que de dépendre uniquement de ce que le modèle a absorbé lors de son entraînement initial.
C’est là l’idée clé
Le modèle lui-même n’a pas nécessairement appris quoi que ce soit de permanent à partir de cet échange.
Ses paramètres internes restent inchangés.
Au lieu de cela, le flux se déroule comme suit :
New Information
↓
External Knowledge Store
↓
Retrieve When Needed
↓
LLM Uses Context
↓
Answer
Ce séparement entre les connaissances fixes du modèle et une source de connaissances externe interchangeable est précisément ce qui confère sa force à RAG.
RAG ne signifie pas que l’IA a appris les informations
Cette distinction est très importante et il est facile de se tromper à son sujet.
Supposons que vous téléchargiez un fichier comme celui-ci :
Project_Report.pdf
et que l’assistant commence à répondre aux questions en s’appuyant sur lui.
Cela ne signifie pas que le modèle ait intégré de manière permanente le contenu de ce rapport dans ses poids.
Au contraire, le document est :
Stored externally
↓
Retrieved when relevant
↓
Provided as context
↓
Used to generate response
Une analogie utile est celle d’un étudiant qui consulte un manuel pendant un examen.
L’étudiant n’a pas mémorisé chaque page à l’avance.
Le processus se déroule plutôt comme suit :
Poser une question, puis trouver la page pertinente, la lire, puis répondre
RAG fonctionne plus ou moins de la même manière.
RAG vs Ajustement fin
Cette comparaison revient constamment, il est donc utile de la clarifier.
Ajustement fin
L’ajustement fin consiste en réalité à modifier les paramètres du modèle en poursuivant son entraînement sur un ensemble ciblé d’exemples.
Conceptuellement :
Base Model
↓
Training Data
↓
Fine-Tuning
↓
Modified Model
RAG
RAG laisse le modèle essentiellement tel quel et fournit plutôt des informations externes au moment où une question est posée.
Base Model
+
External Knowledge
↓
Retrieval
↓
Context
↓
Answer
Voici une vue simplifiée côte à côte :
| Fonctionnalité | RAG | Ajustement fin |
|---|---|---|
| Changement des paramètres du modèle | Généralement non | Oui |
| Connaissances externes | Adéquation excellente | |
| Mise à jour des connaissances | Mettre à jour les documents ou l’index | Peut nécessiter un reconditionnement |
| Documents privés | Utile | Possible, mais avec d’autres compromis |
| Style ou comportement | Limité | cas d’usage plus solide|
| Ancrage dans une source | Potentiel important | Non garanti par nature |
Ces deux techniques ne sont pas mutuellement exclusives ; les équipes peuvent les combiner.
RAG peut-il utiliser Internet ?
Oui, il le peut.
L’ensemble des connaissances externes n’a pas besoin d’être stocké dans un système de gestion de documents privé.
Un système peut plutôt récupérer des informations à partir de sources telles que :
Internet
↓
Search Engine
↓
Relevant Pages
↓
LLM
↓
Answer
Cela devient précieux chaque fois qu’une question dépend de faits à jour.
Par exemple :
« Qu’a changé dans la dernière version de ce logiciel ? »
Dans ce cas, le système pourrait d’abord récupérer la documentation actuelle et l’utiliser pour formuler la réponse.
Néanmoins, la simple récupération d’informations ne garantit pas encore l’exactitude.
La source depuis laquelle les informations sont récupérées doit rester fiable et réellement pertinente pour la question.
RAG pour vos propres documents
L’un des usages les plus pratiques de ce modèle est de vous permettre de communiquer directement avec vos propres fichiers.
Imaginez un dossier contenant quelque chose comme :
Research/
│
├── paper1.pdf
├── paper2.pdf
├── dataset_notes.pdf
├── experiment_results.pdf
└── thesis.pdf
Une configuration basée sur RAG vous permettrait de poser des questions telles que :
"Quelles étaient les principales limites identifiées dans les expériences ?"
Le flux de travail ressemblerait alors à ceci :
Your Documents
↓
Extract Text
↓
Chunk Documents
↓
Create Embeddings
↓
Vector Database
↓
Question
↓
Semantic Search
↓
Relevant Sections
↓
LLM
↓
Answer
C’est précisément pour cette raison que RAG est devenu si précieux pour les workflows de recherche et les systèmes de connaissances à grande échelle.
RAG dans les applications réelles
Ce modèle se retrouve dans une grande variété de systèmes.
Soutien client
Customer Question
↓
Product Documentation
↓
Retrieve Relevant Section
↓
AI
↓
Response
Éducation
Student Question
↓
Course Materials
↓
Relevant Concepts
↓
AI Tutor
↓
Explanation
Recherche
Research Question
↓
Research Papers
↓
Relevant Sections
↓
AI
↓
Summary
Knowledge interne de l’entreprise
Employee Question
↓
Internal Documents
↓
Retrieve Policy
↓
AI
↓
Answer
RAG ne supprime pas complètement les hallucinations
Cet aspect mérite d’être souligné.
Vous pourriez penser :
« Si j’utilise RAG, l’IA ne hallucinera jamais. »
C’est pas tout à fait exact.
RAG peut réduire certains types de réponses non étayées, mais il ne fait pas disparaître complètement le problème.
Par exemple :
Bad Retrieval
↓
Wrong Context
↓
LLM
↓
Wrong Answer
Il existe également plusieurs autres façons dont les choses peuvent mal se passer :
- Des fragments qui ont été divisés de manière à en altérer le sens
- Des faits pertinents qui ne se trouvent tout simplement pas dans le matériel source
- Des extraits récupérés qui ne sont en réalité pas liés à la question
- Des documents obsolètes ou plus exacts
- Des fichiers sources qui étaient déjà erronés ou incompatibles dès le départ
- Trop de contexte fourni d’un coup dans la demande
- Le modèle lui-même qui raisonne incorrectement malgré des données d’entrée de bonne qualité
Pour cette raison, un système RAG solide a besoin de plus qu’une simple base de données vectorielle en arrière-plan.
Évaluation d’un système RAG
Vous pouvez évaluer un pipeline RAG à plusieurs niveaux différents.
Qualité de la récupération
Le système a-t-il obtenu les informations correctes ?
Question
↓
Retrieved chunks
↓
Are they relevant?
Qualité de la génération
Le modèle a-t-il réellement fait bon usage des informations récupérées ?
Retrieved Context
↓
Generated Answer
↓
Is the answer supported?
Qualité globale du processus
Le pipeline dans son ensemble répond-il correctement à la question de l’utilisateur ?
Question
↓
Retrieval
↓
Context
↓
Generation
↓
Final Answer
Il est possible que le système échoue même lorsque le LLM sous-jacent est excellent.
Par exemple :
Si la récupération affiche le mauvais document, même un modèle très performant peut finir par donner une réponse erronée.
Les mathématiques derrière les embeddings
Les embeddings permettent de comparer des informations à l’aide des mathématiques.
Une mesure de similarité largement utilisée est la similarité cosinus.
Pour deux vecteurs A et B, la similarité cosinus est calculée comme le produit scalaire de A et B divisé par le produit de leurs magnitudes.
La valeur obtenue indique dans quelle mesure les deux vecteurs sont alignés en direction.
En termes simples :
High similarity
↓
Vectors point in similar directions
↓
Likely related meaning
Cela offre à RAG une méthode mathématique concrète pour localiser les informations semantiquement liées à une requête.
RAG, c’est comme donner une bibliothèque à l’IA
Ce pourrait être la manière la plus claire d’en visualiser le principe.
Pensez à une IA comme à un étudiant très compétent.
Sans RAG :
Student
↓
Uses what they already remember
↓
Answer
Avec RAG :
Student
↓
Goes to library
↓
Finds relevant book
↓
Reads relevant pages
↓
Answers question
Les connaissances de base et la capacité de raisonnement de l’étudiant n’ont pas changé.
Ce qui a changé, c’est les informations dont cet étudiant dispose à un moment donné.
C’est essentiellement l’idée principale derrière RAG.
Où va RAG
Les systèmes RAG deviennent de plus en plus sophistiqués.
Les futures versions pourraient combiner :
User Question
↓
Query Understanding
↓
Multiple Retrieval Sources
↓
Document Ranking
↓
Reasoning
↓
Tool Use
↓
Verification
↓
Answer + Evidence
Au lieu de s’appuyer sur un seul document, un système pourrait effectuer des recherches dans :
PDFs
+
Database
+
Website
+
API
+
Company Knowledge Base
Les éléments pertinents sont ensuite fusionnés entre eux.
Cela pousse RAG vers le statut d’architecture plus large de connaissance et de raisonnement pour les agents IA, et non simplement d’un truc de récupération d’informations.
Le contexte général
RAG représente un changement significatif dans la façon dont nous concevons les connaissances des IA.
Le modèle ancien était :
Train AI
↓
Put knowledge into model
↓
Ask questions
L’approche plus récente ressemble davantage à :
Train AI
↓
Keep knowledge externally
↓
Retrieve relevant information
↓
Reason over it
↓
Generate answer
Séparer l’intelligence du modèle des connaissances externes s’avère être extrêmement puissant.
Le modèle n’a plus besoin de conserver tous les faits en interne.
Au lieu de cela, il doit savoir comment utiliser efficacement les informations une fois qu’il en a accès.
Dernière pensée
Peut-être que l’avenir de l’IA ne réside pas dans la création d’un modèle qui a mémorisé tout ce qu’il y a à savoir.
Peut-être consiste-t-il plutôt à construire un modèle capable de déterminer ce qu’il doit rechercher, de trouver la source appropriée, d’utiliser efficacement ces informations et de vérifier si la réponse est fiable.
C’est ce qui rend RAG digne d’attention.
AI Model
+
External Knowledge
+
Retrieval
+
Reasoning
+
Verification
↓
More Useful AI
Cela mène à une idée plus large : l’IA la plus intelligente n’est pas nécessairement celle qui sait tout. C’est plutôt celle qui sait comment trouver ce dont elle a besoin.
Lectures complémentaires
- Agentic AI Explained: From Language Models to Autonomous Agents — Une présentation structurée de la manière dont les modèles de langage évoluent vers des systèmes agents grâce à des outils, une mémoire, de la planification, des architectures multi-agents et l’intégration MCP.