Knowledge Engineering
Comprendre/structurer/exploiter les connaissances

Comment extraire les connaissances d’un corpus documentaire ?

Une organisation peut posséder des milliers de documents sans disposer d’une véritable base de connaissances.

Les informations existent, mais elles restent dispersées dans :

Extraire les connaissances d’un corpus consiste à transformer ces contenus en éléments plus structurés :

L’objectif n’est pas seulement d’extraire des mots. Il faut reconstruire ce que les documents affirment, dans quel contexte et avec quel niveau d’autorité.

Ce guide présente une méthode progressive combinant analyse humaine, traitement automatique et validation.

Ce que nous allons extraire

Prenons ce passage :

La procédure 4.2 s’applique aux routeurs X200 fabriqués depuis janvier 2024. En cas de voyant rouge et d’absence de connexion, le technicien doit vérifier la synchronisation avant tout redémarrage. Cette procédure ne doit pas être utilisée lorsqu’un bruit métallique est détecté.

Ce passage contient plusieurs connaissances.

Entités

Procédure 4.2
Routeur X200
Janvier 2024
Voyant rouge
Absence de connexion
Synchronisation
Redémarrage
Bruit métallique
Technicien

Relations

Procédure 4.2 → s’applique à → Routeur X200
Voyant rouge → associé à → Absence de connexion
Technicien → vérifie → Synchronisation

Condition temporelle

Routeur X200 → fabriqué depuis → Janvier 2024

Règle

SI voyant rouge
ET absence de connexion
ALORS vérifier la synchronisation avant le redémarrage.

Exception

SI bruit métallique
ALORS ne pas utiliser la procédure 4.2.

Provenance

Source :
Procédure 4.2.

Une extraction complète doit conserver tous ces niveaux.

Étape 1 — Définir le résultat attendu

Avant d’analyser les documents, précisez ce que vous souhaitez produire.

Le résultat peut être :

La méthode d’extraction dépend du résultat.

Exemple de besoin

Objectif :
Construire un assistant de diagnostic pour les routeurs X200.

Connaissances recherchées :
- produits ;
- symptômes ;
- causes ;
- tests ;
- procédures ;
- exceptions ;
- versions ;
- règles de sécurité.

Cette définition évite d’extraire des éléments sans utilité.

Étape 2 — Formuler les questions

Les questions guident l’extraction.

Exemples :

Les connaissances non nécessaires à ces questions peuvent être traitées plus tard.

Étape 3 — Inventorier le corpus

Créez un registre.

DocumentTypeVersionDateStatutAccès
Procédure X200Procédure4.22026ValidéeSupport
Manuel X200Manuel2.02025ActifInterne
Historique incidentsDonnées—2024–2026ActifRestreint
Notes d’expertsNotes—2026À validerProjet

Ce registre facilite :

Étape 4 — Définir l’autorité des sources

Toutes les sources ne possèdent pas la même valeur.

Exemple de priorité :

1. Réglementation
2. Procédure officielle validée
3. Manuel actuel
4. Base métier
5. Historique des cas
6. Note d’expert non validée

Une information issue d’une source secondaire peut être conservée, mais son statut doit être explicite.

Étape 5 — Préparer les documents

La préparation peut comprendre :

Conservez toujours :

Format intermédiaire

Le Markdown peut constituer un bon format de travail.

---
document_id: "PROC-X200-4.2"
title: "Procédure de diagnostic X200"
version: "4.2"
status: "validé"
date_effective: "2026-01-15"
---

# Diagnostic

## Voyant rouge

En cas de voyant rouge...

Cette structure préserve la hiérarchie.

Étape 6 — Découper selon la structure

Évitez de diviser les documents uniquement selon une taille fixe.

Utilisez :

Chaque unité doit rester interprétable.

Exemple

Document :
Procédure X200 4.2

Section :
Diagnostic du voyant rouge

Sous-section :
Cas avec absence de connexion

Le chemin hiérarchique doit accompagner le passage extrait.

Étape 7 — Définir un schéma de connaissances

Avant l’extraction automatique, définissez les types recherchés.

Types d’entités

Produit
Composant
Symptôme
Cause
Test
Procédure
Action
Personne
Organisation
Document
Date
Version

Types de relations

