Graphify, OKF et RAG : quel niveau de contexte votre codebase a-t-il besoin ?
Les benchmarks montrent que Graphify atteint un niveau de précision équivalent à celui de RAG vectoriel. Voici comment Graphify, OKF de Google et RAG vectoriel s’articulent, avec les facteurs de défaillance et une matrice de décision.
Le fichier de référence propre à Graphify contient un résultat que le battage médiatique entourant ce projet a tendance à ignorer. En termes de précision dans les tâches de réponse à des questions, il est à égalité avec RAG dense, mais il est légèrement inférieur en termes de capacité de rappel. Pourtant, il est qualifié de « tueur de RAG » dans de nombreux blogs de développeurs, et des équipes d’entreprise l’intègrent, ainsi que le format Open Knowledge Format (OKF) de Google, dans leurs agents de codage basés sur l’IA au même mois. Pourquoi ?
Parce que la manière dont cela est présenté est erronée. Graphify et OKF ne concourent pas pour remplacer RAG. Ce sont tous deux des couches spécialisées, l’une structurale et l’autre narrative, qui s’ajoutent à un index vectoriel ; chacune d’elles n’a de sens que face à un mode de défaillance spécifique dans votre système. Si vous les considérez comme des substituts de RAG, vous perdrez du temps d’ingénierie à gérer des graphes de connaissances et des bundles Markdown curatés pour des problèmes qui n’existent pas.
Ce qui suit explique la fonction de chaque couche, pourquoi le véritable avantage de Graphify réside dans le coût d’ingestion et non dans une capacité de récupération supérieure, ainsi qu’une matrice de décision pour un ensemble de codes en 2026.
Ce que dit réellement le fichier de référence
Ouvrez BENCHMARKS.md dans le répertoire de Graphify : les chiffres concernant les publications publiées y sont indiqués.
Prenez d’abord LongMemEval-S avec 50 échantillons. Le mode d’expansion graphique de Graphify atteint une précision QA de 76 % et un taux de rappel de 0,844@10. Une base de référence RAG vectorielle dense utilisant le même modèle (Kimi K2.6), le même embedder BGE-m3 et des budgets de tokens équivalents obtient également 76 % de précision, avec un taux de rappel de 0,848@10. Ainsi, les graphes de connaissances ne l’emportent pas ici : la précision est identique et le taux de rappel est légèrement inférieur. Pire encore pour le discours marketing, le fournisseur lui-même a généré l’ensemble de données et l’a validé de manière aveugle (90,6 % d’accord de notation, kappa de Cohen de 0,81), ce qui signifie qu’aucun tiers n’a sélectionné intentionnellement un résultat défavorable.
Au sujet de LOCOMO (n=300), la situation est similaire, bien que le critère clé passe par le coût d’ingestion.
Graphify affiche une précision de 45,3 % et coûte environ 1,40 $ pour ingérer l’ensemble de données. Supermemory obtient une précision plus élevée, à 49,7 %, mais son coût d’ingestion est de 15,67 $, soit environ 11 fois plus cher. Ainsi, Graphify n’est pas non plus le meilleur en termes de précision. Il l’emporte plutôt en termes de coût et d’efficacité.
Ce schéma se retrouve dans les deux benchmarks publics. Graphify ne surpasse pas un pipeline RAG vectoriel bien optimisé. Il atteint un niveau de précision similaire, tout en coûtant bien moins cher à mettre en place que d’autres systèmes de mémoire. Deux facteurs expliquent son avantage :
- Un coût d’ingestion faible, car l’analyse syntaxique AST ne nécessite absolument aucune appel à une API de LLM.
- Extraction structurale sans risque d’hallucination, car l’analyse déterministe de Tree-sitter permet de déterminer avec précision les relations entre les codes (appels, importations, héritage de classes) sans que aucun modèle ne soit impliqué dans cette étape.
Pour ceux qui pensent que Graphify remplace les bases de données vectorielles, cela redéfinit la question. Il ne s’agit pas de savoir quel outil l’emporte, mais de déterminer quel niveau gère quel contexte, et quel mode de défaillance dans votre stack d’agents reste non résolu.
Trois niveaux plutôt que trois concurrents
De bonnes choix architecturaux exigent de séparer la réalité technique du langage marketing. Les configurations modernes d’agents s’appuient sur trois niveaux de contexte distincts.
┌─────────────────────────────────────────────────────────────────┐
│ AI CODING AGENT CONTEXT │
└────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ VECTOR RAG │ │ GRAPHIFY │ │ GOOGLE OKF │
│ (Unstructured) │ │ (Structure) │ │ (Narrative) │
├───────────────────┤ ├───────────────────┤ ├───────────────────┤
│ • Docs & Tickets │ │ • AST Call Graphs │ │ • Architecture │
│ • Slack Threads │ │ • Class Hierarchies│ │ • Data Schemas │
│ • Long Tail Text │ │ • Imports/Exports │ │ • Playbooks & Run │
└───────────────────┘ └───────────────────┘ └───────────────────┘
Vector RAG
Vector RAG divise le texte non structuré en blocs de tokens de taille fixe (par exemple 512 tokens), les incorpore dans un espace vectoriel, et retourne à l’heure de la requête les k voisins les plus proches. C’est rapide, peu coûteux et adapté aux documents plats et indépendants.
Sa faiblesse fondamentale est structurelle : il aplatisse la hiérarchie. Une analyse de Prism Labs de 2026 le formule ainsi : lorsque la cause et l’effet ne se trouvent pas dans le même bloc de 512 tokens, le système ne sait pas qu’ils sont liés. De meilleurs modèles d’incorporation ne peuvent pas y remédier, car cela fait partie intégrante du découpage du texte en blocs.
Graphify
Graphify est un moteur local et déterministe. Il effectue une analyse syntaxique à l’aide de Tree-sitter sur plus de 36 langages de programmation, dont Python, TypeScript, Go, Rust, Java, C/C++, Swift, SQL et Terraform/HCL, extrait les éléments de code et assemble un graphe structuré avec des arêtes typées telles que calls, imports, inherits et mixes_in.
Chaque arête porte une étiquette. EXTRACTED signifie qu’elle a été lue directement à partir de l’AST avec une confiance totale, tandis que INFERRED indique qu’elle a été générée par une heuristique avec une confiance moindre. De plus, Graphify applique la détection de communautés de Leiden pour séparer les sous-systèmes naturels et identifie les « nœuds divins », c’est-à-dire des fichiers très centraux qui interagissent avec de nombreux modules.
En exécutant /graphify ., on obtient trois artefacts locaux :
graph.htmlest une représentation visuelle interactive du graphique.GRAPH_REPORT.mdest un aperçu écrit des sous-systèmes de la base de code.graph.jsonest l’index lisible par machine et permettant des requêtes.
Format Open Knowledge
Google Cloud a annoncé OKF en juin 2026. Il ne s’agit ni d’un algorithme de recherche ni d’un moteur de base de données. C’est une spécification de métadonnées Markdown neutre par rapport aux fournisseurs. Un paquet est un répertoire contenant des fichiers Markdown en UTF-8 simples avec un frontmatter YAML minimal, où un seul champ, type, est obligatoire. Une en-tête a l’aspect suivant :
---
type: Architecture Concept
title: Payment Gateway Routing
description: Canonical sequence for multi-tenant payment provider dispatch.
tags: [billing, architecture]
---
Il n’y a ni registre de schémas ni charge de fonctionnement importante. Les bundles sont conçus pour être stockés dans Git et lus à l’aide d’outils de shell ordinaires tels que cat. Ce que conserve OKF, c’est une mémoire institutionnelle soigneusement sélectionnée, écrite par des personnes ou rédigée par des agents : le récit cohérent expliquant pourquoi les systèmes sont conçus de cette manière, et non des symboles de code bruts ou des journaux de chat non triés.
Comment les différentes couches divisent le travail
Ensemble, elles répartissent les tâches : Graphify extrait ce que le code est, OKF capture ce que les ingénieurs savent, et vector RAG s’occupe du reste non structuré.
De un tweet à un dépôt de 63 000 étoiles en 90 jours
La hâte à adopter ces outils prend plus de sens si l’on considère ce calendrier, car tout l’écosystème est apparu en l’espace d’une seule période de 90 jours.
2026-04-01: Karpathy posts "LLM Wiki / Knowledge Compiler" concept on X
│
2026-04-03: Safi Shamsi launches Graphify on GitHub (YC S26)
│
2026-06-01: Graphify reaches 58.3K GitHub stars & 1.2M PyPI downloads
│
2026-06-12: Google Cloud releases Open Knowledge Format (OKF) spec
│
2026-07-01: Graphify ↔ OKF hybrid integration toolkit ships (71.5x token claim)
│
2026-07-05: Graphify hits ~78K stars; Level Up Coding scrutinizes "70x token" claims
Même séquence en prose :
- 1er avril 2026 : Andrej Karpathy partage une expérience de pensée sur X : placer des articles de recherche, des notes de code, des captures d’écran et des documents d’architecture dans un seul dossier, puis les interroger à l’aide d’une IA capable de comprendre leurs relations, les LLM jouant le rôle de « compilateurs de connaissances ».
- 3 avril 2026 : Safi Shamsi publie Graphify sur GitHub, transformant cette idée en projet en l’espace de 48 heures. Il rejoint le lot S26 de Y Combinator.
- 1er juin 2026 : le projet atteint 58 300 étoiles sur GitHub et 1,2 million de téléchargements depuis PyPI.
- 12 juin 2026 : Google Cloud présente OKF accompagné de sa spécification ouverte, de paquets d’exemples (e-commerce GA4, Stack Overflow et Bitcoin) ainsi que d’un agent permettant d’extraire les métadonnées de BigQuery.
- 15 juin 2026 : Le Knowledge Catalog de Google Cloud intègre désormais nativement les bundles OKF et les transmet aux agents d’IA d’entreprise.
- 1er juillet 2026 : Un ensemble d’outils permettant de relier Graphify et OKF dans les deux sens est disponible. Les graphes de code de Graphify sont exportés sous forme de catalogues markdown OKF grâce à une divulgation progressive, ce qui permettrait d’économiser jusqu’à 71,5 fois plus de tokens de requête par rapport à la lecture de fichiers bruts.
- 5 juillet 2026 : Graphify atteint près de 78 000 étoiles, et des publications techniques, dont Level Up Coding, commencent à remettre en question les affirmations d’efficacité mises en avant.
Andrus, écrivant durant cette période d’examen approfondi, a noté qu’un gain proche de 70 fois dépend d’une propriété d’un projet que presque aucun post ne mentionne ouvertement. Cette propriété est la topologie du corpus. Le test utilisé pour obtenir ce chiffre de 70 fois reposait sur un ensemble spécifique de 52 fichiers (les dépôts publics de Karpathy, 5 articles de recherche, 4 diagrammes) ; dans les bases de code d’entreprise dotées de structures de paquets plates ou de monorepos volumineux, les économies en tokens varient considérablement.
Quels échecs justifient l’ajout de l’un ou de l’autre outil ?
Le battage médiatique n’est pas une exigence architecturale, tout comme un mécontentement vague vis-à-vis de la configuration actuelle RAG ne l’est pas non plus. Une nouvelle infrastructure nécessite un mode d’échec concret et observé en son soutien.
Un contrôle de réalité en premier
Selon des enquêtes menées dans l’industrie, la part des déploiements RAG d’entreprise qui n’ont pas donné les résultats escomptés ou ont complètement échoué en moins d’un an atteint 72 %. La plupart de ces échecs sont dus à une segmentation insuffisante des données, à des index vectoriels obsolètes ou à des modèles d’incorporation inadaptés, et non au manque d’une base de données graphique. Un graphe de connaissances ajouté à un pipeline de recherche défectueux ne fait qu’aggraver ce problème en ajoutant des composants supplémentaires à gérer.
┌─────────────────────────────────────────┐
│ Does your AI coding agent underperform? │
└────────────────────┬────────────────────┘
│
┌──────────────────┴──────────────────┐
▼ ▼
[ Sifting multi-file code ] [ Loss of tribal context ]
[ dependencies & calls ] [ across team silos ]
│ │
▼ ▼
Multi-Hop Reasoning Failure Knowledge Sprawl Failure
│ │
▼ ▼
TRIGGER: Add Graphify TRIGGER: Add Google OKF
(AST Structural Graph) (Curated Narrative Spec)
Déclencheur un : échecs du raisonnement multi-étapes (ajouter Graphify)
Ce problème apparaît lorsque la réponse dépend de la connexion de faits entre plusieurs fichiers qui ne partagent jamais de fragment de texte.
Un symptôme typique : l’agent ne peut pas répondre à des questions telles que "quoi se passe-t-il au niveau de la couche API si le schéma dans db/migrations/04_users.sql change ?"
Puisque le RAG vectoriel incorpore chaque bloc de manière indépendante, il ignore complètement les références de clés étrangères, les implémentations d’interfaces ou les appels entre fichiers. De meilleures instructions ou des fenêtres de contexte plus grandes ne serviront à rien, car ces relations n’ont jamais été intégrées dans l’espace vectoriel.
Déclencheur deux : connaissances fragmentées (ajouter OKF)
Ce problème survient lorsque le contexte institutionnel important est dispersé dans des canaux Slack, des pages wiki obsolètes et la mémoire non écrite des développeurs.
Le symptôme ici est un agent qui génère du code syntaxiquement valide mais qui enfreint les directives architecturales internes, appelle des API internes obsolètes ou ignore les règles métier spécifiques au domaine.
Graphify ne peut pas aider, car les analyseurs AST ne lisent que le code source et ne peuvent pas extraire l’intention métier. OKF comble cette lacune en proposant une structure Markdown légère, versionnée avec Git, dans laquelle les ingénieurs consignent des conventions système stables que les agents peuvent interpréter de manière fiable.
Des recherches sur les systèmes RAG dans le domaine juridique ont montré que les outils de récupération standard produisent des erreurs sur 17 % à 33 % des requêtes complexes, car la simple récupération ne permet pas de modéliser la logique qui traverse plusieurs documents. Les directives d’Atlan résument l’ordre logique : d’abord RAG, puis un graphe lorsque la profondeur devient un goulot d’étranglement.
Quel est le coût de chaque outil lorsqu’il ne fonctionne pas
Chaque couche ajoutée introduit ses propres modes de défaillance. Les deux projets sont encore jeunes, donc leurs risques opérationnels méritent une attention avant toute utilisation en production.
Où Graphify fait défaut
- Prises de vue obsolètes. L’index du graphe est créé une seule fois et reste statique. Il n’est pas mis à jour lorsque les développeurs modifient les fichiers, de sorte que, en l’absence d’un hook pré-commit Git ou d’une étape CI/CD, il s’éloigne du code source. Un graphe structurel obsolète est pire que rien, car l’agent fournit des réponses erronées avec assurance.
- Communautés bruyantes dans les monolithes hérités. Dans les grandes applications Java ou C++, la détection de Leiden regroupe souvent des modules non liés entre eux simplement parce qu’ils utilisent tous une infrastructure commune telle que des singleton de journalisation ou de télémétrie.
- Hallucinations dans l’enrichissement sémantique. La phase de traitement du code principal est déterministe, mais la phase sémantique optionnelle qui analyse des documents, des PDF et des images fait encore appel à un LLM. Les relations extraites de ces éléments non liés au code peuvent donc être erronées.
- Allégations non vérifiées. Selon l’architecte logiciel Saurabh Sharma, personne en dehors du projet n’a reproduit une comparaison entre les requêtes graphiques de Graphify et des fichiers bruts, ni une évaluation de référence RAG sur un ensemble de test commun. Les chiffres fournis par les fournisseurs doivent être considérés comme une indication approximative seulement.
Où OKF manque de rigueur
- Aucune contrainte ni validation. Le format exclut délibérément les registres de schémas et les règles strictes, de sorte que la qualité d’un ensemble de fichiers dépend entièrement de celui qui les crée.
- Dégradation silencieuse. Le contrat de base demande aux agents de tolérer des types de métadonnées inconnus ainsi que des liens cassés. Cela accélère l’adoption, mais cela permet aux fichiers de devenir non liés et obsolètes sans aucun erreur de compilation.
- Charge de maintenance. Les documents Markdown nécessitent une discipline continue. Si les workflows d’ingénierie ne requièrent pas de mises à jour OKF en même temps que les modifications de code, la couche narrative devient rapidement obsolète.
Le pipeline combiné en pratique
Pour des bases de code d’entreprise complexes, la meilleure configuration en 2026 n’est pas de choisir un seul outil. Il s’agit plutôt de les relier en un pipeline contextuel à plusieurs étapes.
┌──────────────────────────────────────────────────────────────────┐
│ USER / AGENT QUERY: "What breaks if I modify UserService.py?" │
└─────────────────────────────────┬────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 1: OKF Progressive Disclosure Catalog │
│ Read high-level module narrative & owner specs (~2K tokens) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Targeted node identified)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 2: Graphify Structural Graph Query │
│ Traverses AST edges: calls, imports, inherits (Zero-LLM cost) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Unstructured edge cases)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 3: Vector RAG / Sparse Search │
│ Search raw Slack incident logs, GitHub issues, & PR comments │
└──────────────────────────────────────────────────────────────────┘
Étape un : générer les artefacts structurels de Graphify
Installez Graphify dans un environnement isolé, puis exécutez l’analyseur sur l’espace de travail.
# Install Graphify via uv
uv tool install graphifyy
# Register the skill with your local agent environment (Claude Code, Cursor, Codex, Gemini CLI)
graphify install
# Execute AST graph compilation inside your repository root
/graphify .
# Generated Local Artifacts:
# graph.html --> Interactive visual network representation
# GRAPH_REPORT.md --> Natural language summary of communities & god nodes
# graph.json --> Queryable AST relational graph database
Lorsque c’est terminé, l’index structurel local peut être consulté directement pour examiner les chemins de relation.
# Query dependency paths between components
graphify path "UserService" "DatabasePool"
# Trace architectural blast radius before refactoring
graphify query "What components depend on AuthTokenValidator?"
Étape deux : écrire des concepts sélectionnés sous forme de OKF
Exportez ce que la phase de structure a identifié dans un ensemble de concepts conforme à OKF, à placer dans .well-known/okf/ ou docs/knowledge/. Un fichier de concept minimal utilise des liens Markdown ordinaires, et ces liens correspondent directement aux arêtes du graphe de connaissances.
---
type: Database Table Context
title: orders_fact
description: Canonical order transaction table joining billing and fulfillment streams.
resource: bigquery://production-data.commerce.orders_fact
tags: [finance, core-model]
timestamp: 2026-06-20T14:00:00Z
---
# Business Domain Summary
The `orders_fact` table serves as the primary source of truth for revenue calculations.
Modifications to columns must align with the [Customer Profile Spec](./customer_profile.md).
# Schema & Join Constraints
| Column Name | Data Type | Structural Constraint |
|---|---|---|
| `order_id` | STRING | Primary Key; joins with [billing_events](./billing_events.md) |
| `customer_id` | STRING | Foreign Key; see [customers](./customers.md) |
| `status` | STRING | Enum: `pending`, `completed`, `refunded` |
# Related Runbooks
- Incident Protocol: [/runbooks/billing-reconciliation.md](/runbooks/billing-reconciliation.md)
Kopp, spécialiste de la recherche et de l’ingénierie contextuelle, souligne que la structure de liens d’OKF s’adapte parfaitement à GraphRAG, étant donné qu’un lien de orders_fact.md vers customers.md constitue déjà un arête dans un graphe de connaissances.
Preuves issues d’ERPNext
Cette approche combinée a été testée sur ERPNext, un code source d’entreprise open source comptant plus d’un million de lignes de Python et de JavaScript.
Les évaluations ont utilisé Claude Opus 4.8, avec une limite de 14 tours par tâche :
- Un agent de codage de référence utilisant Vector RAG et grep a atteint une couverture des faits clés de 70,8 %.
- Le pipeline hybride Graphify et OKF a atteint une couverture des faits clés de 82,0 %, avec en moyenne environ 140 000 tokens par session de requête.
Une amélioration de 11,2 points sur une base de code de cette taille signifie nettement moins d’erreurs d’exécution des agents. Cela reflète mieux la valeur en environnement de production que les chiffres de réduction artificielle des tokens.
Choix en fonction du type de base de code
Identifiez votre environnement de base de code et son principal mode de défaillance dans la matrice afin de choisir une architecture adaptée.
La version courte
Graphify est le plus performant pour l’analyse structurale déterministe sans coût lié à une API de LLM. OKF propose un standard portable et compatible Git pour le contexte généré aussi bien par des humains que par des agents. Vector RAG reste la solution la plus efficace pour rechercher dans du texte non structuré. Empiler des couches sans mode de défaillance clair augmente la complexité sans améliorer les performances des agents.
Définissez d’abord le problème
Avant d’intégrer Graphify ou OKF dans un pipeline de développement, déterminez quel est le véritable problème parmi les trois : un contexte de code obsolète, des échecs liés à des dépendances multiples, ou des connaissances institutionnelles fragmentées.
Ces deux outils constituent des ajouts utiles à une stack d’IA moderne, et les résultats d’ERPNext démontrent leur réelle valeur sur des bases de code complexes. Néanmoins, le passage d’un simple tweet à un dépôt devenu viral justifie une approche rigoureuse. Lisez directement les données contenues dans BENCHMARKS.md, testez les architectures candidates sur votre propre code, et assemblez une stack adaptée à vos besoins en ingénierie. Commencez par comparer votre configuration aux conditions de type monolithe, microservices ou monorepo présentées dans le tableau.
Lectures complémentaires
- RAG avancé sur Milvus : recherche hybride, HyDE, réécriture des requêtes et réclassement — Construisez un pipeline RAG avec Milvus étape par étape : vecteurs denses et BM25, recherche hybride RRF, filtres de métadonnées, réécriture des requêtes, HyDE, décomposition et réclassement via un cross-encoder.
- Un LLM local utile en 30 minutes : codage, Q&R de documents et reconnaissance vocale — Créez un assistant de codage local, un script de recherche de notes et un système de reconnaissance vocale hors ligne avec Ollama, Qwen3 et Whisper.cpp, ainsi que les règles relatives à la bande passante mémoire pour choisir la taille du modèle.