Knowledge Engineering
Comprendre/structurer/exploiter les connaissances

Comment construire un système RAG fiable : méthode et architecture

Construire un système RAG ne consiste pas seulement à déposer des documents dans une base vectorielle et à connecter un modèle de langage.

Un prototype peut fonctionner rapidement sur quelques questions simples. La difficulté apparaît lorsque le système doit répondre de manière fiable à de vrais utilisateurs, sur des documents nombreux, évolutifs et parfois contradictoires.

Un système RAG fiable doit notamment :

La fiabilité d’un RAG dépend moins de la puissance du modèle que de la qualité de la chaîne complète reliant la question aux sources.

Ce guide présente une méthode progressive pour construire un système RAG exploitable dans un contexte professionnel.

Ce que nous allons construire

Nous prendrons l’exemple d’un assistant destiné à un service de support technique.

Il devra répondre à des questions comme :

Le même processus peut être adapté à :

Qu’est-ce qu’un RAG fiable ?

Un système RAG fiable ne signifie pas qu’il répond toujours.

Il doit au contraire savoir distinguer trois situations :

1. Les sources permettent de répondre.
2. Les sources sont contradictoires ou insuffisantes.
3. La question se situe hors du périmètre.

Dans le premier cas, il répond avec des sources.

Dans le deuxième cas, il indique les limites.

Dans le troisième cas, il refuse de conclure ou réoriente l’utilisateur.

La fiabilité comprend plusieurs dimensions.

Fiabilité documentaire

Les documents utilisés sont :

Fiabilité de la recherche

Le système retrouve les passages nécessaires.

Fidélité de la génération

La réponse reste conforme aux sources.

Traçabilité

L’utilisateur peut retrouver les documents ayant servi à la réponse.

Robustesse

Le système gère :

Sécurité

Le système ne divulgue pas une information à un utilisateur non autorisé.

Architecture générale

Une architecture RAG peut être représentée ainsi :

Sources documentaires
        ↓
Collecte et contrôle
        ↓
Extraction du contenu
        ↓
Découpage
        ↓
Métadonnées
        ↓
Indexation textuelle et vectorielle
        ↓
Question utilisateur
        ↓
Analyse et reformulation
        ↓
Recherche et filtrage
        ↓
Classement des résultats
        ↓
Construction du contexte
        ↓
LLM
        ↓
Réponse, citations et contrôle

Chaque étape peut produire des erreurs.

Il faut donc évaluer la chaîne complète, et pas uniquement la réponse finale.

Étape 1 — Définir le périmètre

Un RAG ne doit pas chercher à répondre à toutes les questions.

Définissez précisément :

Exemple de cadrage

Utilisateurs :
Techniciens du support.

Périmètre :
Diagnostic initial des routeurs X100, X200 et X300.

Sources :
Procédures validées, manuels produits et historique des incidents clôturés.

Résultats :
Proposition de procédure et justification.

Exclusions :
Réparations physiques, décisions commerciales et informations clients confidentielles.

Un périmètre clair facilite :

Étape 2 — Définir les questions de référence

Construisez une liste de questions réelles avant l’implémentation.

Exemples :

Que signifie le voyant rouge du routeur X200 ?
Quelle procédure utiliser si la connexion reste absente après un redémarrage ?
La procédure 3.1 est-elle encore valide ?
Dans quel cas faut-il transmettre l’incident au niveau 2 ?

Ajoutez plusieurs catégories.

Questions factuelles

La réponse se trouve directement dans un document.

Questions procédurales

La réponse nécessite plusieurs étapes.

Questions avec exception

Une règle générale possède une limite.

Questions temporelles

La validité dépend de la date ou de la version.

Questions ambiguës

Le produit ou le contexte n’est pas clairement identifié.

Questions sans réponse

Le corpus ne contient pas l’information.

Ces questions deviendront le premier jeu d’évaluation.

Étape 3 — Sélectionner les sources

N’indexez pas automatiquement tous les fichiers accessibles.

Chaque source doit être évaluée.

CritèreQuestion
AutoritéQui a produit le document ?
ValiditéEst-il encore applicable ?
VersionQuelle version est active ?
CouvertureQuelles questions peut-il traiter ?
ConfidentialitéQui peut y accéder ?
QualitéLe contenu est-il lisible et complet ?
MaintenanceQui le met à jour ?

