À retenir
  • 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.
  • Le coût d'un pipeline RAG en production varie de 200 à 3 000 € par mois pour une PME selon les volumes, contre plusieurs dizaines de milliers d'euros pour un fine-tuning équivalent.

Par Romain Rissoan5 février 202613 min de lecture

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 terme "Retrieval-Augmented Generation" a été formalisé dans un article de recherche de Meta en 2020, mais le concept s'est massivement démocratisé en entreprise à partir de 2023, porté par la disponibilité des APIs LLM et la maturité des bases vectorielles open source. Ce qui était un pattern de recherche expérimental est devenu en quelques années une architecture standard, déployée dans des milliers d'organisations à travers le monde pour des usages allant de l'assistance juridique à la gestion documentaire technique.

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).

Il existe aussi des architectures hybrides qui combinent les deux approches : un modèle fine-tuné pour maîtriser le style et le vocabulaire métier, enrichi par RAG pour accéder aux données opérationnelles récentes. Cette combinaison est particulièrement pertinente dans les secteurs avec un lexique très spécialisé (finance, pharmacie, droit) où le modèle de base produit des formulations inadaptées. Elle reste cependant plus coûteuse à maintenir et se justifie principalement pour des volumes d'utilisation importants.

Architecture d'un RAG : les quatre briques

Un pipeline RAG se décompose en quatre phases qui s'enchaînent à chaque requête utilisateur. Chaque brique a ses propres paramètres de configuration et ses propres leviers d'optimisation. Comprendre leur interaction est essentiel pour diagnostiquer les problèmes de qualité et améliorer les performances de façon ciblée.

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.

Trois stratégies de chunking coexistent en pratique. Le chunking fixe découpe les documents à un nombre défini de tokens (typiquement 256 à 512) avec un chevauchement (overlap) de 10 à 20 % pour préserver le contexte aux jonctions. Le chunking par structure respecte les limites naturelles du document : sections, paragraphes, items de liste. Le chunking sémantique, plus récent, regroupe les phrases dont les embeddings sont proches pour former des blocs cohérents thématiquement. Cette dernière approche produit généralement de meilleurs résultats mais est plus coûteuse en calcul lors de l'indexation.

La phase d'indexation comprend également le traitement des métadonnées : titre du document, date de création ou de mise à jour, auteur, département source, niveau de confidentialité. Ces métadonnées permettent des filtrages précis lors de la récupération — par exemple, ne récupérer que les procédures valides à la date de la requête, ou restreindre la recherche aux documents d'un département spécifique. Des métadonnées bien structurées peuvent doubler la précision du système sans changer le modèle d'embedding.

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.

Le choix du modèle d'embedding a un impact direct sur la qualité de la récupération. Les modèles multilingues (multilingual-e5, paraphrase-multilingual-mpnet) sont indispensables pour des bases de documents en plusieurs langues. Les modèles spécialisés par domaine — il en existe pour le droit, la médecine, la finance — peuvent surpasser les modèles généralistes de 10 à 30 % sur des benchmarks sectoriels. La dimension du vecteur (768 ou 1536 dimensions selon les modèles) influence directement les coûts de stockage et la vitesse de recherche à grande échelle.

Le choix de la base vectorielle doit intégrer plusieurs critères : la capacité à filtrer sur les métadonnées (filtrage hybride), la gestion des mises à jour et suppressions (certaines bases ne supportent pas bien les mises à jour fréquentes), la scalabilité (Pinecone et Weaviate gèrent des dizaines de millions de vecteurs ; Chroma est plus adapté aux prototypes et aux volumes modestes), et les options de déploiement (SaaS, cloud privé, on-premise). Pour une entreprise soumise à des contraintes de souveraineté des données, pgvector — l'extension vectorielle de PostgreSQL — offre une solution robuste intégrée dans un moteur de base de données maîtrisé.

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.

La recherche hybride — combinaison de la recherche vectorielle (sémantique) et de la recherche BM25 (lexicale, par mots-clés) — est aujourd'hui considérée comme la meilleure pratique pour la plupart des cas d'usage métier. La recherche vectorielle excelle sur les requêtes conceptuelles et les synonymes ; BM25 est plus précis lorsque la question contient des termes techniques exacts (numéros de référence, noms propres, codes produit). Leur combinaison via un score fusionné (Reciprocal Rank Fusion) améliore systématiquement les métriques de rappel.

