Knowledge Engineering, RAG et LLM : pourquoi structurer les connaissances à l’ère de l’IA générative ?

Les grands modèles de langage, ou LLM, peuvent résumer des documents, répondre à des questions, produire des textes et manipuler des concepts exprimés en langage naturel.

Ils donnent parfois l’impression qu’il suffit de leur fournir des documents pour construire un système de connaissances.

Cette impression est trompeuse.

Un LLM peut produire une réponse convaincante sans garantir :

Le Knowledge Engineering complète les LLM en organisant les connaissances qu’ils doivent utiliser.

Il apporte notamment :

Le LLM produit et interprète du langage. Le Knowledge Engineering organise les connaissances sur lesquelles ce langage doit s’appuyer.

Ce que vous allez comprendre

À la fin de cet article, vous saurez :

Qu’est-ce qu’un LLM ?

Un Large Language Model est un modèle entraîné sur de grandes quantités de textes afin d’apprendre les régularités du langage.

Il peut notamment :

Un LLM ne fonctionne pas comme une base de données classique.

Il ne stocke pas chaque connaissance sous la forme d’une fiche directement consultable.

Il apprend des paramètres numériques lui permettant de produire les mots les plus plausibles dans un contexte donné.

Connaissance paramétrique et connaissance externe

On peut distinguer deux formes de connaissances utilisées par un système fondé sur un LLM.

La connaissance paramétrique

La connaissance paramétrique correspond à ce que le modèle a appris pendant son entraînement.

Elle est intégrée dans ses paramètres.

Cette connaissance présente plusieurs limites :

La connaissance externe

La connaissance externe se trouve en dehors du modèle.

Elle peut être stockée dans :

Le modèle peut consulter ces sources au moment de répondre.

Cette séparation facilite :

Pourquoi un LLM peut-il produire une réponse fausse ?

Un modèle de langage cherche à produire une suite de mots cohérente.

Il ne vérifie pas automatiquement chaque affirmation dans une source fiable.

Il peut notamment :

Ce phénomène est souvent appelé hallucination.

Le mot ne signifie pas que le système possède une perception humaine. Il désigne une production non fondée ou incorrecte présentée avec assurance.

Qu’est-ce que le RAG ?

Le Retrieval-Augmented Generation, ou génération augmentée par la recherche, associe un LLM à une source externe.

Le processus général est le suivant :

Question de l’utilisateur
          ↓
Recherche dans les documents
          ↓
Sélection des passages pertinents
          ↓
Transmission du contexte au LLM
          ↓
Génération de la réponse

Le RAG permet au modèle d’utiliser des connaissances qui ne se trouvent pas directement dans ses paramètres.

Exemple simple

Un utilisateur demande :

Quelle est la procédure de remplacement du composant X200 ?

Le système recherche dans la documentation.

Il retrouve :

Procédure X200, version 4.2

Il transmet les passages concernés au LLM.

Le modèle formule ensuite une réponse structurée à partir de ces passages.

Les composants d’un système RAG

Les sources

Les sources peuvent être :

L’ingestion

L’ingestion transforme les sources en contenus exploitables.

Elle peut comprendre :

Le découpage

Les documents sont souvent divisés en fragments.

Exemple :

Document
├── Fragment 1
├── Fragment 2
├── Fragment 3
└── Fragment 4

Le découpage doit préserver suffisamment de contexte.

Un fragment trop court perd le sens.

Un fragment trop long introduit du bruit.

Les embeddings

Chaque fragment peut être transformé en vecteur numérique.

Des fragments proches sémantiquement obtiennent des représentations proches.

Cela permet de retrouver un passage même si la question n’utilise pas exactement les mêmes mots.

L’index

Les vecteurs et métadonnées sont stockés dans un index.

Le système peut ensuite rechercher les fragments les plus proches d’une question.

Le retriever

Le retriever sélectionne les contenus à transmettre au modèle.

Il peut utiliser :

Le prompt

Le prompt indique au modèle :

La génération

Le modèle produit une réponse à partir du contexte fourni.

Les citations

Un système fiable doit relier la réponse aux sources utilisées.

Il doit pouvoir indiquer :

Ce que le RAG améliore

Le RAG peut améliorer :

Il ne garantit cependant pas automatiquement une réponse correcte.

Les limites d’un RAG documentaire

Mauvais document retrouvé

Le système peut sélectionner un passage proche lexicalement mais inadapté.

Contexte insuffisant

La réponse peut dépendre d’informations réparties dans plusieurs documents.

Découpage incorrect

Une règle et son exception peuvent être séparées dans deux fragments.

Version obsolète

Le système peut retrouver une ancienne procédure.

Ambiguïté

Un même terme peut désigner plusieurs concepts.

Absence de relations explicites

Le système retrouve des passages, mais ne représente pas nécessairement les relations entre les entités.

