Graphify, OKF та RAG: який шар контексту потрібен вашій кодовій базі?
Бенчмарки показують, що Graphify досягає такої ж точності, як і векторний RAG. Ось як Graphify, OKF від Google та векторний RAG взаємодіють між собою, з механізмами виявлення невдач та матрицею прийняття рішень.
Власний файл тестування Graphify містить результат, який часто ігнорують у всіх хвалебних описах проекту. Щодо точності у відповідях на запитання, він дорівнює результатам технології dense vector RAG, а щодо рівня відтворення інформації він трохи поступається. Проте в блогах розробників його називають „вбивцею RAG“, і саме в тому ж місяці корпоративні команди почали використовувати його разом із форматом Open Knowledge Format (OKF) від Google у своїх AI-агентах для програмування. Чому?
Тому що поширена концепція є хибною. Graphify та OKF не конкурують між собою за право замінити RAG. Обидва є спеціалізованими елементами – один структурним, інший наративним – які доповнюють векторний індекс, причому кожен з них є доцільним лише у разі певних проблем у вашій системі. Якщо розглядати їх як замінники RAG, ви витратите багато часу на підтримку графів знань та структурованих маркдаунових пакетів для проблем, яких у вас насправді немає.
У наступному описано, що робить кожен шар, чому справжньою перевагою Graphify є вартість обробки даних, а не краща здатність до пошуку, а також матриця прийняття рішень для кодової бази 2026 року.
Що насправді говорить файл з тестуванням
Відкрийте BENCHMARKS.md у репозиторії Graphify — там безпосередньо вказані цифри, які не наводяться у публікаціях про результати тестів.
Спочатку розглянемо LongMemEval-S із 50 зразками. Режим розширення графа Graphify дає точність QA на рівні 76% та рівень відтворення інформації 0.844@10. Базова модель типу RAG із щільними векторами, використовуюча ту саму модель (Kimi K2.6), той самий ембеддер BGE-m3 та однаковий бюджет токенів, також досягає 76% точності та 0.848 рівня відтворення інформації@10. Отже, графи знань тут не мають переваги: точність однакова, а рівень відтворення трохи нижчий. Ще гірше те, що сам постачальник надав набір даних та перевірив його сліпо (узгодженість оцінок — 90.6%, коефіцієнт Коена — 0.81), тож жоден сторонній експерт не виявив проблемних результатів.
У проєкті LOCOMO (n=300) ситуація схожа, хоча вирішальним показником стає вартість обробки даних.
Graphify досягає точності 45,3% та коштує приблизно 1,40 долара для обробки набору даних. Supermemory має вищу точність — 49,7%, але його обробка коштує 15,67 долара, що приблизно в 11 разів більше. Отже, Graphify також не є переможцем у змаганні за точність; він перемагає за рахунок нижчої вартості та ефективності.
Ця закономірність спостерігається і в обох публічних тестах. Graphify не перевершує добре налаштовані векторні системи типу RAG за швидкістю пошуку. Він дорівнює їм за точністю, проте коштує значно менше для реалізації порівняно з іншими системами зберігання даних. Два фактори пояснюють його перевагу:
- Низька вартість обробки, оскільки аналіз AST зовсім не вимагає використання API LLM.
- Структурний вилучення без ризику галюцинацій, оскільки детерміністичний парсинг Tree-sitter визначає точні зв’язки в коді (виклики, імпорти, успадкування класів) без участі моделі під час цього етапу.
Для тих, хто вважає, що Graphify замінює векторні бази даних, це переосмислює питання. Рішення полягає не у тому, який інструмент кращий, а у тому, який шар керує яким контекстом та які моди збою в стеку агентів ще залишаються нерозв’язаними.
Три шари замість трьох конкурентів
Хороші архітектурні рішення вимагають розділення технічної реальності від маркетингової термінології. Сучасні конфігурації агентів ґрунтуються на трьох окремих шарах контексту.
┌─────────────────────────────────────────────────────────────────┐
│ 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 розділяє неструктурований текст на блоки токенів фіксованого розміру (наприклад, 512 токенів), вбудовує їх у векторний простір та під час запиту повертає k найближчих сусідів. Цей підхід є швидким, дешевим та підходить для незалежної, однорівневої документації.
Його основний недолік полягає у структурі: він уніфікує ієрархію. У аналізі Prism Labs 2026 року це пояснюється так: коли причина та наслідок знаходяться не в одному блоку з 512 токенів, система не розуміє їхнього зв’язку. Кращі моделі вбудовування не можуть це виправити, оскільки це є невід’ємною частиною розділення тексту на блоки.
Graphify
Graphify — це локальний, детерміністичний двигун. Він використовує аналіз AST за допомогою Tree-sitter для більш ніж 36 мов програмування, зокрема Python, TypeScript, Go, Rust, Java, C/C++, Swift, SQL та Terraform/HCL, виділяє елементи коду та створює структурну графіку з типованими ребрами на кшталт calls, imports, inherits та mixes_in.
Кожне ребро має позначку. EXTRACTED означає, що воно було отримано безпосередньо з AST з повною впевненістю, а INFERRED — що воно було створене за допомогою геуристики з меншою впевненістю. Крім того, Graphify застосовує метод виявлення спільнот Leiden для розділення природних підсистем та позначає „бог-вузли“ — надзвичайно центральні файли, які взаємодіють з багатьма модулями.
Виконання команди /graphify . створює три локальні результати:
graph.html— це інтерактивне візуальне зображення графа.GRAPH_REPORT.md— це письмовий огляд підсистем кодової бази.graph.json— це машинний, доступний для пошуку індекс.
Формат відкритих знань
Google Cloud оголосив про OKF у червні 2026 року. Це не алгоритм пошуку та не двигун баз даних. Це нейтральна за виробником специфікація метаданих у форматі Markdown. Пакет — це каталог звичайних файлів Markdown у форматі UTF-8 із мінімальним YAML-фронтматером, де обов’язковим є лише одне поле — type. Заголовок виглядає так:
---
type: Architecture Concept
title: Payment Gateway Routing
description: Canonical sequence for multi-tenant payment provider dispatch.
tags: [billing, architecture]
---
Немає реєстру схем та немає важкого середовища виконання. Бандли призначені для зберігання в Git та читання за допомогою звичайних інструментів командного рядка, таких як cat. OKF зберігає ретельно підібрану інституційну пам’ять, створену людьми або складену агентами: стабільну наративну інформацію про те, чому системи будуються саме так, а не сирі кодові символи чи неретельно оброблені записи чатів.
Як шари ділять роботу
Разом вони розділяють завдання: Graphify витягує те, що є у коді, OKF фіксує те, що знають інженери, а vector RAG обробляє неструктурований залишок.
Від твіту до репозиторію з 63 тис. зірок за 90 днів
Поспішність у впровадженні цих інструментів має сенс, якщо дивитися на часову шкалу, адже весь екосистема з’явилася протягом одного 90-денного періоду.
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
Та сама послідовність у прозі:
- 1 квітня 2026 року: Андрій Карпати оприлюднює на X ідею експерименту: зберігати наукові статті, нотатки до коду, скріншоти та документацію з архітектури в одній папці, а потім шукати в них інформацію за допомогою ШІ, яке розуміє їхні взаємозв’язки, причому нейромережі виконують роль „компіляторів знань“.
- 3 квітня 2026 року: Сафі Шамсі публікує Graphify на GitHub, перетворюючи цю ідею на проект протягом 48 годин. Він приєднується до групи S26 від Y Combinator.
- 1 червня 2026 року: проект досягає 58 300 „зірок“ на GitHub та 1,2 мільйона завантажень з PyPI.
- 12 червня 2026 року: Google Cloud представляє OKF разом із відкритою специфікацією, зразками пакетів (GA4 для електронної комерції, Stack Overflow та Bitcoin) та агентом, який витягує метадані з BigQuery.
Андрус, пишучи під час того періоду ретельного аналізу, зазначив, що досягнення економії у розмірі майже 70 разів залежить від однієї властивості проекту, про яку майже жодна публікація не згадує відкрито. Ця властивість — топологія корпусу. Тест, який лежить в основі цифри 70 разів, використовував певний набір з 52 файлів (публічні репозиторії Карпаті, 5 наукових статей, 4 діаграми), а у корпоративних кодбазах із простими структурами пакетів або величезними монорепозиторіями економія на токенах сильно варіюється.
Які недоліки виправдовують використання будь-якого інструменту
Ажіотаж не є архітектурною вимогою, так само як і нечітке незадоволення поточною конфігурацією RAG. Новій інфраструктурі потрібен конкретний, спостережуваний спосіб виникнення проблем.
Спочатку перевірка реальності
Дослідження в усій галузі показують, що частка корпоративних рішень RAG, які не виконали своїх функцій або повністю зазнали невдачі протягом року, становить 72%. Більшість цих невдач спричинені поганою структуризацією даних, застарілими векторними індексами чи непідходящими моделями вбудовування інформації, а не відсутністю бази даних у вигляді графа. Додавання графа знань до несправної системи пошуку призводить до того, що система залишається несправною, а ще й додається обов’язок її обслуговування.
┌─────────────────────────────────────────┐
│ 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)
Причина номер один: збої у багатокроковому міркуванні (додати Graphify)
Ця проблема виникає, коли відповідь залежить від поєднання фактів з кількох файлів, які ніколи не містять спільних фрагментів тексту.
Типовий симптом: агент не може відповісти на запитання на кшталт "що зламається у рівні API, якщо зміниться схема у файлі db/migrations/04_users.sql?"
Оскільки метод vector RAG інкорпорує кожен блок незалежно, він нічого не знає про посилання на інші таблиці, реалізацію інтерфейсів чи виклики між файлами. Кращі запити чи більші вікна контексту не допоможуть, адже ці зв’язки ніколи не потрапляють у векторний простір.
Причина номер два: розрізнені корпоративні знання (додати OKF)
Ця проблема виникає, коли важливий інституційний контекст розкиданий по каналах Slack, застарілих сторінках wiki та неписаній пам’яті розробників.
Симптомом тут є агент, який пише синтаксично коректний код, але порушує внутрішні архітектурні принципи, використовує застарілі внутрішні API чи ігнорує бізнес-правила, специфічні для певної галузі.
Graphify не може допомогти, оскільки парсери AST читають лише вихідний код та не можуть визначити бізнес-наміри. OKF заповнює цю прогалину легкою структурою у форматі Markdown із версіонуванням через Git, де інженери записують стабільні системні конвенції, які агенти можуть надійно обробляти.
Дослідження RAG у юридичній галузі показали, що стандартні інструменти пошуку створюють хибні результати у 17%–33% випадків складних запитів, оскільки сам пошук не моделює логіку, яка поширюється на кілька документів. Рекомендації Atlan узагальнюють розумний порядок дій: спочатку RAG, а граф — тоді, коли глибина стає перешкодою.
Скільки коштує кожен інструмент у разі збою
Кожен доданий шар приносить з собою власні способи збою. Обидві проекти ще молоді, тому їхні операційні ризики потребують уваги перед впровадженням у виробництво.
Де Graphify поступається
- Старі знімки стану. Індекс графа створюється один раз та залишається статичним. Він не оновлюється під час редагування файлів розробниками, тому без хука pre-commit у Git або кроку CI/CD він відхиляється від коду. Старий структурний граф гірший, ніж його відсутність, оскільки агент отримує неправильні відповіді на основі застарілих даних.
- Шумні спільноти у легасі-монолітах. У великих додатках на Java чи C++ алгоритми виявлення Leiden часто об’єднують нерелевантні модулі лише через те, що всі вони використовують спільну інфраструктуру, таку як механізми логування чи телеметрії.
- Галюцинації під час семантичного збагачення. Основний етап обробки коду є детермінованим, але необов’язковий етап аналізу документації, PDF-файлів та зображень все одно використовує LLM. Тому взаємозв’язки, вилучені з некодових матеріалів, можуть бути хибними.
- Неперевірені твердження. За словами архітектора програмного забезпечення Саураба Шарми, ніхто поза проектом не відтворив порівняння запитів Graphify з необробленими файлами чи базових результатів RAG на спільному наборі даних для тестування. Цифри від виробників краще розглядати як приблизні орієнтири.
Де OKF не відповідає стандартам
- Відсутність контролю чи перевірки. Формат навмисно не передбачає реєстрів схем та суворих правил, тому якість пакету повністю залежить від того, хто саме пише ці файли.
Комбінований конвеєр у практиці
Для складних корпоративних кодових баз найкраща налаштовка на 2026 рік — це не вибір одного інструменту, а їх поєднання у багатоетапний конвеєр обробки даних.
┌──────────────────────────────────────────────────────────────────┐
│ 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 │
└──────────────────────────────────────────────────────────────────┘
Крок перший: створення структурних елементів Graphify
Встановіть Graphify у ізольованому середовищі, а потім запустіть аналізатор для обробки робочого простору.
# 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
Коли це буде завершено, можна безпосередньо звертатися до локального структурного індексу для перевірки шляхів взаємозв’язків.
# Query dependency paths between components
graphify path "UserService" "DatabasePool"
# Trace architectural blast radius before refactoring
graphify query "What components depend on AuthTokenValidator?"
Другий крок: записати підготовлені концепції у форматі OKF
Експортуйте те, що було знайдено під час структурного аналізу, у пакет концепцій, сумісний з OKF, у директоріях .well-known/okf/ або docs/knowledge/. Мінімальний файл концепції використовує звичайні посилання Markdown, які безпосередньо відповідають ребрам графа знань.
---
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)
Інженер з пошуку та контексту Копп зазначає, що структура посилань OKF ідеально підходить до GraphRAG, оскільки посилання з orders_fact.md на customers.md вже є ребром у графі знань.
Дані з ERPNext
Цей комбінований підхід було протестовано на ERPNext — відкритому кодовому базисі для корпоративних проектів, який містить понад мільйон рядків коду на Python та JavaScript.
Під час оцінювання використовувався Claude Opus 4.8 із обмеженням у 14 кроків на завдання:
- Базовий агент для кодування, який використовував технології vector RAG та grep, досяг 70,8% покриття ключових фактів.
- Гібридний підхід Graphify та OKF досяг 82,0% покриття ключових фактів, з середньою кількістю близько 140 000 токенів на сеанс запиту.
Підвищення на 11,2 бали для кодової бази такого розміру означає значно меншу кількість помилок під час виконання агентами. Це краще відображає реальну продуктивність, ніж цифри щодо скорочення кількості токенів.
Вибір за типом кодової бази
Знайдіть у матриці середовище вашої кодової бази та основний спосіб її збою, щоб обрати відповідну архітектуру.
Короткий варіант
Graphify є найефективнішим для детерміністичного структурного аналізу без витрат на API LLM. OKF пропонує портативний, сумісний з Git стандарт для контексту, створеного як людьми, так і агентами. Vector RAG залишається найкращим варіантом для пошуку у неструктурованому тексті. Накопичення шарів без чіткого механізму усунення збоїв ускладнює ситуацію та не покращує продуктивність агентів.
Спочатку визначте проблему
Перш ніж Graphify чи OKF потраплять у процес розробки, вирішіть, яка з трьох проблем є реальною: застарілий контекст коду, збої у багатоетапних залежностях чи фрагментовані інституційні знання.
Обидві інструменти є корисними доповненнями до сучасної стек-архітектури ШІ, а результати використання ERPNext демонструють реальну користь для складних кодових баз. Проте перехід від одного твіту до популярного репозиторію є підставою для суворості у підході. Ознайомтесь безпосередньо з даними у файлі BENCHMARKS.md, протестуйте потенційні архітектури на власному коді та створіть стек контексту, який відповідає вашим інженерним потребам. Початком може стати порівняння вашої конфігурації з умовами моноліту, мікросервісів чи монорепозиторію у матриці.
Пов’язана література
- Розширені можливості RAG у Milvus: гібридний пошук, HyDE, переписування запитів та їх переранжування — Крок за кроком створіть потік обробки даних RAG у Milvus: вектори типу dense та BM25, гібридний пошук RRF, фільтри метаданих, переписування запитів, технологія HyDE, розкладання даних та переранжування за допомогою крос-енкодерів.
- Корисний локальний LLM за 30 хвилин: програмування, запитання та відповіді до документів, робота з голосом — Створіть локального асистента для програмування, скрипт для пошуку в нотатках та систему роботи з голосом офлайн за допомогою Ollama, Qwen3 та Whisper.cpp, а також дізнайтеся про правила використання пропускної здатності пам’яті для вибору розміру моделі.