Registre documentaire

Créez un registre central.

DocumentVersionStatutDate d’effetResponsable
Procédure X2004.2Validée2026-01-15Support réseau
Procédure X2003.1Obsolète2024-02-01Support réseau
Manuel X2002.0Actif2025-10-12Produit
Note technicien—À valider2026-06-20Équipe support

Un document non validé peut être conservé dans le système, mais il doit être clairement identifié.

Étape 4 — Définir une hiérarchie des sources

Lorsque plusieurs sources se contredisent, le système doit savoir laquelle privilégier.

Exemple :

1. Réglementation en vigueur
2. Procédure officielle validée
3. Manuel produit actuel
4. Documentation interne
5. Historique des incidents
6. Note ou commentaire non validé

Cette hiérarchie doit être définie avec les experts.

Le LLM ne doit pas décider seul de l’autorité des sources.

Étape 5 — Organiser les droits d’accès

Les droits doivent être appliqués avant la génération de la réponse.

Exemples de niveaux :

Public
Interne
Confidentiel
Réservé au support
Réservé aux responsables

Chaque document ou fragment peut contenir :

access_level: "support"
department: "reseau"
client_id: null
confidential: true

La recherche doit exclure les contenus non autorisés avant de transmettre le contexte au modèle.

Un prompt demandant au LLM de ne pas révéler une information n’est pas une protection suffisante.

Étape 6 — Extraire correctement le contenu

L’extraction doit préserver :

Un document mal extrait peut perdre une négation, une colonne ou une exception importante.

Exemple

Le tableau original indique :

SituationAction
Voyant rougeVérifier la synchronisation
Bruit métalliqueNe pas redémarrer

Une mauvaise extraction linéaire peut mélanger les deux lignes et produire une procédure dangereuse.

Les tableaux critiques doivent donc être contrôlés.

Étape 7 — Nettoyer sans détruire le sens

Le nettoyage peut supprimer :

Il ne doit pas supprimer :

Conservez toujours le document original.

Le contenu nettoyé doit pouvoir être relié à sa source.

Étape 8 — Concevoir les métadonnées

Les métadonnées sont souvent aussi importantes que les embeddings.

Exemple :

document_id: "PROC-X200-4.2"
title: "Procédure de diagnostic X200"
version: "4.2"
status: "validé"
product: "X200"
document_type: "procédure"
effective_date: "2026-01-15"
expiration_date: null
department: "support-réseau"
access_level: "support"
language: "fr"
source_url: "/documents/procedure-x200-4-2"

Les métadonnées permettent de filtrer :

Métadonnées au niveau du fragment

Chaque fragment doit conserver :

Exemple :

chunk_id: "PROC-X200-4.2-SEC-07"
section: "Diagnostic du voyant rouge"
heading_path:
  - "Diagnostic"
  - "Voyant rouge"
page: 12

Étape 9 — Choisir une stratégie de découpage

Le découpage influence directement la qualité de la recherche.

Découpage fixe

Le texte est divisé selon un nombre de caractères ou de tokens.

Avantages :

Limites :

Découpage structurel

Le texte est divisé selon :

Cette approche préserve davantage le sens.

Découpage sémantique

Les passages sont regroupés selon leur cohérence thématique.

Il peut être utile pour des documents longs et irréguliers.

Recommandation pratique

Commencez par un découpage structurel.

Chaque fragment doit idéalement contenir :

Exemple de mauvais découpage

Fragment A :

La procédure standard doit être appliquée à tous les incidents X200.

Fragment B :

Exception : ne pas appliquer cette procédure aux modèles fabriqués avant 2024.

Si seul le fragment A est retrouvé, la réponse devient incorrecte.

Les deux éléments doivent être regroupés ou reliés.

Étape 10 — Conserver le contexte hiérarchique

Un fragment isolé peut être ambigu.

Ajoutez le chemin des titres :

Produit X200
> Diagnostic
> Absence de connexion
> Après redémarrage

Le système comprend alors mieux le périmètre du passage.

Vous pouvez également ajouter au texte indexé :

