Knowledge graphs dans le RAG

Un knowledge graph dans le RAG utilise une ontologie de domaine et des relations validées comme couche de connaissance gouvernée, sans remplacer les documents primaires. Il constitue un contrat distinct avec des entrées, sorties et conditions d’échec mesurables. On définit d’abord les types de requêtes, les sources disponibles, les preuves attendues et la latence acceptable, puis seulement le modèle ou la bibliothèque.

Comme le graphe représente des relations explicites entre entités, le retrieval doit retourner non seulement du texte, mais aussi le type de relation et la preuve de son origine. Le générateur ne doit pas transformer un edge faible ou indirect en fait catégorique. C’est particulièrement important pour les dépendances, l’ownership, la compatibilité et les affirmations causales.

Un flux pratique est le suivant : l’entity linker associe la requête aux nœuds canoniques, le traversal trouve les chemins autorisés et le text retrieval ajoute des preuves citées aux affirmations trouvées. Le contrat doit contenir un request ID stable, les versions de configuration, une confidence ou une raison de fallback et assez de provenance pour reproduire le résultat. Un texte sans identifiants de source n’est pas un output de retrieval complet.

Un contrat robuste pour knowledge-graph RAG comprend canonical entity ID, relation type, source document, validFrom, validUntil et confidence. L’index textuel peut être reconstruit souvent, mais ces identités doivent rester reproductibles afin de tester séparément l’entity resolution, le relation retrieval et l’evidence bundle final.

Construisez un knowledge graph lorsqu’un schéma stable et ses relations ont une vraie valeur métier ; ne créez pas une ontologie complexe pour un corpus de pages de référence indépendantes. Conservez en parallèle le meilleur baseline simple, car la complexité supplémentaire ne se justifie que par un gain mesuré. Le router peut prendre en compte le type de requête, le risque, la quantité de preuves attendue et le latency budget.

Si une entité possède plusieurs relation paths incompatibles, le système ne doit pas choisir silencieusement le plus pratique. Il doit exposer le conflit, appliquer un filtre temporel ou une priorité de source et, si les preuves sont insuffisantes, répondre avec une limitation explicite. Les erreurs du graphe deviennent ainsi visibles avant de se transformer en hallucinations convaincantes.

Le principal risque est une mauvaise entity resolution qui fusionne des objets différents, tandis que l’absence de qualificatifs temporels fait passer une relation historique pour actuelle. Un system prompt plus long ne corrige pas cela : il faut des contraintes déterministes, des tests négatifs et une séparation des données non fiables des instructions de gouvernance. Tout fallback automatique doit être visible dans la trace sans élargir les droits ni les sources.

Les tests de release couvrent les entités dupliquées, collisions d’alias, orphan nodes, relations contradictoires et faits expirés. Après chaque défaut, un graph fixture minimal est conservé comme cas de régression. Le rollback doit restaurer ensemble la version d’ontologie, le snapshot du graphe et la policy de retrieval, pas seulement le code applicatif.

Les signaux principaux sont la précision de l’entity linking, l’exactitude du relation traversal, l’evidence coverage, le taux de non-réponse pour les entités inconnues et la qualité des réponses face à un baseline text-only. L’évaluation offline doit contenir des requêtes réelles et adversariales, des labels figés et une segmentation par domaine, langue et risque. Une moyenne ne doit pas masquer l’échec d’un segment critique ; celui-ci exige son propre guardrail threshold.

En production, conservez des IDs stables, un schema registry, des constraints, une review queue pour les nouvelles relations, des dates d’effet, des source pointers et une migration contrôlée de l’ontologie. Déployez d’abord une nouvelle configuration en shadow mode ou sur un petit canary, comparez-la au baseline et revenez automatiquement en arrière si le SLO est violé. Cela relie qualité, coût et fiabilité.

Un knowledge graph est utile pour les relations multi-hop, mais chaque node et edge doit porter source, validFrom, validUntil et confidence. Les relations extraites automatiquement ne deviennent pas des faits canoniques sans validation. Le pipeline résout d’abord les entités, puis les relation paths autorisés, et seulement ensuite collecte les preuves pour la génération. Un traversal trop large crée du bruit, de la latence et un risque de fuite entre tenants.

L’évaluation vérifie l’entity linking, la correction des chemins, la validité temporelle et le support de la réponse. Lorsque les sources se contredisent, le graphe conserve les deux versions et leur provenance au lieu d’écraser le fait. Les mises à jour doivent être idempotentes et propager les suppressions. La réponse finale expose la source chain pour permettre de vérifier le lien entre les affirmations.

• Ne créez pas d’edges sans provenance.
• Limitez la profondeur du traversal.
• Testez les conflits temporels.