Les graphes de connaissances pour l’IA agente : quatre modèles qui vont au-delà de la technologie RAG vectorielle.
La recherche vectorielle permet de trouver des textes similaires, et non des faits liés entre eux. Quatre modèles de graphes pour les agents : l’incitation basée sur des données concrètes, la planification, la validation de l’exécution et l’autocorrection.
Sources: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs
La plupart des équipes qui développent des systèmes d’IA se heurtent au même problème. Une base de données vectorielle est mise en place, les documents sont divisés en fragments, un LLM est intégré, et le tout est qualifié de pipeline RAG. Tout fonctionne tant qu’un utilisateur ne pose pas une question nécessitant la combinaison de trois faits provenant de domaines de données différents. À ce moment-là, le système soit invente une réponse qui semble convaincante, soit fournit une réponse techniquement correcte mais inutile dans ce contexte.
Généralement, ce n’est pas la faute de l’LLM. C’est plutôt celle de la couche de récupération d’informations qui le sous-tend. La recherche par similarité vectorielle consiste essentiellement à trouver des passages ayant un son similaire, ce qui amène le système à identifier des textes proches sur le plan sémantique tout en manquant des faits liés par des relations de cause à effet. Pour un agent qui doit raisonner en plusieurs étapes, prendre des actions et enchaîner des décisions, cette limitation s’aggrave. Une mauvaise réponse peut entraîner l’accumulation d’erreurs tout au long de la chaîne de raisonnement.
Le argument qui mérite d’être pris au sérieux est qu’un graphe de connaissances n’est pas simplement un mécanisme de récupération plus sophistiqué. C’est le fondement structurel qui permet à un agent de raisonner et non seulement de récupérer des informations.
L’idée fondamentale
L’IA agente est souvent considérée comme un mot à la mode : il suffit d’ajouter quelques appels d’outils autour d’un LLM pour se proclamer victorieux. Une approche plus rigoureuse conçoit la couche de connaissances spécifiquement pour le raisonnement à plusieurs étapes et non pour la réponse à des questions en une seule fois.
Le changement consiste à passer d’un modèle de récupération plat à un graphe structuré dans lequel les entités, les relations et le contexte occupent une place centrale. Un graphe ne se contente pas d’enregistrer que le Produit X présente un défaut ; il indique également que le Produit X est fabriqué par le Fournisseur Y, expédié vers la Région Z et couvert par le Cadre de conformité W. Un agent qui interroge ce graphe peut suivre ces liens pour obtenir des informations que une recherche vectorielle ne pourrait jamais révéler.
Rien de tout cela n’est nouveau en théorie des bases de données. L’application rigoureuse de ces principes aux systèmes agents constitue l’aspect innovant, et le moment choisi est judicieux. Les pipelines d’agents ont suffisamment mûri, grâce à une meilleure capacité de raisonnement des LLM, à des API de appel d’outils améliorées et à des frameworks d’orchestration plus riches, au point que la couche de connaissances devient désormais le goulot d’étranglement. Une architecture d’agent irréprochable produit encore des résultats erronés lorsque la représentation des connaissances sous-jacente est plate et désorganisée.
Cette méthode se divise en quatre modèles architecturaux, chacun ciblant une étape différente du cycle de vie de l’agent : l’ancrage, la planification, l’exécution et l’autocorrection. Ensemble, ils forment un plan directeur pour des systèmes en production et non un simple exercice théorique.
Pourquoi c’est important
La production de RAG est souvent fragile, et ses défaillances sont difficiles à tracer. Après une réponse insatisfaisante, la cause reste cachée : une récupération insuffisante, une mauvaise délimitation des segments, ou un modèle qui contredit le contexte qui lui a été fourni. Avec la recherche vectorielle plate, il ne reste plus qu’à deviner. En intégrant un graphe de connaissances, l’explicabilité apparaît presque gratuitement, car le chemin parcouru constitue la trace du raisonnement.
Cela revêt une grande importance dans les secteurs réglementés. La santé, la finance et la technologie juridique ont toutes besoin d’une IA capable de montrer comment elle travaille. Un système qui indique les trois nœuds du graphe et les deux étapes de relation derrière une réponse peut faire l’objet d’une audit, tandis qu’un système ne présentant que le meilleur résultat cosinus ne le peut pas. Pour les équipes qui déployent des systèmes d’IA soumis à de strictes exigences de conformité, c’est là toute la différence entre quelque chose qui peut être mis en œuvre et un simple concept qui ne quitte jamais le laboratoire.
Il existe également un aspect lié à la fiabilité. Les systèmes agents échouent de manière en cascade, où une mauvaise décision prise tôt dans la chaîne affecte négativement tout ce qui suit. Un graphe agit comme une barrière structurelle : les agents peuvent vérifier les conclusions intermédiaires par rapport à lui avant de procéder, ce qui permet de détecter tôt tout écart. Cela ressemble à un vérificateur de faits intégré au cycle de raisonnement et non ajouté en fin de processus.
Le bénéfice peut-être le plus sous-estimé est la mise à jour des connaissances sans avoir à réentraîner le système. Avec les embeddings, ajouter de nouvelles informations signifie souvent ré-embedding de gros volumes de données, ce qui peut perturber le comportement actuel de récupération des informations. Avec un graphe, il suffit d’ajouter des nœuds et des arêtes, et le raisonnement de l’agent les reflète immédiatement. Dans des domaines en évolution rapide tels que les marchés financiers, la recherche médicale ou les écosystèmes logiciels en constante mutation, c’est un réel avantage opérationnel.
Les quatre modèles en pratique
1. L’incitation basée sur les connaissances
Le premier modèle ancre le contexte de départ de l’agent dans des faits structurés et non dans des résultats de similarité flous. Au lieu de récupérer des passages qui semblent similaires, interrogez le graphe pour obtenir le sous-graphe pertinent à l’intention de l’utilisateur, puis intégrez ce contexte structuré dans le prompt.
from neo4j import GraphDatabase
import json
def get_grounded_context(user_query: str, entity_extractor, driver) -> str:
# Step 1: Extract entities from the user query
entities = entity_extractor(user_query) # e.g., ["Product X", "Supplier Y"]
# Step 2: Pull a relevant subgraph from Neo4j
with driver.session() as session:
result = session.run(
"""
MATCH (e)-[r]-(connected)
WHERE e.name IN $entities
RETURN e.name AS entity,
type(r) AS relationship,
connected.name AS related_entity,
connected.attributes AS attributes
LIMIT 50
""",
entities=entities
)
subgraph = [record.data() for record in result]
# Step 3: Format subgraph as structured context
context_str = json.dumps(subgraph, indent=2)
grounded_prompt = f"""
You are a reasoning agent. Use ONLY the following structured knowledge to answer.
If the answer isn't derivable from this context, say so explicitly.
KNOWLEDGE GRAPH CONTEXT:
{context_str}
USER QUERY: {user_query}
"""
return grounded_prompt
Regardez ce qui se passe ici. L’agent ne cherche pas des documents ressemblant à la question. Il extrait des entités concrètes, récupère leur environnement relationnel et l’injecte comme contexte structuré. Ce que reçoit le LLM, c’est une carte, alors qu’auparavant il ne recevait qu’une série de paragraphes qui ne étaient que faiblement liés entre eux.
2. Planification guidée par un graphe
Le deuxième modèle concerne la planification en plusieurs étapes. Les agents divisent des objectifs complexes en étapes exécutables, et ces étapes doivent reposer sur ce qui est réellement possible compte tenu de l’état actuel des connaissances. Un graphe rend la planification bien moins libre.
Comparez la planification d’un voyage en voiture sans carte et avec une carte. Sans elle, le itinéraire n’est que plausible. Avec elle, l’itinéraire respecte les routes réelles, les distances et les contraintes. Le graphe remplit alors le rôle de la carte.
def plan_with_graph(goal: str, graph_schema: dict, llm) -> list[dict]:
schema_str = json.dumps(graph_schema, indent=2)
planning_prompt = f"""
You are a planning agent. Given the goal below, decompose it into steps.
Each step must reference a valid entity type or relationship from the schema.
Do not invent steps that require knowledge outside this schema.
GRAPH SCHEMA:
{schema_str}
GOAL: {goal}
Return a JSON list of steps. Each step must include:
- "action": what to do
- "graph_query": the Cypher query to retrieve required context
- "depends_on": list of prior step indices this step requires
"""
raw_plan = llm.complete(planning_prompt)
plan = json.loads(raw_plan)
return plan
Le détail essentiel consiste à injecter graph_schema dans le planificateur. L’agent ne peut planifier que des étapes que le graphe prend en compte structurellement, ce qui réduit considérablement les plans fantaisistes, car il ne peut proposer d’actions dépendant de relations de données absentes du modèle de connaissances.
3. Exécution avec validation du graphe
Lors de l’exécution, l’agent agit et génère des résultats partiels au fur et à mesure. Le troisième modèle préconise de valider chaque résultat intermédiaire par rapport au graphe avant de l’accepter. Supposons que l’agent conclue que le fournisseur Y est à l’origine du défaut constaté dans le produit X. Le système doit alors confirmer immédiatement que le graphe contient bien une relation entre ce fournisseur et ce produit, et signaler l’allégation si ce n’est pas le cas.
def execute_with_validation(step: dict, intermediate_result: str, driver, llm) -> dict:
# Extract claims from the intermediate result
claim_extraction_prompt = f"""
Extract all factual claims from this text as a list of (subject, predicate, object) triples.
TEXT: {intermediate_result}
Return as JSON array.
"""
claims = json.loads(llm.complete(claim_extraction_prompt))
validation_results = []
with driver.session() as session:
for claim in claims:
result = session.run(
"""
MATCH (s {name: $subject})-[r]-(o {name: $object})
WHERE type(r) = $predicate OR $predicate IN r.aliases
RETURN count(r) AS match_count
""",
subject=claim["subject"],
predicate=claim["predicate"],
object=claim["object"]
)
record = result.single()
validation_results.append({
"claim": claim,
"validated": record["match_count"] > 0
})
unvalidated = [v for v in validation_results if not v["validated"]]
return {
"result": intermediate_result,
"validated": len(unvalidated) == 0,
"flagged_claims": unvalidated
}
C’est sans doute ici que réside la majeure partie de la valeur de production. Un détecteur de hallucinations continu est intégré dans le cycle d’exécution en tant que composante structurelle du processus de raisonnement, et non comme une solution ajoutée ultérieurement. Les affirmations non validées ne font pas planter le système ; elles sont marquées afin que l’agent puisse les réviser ou les soumettre à une révision humaine.
4. Auto-correction par parcours du graphe
Le quatrième modèle ferme ce cycle. Lorsqu’une incohérence est détectée ou que des retours négatifs sont reçus, l’agent ne tente pas de nouveau aveuglément. Il parcourt le graphe pour trouver des chemins de raisonnement alternatifs, ce qui distingue un agent qui échoue de manière élégante d’un agent qui reste bloqué indéfiniment face à de mauvaises entrées.
Supposons que l’agent enquête sur les raisons pour lesquelles une vérification de conformité a échoué. En partant de l’entité qui a provoqué cet échec, il suit les relations vers l’extérieur et découvre un maillon manquant, par exemple une mise à jour réglementaire qui n’a pas encore été associée à la catégorie de produit concernée. Il s’agit d’une lacune dans le graphe et non dans le LLM, et l’agent peut la signaler explicitement : la conclusion ne pouvait pas être validée car la relation entre une mise à jour réglementaire spécifique et la catégorie de produit de santé n’existe pas. Il s’agit d’une erreur pouvant être corrigée et non d’une hallucination.
Que faire à ce sujet
Ne vous précipitez pas pour supprimer la base de données vectorielle. Commencez par vous demander où la structure est importante dans le domaine concerné. Énumérez les entités impliquées et les relations entre elles, puis examinez les questions que l’agent doit répondre et comptez combien exigent de suivre des liens à travers plusieurs faits consécutifs. Lorsque la plupart des questions difficiles se caractérisent ainsi, le problème de fond est un problème de graphe.
En ce qui concerne les outils, Neo4j est la base de données de graphe la plus établie, et son SDK Python s’intègre bien avec LangChain et LlamaIndex. Amazon Neptune et Memgraph constituent de bonnes alternatives en fonction de l’endroit où vous exécutez votre système. Pour l’orchestration, envisagez LangGraph, dont la gestion de l’état ressemble à la traversée de graphes. L’état de raisonnement de l’agent se trouve déjà dans une structure de graphe, ce qui rend naturel l’ajout d’un graphe de connaissances externe.
Une séquence viable commence par le premier modèle, qui vise à apporter les plus petites modifications possibles à un système RAG que vous utilisez déjà. Construisez d’abord le premier graphe en vous concentrant sur les entités et les relations les plus importantes, puis comparez les taux d’hallucinations pour les prompts fondés sur des données réelles avec votre valeur de référence. Si ces taux diminuent, ce qui est très probable, vous aurez alors les arguments nécessaires pour justifier l’utilisation des trois autres modèles.
Un point d’attention : la construction de graphes n’est pas du tout simple. Des données sources désordonnées, incohérentes ou mal étiquetées entraînent un graphe chaotique ainsi qu’un comportement de l’agent imprévisible ; donc le principe « du mauvais entrée, du mauvais résultat » s’applique ici comme partout ailleurs. Investissez dans la qualité des données et dans la conception de l’ontologie avant de mettre en place l’infrastructure de graphes. Un graphe propre et bien structuré comptant 10 000 nœuds performera mieux qu’un graphe étendu mais incohérent comptant 10 millions de nœuds.
Où cela mène-t-il ?
Ces agents vont au-delà du simple récupération et de la génération de contenu. Ils maintiennent un modèle structuré et en évolution du monde dans lequel ils opèrent, et l’utilisent pour raisonner, planifier et s’autocorriger en temps réel. Ce qui distingue les IA qui se contentent de répondre à des questions de celles qui résolvent des problèmes réside principalement dans la manière dont les connaissances sont représentées, et les graphes comptent parmi les solutions structurelles les plus efficaces disponibles.
Essayez cela sur n’importe quel système : si l’agent prend une mauvaise décision demain, pourra-t-on en retracer la cause exacte ? Lorsque c’est impossible, la production fonctionne à l’aveugle. Ces quatre modèles caractérisent des agents qui exposent leur raisonnement, vérifient leurs propres conclusions et échouent de manière permettant une débogage, et c’est là la forme que doit prendre une IA de niveau industriel. Les équipes qui y parviendront en premier devanceront celles qui continuent de se fier aux scores de cosinus en se demandant pourquoi leurs agents échouent constamment.
Lectures complémentaires
- Notes pratiques : Construire un système de détection de la fraude agent prêt pour la production — Guide pas à pas des Notes pratiques : Construire un système de détection de la fraude agent prêt pour la production : contrats, vérifications et emplacements de code à insérer pour les équipes qui mettent en œuvre ce modèle.
- Retraitement sémantique avec ChromaDB et des embeddings pour une plateforme multi-agent — Passer d’une plateforme multi-agent d’entreprise à un retraitement sémantique véritable : segmentation tenant compte du contexte des mots, distance cosinus dans ChromaDB, couches de test et la prochaine étape de RetrievalAgent.