Document : Procédure de diagnostic X200
Section : Absence de connexion après redémarrage

Étape 11 — Utiliser une recherche hybride

La recherche vectorielle ne suffit pas toujours.

Une recherche hybride combine :

Recherche vectorielle

Utile pour rapprocher :

perte de connexion

et :

absence de synchronisation réseau

Recherche lexicale

Utile pour retrouver précisément :

X200
PROC-458
Code erreur E17
Article 12.4

Filtres

Utiles pour exclure :

Étape 12 — Analyser la question

Avant la recherche, le système peut identifier :

Question :

Quelle procédure appliquer au X200 si le voyant reste rouge après le redémarrage ?

Analyse :

product: "X200"
symptom: "voyant rouge"
previous_action: "redémarrage"
intent: "procedure"

Cette analyse permet d’améliorer les filtres et la recherche.

Étape 13 — Reformuler avec prudence

Le système peut générer plusieurs requêtes.

Question initiale :

Pourquoi le X200 reste-t-il rouge ?

Requêtes possibles :

voyant rouge X200
absence de synchronisation X200
diagnostic voyant principal X200

La reformulation améliore le rappel.

Elle ne doit pas ajouter des faits absents de la question.

Étape 14 — Classer les résultats

Les premiers résultats retrouvés ne sont pas toujours les meilleurs.

Un classement secondaire peut prendre en compte :

Exemple de score conceptuel :

Pertinence sémantique
+
Correspondance produit
+
Statut validé
+
Version active
+
Autorité de la source

Étape 15 — Construire le contexte

Le contexte transmis au LLM doit être :

Évitez de transmettre dix fragments disant presque la même chose.

Regroupez plutôt :

  1. la règle principale ;
  2. l’exception ;
  3. la procédure ;
  4. la source de validation.

Format de contexte possible

SOURCE 1
Document : Procédure X200
Version : 4.2
Statut : Validé
Section : Voyant rouge
Contenu : ...

SOURCE 2
Document : Manuel X200
Version : 2.0
Section : Synchronisation
Contenu : ...

Cette structure facilite les citations.

Étape 16 — Concevoir le prompt de réponse

Le prompt doit définir le comportement du modèle.

Exemple :

Réponds uniquement à partir des sources fournies.

Distingue clairement :
- les faits confirmés ;
- les hypothèses ;
- les informations manquantes.

Cite chaque source utilisée avec son titre et sa version.

N’utilise pas une procédure obsolète lorsqu’une version active existe.

Lorsque les sources ne permettent pas de conclure, indique-le explicitement.

Ne transforme pas une recommandation en certitude.

Le prompt ne remplace pas les contrôles en amont.

Il complète la chaîne.

Étape 17 — Exiger des citations vérifiables

Une citation doit renvoyer à un élément identifiable :

Exemple :

La procédure recommande de vérifier la synchronisation avant toute réinitialisation complète.

Source : Procédure de diagnostic X200, version 4.2, section « Voyant rouge ».

Évitez les citations vagues comme :

Selon la documentation...

Étape 18 — Gérer les contradictions

Deux sources peuvent diverger.

Exemple :

Procédure 3.1 :
Redémarrer immédiatement.

Procédure 4.2 :
Vérifier la synchronisation avant le redémarrage.

Le système doit :

  1. identifier les versions ;
  2. appliquer la hiérarchie des sources ;
  3. présenter la contradiction si elle reste pertinente ;
  4. utiliser la source active ;
  5. conserver la trace de l’ancienne procédure.

Réponse attendue

La version actuellement active recommande de vérifier la synchronisation avant le redémarrage.

La procédure 3.1 indiquait un redémarrage immédiat, mais elle est marquée comme obsolète.

Source active : Procédure X200, version 4.2.

Étape 19 — Gérer l’absence de réponse

Un RAG fiable doit pouvoir répondre :

Je ne dispose pas d’une source suffisante pour répondre.

Il peut préciser :

Exemple :

Le modèle exact du routeur n’est pas indiqué. Les procédures diffèrent entre X100, X200 et X300. Précisez le modèle avant d’appliquer une procédure.

Étape 20 — Distinguer recherche et raisonnement métier

Le RAG retrouve des connaissances.