CONCERNE
PRESENTE
PEUT_INDIQUER
VERIFIE
TRAITE
REMPLACE
S_APPLIQUE_A
INTERDIT
JUSTIFIE

Types de règles

Condition → Action
Condition → Conclusion
Condition → Interdiction
Condition → Escalade

Ce schéma peut prendre la forme :

Étape 8 — Construire un glossaire initial

Relevez les termes importants.

TermeDéfinitionSynonymesSource
SynchronisationÉtablissement de la liaison réseauSynchroManuel X200
Incident critiqueBlocage sans solution de contournementP1Procédure support
RedémarrageRemise en service de l’équipementRebootDocumentation technique

Le glossaire aide à :

Étape 9 — Extraire les entités

L’extraction d’entités identifie les objets nommés ou les concepts du domaine.

Texte :

Le technicien Paul Martin a appliqué la procédure 4.2 au routeur X200 du client Alpha.

Extraction :

Paul Martin → Personne
Procédure 4.2 → Procédure
Routeur X200 → Produit
Client Alpha → Organisation

Entités nommées et concepts

Une entité nommée désigne souvent un objet particulier :

Paul Martin
Entreprise Alpha
Procédure 4.2

Un concept désigne une catégorie :

Technicien
Client
Procédure
Produit

Il faut conserver cette distinction.

Étape 10 — Extraire les relations

Après les entités, identifiez leurs liens.

Texte :

Paul Martin a appliqué la procédure 4.2 au routeur X200 du client Alpha.

Relations :

Paul Martin → APPLIQUE → Procédure 4.2
Procédure 4.2 → S_APPLIQUE_A → Routeur X200
Routeur X200 → APPARTIENT_A → Client Alpha

Chaque relation doit conserver :

Étape 11 — Extraire les propriétés

Les propriétés décrivent une entité.

Texte :

La procédure 4.2, publiée le 15 janvier 2026, remplace la version 3.1.

Extraction :

Procédure 4.2
- date_publication : 2026-01-15
- statut : active

Relation :

Procédure 4.2 → REMPLACE → Procédure 3.1

Étape 12 — Extraire les règles

Les règles apparaissent souvent sous des formes linguistiques variées.

Forme explicite

Si le voyant est rouge, vérifier la synchronisation.

Forme impérative

Vérifiez la synchronisation lorsque le voyant devient rouge.

Forme normative

La synchronisation doit être vérifiée en présence d’un voyant rouge.

Forme négative

Ne redémarrez pas l’équipement lorsqu’un bruit métallique est détecté.

Ces formulations peuvent être normalisées.

Représentation structurée

rule_id: "REGLE-X200-017"

conditions:
  - symptom: "voyant rouge"
  - state: "connexion absente"

action:
  type: "verification"
  target: "synchronisation"

priority: "haute"

source:
  document_id: "PROC-X200-4.2"
  section: "Diagnostic du voyant rouge"

Étape 13 — Extraire les exceptions

Les exceptions sont souvent introduites par :

Texte :

La procédure s’applique à tous les modèles X200, sauf aux unités fabriquées avant janvier 2024.

Règle générale :

Procédure 4.2 → s’applique à → X200

Exception :

SI date de fabrication < janvier 2024
ALORS procédure 4.2 non applicable.

La règle et l’exception doivent rester reliées.

Étape 14 — Détecter la négation

Comparez :

Le routeur est compatible avec le module M10.

et :

Le routeur n’est pas compatible avec le module M10.

Une extraction qui ignore la négation produit une connaissance opposée au texte.

Repérez notamment :

Étape 15 — Détecter la modalité

Toutes les phrases n’expriment pas une certitude.

Comparez :

Le voyant rouge indique une perte de synchronisation.
Le voyant rouge peut indiquer une perte de synchronisation.
Le voyant rouge semble indiquer une perte de synchronisation.

Représentez le niveau d’affirmation.

relation: "PEUT_INDIQUER"
confidence: 0.65
status: "hypothèse"

Évitez de transformer une possibilité en fait certain.

Étape 16 — Extraire la dimension temporelle

Une connaissance peut être vraie uniquement pendant une période.

Texte :

Marie Dupont a dirigé le projet Orion de janvier 2023 à mars 2026.

Extraction :

Marie Dupont → DIRIGE → Projet Orion
date_debut : 2023-01
date_fin : 2026-03

