La première fois que j’ai entendu « knowledge graph », je me suis imaginé ces tableaux de théories du complot avec des fils rouges reliant des photos et des coupures de journaux. Il s’avère que ce n’est pas une analogie si terrible — sauf que les knowledge graphs sont organisés, lisibles par machine et réellement utiles.
Mon introduction aux knowledge graphs a été accidentelle. Je construisais un système RAG pour un cabinet d’avocats — vous savez, le genre où vous fournissez des documents à une IA et elle répond à des questions à leur sujet. Le système fonctionnait plutôt bien pour des questions simples. Mais quand un avocat a demandé « Quels de nos clients ont été impliqués dans des litiges avec des entreprises qui ont ensuite été acquises par nos autres clients ? », le système RAG a eu du mal. Il n’a pas pu relier les points à travers plusieurs relations.
Entrez les knowledge graphs. Deux semaines de travail plus tard, la même question a donné une liste de sept situations pertinentes, chacune avec la chaîne de relations qui les reliait. Le partenaire senior a qualifié cela de « vraiment utile », ce qui, venant d’un avocat de 30 ans d’expérience, équivaut en gros à une ovation debout.
Pourquoi ils sont importants pour l’IA
Les LLM sont doués pour le langage. Ils ne sont pas bons pour le raisonnement structuré à travers les relations. Demandez à ChatGPT un document — génial. Demandez-lui de retracer la chaîne de propriété entre cinq entreprises à travers trois fusions sur dix ans — terrible.
Les knowledge graphs comblent cette lacune. Ils organisent l’information sous forme d’entités (personnes, entreprises, concepts) reliées par des relations (« travaille chez », « acquis par », « situé à »). Cette structure rend le raisonnement multi-saut naturel : commencez à l’Entité A, suivez les relations, arrivez à l’Entité D et expliquez le chemin.
Le RAG s’améliore de manière spectaculaire. Le RAG standard retourne des morceaux de texte qui sont sémantiquement similaires à votre question. Le RAG amélioré par le knowledge graph récupère des entités liées et leurs connexions. La différence : le RAG standard trouve des paragraphes pertinents. Le RAG amélioré par le graph trouve des faits pertinents et les relations entre eux.
J’ai constaté une amélioration de 40 % de la qualité des réponses pour des questions complexes, riches en relations, après avoir ajouté un knowledge graph à un système RAG. Pour des questions factuelles simples, l’amélioration était minimale. Le knowledge graph vaut son pesant d’or lorsque les questions impliquent des connexions.
Les hallucinations diminuent de manière mesurable. Lorsque l’IA peut vérifier une affirmation par rapport à un knowledge graph de faits vérifiés, elle est moins susceptible de faire des erreurs. « Einstein a travaillé à Princeton » — vérifiez le graph, oui, cette relation existe. « Einstein a travaillé au MIT » — vérifiez le graph, aucune relation de ce type. À signaler.
Construire un (C’est plus facile que vous ne le pensez)
Neo4j est l’endroit où la plupart des gens commencent, et pour une bonne raison. C’est le PostgreSQL des bases de données graphes — mature, bien documenté et avec la plus grande communauté. Le langage de requête Cypher ressemble presque à de l’anglais : MATCH (p:Person)-[:WORKS_AT]->(c:Company) WHERE c.name = "Acme" RETURN p.name
J’ai utilisé Neo4j pour trois projets en production. La courbe d’apprentissage est d’environ une semaine pour être productif, un mois pour être à l’aise. Le niveau gratuit (Neo4j Aura) est suffisant pour le développement et les petits projets.
Pour un prototypage rapide, pgvector + PostgreSQL fonctionne en réalité de manière étonnamment bien si vous exécutez déjà Postgres. Vous ne bénéficiez pas des capacités complètes de parcours de graphes de Neo4j, mais pour des requêtes simples d’entités-relation avec recherche de similarité vectorielle, c’est suffisant et une base de données de moins à gérer.
Le raccourci alimenté par l’IA
Voici la partie qui m’aurait fait gagner des semaines si quelqu’un me l’avait dit plus tôt : vous pouvez utiliser les LLM pour construire automatiquement votre knowledge graph.
Fournissez vos documents à un LLM avec un prompt comme : « Extraire toutes les entités (personnes, organisations, technologies) et relations de ce texte. Sortir en triples JSON : {sujet, prédicat, objet}. » Le LLM fait un travail étonnamment bon — environ 85 % de précision sur l’extraction d’entités et 70 % sur les relations. Nettoyez les 15-30 % restants manuellement, et vous obtenez un knowledge graph construit en heures au lieu de mois.
J’ai utilisé cette approche pour construire un knowledge graph de 50 000 entités à partir d’un corpus de 10 000 documents. Cela a pris deux jours de temps de calcul et un jour de nettoyage manuel. L’alternative — l’ingénierie des connaissances manuelle — aurait pris des mois à une équipe.
Où je vois les knowledge graphs aller
La combinaison de knowledge graphs et de LLM est encore à ses débuts. La plupart des applications IA aujourd’hui sont de purs RAG — texte entrant, texte sortant. Mais les équipes dont je parle qui construisent de véritables IA d’entreprise ajoutent toutes des knowledge graphs. Elles ont compris que les relations structurées sont la pièce manquante qui rend les applications IA réellement fiables pour des domaines complexes.
Les entreprises de santé construisent des knowledge graphs reliant gènes, protéines, maladies, médicaments et effets secondaires. Les entreprises financières cartographient les relations entre entreprises, structures de propriété et connexions réglementaires. La technologie juridique relie les affaires, les lois, les juges et les précédents.
Les outils sont matures. Neo4j existe depuis 15 ans. Les modèles d’intégration IA sont éprouvés. Le véritable problème est la sensibilisation — la plupart des développeurs construisant des applications IA n’ont tout simplement pas envisagé d’ajouter un knowledge graph.
Si votre application IA doit répondre à des questions sur les relations entre les choses, un knowledge graph l’améliorera considérablement. Si elle doit juste répondre à des questions factuelles issues de documents, un RAG standard est suffisant. Sachez faire la différence et choisissez en conséquence.
🕒 Published: