RAG ou Knowledge Graph ?
Le guide de décision pour l'industrie réglementée

Ce guide s'adresse aux DSI, directeurs R&D, responsables IA et architectes qui doivent choisir une architecture pour un projet IA sur corpus documentaire en secteur réglementé. Il ne prétend pas que l'une est toujours meilleure que l'autre. Il donne les critères qui font la différence.

D'abord : de quoi parle-t-on ?

RAG (Retrieval-Augmented Generation) : un système qui recherche des passages pertinents dans un corpus de documents (via embeddings vectoriels), puis demande à un LLM de formuler une réponse en s'appuyant sur ces passages.

Knowledge Graph (graphe de connaissance) : un système qui modélise les entités d'un domaine (substances, composants, organismes, réglementations, décisions) et les relations entre elles sous forme de graphe. Les requêtes traversent ce graphe et retournent des faits tracés jusqu'à leur source.

Ce ne sont pas deux façons de faire la même chose. Ce sont deux philosophies différentes de ce que doit faire un système d'information.

Ce que le RAG fait bien

Le RAG est une architecture mature, rapide à déployer, puissante pour certains usages :

• Synthèse documentaire : "Résume les conclusions de ces 50 rapports sur ce sujet" → le RAG excelle
• Question ouverte sur corpus large : "Qu'est-ce que l'entreprise dit globalement sur X ?" → correct
• Reformulation et explication : "Explique ce paragraphe en langage simple" → très bon
• Veille et résumé : "Quoi de neuf dans les 20 dernières publications ?" → efficace
• Time-to-market : déploiement en quelques semaines sur un corpus existant

Ce que le RAG ne peut pas faire

Les limites du RAG ne sont pas des bugs. Ce sont des caractéristiques structurelles de l'architecture.

Traçabilité précise : impossible par construction

Un LLM fusionne l'information de plusieurs passages pour générer une réponse. Il ne peut pas garantir que chaque élément de la réponse provient d'un document source spécifique, d'une section précise, d'une version datée. Dans un contexte ALCOA+ (pharma), ceci suffit à disqualifier l'architecture : "Attributable" et "Original" ne sont pas satisfaits.

Précision sur termes similaires : non contrôlable

Des termes proches ("hépatotoxicité", "toxicité hépatique", "effets hépatiques") seront regroupés par similarité vectorielle. Ce regroupement est parfois juste, parfois non. Sur des nomenclatures réglementaires (MedDRA, REACH, ICD), cette approximation génère des erreurs difficiles à détecter.

Cohérence inter-sessions : non garantie

Posez la même question deux fois à un système RAG : vous pouvez obtenir des réponses différentes. Sur un corpus réglementaire où "est-ce que cette substance est autorisée ?" doit avoir une réponse identique quelle que soit la session, c'est incompatible.

Hallucination sur corpus spécialisé : sous-estimée

Sur des corpus techniques spécialisés, la proportion de réponses partiellement incorrectes est significativement plus élevée que sur des corpus généralistes — parce que le modèle complète ce qu'il ne trouve pas avec ce qui lui "semble cohérent" dans son apprentissage général.

Ce que le Knowledge Graph fait bien

• Requêtes multi-critères précises : "Toutes les substances X avec propriété Y, mise à jour depuis date Z, dans catégorie W" → secondes, sans risque d'erreur
• Traçabilité exacte : chaque fait est horodaté, attribué à un document source + section + version
• Cohérence garantie : la même requête retourne le même résultat
• Relations complexes : "Qui a décidé quoi, pourquoi, et avec quelles conditions, en 2017 ?" → le graphe traverse les relations
• Conformité réglementaire : ALCOA+, ITAR, exigences d'audit → satisfaits structurellement
• Interrogation transverse : croiser des données de sources hétérogènes (GED + CMMS + base réglementaire externe)

Ce que le Knowledge Graph ne fait pas

• Il ne génère pas de texte naturel — il produit des résultats structurés (un LLM peut reformuler en aval, sur résultat validé)
• Il ne se déploie pas en 2 semaines — modéliser un domaine réglementaire demande 2 à 4 mois pour un premier périmètre
• Il ne répond pas aux questions ouvertes — "dis-moi tout ce qui est intéressant sur ce sujet" → il répond à des requêtes structurées
• Il nécessite une modélisation métier — quelqu'un doit définir ce qu'est une "dérogation", une "condition de compensation"

Les cas où on combine les deux

Il n'y a pas de règle interdisant de combiner. Certaines architectures utilisent le graphe comme source de vérité pour les faits précis, et le LLM pour la mise en forme ou la synthèse des résultats. Le graphe répond "voici les 14 précédents correspondant à votre requête, avec leur source exacte". Le LLM reformule : "Voici une synthèse structurée de ces 14 précédents."

Ce qui ne fonctionne pas : donner au LLM la responsabilité de la réponse réglementaire, et l'appuyer sur le graphe comme simple source de contexte. L'architecture doit être claire sur qui est responsable de la réponse.

La grille de décision en 5 questions

Les questions à poser à vos fournisseurs

Si vous évaluez une architecture IA pour un corpus réglementaire, posez ces questions à vos fournisseurs :

• « Si je pose deux fois la même question, est-ce que j'obtiens deux fois la même réponse ? »
• « Pour chaque élément de la réponse, pouvez-vous me citer le document source, la section exacte et la date de validation ? »
• « Où est traitée l'inférence — dans le cloud d'un tiers ou en on-premise ? »
• « Comment votre système gère-t-il deux substances aux noms proches ? »

Les réponses révèlent l'architecture réelle derrière la démonstration.