Sans dates, le système pourrait présenter Marie comme responsable actuelle.

Étape 17 — Distinguer publication et application

Un document peut être :

Exemple :

publication_date: "2025-12-15"
effective_date: "2026-01-01"
expiration_date: null

La date de publication ne suffit pas pour déterminer la validité.

Étape 18 — Conserver la provenance

Chaque connaissance doit être reliée à son origine.

Exemple :

statement_id: "STMT-00458"

subject: "Procédure 4.2"
predicate: "S_APPLIQUE_A"
object: "Routeur X200"

source:
  document_id: "PROC-X200-4.2"
  page: 12
  section: "Périmètre"
  excerpt_id: "CHUNK-017"

extraction:
  method: "automatique"
  model_version: "extractor-2"
  confidence: 0.93

validation:
  status: "validé"
  reviewer: "expert-support"
  date: "2026-07-12"

La provenance permet :

Étape 19 — Résoudre les entités

Le corpus peut contenir :

Entreprise Alpha
Alpha SAS
Société Alpha
Alpha

Il faut déterminer si ces mentions désignent la même organisation.

Critères

Résultat possible

canonical_entity: "ORG-ALPHA-001"
preferred_label: "Entreprise Alpha"
aliases:
  - "Alpha SAS"
  - "Société Alpha"

Les cas ambigus doivent rester non résolus.

Étape 20 — Normaliser les relations

Plusieurs formulations peuvent désigner une même relation.

travaille pour
est employé par
fait partie de
appartient à l’équipe de

Selon le domaine, elles peuvent être regroupées sous :

TRAVAILLE_POUR

Mais ne fusionnez pas automatiquement des relations différentes.

travaille pour

n’est pas nécessairement équivalent à :

preste pour

ou :

partenaire de

Étape 21 — Utiliser un LLM pour assister l’extraction

Un LLM peut proposer :

Exemple de consigne structurée

À partir du passage fourni :

1. identifie les entités ;
2. attribue un type parmi la liste autorisée ;
3. extrait les relations explicites ;
4. conserve les négations ;
5. distingue faits, hypothèses et obligations ;
6. indique la phrase source ;
7. n’invente aucune relation implicite ;
8. retourne un résultat JSON conforme au schéma.

Sortie attendue

{
  "entities": [
    {
      "label": "Procédure 4.2",
      "type": "Procedure"
    },
    {
      "label": "Routeur X200",
      "type": "Produit"
    }
  ],
  "relations": [
    {
      "subject": "Procédure 4.2",
      "predicate": "S_APPLIQUE_A",
      "object": "Routeur X200",
      "status": "explicite"
    }
  ]
}

Une sortie structurée facilite la validation.

Étape 22 — Limiter les types autorisés

Une liste ouverte produit rapidement des relations incohérentes.

Préférez un schéma contrôlé.

Types autorisés :
- Produit
- Symptôme
- Cause
- Test
- Procédure
- Document

Relations autorisées :
- CONCERNE
- PRESENTE
- PEUT_INDIQUER
- VERIFIE
- TRAITE
- JUSTIFIE

Les éléments inconnus peuvent être placés dans :

À examiner

plutôt que transformés immédiatement en nouvelle classe.

Étape 23 — Valider automatiquement

Les contrôles automatiques peuvent vérifier :

Exemple :

ANIME
Sujet autorisé : Formateur
Objet autorisé : Session

La relation suivante est invalide :

Toulouse → ANIME → Marie

Étape 24 — Valider humainement

Les experts doivent examiner en priorité :

Une validation exhaustive peut être impossible.

Utilisez alors un échantillonnage fondé sur le risque.

Priorité élevée

Priorité moyenne

Étape 25 — Gérer les contradictions

Deux documents peuvent affirmer :

La procédure 4.2 s’applique aux modèles fabriqués depuis 2024.

et :

La procédure 4.2 s’applique à tous les modèles X200.

Ne supprimez pas automatiquement l’une des affirmations.

Conservez :

La contradiction peut révéler :

Étape 26 — Produire plusieurs sorties

Le même corpus peut alimenter plusieurs structures.

Glossaire

Concepts et définitions

Taxonomie

Produit
├── Routeur
│   ├── X100
│   ├── X200
│   └── X300

Graphe

Procédure 4.2 → S_APPLIQUE_A → X200

