Qualité d’un graphe de connaissances : comment contrôler les entités et les relations ?

Un graphe de connaissances peut contenir des millions de nœuds et rester peu fiable.

La qualité ne dépend pas uniquement du volume.

Elle dépend notamment de la capacité du graphe à représenter correctement :

les bonnes entités ;
les relations utiles ;
les identités ;
les dates ;
les sources ;
les niveaux de confiance ;
les règles du domaine.

Une seule fusion incorrecte peut créer de nombreuses fausses relations. Une relation ancienne peut présenter une situation passée comme actuelle. Une extraction automatique peut transformer une hypothèse en fait.

La qualité d’un graphe ne se mesure pas au nombre de connexions, mais à la fiabilité et à l’utilité de ces connexions.

Ce guide présente une méthode pour contrôler un graphe de connaissances avant et après son déploiement.

Les principales dimensions de qualité

La qualité d’un graphe peut être analysée selon plusieurs dimensions.

Exactitude

Les entités et relations correspondent-elles à la réalité représentée ?

Complétude

Le graphe contient-il les connaissances nécessaires aux questions prévues ?

Cohérence

Les données respectent-elles le modèle et les contraintes ?

Unicité

Une même entité est-elle représentée une seule fois ?

Fraîcheur

Les relations sont-elles encore valides ?

Provenance

Chaque fait important possède-t-il une source ?

Explicabilité

Le système peut-il montrer les chemins utilisés ?

Utilité

Le graphe permet-il réellement de traiter les cas d’usage ?

Accessibilité

Les droits sont-ils respectés au niveau des nœuds, relations et sources ?

Un graphe peut être exact mais incomplet

Exemple :

Marie → travaille pour → Entreprise Alpha

Cette relation peut être correcte.

Mais si le graphe ne contient pas :

Entreprise Alpha → participe à → Projet Orion

il ne pourra pas répondre à une question sur les collaborateurs du projet Orion.

L’exactitude et la complétude doivent donc être évaluées séparément.

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

La qualité ne peut pas être évaluée sans objectif.

Exemples :

quelles formations développent cette compétence ?
quelles personnes travaillent sur ce projet ?
quelles procédures concernent ce produit ?
quels contrats couvrent ce client ?
quelles sources justifient cette relation ?

Ces questions définissent :

les types de nœuds nécessaires ;
les relations ;
la profondeur des chemins ;
la couverture attendue.

Exemple

Question :

Quel parcours doit suivre Marie avant la certification SEO ?

Le graphe doit contenir :

Marie → possède → Compétence débutante

Formation intermédiaire → exige → Compétence débutante

Formation intermédiaire → développe → Compétence intermédiaire

Formation avancée → exige → Compétence intermédiaire

Certification SEO → exige → Compétence avancée

Si une seule relation manque, le parcours peut être interrompu.

Étape 2 — Définir un modèle de qualité

Créez une fiche pour chaque type de nœud.

Exemple : personne

node_type: "Personne"

required_properties:
  - id
  - nom

recommended_properties:
  - email
  - organisation

unique_properties:
  - id

forbidden_relations:
  - "EST_UN_PRODUIT"

Exemple : formation

node_type: "Formation"

required_properties:
  - id
  - titre
  - statut

required_relations:
  - type: "DEVELOPPE"
    minimum: 1
    target: "Competence"

Ce modèle permet de construire des contrôles automatiques.

Étape 3 — Contrôler les types de nœuds

Chaque nœud doit posséder un type cohérent.

Exemples :

Marie Dupont → Personne

Entreprise Alpha → Organisation

Toulouse → Ville

Formation SEO → Formation

Erreur de typage

Toulouse → Formateur

Cette erreur peut venir :

d’une extraction automatique ;
d’une relation mal définie ;
d’un domaine ontologique incorrect ;
d’un import défectueux.

Contrôles

type présent ;
type autorisé ;
type non contradictoire ;
propriétés compatibles avec le type ;
relations compatibles.

Étape 4 — Contrôler les propriétés obligatoires

Exemple :

Une formation doit posséder :

un identifiant ;
un titre ;
un statut ;
une source.

Requête conceptuelle :

Trouver toutes les formations sans statut.

Les résultats doivent être corrigés avant leur utilisation.

Propriétés mal formées

Exemples :

date : "demain"

prix : "beaucoup"

email : "Marie Dupont"

Les types de valeurs doivent être validés.

Étape 5 — Contrôler les relations

Chaque relation doit correspondre à une définition.

Exemple :

ANIME
Sujet : Formateur
Objet : Session

Relation correcte :

Paul → ANIME → Session SEO octobre

Relation incorrecte :

