Graphify, OKF и RAG: какой слой контекста необходим вашему кодовому базису
Результаты тестирования показывают, что Graphify демонстрирует такую же точность, как и векторный RAG. Вот как Graphify, OKF от Google и векторный RAG взаимосвязаны, а также факторы, приводящие к сбоям, и матрица принятия решений.
Собственный файл тестирования Graphify содержит результат, который часто игнорируется в всей этой ажиотажной рекламе проекта. По точности ответов на вопросы он соперничает с технологией dense vector RAG, но уступает ей немного по показателю воспроизводимости. Тем не менее в блогах разработчиков его называют «убийцей RAG», и именно в том же месяце корпоративные команды начали использовать его вместе с форматом Open Knowledge Format (OKF) от Google в своих ИИ-агентах для программирования. Почему?
Потому что текущее восприятие ситуации ошибочно. Graphify и OKF не конкурируют друг с другом за замену технологии RAG. Оба представляют собой специализированные компоненты — один структурный, другой повествовательный — которые дополняют векторный индекс, причем каждый из них нужен лишь для решения определенных проблем в системе. Если считать их заменой RAG, это приведет к трате времени инженеров на поддержку графов знаний и специально подготовленных пакетов Markdown для проблем, у которых их вообще нет.
Далее рассматривается функция каждого слоя, почему настоящим преимуществом 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 по скорости поиска. По точности он сопоставим с векторными системами RAG, но его создание обходится значительно дешевле, чем у других систем хранения данных. Его преимущества объясняются двумя факторами:
- Низкая стоимость загрузки, поскольку парсинг AST совсем не требует вызовов API больших языковых моделей.
- Структурный извлечение без риска галлюцинаций, поскольку детерминистический парсер 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 community detection для выделения естественных подсистем и отмечает «боговские узлы» — крайне центральные файлы, взаимодействующие со многими модулями.
Выполнение команды /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.
- 15 июня 2026 года: Каталог знаний от Google Cloud теперь нативно обрабатывает пакеты OKF и передаёт их в корпоративные ИИ-агенты.
- 1 июля 2026 года: появляется набор инструментов для взаимодействия Graphify и OKF в обоих направлениях. Графы кода Graphify экспортируются в виде маркдовых каталогов OKF с использованием механизма постепенного раскрытия информации; это позволяет сократить использование токенов запросов примерно в 71,5 раз по сравнению с чтением сырых файлов.
- 5 июля 2026 года: у проекта Graphify уже почти 78 000 звёзд, и технические публикации, включая Level Up Coding, начинают ставить под сомнение заявления об его высокой эффективности.
Андрус, писавший в период этого тщательного анализа, отметил, что достижение экономии в 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, устаревшим страницам вики и неписаным знаниям разработчиков.
Симптомом здесь является агент, который пишет синтаксически корректный код, нарушающий внутренние архитектурные принципы, использует устаревшие внутренние API или игнорирует специфические для домена бизнес-правила.
Graphify не может помочь, поскольку парсеры AST читают только исходный код и не могут выявить бизнес-намерения. OKF заполняет этот пробел с помощью легкой структуры Markdown с версионированием через Git, в которой инженеры записывают стабильные системные конвенции, позволяющие агентам их надежно парсить.
Исследования в области RAG для юридических доменов показали, что стандартные инструменты поиска выдумывают ответы на 17–33% сложных запросов, поскольку один лишь поиск не способен моделировать логику, распространяющуюся на несколько документов. Рекомендации Atlan обобщают разумный порядок действий: сначала RAG, а графы — тогда, когда глубина становится узким местом.
Сколько стоит каждый инструмент при сбоях
Каждый добавляемый слой приносит с собой собственные способы сбоев. Оба проекта находятся на ранней стадии, поэтому их операционные риски требуют внимания перед внедрением в производство.
В чём проявляются недостатки Graphify
- Устаревшие снимки состояния. Индекс графа создаётся один раз и остаётся статичным. Он не обновляется при редактировании файлов разработчиками, поэтому без хука pre-commit в Git или этапа CI/CD он отклоняется от кода. Устаревший структурный граф хуже, чем его отсутствие, поскольку агент может выдавать неверные ответы на основе устаревших данных.
- Шумные сообщества в легаси-монолитах. В крупных приложениях на Java или C++ алгоритмы обнаружения Leiden часто объединяют несвязанные модули лишь потому, что все они используют общую инфраструктуру, такую как механизмы логирования или телеметрии.
В чём проявляются недостатки OKF
- Отсутствие контроля и верификации. Формат намеренно не включает реестры схем и строгие правила, поэтому качество пакета полностью зависит от того, кто и как пишет файлы.
- Тихое ухудшение качества. Основной контракт предписывает агентам терпеть неизвестные типы метаданных и сломанные ссылки. Это ускоряет внедрение, но позволяет пакетам превращаться в неработающие, устаревшие файлы без каких-либо ошибок сборки.
- Нагрузка по техническому обслуживанию. Документация в формате Markdown требует постоянного внимания. Если рабочие процессы инженеров не предусматривают обновления 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 — open-source корпоративной платформе, содержащей более миллиона строк кода на 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, а также правила определения пропускной способности памяти для выбора размера модели.