Posez cette question à un RAG classique : « si le service Paiement tombe, quels clients sont impactés ? ». Il va chercher des passages qui ressemblent à la question… et vous ramener la doc du service Paiement. La réponse, elle, n’est écrite nulle part : elle se déduit — Paiement est appelé par Commande, Commande sert la boutique, la boutique a des clients Premium. Trois sauts de lien. Un archiviste ne sait pas faire ça.
Vous connaissez le mur des séries policières : photos, lieux, indices — et des ficelles rouges entre eux. Le détective ne résout pas l’enquête parce qu’il a le plus gros carton d’archives, mais parce qu’il a relié les indices. Donner ce mur à une IA, c’est tout l’objet du graph engineering. On le monte ensemble — vous allez voir, c’est pas sorcier.
Le point aveugle de l’archiviste
Le RAG vectoriel, c’est un archiviste génial : il retrouve en un instant les passages sémantiquement proches de votre question. Tant que la réponse est écrite quelque part dans un document, il brille.
Mais la similarité a un point aveugle : les relations. Découpés en morceaux et rangés par ressemblance, vos documents deviennent un sac de confettis — chaque confetti est pertinent, mais les ficelles entre eux ont été coupées au découpage. D’où deux familles de questions qui font caler l’archiviste :
- Les questions multi-sauts : « qui a validé la décision qui a introduit la dépendance qui pose problème ? » — la réponse traverse trois documents qui ne se ressemblent pas.
- Les questions globales : « quels sont les grands thèmes de ce corpus ? » — aucun morceau ne ressemble à la question, puisque la réponse est partout.
Face à ça, récupérer « les 10 passages les plus similaires » ne suffit plus. Il faut suivre les ficelles.
Le mur d’enquête, formellement
Un graphe de connaissances, c’est trois ingrédients — pas un de plus :
- les nœuds : les entités (le service Paiement, la cliente ACME, l’ADR n°12) — les photos sur le mur ;
- les arêtes : les relations, orientées et nommées (appelle, dépend de, a décidé) — les ficelles rouges ;
- les propriétés : les détails portés par l’un ou l’autre (criticité, date, statut).
L’unité de base s’écrit en triplet sujet → prédicat → objet : Commande —appelle→ Paiement, ACME —souscrit→ Premium. Rien de plus. Et pourtant ce petit format change la nature de la recherche : au lieu de demander « qu’est-ce qui ressemble à ma question ? », on demande « qu’est-ce qui est relié à ce nœud, et de quelle façon ? ». La ressemblance devient de la traversée.
Le graph engineering : le métier de monter le mur
Le mur ne se monte pas tout seul — et c’est là que naît la discipline. Vous allez reconnaître un cycle : c’est le même que celui de la mémoire, appliqué aux relations.
- Modéliser — choisir l’ontologie : quelles entités et quelles relations comptent pour vos questions. C’est le geste le plus important et le moins technique : un glossaire du domaine bien tenu en est déjà le brouillon.
- Extraire — remplir le graphe. Bonne nouvelle : lire du texte et en sortir des triplets, c’est précisément ce qu’un LLM fait bien. On lui donne les documents et le schéma, il propose
sujet —relation→ objet, l’humain tranche sur les cas douteux. - Stocker et interroger — une base orientée graphe (Neo4j, Cosmos DB en mode Gremlin…) et son langage de traversée : « pars de ce nœud, suis dépend de sur trois sauts, remonte ce que tu croises ».
- Entretenir — le mur vieillit : « ACME », « Acme Corp » et « acme-prod » sont-ils le même nœud ? La fusion d’entités et la péremption des relations sont l’équivalent graphe du ménage dans les fiches mémoire.
GraphRAG : l’archiviste ET le détective
Le graphe ne remplace pas le vectoriel — les deux s’emboîtent, et l’assemblage porte un nom : GraphRAG.
- Entrer : la question de l’utilisateur est floue (« le truc des paiements qui rame ») — l’embedding retrouve le bon nœud d’entrée dans le graphe. L’archiviste ouvre la bonne porte.
- Raisonner : depuis ce nœud, on traverse — dépendances, décisions, responsables — pour assembler un contexte que la similarité seule n’aurait jamais réuni. Le détective suit les ficelles.
- Résumer : pour les questions globales, on pré-calcule des communautés (les quartiers du graphe) et leurs résumés — répondre à « de quoi parle ce corpus ? » devient possible sans relire le corpus.
Le résultat part ensuite, comme toujours, sur le bureau du modèle : le graphe ne génère rien, il sélectionne mieux ce qu’on donne à lire. C’est aussi la mécanique des context providers d’Agent Framework version graphe : des souvenirs reliés, servis au bon moment.
Et un secret pour finir de vous convaincre : votre dépôt est déjà un graphe. Appels entre classes, références entre projets, diagrammes as code, historique des commits — quand un agent remonte « qui appelle cette méthode ? », il fait de la traversée de graphe sans le dire. Le graph engineering, c’est offrir la même chose à la connaissance métier.
Le mot d’honnêteté
Le mur d’enquête impressionne, mais il se paie — trois avertissements avant de sortir les ficelles rouges :
- La plupart des besoins n’en ont pas besoin. Si vos questions sont « où est-ce écrit ? », le RAG vectoriel suffit et coûte dix fois moins cher à monter. Le graphe se justifie quand vos questions sont multi-sauts ou globales — pas avant. Commencez simple, mesurez avec des evals, complexifiez si les échecs le prouvent.
- L’extraction automatique se relit. Un LLM qui extrait des triplets peut halluciner une relation — et une relation fausse dans un graphe est plus toxique qu’un passage mal classé : elle sera traversée avec assurance à chaque requête.
- Le schéma est un pari. Une ontologie trop fine coûte une fortune à remplir ; trop grossière, elle ne répond à rien. Règle pratique : modélisez pour les questions que vous posez vraiment, pas pour la beauté du modèle.
En résumé
| RAG vectoriel | GraphRAG | |
|---|---|---|
| La métaphore | l’archiviste | le détective et son mur |
| Retrouve | ce qui ressemble | ce qui est relié |
| Brille sur | « où est-ce écrit ? » | multi-sauts et questions globales |
| Unité de base | le morceau de texte | le triplet sujet → relation → objet |
| Coût de construction | faible | élevé (schéma, extraction, entretien) |
| Risque type | passage manquant | relation fausse traversée avec aplomb |
- Un graphe = nœuds + arêtes + propriétés ; la question passe de « qu’est-ce qui ressemble ? » à « qu’est-ce qui est relié ? ».
- Le graph engineering = modéliser, extraire, interroger, entretenir — le cycle de la mémoire, appliqué aux relations.
- GraphRAG emboîte les deux : le vectoriel trouve la porte d’entrée, la traversée fait le raisonnement.
- Et l’ordre des choses : d’abord le RAG simple, des evals — le mur d’enquête quand les échecs multi-sauts le justifient.
Le détective ne jette pas ses archives : il les relie. Faites pareil pour votre IA — et le jour où on vous demandera « si Paiement tombe, qui appelle-t-on ? », elle suivra les ficelles au lieu de vous tendre la doc. Et ça, franchement… c’est pas sorcier.
