Context Engineering — Section 8 : Knowledge Graphs
Connecter les faits : l'épine dorsale de la connaissance pour un raisonnement fiable.
8. Knowledge Graphs : La Connaissance Structurée
- A. Panorama
- B. Concepts Clés
- C. KG-RAG vs Vector RAG
- D. Construction du Graphe
- E. Interrogation (Querying)
- F. Raisonnement
- G. Technologies
- H. Pitfalls
- I. Snippets
- J. Playbook
Panorama : Au-delà du Texte Non Structuré
Un LLM apprend des motifs dans le texte, mais ne "comprend" pas les faits sous-jacents. Un Knowledge Graph (KG) structure l'information comme un réseau d'entités et de relations, agissant comme une **base de connaissances externe, factuelle et vérifiable**. L'approche **neuro-symbolique** combine la fluidité du LLM (neuro) avec la rigueur du KG (symbolique).
- Explicabilité (Explainability) : On peut montrer le chemin de raisonnement (les triplets) utilisé pour arriver à une réponse.
- Raisonnement Multi-Sauts : Permet de répondre à des questions complexes qui nécessitent de connecter plusieurs informations.
Les Concepts Clés d'un Knowledge Graph
Un KG est conceptuellement simple, basé sur une structure de triplets.
| Composant | Définition | Exemple |
|---|---|---|
| Entité (Noeud) | Un objet, une personne, un concept unique. Le "nom" de notre graphe. | `Paris`, `Marie Curie`, `Projet Apollo` |
| Relation (Arc) | Le lien sémantique entre deux entités. Le "verbe". | `IS_LOCATED_IN`, `WON_AWARD`, `HAS_TEAM_MEMBER` |
| Triplet (S-P-O) | L'unité atomique d'un KG : Sujet-Prédicat-Objet. | `(Marie Curie, WON_AWARD, Nobel Prize in Physics)` |
| Attribut (Literal) | Une propriété d'une entité qui n'est pas une autre entité (donnée brute). | Marie Curie a un `birth_date` de `1867-11-07`. |
KG-RAG vs. Vector RAG
Ce ne sont pas des approches concurrentes mais complémentaires. Le RAG sur KG excelle là où le RAG vectoriel sur texte brut échoue.
| Caractéristique | Vector RAG (Texte) | KG-RAG (Graphe) |
|---|---|---|
| Principe | Recherche de similarité sémantique sur des chunks de texte. | Traversée de chemins structurés entre entités. |
| Question Type | "Quels documents parlent de la politique de sécurité ?" (Recherche d'information) | "Quels employés ont accès au projet qui utilise la base de données vulnérable ?" (Raisonnement multi-sauts) |
| Avantages | Simple à mettre en place, bon pour les questions ouvertes. | Précis, explicable, pas d'hallucination sur les faits, puissant pour les questions complexes. |
| Inconvénients | Peut retourner des passages non pertinents, sensible aux hallucinations, "boîte noire". | Plus complexe à construire et à maintenir. |
Construction du Graphe de Connaissances
Le défi principal est de peupler le KG avec des données de haute qualité.
- Extraction depuis des sources structurées : Le plus simple. Transformer des tables SQL, des CSV ou des APIs en triplets. Une ligne dans une table `users` devient une entité `User` avec des attributs.
- Extraction depuis du texte non structuré (avec des LLMs) : Le plus puissant. On utilise un LLM pour lire des documents et en extraire des triplets.
1. Prompting : On donne au LLM un texte et un schéma (ex: Pydantic) des entités/relations à extraire.
2. Validation : L'extraction n'est jamais parfaite. Une étape de validation (humaine ou automatisée) est nécessaire pour corriger les erreurs avant d'ingérer les faits dans le graphe. - Définition de l'Ontologie (Schéma) : Avant d'extraire, il faut définir quels types d'entités (`Person`, `Company`) et de relations (`WORKS_FOR`, `ACQUIRED`) existent dans votre domaine. C'est le plan de votre KG.
Interrogation (Querying) du Graphe
Le LLM agit comme une interface en langage naturel pour le graphe, en traduisant les questions en requêtes formelles.
- SPARQL (RDF) : Le standard du W3C, plus verbeux mais très puissant pour les graphes de données ouvertes (Linked Open Data).
1. L'intention de l'utilisateur.
2. Le **schéma du graphe** (les types de noeuds, de relations et leurs propriétés).
3. Quelques exemples de questions et de leurs traductions en Cypher (few-shot learning).
- Le LLM génère alors le code Cypher que votre application exécute sur la base de données.
Raisonnement avec les Knowledge Graphs
Le raisonnement est la capacité à déduire de nouveaux faits à partir de faits existants. C'est là que les KGs surpassent les bases de données traditionnelles.
- Inférence de Relations : Si `(A, EST_FILS_DE, B)` et `(B, EST_FRERE_DE, C)`, on peut inférer `(A, EST_NEVEU_DE, C)` grâce à des règles prédéfinies dans l'ontologie.
- Validation par Contraintes : Le schéma peut imposer des règles. Ex: "Une relation `A_POUR_CAPITALE` ne peut exister qu'entre une entité de type `Pays` et une entité de type `Ville`." Cela garantit la cohérence des données.
- Analyse de Chemins : Trouver le chemin le plus court entre deux entités, ou identifier des motifs complexes (ex: "trouver tous les employés qui travaillent dans un projet dirigé par quelqu'un de leur ancienne entreprise").
Technologies et Écosystème
| Catégorie | Exemples de Technologies |
|---|---|
| Bases de Données Graphe | - Neo4j (leader, modèle Property Graph, Cypher) - Amazon Neptune (service managé AWS) - TigerGraph (orienté performance pour les très grands graphes) |
| Frameworks d'Intégration LLM | - LangChain (GraphCypherQAChain) - LlamaIndex (KnowledgeGraphIndex) |
| Bibliothèques d'Extraction | - Utilisation de LLMs via Instructor + Pydantic pour extraire des triplets de manière structurée. |
Pièges & Challenges
Le challenge le plus courant n'est pas la technologie, mais l'acquisition des données. Un KG est inutile s'il n'est pas peuplé avec des données complètes et à jour. La construction du KG est un projet de data engineering à part entière.
- Conception du Schéma (Ontologie) : Un schéma trop simple manquera de pouvoir expressif ; un schéma trop complexe sera impossible à maintenir et à requêter.
- Désambiguïsation d'Entités : Le LLM extrait "Apple". S'agit-il de l'entreprise ou du fruit ? Un processus de "Entity Linking" est nécessaire pour lier les mentions aux entités uniques du graphe.
- Performance des Requêtes NL2Query : Le LLM peut générer des requêtes Cypher sub-optimales ou incorrectes. Le "prompt engineering" pour le traducteur est un processus itératif.
Snippet 1 : Extraction de Triplets avec un LLM
import instructor
from openai import OpenAI
from pydantic import BaseModel, Field
from typing import List
class Relation(BaseModel):
subject: str = Field(description="The subject entity.")
predicate: str = Field(description="The relationship between the subject and the object.")
object: str = Field(description="The object entity.")
class TripletExtractor(BaseModel):
relations: List[Relation]
client = instructor.patch(OpenAI())
def extract_triplets_from_text(text: str) -> TripletExtractor:
return client.chat.completions.create(
model="gpt-4-turbo",
response_model=TripletExtractor,
messages=[
{"role": "system", "content": "Extract all Subject-Predicate-Object triplets from the text."},
{"role": "user", "content": text}
]
)
# text = "Elon Musk founded SpaceX, which is headquartered in Hawthorne."
# result = extract_triplets_from_text(text)
# for rel in result.relations:
# print(f"({rel.subject}) -[{rel.predicate}]-> ({rel.object})")
# Output: (Elon Musk) -[FOUNDED]-> (SpaceX)
# (SpaceX) -[IS_HEADQUARTERED_IN]-> (Hawthorne)
Snippet 2 : Chaîne KG-RAG avec LangChain (Concept)
from langchain.chains import GraphCypherQAChain
from langchain_community.graphs import Neo4jGraph
from langchain_openai import ChatOpenAI
# 1. Connexion à la base de données Neo4j
graph = Neo4jGraph(
url="bolt://localhost:7687", username="neo4j", password="password"
)
# 2. Le LLM qui traduira en Cypher et synthétisera la réponse
llm = ChatOpenAI(model="gpt-4-turbo", temperature=0)
# 3. La chaîne qui orchestre le tout
# Elle introspecte le schéma du graphe pour l'injecter dans le prompt
chain = GraphCypherQAChain.from_llm(
llm=llm, graph=graph, verbose=True
)
# 4. Exécution
# La chaîne va :
# - Prendre la question
# - Générer une requête Cypher
# - L'exécuter sur Neo4j
# - Recevoir les résultats
# - Les synthétiser en une réponse en langage naturel
# response = chain.invoke({"query": "How many employees work at Acme Inc.?"})
# print(response["result"])
Playbook de Déploiement
- Étape 1 : Définir un périmètre restreint. Ne tentez pas de modéliser l'univers. Choisissez un cas d'usage avec des entités et relations claires (ex: organigramme d'entreprise, catalogue de produits, dépendances de services IT).
- Étape 2 : Concevoir une Ontologie simple. Définissez 3 à 5 types d'entités et 5 à 10 types de relations pour commencer. Vous pourrez l'enrichir plus tard.
- Étape 3 : Mettre en place un pipeline d'extraction LLM. Utilisez le snippet d'extraction de triplets pour peupler votre KG à partir d'une poignée de documents de confiance. Inutile d'ingérer des To de données au début.
- Étape 4 : Utiliser une base de données graphe managée. Des services comme Neo4j Aura vous permettent de démarrer en quelques minutes sans gérer l'infrastructure.
- Étape 5 : Construire la chaîne de Question/Réponse. Utilisez une librairie comme LangChain pour créer la chaîne NL2Query. Le plus gros du travail sera d'affiner le prompt en lui donnant le schéma et de bons exemples.
- Étape 6 : Intégrer avec la recherche vectorielle. Une fois que le KG-RAG fonctionne, rendez-le plus intelligent en utilisant la recherche vectorielle pour trouver les entités de départ les plus probables avant d'exécuter la requête Cypher.