Base de règles

SI voyant rouge
ALORS vérifier la synchronisation.

Index RAG

Fragments documentaires sourcés.

Ces sorties sont complémentaires.

Étape 27 — Tester l’extraction

Construisez un jeu de passages annotés.

Pour chaque passage, définissez :

Exemple

Passage :

Ne redémarrez pas le routeur X200 lorsqu’un bruit métallique est détecté.

Attendu :

entities:
  - Routeur X200
  - Bruit métallique
  - Redémarrage

rule:
  condition: "bruit métallique détecté"
  action: "ne pas redémarrer"
  polarity: "interdiction"

Indicateurs

Précision des entités

Parmi les entités extraites, combien sont correctes ?

Rappel des entités

Parmi les entités attendues, combien ont été retrouvées ?

Précision des relations

Les relations extraites sont-elles exactes ?

Rappel des relations

Les relations nécessaires ont-elles été retrouvées ?

Exactitude de la provenance

La bonne phrase source est-elle conservée ?

Exactitude des négations

Les interdictions et absences sont-elles correctement représentées ?

Étape 28 — Organiser une boucle de correction

Extraction
  ↓
Validation
  ↓
Erreur identifiée
  ↓
Correction du schéma ou de la consigne
  ↓
Nouvelle extraction
  ↓
Test de régression

Les erreurs corrigées doivent devenir des tests permanents.

Exemple de pipeline complet

Documents
  ↓
Inventaire et métadonnées
  ↓
Extraction structurée
  ↓
Découpage
  ↓
Détection des entités
  ↓
Extraction des relations
  ↓
Extraction des règles
  ↓
Détection des exceptions
  ↓
Résolution d’entités
  ↓
Validation automatique
  ↓
Validation humaine
  ↓
Glossaire, graphe, règles et index RAG

Exemple final

Texte :

Depuis le 1er janvier 2026, la formation SEO avancée exige un niveau intermédiaire. Les participants disposant d’une expérience professionnelle équivalente peuvent être admis après validation du responsable pédagogique.

Entités

Formation SEO avancée
Niveau intermédiaire
Participant
Expérience professionnelle
Responsable pédagogique
1er janvier 2026

Règle générale

SI participant possède le niveau intermédiaire
ALORS participant éligible à la formation avancée.

Exception

SI participant possède une expérience équivalente
ET si le responsable pédagogique valide
ALORS participant éligible.

Date d’application

2026-01-01

Provenance

Document :
Règlement pédagogique.

Section :
Admission aux formations avancées.

Cette extraction peut alimenter :

Checklist d’extraction

Cadrage

Préparation

Modélisation

Extraction

Validation

Erreurs fréquentes

Extraire des mots sans définir l’usage

Le résultat devient une liste difficile à exploiter.

Ignorer la structure du document

Les titres, tableaux et exceptions sont perdus.

Transformer chaque phrase en fait certain

Les hypothèses et possibilités deviennent des affirmations.

Ignorer les négations

Le sens de la connaissance est inversé.

Ne pas conserver les sources

La connaissance ne peut plus être vérifiée.

Fusionner les entités selon le nom uniquement

Les homonymes sont confondus.

Laisser le modèle créer librement les relations

Le vocabulaire devient incohérent.

Ne pas distinguer règle et exemple

Un cas particulier peut être transformé en règle générale.

Ne pas organiser la validation

Les erreurs automatiques se propagent dans le graphe ou le RAG.

À retenir

  1. L’extraction commence par les questions auxquelles le système devra répondre.
  2. Le corpus doit être inventorié et versionné.
  3. La structure des documents doit être préservée.
  4. Un schéma définit les entités et relations recherchées.
  5. Les règles doivent être distinguées des faits.
  6. Les exceptions doivent rester reliées aux règles générales.
  7. Les négations et modalités sont essentielles.
  8. Les dates déterminent souvent la validité.
  9. Chaque connaissance doit conserver sa provenance.
  10. La résolution d’entités doit rester prudente.
  11. Les LLM peuvent accélérer l’extraction, mais pas la valider seuls.
  12. Les connaissances extraites peuvent alimenter un glossaire, un graphe, des règles et un RAG.

Continuer

Découvrir les méthodes d’acquisition des connaissances

Apprendre à créer un graphe de connaissances

Construire une base de connaissances