- Le RAG (Retrieval-Augmented Generation) connecte un LLM à une base documentaire externe sans modifier les poids du modèle.
- Il est moins coûteux et plus facile à maintenir que le fine-tuning pour des bases documentaires qui évoluent régulièrement.
- Selon Gartner, le RAG est la technique d'adaptation de LLM la plus adoptée en entreprise en 2025-2026, devant le fine-tuning et le prompt engineering pur.
- L'architecture comprend quatre briques : indexation, embeddings, récupération et génération.
- La sécurité des données est maîtrisable : les données ne quittent pas votre infrastructure si le modèle est hébergé on-premise ou en cloud privé.
- La qualité du découpage des documents (chunking) conditionne 60 à 70 % de la pertinence des réponses finales.
Qu'est-ce que le RAG ?
Le RAG (Retrieval-Augmented Generation) est une architecture qui enrichit le contexte d'un modèle de langage avec des documents récupérés dynamiquement depuis une base de connaissances, au moment même où l'utilisateur pose sa question. Au lieu de mémoriser vos données pendant l'entraînement, le modèle les consulte à la demande — comme un expert qui feuillette un classeur avant de vous répondre.
En pratique, cela donne : un collaborateur pose une question sur votre politique RH, le système récupère les passages pertinents du document interne, les injecte dans le prompt du LLM, et le modèle génère une réponse sourcée et vérifiable. Si la politique change, il suffit de mettre à jour le document dans la base — aucun ré-entraînement nécessaire.
Le RAG répond à la question que tout DSI se pose : "Comment donner à un LLM accès à nos connaissances internes sans les exposer à l'éditeur du modèle ?"
Pourquoi le RAG plutôt que le fine-tuning ?
Le fine-tuning consiste à ré-entraîner un modèle sur vos données pour en modifier les poids ; le RAG lui fournit les informations au moment de l'inférence. Les deux approches ne répondent pas aux mêmes besoins.
- Mises à jour des données : le RAG gère nativement les contenus qui évoluent (réglementation, procédures, offres) — le fine-tuning nécessite un nouveau cycle d'entraînement à chaque changement.
- Coût : fine-tuner un modèle de taille significative coûte de 10 000 à plusieurs centaines de milliers d'euros selon la taille du corpus ; un pipeline RAG se déploie pour une fraction de ce budget.
- Traçabilité : le RAG cite ses sources (chunk, document, page) — une exigence croissante dans les secteurs régulés.
- Quand préférer le fine-tuning : lorsque vous souhaitez modifier le style ou la tonalité du modèle, ou l'adapter à un langage très spécialisé absent de ses données d'entraînement (jargon métier rare, langue peu représentée).
Architecture d'un RAG : les quatre briques
Un pipeline RAG se décompose en quatre phases qui s'enchaînent à chaque requête utilisateur.
1. Indexation des documents
Vos documents (PDF, Word, pages intranet, tickets CRM…) sont découpés en fragments appelés "chunks". La taille et la stratégie de découpage sont déterminantes : trop court, le contexte est perdu ; trop long, le signal pertinent est dilué dans du bruit. Un bon chunking combine des règles sémantiques (paragraphes, sections) plutôt que des coupures arbitraires au nombre de caractères.
2. Embeddings et base vectorielle
Chaque chunk est transformé en vecteur numérique par un modèle d'embedding (OpenAI Ada, Cohere, sentence-transformers…). Ces vecteurs sont stockés dans une base vectorielle (Pinecone, Weaviate, pgvector, Chroma). La question de l'utilisateur est, elle aussi, convertie en vecteur au moment de la requête.
3. Récupération (retrieval)
Le système calcule la similarité cosinus entre le vecteur de la question et les vecteurs des chunks. Les N passages les plus proches sémantiquement sont sélectionnés. Des techniques de re-ranking (BM25, cross-encoders) améliorent la précision en combinant recherche vectorielle et recherche lexicale.
4. Génération
Les passages récupérés sont injectés dans le prompt système du LLM, qui génère une réponse en s'appuyant exclusivement sur ces sources. Un bon prompt RAG demande au modèle de citer ses sources et d'indiquer explicitement quand il ne trouve pas la réponse dans les documents fournis.
Sécurité & confidentialité des données
La confidentialité est la première préoccupation des directions juridiques et de la DSI face à un projet RAG. Les réponses varient selon l'architecture choisie.
- Cloud SaaS (OpenAI, Azure OpenAI…) : les chunks sont envoyés à l'API de l'éditeur à chaque requête. Vérifiez les conditions de traitement des données et activez les options "no training" disponibles. L'AI Act et le RGPD encadrent ces transferts.
- Cloud privé (Azure Confidential Computing, AWS Nitro…) : l'inférence s'effectue dans un enclave sécurisé ; les données ne sortent pas de votre périmètre contractuel.
- On-premise (Ollama, vLLM, modèles open source) : aucune donnée ne quitte votre infrastructure. Idéal pour les données très sensibles (RH, juridique, R&D). La CNIL recommande cette option pour les traitements impliquant des données personnelles à grande échelle.
Quel que soit le choix d'hébergement, mettez en place un contrôle d'accès granulaire à la base vectorielle : un utilisateur ne doit accéder qu'aux documents auxquels il a normalement droit dans votre SI. Un RAG sans ACL (Access Control List) peut involontairement exposer des données confidentielles entre départements.