Il ne garantit pas l’application rigoureuse d’une règle.

Pour les décisions importantes, utilisez une architecture hybride.

Question
  ↓
LLM : extraction des faits
  ↓
Base de connaissances
  ↓
Moteur de règles
  ↓
Conclusion
  ↓
LLM : formulation de la réponse

Exemple de règle :

SI le produit est X200
ET si le voyant est rouge
ET si un bruit métallique est présent
ALORS ne pas redémarrer.

Le moteur de règles applique la décision.

Le LLM l’explique.

Étape 21 — Tester le système avant le déploiement

Le jeu d’évaluation doit contenir :

Exemples de tests

Test documentaire

Quelle est la procédure active pour le X200 ?

Test temporel

La procédure de 2024 est-elle encore valide ?

Test d’exception

Puis-je redémarrer si un bruit métallique est présent ?

Test de refus

Quelle procédure utiliser pour le produit Z900 ?

Le corpus ne couvre pas ce produit.

Test d’accès

Un utilisateur sans autorisation demande un document confidentiel.

Étape 22 — Journaliser les erreurs

Conservez :

Cette journalisation permet de distinguer :

Les données sensibles doivent être protégées ou anonymisées.

Étape 23 — Déployer progressivement

Déploiement recommandé :

Prototype interne
  ↓
Test par les experts
  ↓
Pilote avec quelques utilisateurs
  ↓
Analyse des erreurs
  ↓
Extension progressive

Évitez de déployer immédiatement à toute l’organisation.

Étape 24 — Maintenir le corpus

La maintenance doit traiter :

Cycle documentaire

Brouillon
  ↓
À valider
  ↓
Validé
  ↓
Actif
  ↓
À réviser
  ↓
Obsolète
  ↓
Archivé

L’index doit refléter ces statuts.

Architecture minimale recommandée

Pour un premier système fiable :

Documents validés
+
Métadonnées
+
Découpage structurel
+
Recherche hybride
+
Filtres d’accès
+
Citations
+
Jeu de tests
+
Journal des erreurs

Architecture avancée

Documents
+
Taxonomie
+
Index lexical
+
Index vectoriel
+
Graphe de connaissances
+
Moteur de règles
+
LLM
+
Évaluation automatisée
+
Gouvernance

Ajoutez le graphe ou les règles uniquement lorsque les cas d’usage le justifient.

Checklist de mise en production

Sources

Ingestion

Recherche

Génération

Exploitation

Erreurs fréquentes

Indexer tous les fichiers disponibles

La quantité de contenus ne garantit pas leur qualité.

Utiliser uniquement la recherche vectorielle

Les identifiants, versions et termes précis nécessitent souvent une recherche lexicale.

Négliger les métadonnées

Le système ne peut pas filtrer les mauvaises versions.

Couper une règle de son exception

La réponse devient dangereusement incomplète.

Demander au LLM de choisir la source officielle

L’autorité des sources doit être définie par la gouvernance.

Masquer les incertitudes

Le système doit signaler les informations manquantes ou contradictoires.

Tester uniquement les bonnes réponses

Les refus, ambiguïtés et erreurs sont tout aussi importants.

Confondre réponse fluide et réponse exacte

Une réponse bien écrite peut être fausse.

À retenir

  1. Un système RAG fiable commence par un périmètre précis.
  2. La qualité des sources détermine la qualité des réponses.
  3. Les métadonnées permettent de gérer les versions, statuts et droits.
  4. Le découpage doit préserver les règles et leurs exceptions.
  5. Une recherche hybride est souvent plus robuste qu’une recherche uniquement vectorielle.
  6. Le contexte transmis au LLM doit être cohérent et sourcé.
  7. Les citations doivent être vérifiables.
  8. Le système doit savoir ne pas répondre.
  9. Les règles critiques doivent être appliquées par un mécanisme contrôlé.
  10. Les tests doivent couvrir les erreurs et les ambiguïtés.
  11. La journalisation permet d’améliorer la chaîne.
  12. La maintenance documentaire fait partie du système RAG.

Continuer

Comprendre Knowledge Engineering, RAG et LLM

Comparer RAG et GraphRAG

Apprendre à évaluer un système RAG