Formation SEO → ANIME → Paul

Dictionnaire des relations

Relation	Sujet	Objet	Sens
POSSEDE	Personne	Compétence	Compétence détenue
DEVELOPPE	Formation	Compétence	Compétence visée
ANIME	Formateur	Session	Animation
MET_EN_OEUVRE	Session	Formation	Programme réalisé
JUSTIFIE	Document	Règle	Source de la règle

Ce dictionnaire doit être utilisé par :

l’extraction ;
l’import ;
les contrôles ;
les requêtes ;
la documentation.

Étape 6 — Détecter les relations trop vagues

Relations problématiques :

EST_LIE_A
CONCERNE
A_UN_RAPPORT_AVEC

Elles peuvent parfois être nécessaires, mais elles apportent peu d’information.

Préférez :

TRAVAILLE_POUR
APPARTIENT_A
DEVELOPPE
EXIGE
REMPLACE
CITE

Indicateur

Mesurez la proportion de relations génériques.

Relations génériques
÷
Relations totales

Un taux élevé peut révéler un modèle insuffisamment précis.

Étape 7 — Détecter les doublons

Un même objet peut apparaître plusieurs fois.

Entreprise Alpha
Alpha SAS
Société Alpha

Ces trois nœuds peuvent représenter :

la même entreprise ;
des structures distinctes ;
une marque et une société ;
différentes périodes.

Signaux de doublon

même identifiant officiel ;
même adresse ;
même domaine internet ;
même email ;
propriétés très proches ;
relations identiques.

Faux doublon

Jean Martin

peut désigner plusieurs personnes.

Le nom seul n’est pas suffisant pour fusionner.

Score de correspondance

candidate_pair:
  entity_a: "ORG-001"
  entity_b: "ORG-458"

signals:
  same_website: true
  same_address: true
  same_identifier: true

decision:
  merge: true
  confidence: 0.99

Les fusions importantes doivent être réversibles.

Étape 8 — Contrôler les identifiants

Un identifiant doit être :

unique ;
stable ;
non dépendant du libellé ;
conservé lors d’un renommage.

Mauvais identifiant :

formation-seo-avancee

s’il change lorsque le titre est modifié.

Identifiant plus stable :

FORMATION-000458

Le libellé peut évoluer sans modifier l’identité.

Étape 9 — Contrôler la provenance

Une relation importante devrait posséder :

une source ;
une date ;
un passage ;
un statut ;
une méthode d’extraction ;
éventuellement un validateur.

Exemple

statement:
  subject: "Formation SEO avancée"
  predicate: "EXIGE"
  object: "Compétence SEO intermédiaire"

source:
  document_id: "REGLEMENT-2.1"
  section: "Prérequis"
  page: 12

extraction:
  method: "manuelle"

validation:
  status: "validé"
  validator: "responsable-pedagogique"

Indicateur de couverture

Relations avec source
÷
Relations totales

Pour les relations critiques, l’objectif peut être de 100 %.

Étape 10 — Contrôler la dimension temporelle

Une relation peut ne plus être vraie.

Exemple :

Marie → travaille pour → Entreprise Alpha

Propriétés nécessaires :

date_debut : 2022-01-01
date_fin : 2026-03-31

Sans date de fin, le graphe peut présenter cette relation comme actuelle.

Questions temporelles

quelle relation était valide à une date donnée ?
quelle version s’appliquait ?
qui occupait ce rôle en 2025 ?
quel contrat couvrait le produit lors de l’incident ?

Contrôles

date de début valide ;
date de fin postérieure ;
absence de chevauchement injustifié ;
statut cohérent avec les dates ;
historique conservé.

Étape 11 — Distinguer fait, hypothèse et proposition

Toutes les relations ne possèdent pas le même statut.

Voyant rouge → PEUT_INDIQUER → Perte de synchronisation

Cette relation ne doit pas être traitée comme :

Voyant rouge → PROUVE → Perte de synchronisation

Statuts possibles

Confirmé
Probable
Hypothèse
Contesté
Proposé automatiquement
Obsolète

Exemple

predicate: "PEUT_INDIQUER"
confidence: 0.72
status: "hypothèse-validée"

Le système de réponse doit préserver cette nuance.

Étape 12 — Détecter les contradictions

Exemple :

Entreprise Alpha → située à → Toulouse

Entreprise Alpha → située à → Bordeaux

Ce n’est pas forcément une contradiction.

L’entreprise peut :

avoir déménagé ;
posséder plusieurs établissements ;
avoir un siège et une agence ;
être confondue avec une autre entreprise.

Il faut examiner :

les dates ;
le type de relation ;
les sources ;
l’identité.

