Architecture documentaire

RAG local en entreprise : architecture et conditions de réussite

Comprendre l’architecture d’un RAG local, ses conditions de réussite, son évaluation, ses limites de sécurité et les responsabilités d’exploitation.

24 juillet 202611 min

Réponse directe

Un RAG local recherche des passages dans les sources autorisées puis les fournit au modèle comme contexte de réponse. Il ne corrige pas des documents obsolètes, ne remplace pas les droits d’accès et ne garantit pas l’exactitude. Sa réussite dépend d’abord des sources, des permissions, d’un corpus d’évaluation et de citations vérifiables.

Définition

Le RAG ajoute un contexte, il ne réentraîne pas le modèle.

Le Retrieval-Augmented Generation associe une étape de recherche à une étape de génération. À chaque question, le système cherche des passages pertinents dans un corpus puis les fournit au modèle. Le modèle doit répondre à partir de ce contexte et, idéalement, citer les sources utilisées.

Rechercher

Identifier les passages autorisés les plus utiles pour la question.

Répondre

Produire une réponse limitée par les instructions et le contexte reçu.

Vérifier

Afficher les références et permettre une validation par l’utilisateur.

Architecture

Une chaîne de données et de responsabilités.

Un RAG exploitable ne se résume pas à une base vectorielle. Les droits d’accès doivent être appliqués avant que le contexte n’arrive au modèle ; la provenance et la version des documents doivent rester visibles jusqu’à la citation.

Sources et permissions

Documents autorisés et propriétaires identifiés

GEDprocéduresbases métierdroits d’accès
Ingestion

Extraction, découpage et métadonnées

parsingchunksversionprovenance
Index

Représentation et recherche

embeddingsindex lexicalindex vectorielfiltres
Retrieval

Sélection du contexte utile

requêtefiltres ACLreclassementpassages
Génération locale

Réponse à partir du contexte

LLMinstructionscitationsrefus
Contrôle

Validation, journaux et évaluation continue

feedbacktestsmonitoringaudit
Architecture de référence à adapter aux données, aux droits et au niveau de service.

Prérequis

Six conditions de réussite.

Des sources possédées et maintenues

Chaque corpus a un propriétaire, une fréquence de mise à jour et une règle d’archivage.

Des permissions applicables à la recherche

Un utilisateur ne doit jamais récupérer un passage auquel il n’a pas droit, même si le modèle peut techniquement le résumer.

Un découpage adapté au document

La taille des passages, les titres, tableaux et métadonnées sont évalués selon les questions réelles.

Des réponses avec provenance

Les passages cités, leur document et leur version doivent être accessibles depuis la réponse.

Une règle de refus

Le système doit savoir indiquer qu’aucune source suffisante n’a été trouvée.

Une boucle de maintenance

Les erreurs observées alimentent le corpus de test, les réglages de recherche et la gouvernance documentaire.

Évaluation

Tester la recherche séparément de la réponse.

Une réponse incorrecte peut venir d’un document absent, d’un mauvais passage, d’un contexte tronqué ou du modèle. Un jeu d’évaluation doit donc conserver la question, la source attendue, les passages pertinents et les critères de réponse.

Recherche

Le bon document et le bon passage apparaissent-ils dans les premiers résultats ?

Fidélité

La réponse est-elle supportée par les passages cités, sans ajout non démontré ?

Complétude

Les éléments indispensables de la réponse attendue sont-ils présents ?

Refus et sécurité

Le système refuse-t-il lorsque la source manque ou que l’utilisateur n’est pas autorisé ?

Limites

Les risques à traiter explicitement.

  • Documents obsolètes ou contradictoires
  • Fuite de données par des droits mal appliqués
  • Instructions malveillantes dans les documents
  • Passages pertinents absents des premiers résultats
  • Réponse plausible mais non supportée par la source
  • Coût mémoire et latence d’un contexte trop long

Sources

Références utilisées.

Les affirmations techniques s’appuient en priorité sur des organismes publics, des publications de recherche et la documentation des outils.

Décision suivante

Valider le cas d’usage avant de choisir le modèle ou le matériel.

Présenter votre contexte