Le re-ranking est une étape supplémentaire qui réordonne les N premiers résultats de la recherche à l'aide d'un modèle cross-encoder plus lent mais plus précis que la similarité cosinus. Des modèles comme Cohere Rerank ou les cross-encoders de sentence-transformers évaluent la pertinence de chaque paire (question, chunk) de façon plus fine que la simple distance vectorielle. Cette étape coûte quelques centimes par requête mais peut améliorer la précision de 15 à 25 % sur des corpus hétérogènes.

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.

La conception du prompt de génération est souvent le levier le plus rapide pour améliorer la qualité des réponses. Un prompt RAG efficace inclut généralement : une instruction explicite d'utiliser uniquement les documents fournis, une demande de citation systématique des sources avec titre et passage, une instruction pour signaler l'absence de réponse dans la base plutôt que d'halluciner, et des contraintes de format adaptées à l'interface (longueur de réponse, présence de listes, niveau de technicité). La température du modèle est habituellement réglée basse (0,1 à 0,3) pour des cas d'usage documentaires où la reproductibilité prime sur la créativité.

Coûts, performances et stratégies d'évaluation

L'évaluation d'un système RAG est plus complexe que celle d'un logiciel classique, car la qualité des réponses dépend de l'interaction entre quatre variables : la qualité des chunks, la pertinence du retrieval, la précision du re-ranking, et la capacité de génération du LLM. Identifier où se situe un problème de qualité requiert une approche d'évaluation structurée à chaque niveau du pipeline.

Métriques d'évaluation du retrieval

Deux métriques principales évaluent la qualité de la récupération. Le rappel (recall) mesure la proportion de documents pertinents effectivement récupérés parmi tous les documents pertinents de la base — une métrique critique lorsqu'il ne faut pas manquer d'information (compliance, juridique). La précision (precision) mesure la proportion de documents récupérés qui sont effectivement pertinents — une métrique importante lorsque le contexte injecté dans le LLM doit rester propre pour éviter la dilution du signal. Le compromis entre ces deux métriques se pilote principalement via le paramètre K (nombre de chunks récupérés) et le seuil de score minimal.

Des frameworks d'évaluation spécialisés comme RAGAS (RAG Assessment) permettent de mesurer automatiquement la faithfulness (fidélité de la réponse aux sources récupérées), l'answer relevancy (pertinence de la réponse par rapport à la question), et le context precision (proportion du contexte récupéré réellement utile pour la réponse). Ces métriques automatisées ne remplacent pas l'évaluation humaine mais permettent de détecter rapidement les régressions lors des mises à jour du pipeline.

Structure de coûts d'un pipeline RAG

Les coûts d'un pipeline RAG en production se répartissent en trois catégories. Les coûts d'indexation (one-shot et incrémentaux) couvrent le calcul des embeddings lors de l'ingestion des documents — typiquement quelques centimes pour 1 000 pages avec les modèles actuels. Les coûts de requête comprennent le calcul de l'embedding de la question, la recherche vectorielle, et le coût d'inférence du LLM (proportionnel au nombre de tokens dans le contexte injecté). Les coûts d'infrastructure couvrent l'hébergement de la base vectorielle et de l'API.

Pour une PME avec 10 000 requêtes mensuelles sur une base de 50 000 documents, le coût mensuel total se situe généralement entre 200 et 800 € avec un LLM SaaS, ou entre 800 et 2 500 € avec une infrastructure on-premise (incluant l'amortissement matériel et les coûts d'énergie). Le passage à un modèle open source auto-hébergé (Mistral, Llama) réduit les coûts d'inférence mais implique un investissement initial en infrastructure et en ingénierie MLOps. Ce choix se justifie généralement à partir de 50 000 requêtes mensuelles ou lorsque les contraintes de confidentialité l'imposent.

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.

La sécurité d'un système RAG comprend également la protection contre les attaques par injection de prompt. Si des utilisateurs peuvent injecter des contenus dans la base documentaire (via une GED ouverte, un wiki collaboratif ou un système de tickets), un acteur malveillant peut tenter d'insérer des instructions qui modifient le comportement du LLM lors de la génération. Un cadrage stratégique intégrant la sécurité dès la conception est indispensable. Des garde-fous techniques — validation des contenus ingérés, détection d'injections dans les chunks récupérés, sandboxing du prompt de génération — sont recommandés pour les systèmes accessibles à un large public interne ou externe.

À lire aussi