Contradiction réelle

Contrat 458 → statut → Actif

Contrat 458 → statut → Expiré

à la même date et dans le même contexte.

Processus

Détection
  ↓
Vérification des identités
  ↓
Vérification des dates
  ↓
Vérification des périmètres
  ↓
Comparaison des sources
  ↓
Correction ou coexistence documentée

Étape 13 — Contrôler les contraintes ontologiques

Une ontologie peut définir :

Personne et Organisation sont disjointes.

Une session met en œuvre exactement une formation.

Une formation développe au moins une compétence.

Les contrôles peuvent détecter :

une session sans formation ;
une session reliée à trois formations alors que le modèle l’interdit ;
une entité classée simultanément comme personne et organisation.

Monde ouvert et validation

Dans certaines ontologies, l’absence d’une relation ne signifie pas nécessairement qu’elle est fausse.

Pour valider que certaines données sont obligatoires, un mécanisme de validation spécifique peut être nécessaire.

Il faut distinguer :

raisonnement ontologique ;
validation de données ;
règles métier.

Étape 14 — Mesurer la complétude

La complétude absolue est rarement mesurable.

Il faut la définir par rapport aux questions.

Complétude par type

Proportion des formations possédant au moins une compétence.

Complétude par relation

Proportion des incidents reliés à un produit.

Complétude par cas d’usage

Proportion des questions de référence auxquelles le graphe permet de répondre.

Cette dernière mesure est souvent la plus utile.

Étape 15 — Mesurer la connectivité utile

Un graphe très connecté n’est pas nécessairement meilleur.

Un grand nombre de relations peut venir de liens vagues ou redondants.

Mesures possibles :

nombre moyen de relations par nœud ;
proportion de nœuds isolés ;
profondeur des chemins utiles ;
nombre de relations génériques ;
couverture des parcours attendus.

Nœuds isolés

Un nœud isolé peut être :

une donnée incomplète ;
une entité récemment ajoutée ;
un contenu sans relation ;
une erreur d’import.

Il faut vérifier s’il doit être relié ou supprimé.

Étape 16 — Tester les parcours

Un graphe est utilisé pour parcourir des relations.

Testez les chemins prioritaires.

Parcours pédagogique

Participant
  → POSSEDE
  → Compétence
  ← EXIGE
  ← Formation
  → DEVELOPPE
  → Compétence suivante

Parcours contractuel

Client
  → POSSEDE
  → Contrat
  → COUVRE
  → Produit
  → CONCERNE
  → Incident

Cas de test

question: "Quelle formation Marie peut-elle suivre ?"

expected_path:
  - "Marie"
  - "POSSEDE"
  - "SEO débutant"
  - "EXIGE_PAR"
  - "Formation SEO intermédiaire"

Le test doit contrôler le chemin, pas uniquement la réponse finale.

Étape 17 — Tester les requêtes négatives

Le graphe doit également éviter de produire certains résultats.

Exemple :

Marie possède le niveau débutant.

Elle ne doit pas être recommandée directement pour une formation exigeant le niveau avancé.

Test

Résultat interdit :
Formation expert.

Les tests négatifs détectent les connexions ou règles trop permissives.

Étape 18 — Évaluer l’extraction automatique

Si un LLM ou un système NLP construit le graphe, mesurez :

précision des entités ;
rappel des entités ;
précision des relations ;
rappel des relations ;
exactitude des types ;
conservation des négations ;
exactitude des sources.

Exemple

Passage :

La procédure ne s’applique pas aux modèles fabriqués avant 2024.

Extraction incorrecte :

Procédure → S_APPLIQUE_A → Modèles avant 2024

L’erreur inverse le sens.

Les négations doivent donc faire l’objet de tests spécifiques.

Étape 19 — Contrôler les fusions produites par un LLM

Un modèle peut rapprocher :

Alpha

et :

Alpha Technologies

sans preuve suffisante.

Toute fusion doit conserver :

les entités initiales ;
les critères ;
le score ;
la décision ;
le validateur ;
une possibilité de retour arrière.

Étape 20 — Contrôler les suppressions

Supprimer une entité peut supprimer indirectement de nombreuses relations.

Avant suppression, identifiez :

les relations entrantes ;
les relations sortantes ;
les documents associés ;
les réponses affectées ;
les règles dépendantes.

Une entité peut être marquée comme inactive plutôt que supprimée.

Étape 21 — Évaluer la fraîcheur

Indicateurs possibles :

âge moyen des relations ;
proportion de faits révisés ;
relations expirées encore actives ;
sources dont la prochaine révision est dépassée ;
entités sans date de mise à jour.

Exemple