Application incorrecte d’une règle

Le LLM peut reformuler une règle sans l’appliquer de manière stable.

Sources contradictoires

Deux documents peuvent fournir des informations incompatibles.

Le système doit savoir :

Le rôle du Knowledge Engineering dans un RAG

Le Knowledge Engineering intervient à plusieurs niveaux.

Définir le vocabulaire

Il permet de distinguer :

Exemple :

client
compte client
acheteur
bénéficiaire

Ces termes ne sont pas toujours équivalents.

Construire une taxonomie

Une taxonomie peut organiser les documents selon :

Elle améliore le filtrage.

Définir une ontologie

Une ontologie informatique peut préciser :

Une formation développe une compétence.
Une procédure s’applique à un produit.
Un contrat concerne un client.
Une règle possède un champ d’application.

Ajouter un graphe de connaissances

Le graphe de connaissances relie les entités.

Procédure 4.2 → s’applique à → Routeur X200
Routeur X200 → appartient à → Gamme Réseau
Incident 458 → concerne → Routeur X200

Formaliser les règles

Un moteur symbolique peut vérifier :

SI le contrat est expiré
ALORS la garantie standard ne s’applique pas.

Le LLM n’a pas à improviser la règle.

Gérer les exceptions

Exemple :

La procédure standard s’applique à la gamme X200.

Exception :

Elle ne s’applique pas aux modèles fabriqués avant 2024.

Conserver la provenance

Chaque connaissance doit pouvoir être reliée à :

Architecture documentaire simple

Question
  ↓
Recherche vectorielle
  ↓
Fragments documentaires
  ↓
LLM
  ↓
Réponse

Cette architecture convient lorsque :

Architecture enrichie par les connaissances

Question
  ↓
Analyse des concepts
  ↓
Taxonomie et filtres
  ↓
Recherche documentaire
  ↓
Graphe ou base de connaissances
  ↓
Règles et contraintes
  ↓
LLM
  ↓
Réponse avec justification

Cette architecture devient utile lorsque :

Exemple : assistant de formation

Question :

Marie peut-elle suivre la formation SEO avancée ?

Base de connaissances

Marie possède le niveau débutant.
Formation SEO avancée exige le niveau intermédiaire.
Formation SEO intermédiaire développe le niveau intermédiaire.

Règle

SI un participant ne possède pas le niveau requis
ALORS recommander la formation préparatoire.

Réponse

Le système peut produire :

Marie ne peut pas encore suivre directement la formation SEO avancée. Le niveau intermédiaire est requis. La formation SEO intermédiaire constitue l’étape préparatoire adaptée.

Le LLM formule la réponse.

La base de connaissances fournit les faits.

Le moteur de règles produit la conclusion.

Exemple : assistant juridique

Question :

Cette clause est-elle applicable au contrat Alpha ?

Le système doit vérifier :

Un RAG uniquement vectoriel pourrait retrouver une clause similaire.

Le Knowledge Engineering permet de représenter le contexte nécessaire à son application.

Le rôle des métadonnées

Les métadonnées permettent de filtrer les sources.

Exemples :

type_document : procédure
produit : X200
version : 4.2
date_validité : 2026-07-12
statut : validé
public : techniciens

Une recherche peut alors exclure :

Le rôle des questions de compétence

Les questions de compétence définissent ce que le système doit savoir traiter.

Exemples :

Elles permettent de tester le système de manière concrète.

Évaluer un système RAG

L’évaluation doit distinguer plusieurs étapes.

Qualité de la recherche

Les bons documents ont-ils été retrouvés ?

Qualité du contexte

Les fragments contiennent-ils toutes les informations nécessaires ?

Fidélité

La réponse est-elle réellement fondée sur les sources ?

Exactitude

La conclusion est-elle correcte ?

Couverture

Le système répond-il aux principales questions ?

Citation

Les sources sont-elles correctement identifiées ?

Refus

Le système sait-il signaler qu’il ne dispose pas d’une information suffisante ?

Respect des règles

Les contraintes métier sont-elles appliquées ?

Exemples de tests

Cas normal

La réponse se trouve clairement dans un document valide.

Cas ambigu

Plusieurs concepts portent le même nom.

Cas contradictoire

Deux sources affirment des choses différentes.

Cas obsolète

Une ancienne procédure existe encore dans la base.

Cas hors périmètre

La question ne concerne pas le domaine couvert.

Cas insuffisant

Les sources ne permettent pas de répondre.

Gouvernance

Un système RAG doit posséder une gouvernance.

Il faut définir :

Sécurité et droits d’accès

Le système ne doit pas fournir toutes les connaissances à tous les utilisateurs.

Il doit pouvoir filtrer selon :

Une bonne recherche sur une source interdite reste une fuite d’information.

LLM et extraction de connaissances

Un LLM peut aider à construire la base.

