Recherche vectorielle contre graphe de connaissances : combien coûte réellement la construction et la maintenance d'un GraphRAG

• Corpus source et taille du graphe : 10 019 fiches de connaissances, déployées en 5 237 nœuds et 19 803 arêtes (fichier SQLite de 15 Mo)
• Économie à l'étape de construction : réduction du coût d'extraction de 1 500 $ estimés (avec un préfixe de 117K tokens par appel) à quelques dollars
• Compression des entités par dictionnaire canonique : 1 213 orthographes de projets regroupées en 81 projets canoniques (facteur 15)
• Vitesse du circuit hybride : 13 ms pour un classement FTS5 sur 538 956 messages et 87 ms pour une jointure graphe en deux étapes

Après un an d'exploitation de mon propre système de mémoire, j'ai fini par résumer la différence entre les deux approches en une phrase : la recherche vectorielle répond à « trouve-moi une citation sur X », tandis que le graphe répond à « explique-moi comment X est structuré et avec qui il est connecté ». Quand on demande « quels outils avons-nous utilisés sur ce projet pendant un an et demi, et qui y a participé », aucun chunk de texte ne contient la réponse complète — la recherche vectorielle renvoie trois fragments aléatoires, et le modèle invente avec assurance les 80 % manquants du tableau.

L'étude souvent citée de Microsoft Research (`arXiv:2404.16130`), qui promet une victoire de GraphRAG dans 72 à 83 % des comparaisons par paires en termes d'exhaustivité des réponses, est vraie mais sous conditions strictes. La mesure a été effectuée sur une tâche de synthèse globale du corpus (`query-focused summarization` sur 1,0 à 1,7 million de tokens), et la fourchette de 72-83 % inclut la configuration `TS`, qui n'utilise aucun graphe mais applique un `map-reduce` directement sur les textes sources.

Comment ne pas cramer 1 500 $ en prompt système lors de l'extraction

d'entités sur 10 019 entrées ?

Lorsque je me suis attaqué à la construction d'un graphe sur 10 019 fiches de connaissances (5 658 notes d'apprentissage, 2 657 fragments de code, 1 209 discussions et 155 analyses d'erreurs), ma première implémentation naïve a failli ruiner le projet. L'idée semblait naturelle : découper le corpus en lots de 200 entrées et lancer un agent en ligne de commande en sous-processus pour chaque lot. Le premier appel test a coûté 15 centimes : le client CLI rechargeait à chaque démarrage le prompt système, les règles et les descriptions de compétences — soit 117 000 tokens de préfixe technique.

Sur 49 lots, cela représentait plus de 7 $ gaspillés à vide, et en traitant les 10 019 entrées une par une, la facture aurait dépassé 1 500 $.

Nous avons restructuré le pipeline : élimination préalable de 287 entrées inutiles, puis lancement de vagues de 5 à 7 sous-agents en parallèle, à l'intérieur d'une seule session parente vivante où le préfixe est déjà mis en cache. Une tentative de monter à 20 workers simultanés s'est heurtée à un throttling serveur après 411 tâches sur 672 ; nous avons donc fixé l'optimum : des identifiants de lots stables dans un manifeste et des vagues allant jusqu'à 6-8 agents en parallèle.

Pourquoi l'exploitation du graphe coûte-t-elle plus cher que sa

construction, et comment un dictionnaire canonique compresse-t-il les projets par 15 ?

Chaque nouvelle vague d'extraction d'entités apporte des dizaines de variantes d'orthographe pour les mêmes noms et marques. Si on les enregistre telles quelles en base, un mois plus tard, un seul projet se transforme en quinze îlots isolés dans le graphe. Le seul remède : un dictionnaire canonique déterministe (`_MAPS`) appliqué avant l'écriture en base :

```python def canon(entity_kind: str, raw_name: str) -> str: # Normalise le nom brut d'une entité ou l'élimine comme bruit (chaîne vide) cleaned = (str(raw_name) if raw_name is not None else "").strip() return _MAPS.get(entity_kind, {}).get(cleaned, cleaned) ```

Après application des cartes de normalisation, 1 213 orthographes brutes de projets se sont regroupées en 81 projets réels (facteur 15 !), 2 542 variantes d'outils se sont réduites à 1 068, les entreprises sont passées de 1 427 à 1 115, et les personnes de 783 à 590. 66 pseudo-outils supplémentaires et 11 « entreprises » abstraites (« Holding », « Bibliothèque ») ont été mappés vers une chaîne vide.

Au passage, nous avons corrigé deux pièges classiques : une boucle `for t in stack` itérant sur un champ chaîne de caractères au lieu d'une liste, qui avait généré 96 000 arêtes parasites vers des lettres isolées de l'alphabet (corrigé par une vérification `isinstance(v, list)`), et une explosion de l'auto-liage par sous-chaîne de titre produisant 27 000 fausses relations (corrigée par un filtre de longueur minimale de 5 caractères et une condition limitant la clé à au plus 4 projets, ce qui a donné 543 arêtes `about` précises).

Quand deux tables SQLite suffisent-elles à la place d'un serveur de

graphe dédié ?

La première version de notre graphe vivait sur un serveur dans une base FalkorDB (sur Redis et GraphBLAS). On y a découvert que le dialecte Cypher ne supportait ni les regex `=~` ni le `shortestPath()` non dirigé, et qu'à cause d'un connecteur MCP désactivé et de la nécessité de monter un tunnel SSH, le graphe de 4 743 nœuds est resté 7 semaines complètement coupé des agents.

Nous avons migré tout le graphe vers un fichier SQLite local de 15 Mo, composé de deux tables (`nodes` et `edges`). À l'échelle de 5 237 nœuds et 19 803 arêtes, une requête SQL classique avec deux `JOIN` identifie les meilleurs projets par nombre d'outils et de sessions (le leader affiche 277 sessions et 285 outils) en 87 ms, tandis qu'une recherche plein texte FTS5 sur un demi-million de messages répond en 13 ms.

Cette recherche hybride, sans démons superflus, est intégrée à l'architecture de [Nomad AI](https://nomadnet.ai) et de la plateforme cloud [agent.nomadnet.ai](https://agent.nomadnet.ai). Pour apprendre à construire des RAG et des graphes de connaissances industriels, rendez-vous sur [Hamidun Academy](https://academy.hamidun.com) (essai de 72 heures ouvert), et les scripts de canonisation sont disponibles sur [Vibe Club](https://hamidun.com/club).