Indicateur	Résultat
Relations révisées depuis moins d’un an	78 %
Relations expirées actives	34
Sources sans date	12 %
Entités sans responsable	7 %

Étape 22 — Évaluer l’utilité

Un graphe techniquement correct peut rester inutile.

Mesurez :

taux de questions résolues ;
temps économisé ;
chemins effectivement utilisés ;
taux de clic sur les sources ;
erreurs métier ;
satisfaction des utilisateurs.

Test d’ablation

Retirez temporairement le graphe et comparez les résultats avec :

une base SQL ;
un RAG ;
une recherche documentaire.

Si la qualité reste identique, le graphe peut être disproportionné.

Étape 23 — Construire un tableau de qualité

Dimension	Indicateur	Objectif
Exactitude	Relations validées	98 %
Provenance	Relations avec source	100 %
Unicité	Doublons confirmés	0
Fraîcheur	Relations expirées actives	0
Cohérence	Violations de contraintes	0
Complétude	Questions de référence couvertes	90 %
Explicabilité	Réponses avec chemin	95 %

Les seuils dépendent du niveau de risque.

Étape 24 — Organiser les contrôles automatiques

Contrôles quotidiens ou à chaque import :

identifiants dupliqués ;
types inconnus ;
propriétés obligatoires absentes ;
relations interdites ;
dates invalides ;
sources absentes ;
nœuds isolés ;
contradictions simples.

Contrôles périodiques

révision des connaissances ;
échantillon de relations ;
audit des fusions ;
analyse des parcours ;
comparaison avec les sources ;
revue des droits.

Étape 25 — Organiser la correction

Une erreur doit être traitée selon un processus.

Signalement
  ↓
Classification
  ↓
Analyse de l’impact
  ↓
Correction
  ↓
Validation
  ↓
Réexécution des tests
  ↓
Publication

Classification des erreurs

Erreur d’entité
Erreur de type
Erreur de relation
Erreur de source
Erreur temporelle
Erreur de fusion
Erreur d’extraction
Erreur de règle
Erreur d’accès

Checklist de qualité

Nœuds

[ ] les types sont définis ;
[ ] les identifiants sont uniques ;
[ ] les propriétés obligatoires sont présentes ;
[ ] les valeurs utilisent le bon format ;
[ ] les nœuds isolés sont examinés.

Relations

[ ] chaque relation possède une définition ;
[ ] le sujet et l’objet sont compatibles ;
[ ] les relations génériques sont limitées ;
[ ] les négations sont conservées ;
[ ] les niveaux de confiance sont représentés.

Identités

[ ] les doublons sont détectés ;
[ ] les homonymes ne sont pas fusionnés automatiquement ;
[ ] les critères de fusion sont enregistrés ;
[ ] les fusions sont réversibles.

Provenance et temps

[ ] les relations critiques possèdent une source ;
[ ] les dates de validité sont présentes ;
[ ] les anciennes relations sont clôturées ;
[ ] les contradictions sont contextualisées.

Cas d’usage

[ ] les chemins prioritaires sont testés ;
[ ] les résultats interdits sont testés ;
[ ] la couverture des questions est mesurée ;
[ ] la valeur du graphe est comparée à une solution plus simple.

Erreurs fréquentes

Mesurer uniquement le nombre de nœuds

Le volume ne garantit pas la qualité.

Considérer chaque relation extraite comme vraie

Une extraction automatique reste une proposition.

Fusionner selon le nom

Les homonymes créent de fausses connexions.

Oublier les dates

Le graphe mélange présent et passé.

Ne pas conserver les passages sources

Les relations deviennent impossibles à vérifier.

Utiliser trop de relations vagues

Le graphe paraît connecté sans apporter de sens.

Tester uniquement les nœuds

La valeur se trouve souvent dans les chemins.

Ne pas mesurer la couverture des questions

Le graphe peut être cohérent mais inutile.

À retenir

La qualité d’un graphe possède plusieurs dimensions.
L’exactitude et la complétude sont différentes.
Les types et propriétés doivent être contrôlés.
Les relations doivent être précises et documentées.
Les identifiants doivent rester stables.
La résolution d’entités constitue un risque majeur.
Les sources doivent être conservées au niveau des faits.
Les dates permettent de distinguer présent et passé.
Les hypothèses ne doivent pas être transformées en certitudes.
Les contraintes détectent les incohérences.
Les chemins doivent être testés sur des questions réelles.
Un graphe doit démontrer une valeur supérieure à une solution plus simple.

Continuer

Apprendre à créer un graphe de connaissances

Comparer une ontologie et un graphe

Mettre en place une gouvernance des connaissances