Создание графа знаний из кода с помощью Graphify
Разбираем Graphify: инструмент для построения графа знаний из исходного кода, документации и схем без использования векторных баз данных.
Как Graphify превращает код в знания
Принцип работы на основе AST
Чтобы понять, как Graphify извлекает смыслы, нужно перестать смотреть на код как на набор текстовых строк. Для обычного LLM-агента код — это просто большой массив токенов, в котором легко потерять контекст при глубокой вложенности. Graphify подходит к задаче иначе: он использует абстрактное синтаксическое дерево (AST).
Процесс выглядит так: инструмент парсит исходный код и строит дерево, где каждый узел — это конкретный элемент языка: объявление функции, класс, переменная или вызов метода. Вместо того чтобы пытаться «угадать» связи между файлами через семантический поиск, Graphify фиксирует их структурно. Если функция calculate_metrics вызывается в модуле analytics.py, это не просто похожесть слов, это жесткая связь в дереве.
С практической точки зрения это даёт ту самую предсказуемость, которой не хватает при работе с чистым текстом. Мы получаем не «вероятностное сходство», а точную карту зависимостей. Если вы изучаете реверс-инжиниринг с помощью AI-агентов, понимание точной структуры вызовов критически важно, чтобы агент не начал галлюцинировать несуществующими связями.
Для анализа проекта достаточно запустить парсинг, указав корень репозитория. Пример типичного процесса инициализации графа через CLI:
bash# Инициализация анализа проекта и построение AST-графа
graphify analyze ./src --output ./knowledge_graph --format json
В результате на выходе мы получаем не просто список файлов, а структурированный граф, где узлы связаны типами отношений: defines, calls, inherits или imports.
Почему отсутствие векторного хранилища — это плюс
В последнее время стало модно упаковывать всё подряд в векторные базы данных (Vector DB), превращая код в набор эмбеддингов. Это работает для поиска по смыслу, но часто проигрывает в точности, когда дело касается логики. Если вам нужно найти, где именно инициализируется объект DatabaseConnection, векторный поиск может выдать вам пять похожих по смыслу мест, но промахнуться мимо нужного.
Graphify сознательно отказывается от использования векторных хранилищ в пользу графовых структур. И вот почему это решение оправдано:
- Детерминизм вместо вероятности. В графе связь между классом и его методом либо есть, либо её нет. В векторном пространстве «близость» векторов — величина переменная, которая зависит от модели эмбеддингов и параметров поиска.
- Снижение вычислительной сложности. Вам не нужно разворачивать тяжелую инфраструктуру вроде Chroma или Pinecone, чтобы просто проанализировать небольшой проект. Это делает инструмент пригодным для использования в локальных наборах навыков для работы с AI-агентами, где важна скорость и автономность.
- Контекстная целостность. Граф позволяет выполнять обходы (traversal) по цепочке зависимостей. Вы можете спросить: «Какие функции затронет изменение этого интерфейса?», и инструмент пройдёт по связям в AST, а не будет искать похожие куски текста.
Если мы посмотрим на конфигурацию, которая управляет глубиной извлечения связей, мы увидим, что фокус смещён на топологию, а не на семантическую плотность:
yaml# Пример конфигурации графа (graphify.yaml)
extraction:
depth: 5 # Глубина обхода зависимостей
include_comments: true # Использование комментариев как метаданных для узлов
ast_rules:
- type: function_call
relation: calls
- type: class_definition
relation: defines
Такой подход делает процесс создания графа знаний из кода прозрачным. Мы получаем инструмент, который работает с кодом на уровне компилятора, а не на уровне текстового редактора. Это фундаментально меняет качество ответов агентов, так как они начинают опираться на архитектуру, а не на статистику слов.
Возможности анализа и поддерживаемые форматы
Работа с SQL-схемами и конфигурациями
Главное отличие Graphify от классических RAG-систем (Retrieval-Augmented Generation) заключается в том, что инструмент не пытается «запихнуть» код в векторное пространство. Вместо этого он анализирует структуру. Если мы говорим о базах данных, то Graphify не просто читает текст запроса, а строит связи между таблицами, ключами и типами данных.
С практической точки зрения это крайне полезно при анализе legacy-проектов, где документация отсутствует, а логика разбросана по сотням SQL-миграций. Инструмент парсит DDL-файлы и превращает их в узлы графа. Например, если у вас есть схема базы данных, Graphify свяжет таблицу users с orders через внешний ключ, создав семантическую связь, которую AI-агент сможет использовать для построения точных запросов.
Чтобы проанализировать схему, достаточно указать путь к директории с SQL-файлами в конфигурационном файле проекта. Пример базового конфига для обработки схем:
yaml# graphify-config.yaml
analysis:
sources:
- path: "./migrations/postgres"
type: "sql" # Указываем тип, чтобы задействовать SQL-парсер
- path: "./configs/nginx"
type: "config" # Анализ конфигурационных файлов
output:
format: "graphml" # Формат для последующей визуализации или загрузки в базу графов
Предсказуемость результата здесь выше, чем при использовании векторного поиска: вы точно знаете, что связь между сущностями основана на синтаксическом анализе (AST), а не на вероятностном сходстве слов. Это критично, когда вы занимаетесь реверс-инжинирингом с помощью AI-агентов в REA, где ошибка в понимании структуры данных может привести к неверным выводам.
Интеграция с документацией и PDF
Код редко существует в вакууме. Часто логика работы системы описана в PDF-спецификациях, архитектурных схемах или README-файлах. Graphify умеет извлекать сущности из неструктурированного текста и пытаться сопоставить их с объектами из исходного кода.
Если в документации упоминается «процесс авторизации через OAuth2», а в коде есть класс AuthService, инструмент создаёт связь между текстовым описанием и программной реализацией. Это позволяет превратить разрозненные файлы в единую базу знаний.
Для работы с документацией важно правильно подготовить входные данные. Если вы используете PDF, убедитесь, что текст в них доступен для выделения (не является просто набором картинок), иначе парсер не сможет извлечь семантические связи.
Пример структуры папок для комплексного анализа:
bash.
├── src/ # Исходный код (Python/Go/JS)
├── docs/ # Markdown и текстовые описания
│ └── architecture.md
├── specs/ # Спецификации в PDF
│ └── api_v2_spec.pdf
└── graphify.yaml # Конфигурация инструмента
При запуске анализа через CLI, Graphify обходит эти директории:
bash# Запуск процесса построения графа из всех указанных источников
graphify build --config ./graphify.yaml
Такой подход позволяет сформировать полноценный набор навыков для работы с AI-агентами, так как агент получает не просто куски текста, а понимание контекста: что этот код делает, как он описан в документации и как он связан с другими компонентами системы. Это фундамент для создания надежных систем, где создание графа знаний из кода с помощью Graphify становится первым шагом к автоматизации глубокого анализа инфраструктуры.
Использование Graphify в AI-инструментах
Подключение к Claude Code и Cursor
Когда мы говорим об использовании Graphify в связке с AI-инструментами, важно понимать: мы не просто даём модели «прочитать файлы». Мы предоставляем ей структурированную карту зависимостей. В таких инструментах, как Claude Code или Cursor, основной проблемой часто становится потеря контекста при разрастании кодовой базы. Векторный поиск (RAG) может найти похожий кусок кода, но он часто упускает логическую связь между объявлением интерфейса в одном модуле и его реализацией в другом.
С практической точки зрения, интеграция Graphify позволяет превратить разрозненные фрагменты кода в единую семантическую сеть. Для Claude Code это выглядит как предоставление расширенного контекста через локальный индекс.
Чтобы интегрировать Graphify в рабочий процесс с Claude Code, можно использовать подход с предварительной генерацией графа и его экспортом в формате, который агент сможет интерпретировать как «карту проекта».
Сначала сгенерируйте граф для вашего репозитория:
bash# Генерация графа знаний для текущей директории
graphify build --path ./src --output ./docs/knowledge-graph.json
После этого вы можете передать этот файл в контекст Claude Code. Это позволит агенту не гадать, как связаны компоненты, а точно следовать по путям, проложенным AST-анализом. Если вы хотите автоматизировать этот процесс, рекомендую изучить настройку GStack, которая помогает оптимизировать работу с инструментами Claude.
В Cursor интеграция происходит через использование .cursorrules. Вы можете прописать инструкцию, которая заставляет редактор при анализе сложных запросов обращаться к экспортированному графу.
Пример конфигурации в .cursorrules:
markdown# Context Awareness via Graphify
When analyzing complex architectural dependencies, always refer to `./docs/knowledge-graph.json`.
Use the relationships defined in the graph to trace function calls and class inheritance
across different modules.
Это значительно повышает предсказуемость ответов модели: вместо того чтобы предлагать правки, которые ломают зависимости в соседних модулях, Cursor будет видеть всю цепочку вызовов. Это критически важно, если вы занимаетесь реверс-инжинирингом с помощью AI-агентов, где понимание связей важнее, чем просто поиск по тексту.
Автоматизация через Gemini CLI
Если ваша задача — не интерактивная разработка, а автоматический аудит кода или генерация документации в CI/CD, то ручное использование IDE не подходит. Здесь на сцену выходит Gemini CLI.
С точки зрения системного инженера, наиболее правильный путь — это создание конвейера (pipeline), где Graphify выступает в роли этапа обогащения данных. Мы превращаем «сырой» код в структурированный граф, а затем скармливаем этот граф модели Gemini для глубокого анализа.
Предположим, нам нужно проверить проект на наличие архитектурных нарушений. Мы можем составить скрипт, который объединяет вывод Graphify и запросы к Gemini.
Пример Bash-скрипта для автоматизации:
bash#!/bin/bash
# Скрипт для автоматического аудита архитектуры
PROJECT_DIR="./my-service"
GRAPH_OUTPUT="./temp_graph.json"
echo "--- Шаг 1: Генерация графа знаний ---"
graphify build --path "$PROJECT_DIR" --output "$GRAPH_OUTPUT"
echo "--- Шаг 2: Анализ через Gemini CLI ---"
# Передаем граф и запрос на анализ архитектуры
gemini analyze \
--context "$GRAPH_OUTPUT" \
--prompt "Проверь граф на наличие циклических зависимостей между модулями и предложи способы их устранения." \
--model "gemini-1.5-pro" > audit_report.md
echo "--- Анализ завершен. Отчет: audit_report.md ---"
Такой подход позволяет избежать проблем, характерных для стандартного RAG. Вместо того чтобы пытаться «запихнуть» весь код в векторную базу, мы передаём модели уже обработанную, высокоуровневую структуру. Это экономит токены и, что важнее, снижает вероятность галлюцинаций.
Если вы планируете внедрять подобные инструменты в свои рабочие процессы, рекомендую сначала изучить базовый набор навыков для работы с AI-агентами, чтобы понимать ограничения и возможности подобных автоматизаций.
Использование Graphify в связке с LLM превращает AI из простого «умного автодополнителя» в полноценного архитектурного консультанта, который понимает структуру вашего приложения так же хорошо, как и вы.
Практическое применение для инженеров
Улучшение контекста для AI-агентов
Когда мы работаем с AI-агентами, главная проблема — это «галлюцинации» из-за неполного контекста. Если вы просите агента отрефакторить функцию в крупном монолите, он видит только этот кусок кода, но не понимает, как изменение затронет соседние модули или глобальные состояния. Традиционный подход с использованием векторных баз данных (RAG) часто подводит: поиск по сходству векторов может выдать похожий по смыслу кусок кода, который на самом деле никак не связан с текущей логикой.
Graphify решает это иначе. Вместо того чтобы скармливать агенту случайные фрагменты текста, мы передаём ему структуру. Благодаря использованию AST (Abstract Syntax Tree), инструмент строит карту связей: где объявлена переменная, какие функции её используют и как данные текут через систему.
С практической точки зрения это превращает работу агента из «угадывания» в осознанное проектирование. Если вы используете набор навыков для работы с AI-агентами, то понимаете, что качество ответа напрямую зависит от глубины контекста. С графом знаний агент может выполнить запрос вроде: «Найди все места, где использование этого интерфейса может привести к race condition».
Пример того, как можно подготовить контекст для агента, передав ему выгрузку связей из Graphify в формате JSON:
json{
"node": "UserService.createUser",
"type": "function",
"calls": [
{
"target": "Database.execute",
"relation": "dependency"
},
{
"target": "EmailService.sendWelcome",
"relation": "side_effect"
}
],
"context_depth": 2
}
Такая предсказуемость структуры позволяет агенту не просто писать код, а понимать архитектурные границы проекта.
Поиск зависимостей в сложных проектах
В больших проектах, которые годами обрастали кодом, поиск скрытых зависимостей превращается в детективную работу. Вы меняете тип аргумента в одном методе и через час обнаруживаете, что упал сервис, который, казалось бы, вообще не имеет отношения к этому модулю.
Graphify позволяет визуализировать эти связи, превращая абстрактный код в понятный граф. Это особенно полезно при проведении рефакторинга или при входе в новый проект. Вместо того чтобы вручную прочёсывать тысячи строк, вы можете построить граф зависимостей и увидеть реальную картину.
Допустим, вам нужно проанализировать влияние изменений в конкретном модуле. Сначала можно использовать CLI-интерфейс для генерации графа конкретной директории:
bash# Генерация графа зависимостей для модуля auth
graphify analyze ./src/modules/auth --output-format dot --out ./auth_graph.dot
Полученный файл .dot можно конвертировать в интерактивную визуализацию. Это помогает увидеть «узкие места» — функции или классы, которые перегружены связями и становятся критическими точками отказа.
Если ваша задача связана с глубоким анализом бинарных файлов или обфусцированного кода, где стандартные инструменты анализа не справляются, стоит изучить методы реверс-инжиниринга с помощью AI-агентов. Граф знаний здесь выступает фундаментом: он даёт агенту ту самую структурную опору, без которой любая попытка анализа превращается в гадание на кофейной гуще.
Для тех, кто хочет автоматизировать этот процесс в рамках своего рабочего окружения, полезно будет изучить настройку GStack, чтобы интегрировать подобные инструменты анализа непосредственно в цикл разработки.
Заключение
Практические выводы
Graphify — это не очередная надстройка над векторным поиском, а инструмент для тех, кому важна предсказуемость связей. Если классический RAG (Retrieval-Augmented Generation) часто галлюцинирует, потому что пытается найти «похожие» куски текста, то графовый подход опирается на жесткую структуру AST (Abstract Syntax Tree). Это критично, когда вы анализируете сложную систему, где важно не просто найти определение функции, а понять, какие зависимости она тянет за собой.
С практической точки зрения, инструмент лучше всего показывает себя в двух сценариях:
- Аудит легаси-кода: когда нужно быстро восстановить архитектурные связи в проекте, который никто не документировал годами.
- Подготовка контекста для AI-агентов: вместо того чтобы скармливать модели огромные файлы, вы передаёте ей выверенный граф, что экономит токены и снижает уровень шума.
Если вы хотите глубже разобраться в том, как подобные методы применяются в специфических задачах, рекомендую изучить материал про реверс-инжиниринг с помощью AI-агентов в REA.
Когда Graphify может не подойти
Несмотря на технологичность, у подхода с графами есть свои ограничения. Во-первых, построение графа требует вычислительных ресурсов, особенно на огромных монолитах. Если ваш проект весит десятки гигабайт, процесс индексации может занять значительное время.
Во-вторых, точность графа напрямую зависит от качества исходных данных. Если в коде много макросов (в случае с C/C++) или сложной динамической типизации, которую статический анализатор не может разрешить, граф получится неполным. В таких случаях «дыры» в структуре могут привести к тому, что AI-агент просто не увидит важную связь.
Для тех, кто планирует использовать подобные инструменты в промышленной разработке, важно понимать набор навыков для работы с AI-агентами, чтобы уметь правильно интерпретировать полученные данные.
Итоговая конфигурация для старта
Чтобы не тратить время на чтение документации, я подготовил базовый пример того, как запустить процесс анализа локального репозитория. Для работы убедитесь, что у вас установлен Python 3.10+ и настроены переменные окружения для доступа к LLM.
Сначала создайте конфигурационный файл graphify.yaml, чтобы зафиксировать правила парсинга:
yaml# Конфигурация для анализа проекта
project_path: "./my-cool-app"
output_format: "jsonl" # Формат для последующей загрузки в базу знаний
parser_settings:
include_comments: true # Важно для извлечения контекста из документации
depth: 3 # Глубина анализа зависимостей
exclude_dirs:
- "node_modules"
- "tests"
- "dist"
Затем запустите индексацию через терминал:
bash# Запуск построения графа из локальной директории
graphify index --config graphify.yaml --model claude-3-5-sonnet
После завершения вы получите структурированный файл, который можно использовать как фундамент для создания собственной базы знаний или интеграции в инструменты Claude Code. Помните: граф — это лишь карта, а понимание территории всё равно остаётся за инженером.
FAQ
Как Graphify понимает связи в коде?
Инструмент не просто ищет текстовые совпадения, а работает на уровне абстрактного синтаксического дерева (AST). Когда Graphify сканирует проект, он разбирает структуру файлов, определяя, где объявлена функция, где она вызывается и какие типы данных при этом используются.
С практической точки зрения это работает так: вместо того чтобы полагаться на семантический поиск (как в RAG-системах), инструмент строит жесткие логические связи. Если в одном файле вы определили класс DatabaseConnector, а в другом его вызываете, Graphify создаст ребро в графе, соединяющее эти узлы. Это обеспечивает предсказуемость: вы всегда можете отследить цепочку зависимостей, что критически важно, если вы занимаетесь реверс-инжинирингом с помощью AI-агентов в REA.
Нужно ли разворачивать отдельную базу данных?
Нет, в этом и заключается одно из главных преимуществ архитектуры Graphify — отсутствие необходимости в тяжеловесных векторных базах данных. Инструмент хранит структуру графа локально или в легковесных форматах, что упрощает настройку GStack: инструменты Claude Code от Гарри Тана и другие подобные связки.
Для работы достаточно иметь установленный runtime и доступ к исходникам. Если вы хотите проверить, как инструмент видит ваш проект, можно запустить индексацию через CLI:
bash# Запуск индексации текущей директории без поднятия внешних БД
graphify index ./src --output ./knowledge-graph.json
Такой подход позволяет избежать лишних накладных расходов на инфраструктуру, что особенно ценно при работе в рамках домашней лаборатории.
Какие IDE поддерживают этот инструмент?
На текущий момент Graphify позиционируется прежде всего как CLI-инструмент, который предоставляет данные для других систем. Однако его легко интегрировать в рабочее окружение через расширения для VS Code или JetBrains, если использовать промежуточный слой, который читает сгенерированный JSON-граф.
Если вы строите свой набор навыков для работы с AI-агентами, рекомендую настроить автоматическую генерацию графа при каждом коммите. Это можно сделать через простой pre-commit hook:
yaml# Пример конфигурации .pre-commit-config.yaml
repos:
- repo: local
hooks:
- id: graphify-update
name: Update Knowledge Graph
entry: graphify index ./src
language: system
files: \.(py|js|go|ts)$
Можно ли анализировать не только код, но и документацию?
Да, Graphify умеет объединять разные типы данных в единую структуру. При индексации вы можете указать пути к Markdown-файлам или схемам архитектуры. Инструмент сопоставит текстовые описания из документации с реальными именами функций и классов из AST.
Например, если в вашем README.md написано, что «модуль auth отвечает за проверку токенов», Graphify попытается найти связь между этим утверждением и соответствующим кодом. Это превращает разрозненные файлы в целостный граф знаний из кода с помощью Graphify, где документация служит дополнительным слоем контекста для AI-агентов.
Часто задаваемые вопросы
Чем Graphify отличается от классического RAG с векторными базами данных
В традиционном RAG поиск строится на семантической близости векторов, что часто приводит к ошибкам, когда модель находит похожие по смыслу, но структурно несвязанные фрагменты кода. Graphify использует AST для фиксации жестких связей: если одна функция вызывает другую, это отражается в графе как точная зависимость, а не как вероятность. С практической точки зрения это избавляет от необходимости разворачивать тяжеловесные векторные хранилища и снижает риск галлюцинаций при анализе архитектуры.
Можно ли использовать Graphify для анализа документации вместе с кодом
Да, инструмент позволяет объединять программный код и текстовую документацию в единую структуру знаний. При парсинге документации Graphify пытается сопоставить текстовые описания с узлами AST, создавая мост между тем, что написано в README, и тем, как это реализовано в функциях или классах. Это помогает получить более целостную картину проекта, где документация выступает не просто набором файлов, а частью общего графа зависимостей.
Какие форматы вывода поддерживает инструмент для интеграции в другие системы
По умолчанию Graphify генерирует результат в формате JSON, что удобно для последующей обработки скриптами или передачи в другие инструменты анализа. Структура JSON содержит четкое описание узлов и типов отношений, таких как calls или inherits, что позволяет легко импортировать эти данные в специализированные графовые базы данных, например, Neo4j. Если вам нужно визуализировать связи, полученный JSON можно преобразовать в формат, поддерживаемый библиотеками вроде D3.js или Cytoscape.
Насколько глубоко инструмент анализирует зависимости внутри больших репозиториев
Глубина анализа зависит от сложности AST-дерева, которое строится на основе синтаксиса языка. Инструмент проходит по всем вложенным структурам, фиксируя связи между определениями и вызовами на всех уровнях иерархии. Однако стоит учитывать, что при работе с экстремально большими монолитами время парсинга может расти, поэтому для оптимизации процесса рекомендуется указывать конкретные директории через аргументы CLI, ограничивая область анализа только необходимыми модулями.