Il peut proposer :

Exemple :

Texte :

Marie Dupont anime la session SEO avancée organisée à Toulouse par Entreprise Alpha.

Extraction proposée :

Marie Dupont → anime → Session SEO avancée
Session SEO avancée → organisée par → Entreprise Alpha
Session SEO avancée → située à → Toulouse

Ces propositions doivent être validées.

Pourquoi la validation humaine reste nécessaire

Le LLM peut :

Le modèle accélère l’extraction.

Il ne garantit pas la qualité de la connaissance.

RAG, GraphRAG et systèmes hybrides

ArchitectureForce principale
RAG documentaireRetrouver des passages
RAG avec métadonnéesFiltrer les bonnes sources
RAG avec ontologieComprendre les concepts
RAG avec règlesAppliquer des contraintes
GraphRAGRelier plusieurs entités et documents
Architecture hybrideCombiner recherche, graphe, règles et génération

Quand un RAG simple suffit-il ?

Un RAG simple peut suffire lorsque :

Quand faut-il davantage de Knowledge Engineering ?

Une structuration plus forte devient nécessaire lorsque :

Erreurs fréquentes

Indexer tous les documents sans tri

Les brouillons et versions obsolètes contaminent les réponses.

Négliger les métadonnées

Le système ne peut pas filtrer correctement.

Croire que le RAG supprime toutes les hallucinations

Le modèle peut encore mal interpréter les sources.

Confondre document pertinent et réponse correcte

Le bon document peut être retrouvé mais mal utilisé.

Ne pas formaliser les exceptions

Le système applique une règle générale à tous les cas.

Ne pas tester les refus

Le système doit savoir dire qu’il ne sait pas.

Utiliser le LLM comme seul arbitre

Le modèle ne remplace pas un moteur de règles ou une validation experte.

Ne pas gérer les droits

Une information pertinente peut être confidentielle.

À retenir

  1. Un LLM produit du langage à partir de régularités apprises.
  2. Sa connaissance paramétrique n’est pas facilement vérifiable ni actualisable.
  3. Le RAG relie le modèle à des sources externes.
  4. Un RAG documentaire retrouve principalement des fragments de textes.
  5. Le Knowledge Engineering structure les concepts, relations, règles et sources.
  6. Une taxonomie améliore l’organisation et le filtrage.
  7. Une ontologie réduit les ambiguïtés.
  8. Un graphe relie les entités présentes dans plusieurs sources.
  9. Un moteur de règles garantit une application plus stable des contraintes.
  10. Les métadonnées, versions et droits d’accès sont essentiels.
  11. Les LLM peuvent aider à extraire les connaissances, mais les résultats doivent être validés.
  12. La qualité d’un RAG dépend d’abord de la qualité de sa base de connaissances.

Vérifiez votre compréhension

Qu’est-ce qu’une connaissance paramétrique ?

Une connaissance intégrée dans les paramètres du modèle pendant son entraînement.

Qu’est-ce que le RAG ?

Une architecture qui recherche des sources externes avant de demander au LLM de produire une réponse.

Pourquoi le RAG ne garantit-il pas une réponse exacte ?

Parce que le système peut retrouver un mauvais passage, manquer une exception ou mal interpréter le contenu.

Quel rôle joue une ontologie ?

Elle définit les concepts, leurs relations et leurs contraintes.

Quel rôle joue un moteur de règles ?

Il applique des règles explicites de manière plus stable qu’un LLM seul.

Pourquoi conserver les métadonnées ?

Pour filtrer les sources selon leur date, version, type, statut ou niveau d’accès.

Questions fréquentes

Un RAG empêche-t-il les hallucinations ?

Il peut les réduire, mais ne les élimine pas.

Faut-il une ontologie pour construire un RAG ?

Non. Elle devient utile lorsque le vocabulaire, les relations ou les règles sont complexes.

Un LLM peut-il interroger une base de données ?

Oui, directement ou en générant une requête structurée, sous réserve de contrôles.

Quelle différence existe-t-il entre RAG et entraînement spécialisé ?

Le RAG ajoute des sources au moment de la réponse. L’entraînement spécialisé modifie le comportement ou les paramètres du modèle.

Un RAG peut-il utiliser des documents privés ?

Oui, à condition de gérer correctement les droits d’accès et la sécurité.

Le Knowledge Engineering ralentit-il le projet ?

Il ajoute une phase de structuration, mais réduit les ambiguïtés, erreurs et coûts de maintenance ultérieurs.

Continuer le parcours

Étape précédente

Raisonnement symbolique : principes et inférences

Étape suivante

La prochaine étape consiste à comprendre comment un graphe peut compléter la recherche documentaire et relier les connaissances dispersées.

➡️ GraphRAG : fonctionnement, architecture et cas d’usage

Revenir au sommaire

Voir le parcours complet de Knowledge Engineering