Если вам нужно находить похожие фрагменты документов, начинайте с Vector Database; если важны сущности, связи, многошаговые запросы и аудит — выбирайте Knowledge Graph. Для производственного AI Agent чаще всего подходит комбинация: векторный слой отвечает за широкий поиск кандидатов, а графовый слой — за проверку связей и построение объяснимого контекста.
Эта статья предназначена разработчикам, которые выбирают хранилище для RAG-приложения. Она также полезна архитекторам, которым нужно отслеживать сложные зависимости и историю решений, а также платформенным командам, оценивающим стоимость комбинированной схемы. Если вы параллельно планируете временное тестовое окружение, общие материалы для технических читателей доступны на русскоязычной странице Kvmzen.
Сначала определите тип вопроса, а не название технологии
Главная ошибка при выборе хранилища — сравнивать продукты до того, как сформулирован запрос пользователя. Вопрос «найдите похожую информацию» и вопрос «покажите цепочку причин и связанных участников» требуют разных механизмов поиска.
В чём разница между Knowledge Graph и Vector Database?
Векторная база данных ищет объекты, близкие к запросу в многомерном пространстве признаков. Обычно это означает, что текст разбивается на фрагменты, для каждого фрагмента создаётся embedding, а затем выполняется поиск ближайших векторов.
Граф знаний хранит сущности и отношения между ними. В RDF-модели данные выражаются тройками «субъект — предикат — объект», а наборы графов могут разделяться по контекстам и источникам. Это описано в официальном введении в RDF 1.1 и в спецификации наборов RDF-графов.
Поэтому базовая развилка выглядит так:
- «Какой документ похож на этот запрос?» — преимущество Vector Database.
- «Какие факты связаны с этим клиентом?» — преимущество графа знаний.
- «Какие подразделения, договоры и решения связаны одной цепочкой?» — преимущество графа.
- «Найдите похожие инструкции, даже если пользователь использует другие слова» — преимущество векторного поиска.
- «Соберите ответ из сущности, её соседей, временных ограничений и источников» — обычно нужна комбинация.
Векторный поиск не понимает отношения автоматически. Если два фрагмента используют похожую лексику, они могут оказаться рядом в выдаче даже тогда, когда между описанными объектами нет нужной связи. Граф, напротив, может вернуть путь между объектами, но не обязан хорошо находить текст, сформулированный неожиданными словами.
Структура данных определяет стоимость сопровождения
Vector Database проще запустить на неструктурированном корпусе. Типовой поток выглядит так:
- документы загружаются в конвейер;
- текст делится на фрагменты;
- для каждого фрагмента вычисляется embedding;
- embedding и метаданные записываются в индекс;
- при запросе система ищет ближайшие фрагменты;
- найденный контекст передаётся языковой модели.
Такой подход удобен для базы инструкций, внутренней документации, переписки и технических заметок. Вам не нужно заранее описывать каждую сущность и каждую связь. Достаточно определить правила разбиения текста, модель embedding, фильтры метаданных и стратегию повторной индексации.
Но простота загрузки не отменяет скрытые расходы. При изменении модели embedding обычно приходится пересчитывать векторы. При изменении текста нужно корректно удалить старую версию фрагмента, обновить метаданные и проверить, что в индексе не остались дубликаты. При слишком крупных фрагментах повышается шум, а при слишком мелких теряется контекст.
Knowledge Graph требует более строгой подготовки. Вам необходимо определить:
- типы сущностей: пользователь, договор, продукт, команда, инцидент;
- типы связей: «принадлежит», «зависит от», «заменяет», «одобрил»;
- идентификаторы, по которым одна сущность узнаётся в разных документах;
- правила разрешения дубликатов;
- атрибуты времени, источника и уровня доверия;
- процедуру удаления или пересмотра устаревшего факта.
На старте это дороже по времени и качеству данных. Зато одна корректно определённая связь может использоваться в десятках сценариев: в поиске, контроле доступа, отчётах, рекомендациях и агентной памяти.
Знания в графе нужно полностью извлекать из каждого документа?
Нет. Это зависит от задачи. Для простого RAG обычно достаточно индексировать текст и несколько устойчивых метаданных. Для графовой архитектуры необязательно извлекать все возможные отношения: лучше начать с тех связей, которые участвуют в принятии решений.
Например, в системе поддержки можно сначала моделировать только четыре типа фактов:
- клиент связан с организацией;
- организация использует продукт;
- инцидент затрагивает продукт;
- решение инцидента подтверждено специалистом.
Такой ограниченный граф полезнее, чем большой набор автоматически извлечённых связей без контроля качества.
Многошаговые запросы дают графу заметное преимущество
Многошаговой запрос требует не просто найти похожий текст, а последовательно перейти от одной сущности к другой. Допустим, руководитель спрашивает: «Какие поставщики затронуты изменением компонента, если компонент используется в заказах клиентов из регулируемого сегмента?»
Здесь нужно пройти несколько уровней:
- найти изменённый компонент;
- определить продукты, в которых он используется;
- связать продукты с заказами;
- отфильтровать клиентов по сегменту;
- вернуть поставщиков и подтверждающие источники.
Vector Database может найти фрагменты про компонент, продукты и поставщиков. Однако она не гарантирует, что найденные фрагменты относятся к одной и той же цепочке. Модель может получить правдоподобный, но логически смешанный контекст.
Knowledge Graph позволяет задать условия перехода между узлами и проверить, существует ли нужный путь. В графовой базе базовыми сущностями являются узлы, отношения и пути; это отражено в официальном руководстве по основным понятиям графовых запросов. Для подобных задач важен не сам факт близости текста, а существование конкретной последовательности отношений.
Почему многошаговые вопросы плохо решаются одним векторным поиском?
Потому что векторная близость не равна логической связанности. Поиск может вернуть правильные отдельные факты, но не доказать, что они соединяются в нужном порядке. Если ответ зависит от нескольких переходов, вам придётся добавлять отдельный этап идентификации сущностей, фильтрации, проверки источников и сборки пути.
Это не означает, что Vector Database бесполезна для сложных запросов. Она хорошо подходит для первичного поиска документов и фрагментов, из которых затем извлекаются сущности. Проблема появляется, когда вы используете её выдачу как готовое доказательство связи.
Хороший пример — история решений в AI Memory. Векторный слой быстро найдёт похожие прошлые обсуждения, но графовый слой сможет проверить, какая команда приняла решение, к какому проекту оно относилось, какие ограничения действовали на тот момент и было ли решение позже отменено.
Объяснимость, права доступа и удаление данных
Для корпоративной системы недостаточно получить хороший ответ. Вы должны понимать, откуда он взялся, какие данные использованы и имеет ли пользователь право их видеть.
В Vector Database результат обычно сопровождается идентификатором фрагмента, расстоянием, ссылкой на документ и метаданными. Это позволяет построить цитирование, но не всегда показывает логическую цепочку. Если один документ описывает проблему, второй — ограничение, а третий — исключение, пользователю приходится самостоятельно сопоставлять эти части.
В Knowledge Graph путь может быть частью результата: сущность A связана с сущностью B через отношение C, а каждый узел или переход имеет источник, дату действия и владельца. В RDF наборы могут разделяться на именованные графы, которые представляют разные контексты или источники. Это удобно для хранения происхождения фактов и раздельного управления наборами данных.
Контроль доступа тоже требует аккуратного проектирования. Графовая система может разделять права на обнаружение узлов, чтение свойств и прохождение отношений. В документации по правам чтения эти уровни описаны отдельно: пользователь может иметь право найти сущность, но не читать конкретное свойство.
Векторный слой часто фильтрует доступ по метаданным: организация, проект, отдел, уровень конфиденциальности. Это работает только при условии, что фильтр применяется до формирования контекста, а не после передачи найденных фрагментов языковой модели.
В комбинированной архитектуре идентификатор документа, фрагмента, сущности и графового узла должен быть связан явно. Если векторный результат нельзя однозначно сопоставить с узлом графа, проверка доступа и источника становится предположением.
При удалении персональных или конфиденциальных данных также возникают разные риски. В Vector Database требуется удалить все связанные embeddings и проверить кэш, резервные копии и производные индексы. В графе нужно удалить сам факт, его альтернативные версии, связи и иногда агрегированные представления. Поэтому политика жизненного цикла должна быть общей для обоих слоёв.
Производительность нужно измерять на одной рабочей нагрузке
Нельзя честно объявить одну технологию «быстрее» без одинакового набора данных, одинаковых запросов, одинакового оборудования и одинакового уровня качества результата. Скорость индекса на маленьком корпусе ничего не говорит о поведении при сложной фильтрации и частых обновлениях.
Для Vector Database отдельно измеряйте:
- время вычисления embedding;
- время загрузки и построения индекса;
- задержку поиска кандидатов;
- полноту выдачи после фильтрации;
- стоимость вызовов embedding-модели;
- время повторной индексации изменённых документов.
Для Knowledge Graph измеряйте:
- время извлечения сущностей и отношений;
- долю ошибок нормализации сущностей;
- задержку одношагового и многошагового запроса;
- размер индекса после добавления связей;
- стоимость проверки и исправления фактов;
- время построения ответа с указанием пути и источников.
У векторных индексов тоже есть параметры, которые влияют на компромисс между скоростью и полнотой. Например, документация расширения для PostgreSQL описывает IVFFlat как индекс, который делит векторы на списки и ищет только в ближайших списках. Параметр числа проверяемых списков влияет на полноту и скорость. Для HNSW в той же документации указано значение ef_search по умолчанию, равное 40. Эти параметры нельзя переносить между разными системами без повторного тестирования. Подробнее смотрите официальное описание IVFFlat, HNSW и настройки поиска.
Ещё один проверяемый показатель — объём хранения. Для типа vector в документации указана формула 4 × число измерений + 8 байт на один вектор без учёта служебных структур индекса. Это не итоговая стоимость системы: к ней добавляются метаданные, индексы, репликация, резервное копирование и исходный текст. Но формула помогает заранее оценить порядок нагрузки.
Графовые запросы имеют другой профиль. Большое количество соседей, длинные пути и слабые ограничения могут резко увеличить объём промежуточных результатов. Поэтому в запросах нужно задавать максимальную глубину, разрешённые типы связей, временной диапазон и лимит узлов.
Первая проверка: зафиксируйте шесть измеримых критериев
Перед выбором хранилища составьте небольшой тестовый набор. Он должен включать не только удобные вопросы, но и случаи, где архитектура может ошибиться.
Проверяйте шесть метрик:
- Качество первичного поиска. Находит ли система нужные фрагменты при перефразировании запроса?
- Связность результата. Относятся ли найденные факты к одной сущности, проекту или цепочке?
- Многошаговая точность. Корректно ли система проходит два и более отношения?
- Объяснимость. Может ли ответ показать источник, путь, дату и основание выбора?
- Стоимость обновления. Что происходит при изменении одного документа или факта?
- Операционная сложность. Сколько компонентов нужно резервировать, мониторить и восстанавливать?
Соберите три группы запросов:
- семантические: «найдите похожие инструкции»;
- сущностные: «что известно об этом клиенте»;
- многошаговые: «какие решения повлияли на этот проект и кто их утвердил».
Оценивайте не только правильность финального ответа. Отдельно фиксируйте полноту источников, ложные связи, пропущенные ограничения и время каждого этапа.
Решение зависит от сценария, а не от полноты архитектуры
Ниже — рабочая матрица, которую можно использовать на этапе архитектурного отбора.
| Сценарий | Vector Database | Knowledge Graph | Рекомендуемое решение |
|---|---|---|---|
| Простые вопросы по документам | Быстрый старт и хороший поиск похожего текста | Избыточна при отсутствии устойчивых связей | Vector Database |
| Персональная память AI Agent | Находит похожие эпизоды и предпочтения | Хранит стабильные факты, связи и историю изменений | Комбинация |
| Сложные отношения и многошаговое рассуждение | Даёт кандидатов, но требует проверки | Удобна для путей, ограничений и зависимостей | Knowledge Graph или комбинация |
| Регуляторный аудит | Нужны строгие метаданные и цитирование | Проще представить происхождение и цепочку фактов | Knowledge Graph с текстовым слоем |
| Быстрый PoC с неструктурированными данными | Минимум предварительного моделирования | Требует схемы и нормализации | Vector Database |
| Большой корпус с вопросами «по всей коллекции» | Может пропустить глобальные темы | Помогает агрегировать сущности и сообщества | Комбинация или GraphRAG |
Проект GraphRAG показывает именно такой гибридный подход: конвейер извлекает сущности, отношения и утверждения из текста, строит сообщества, создаёт сводки и одновременно формирует векторные представления. В документации описаны локальный поиск по конкретным сущностям, глобальный поиск по сводкам сообществ и базовый векторный поиск. Смотрите описание индексатора GraphRAG и обзор режимов поиска.
Можно ли использовать Knowledge Graph и Vector Database вместе?
Да, и для AI Agent это часто наиболее практичный вариант. Но роли слоёв должны быть разделены заранее:
- Vector Database выполняет широкий первичный поиск по тексту и похожим эпизодам.
- Из найденных фрагментов извлекаются идентификаторы сущностей.
- Knowledge Graph проверяет отношения, права, временные условия и допустимые пути.
- Исходные фрагменты возвращаются в контекст модели как доказательства.
- Финальный ответ содержит ссылки на документы и, где нужно, объяснение цепочки.
Не стоит строить граф ради каждого абзаца. Если у вас несколько сотен простых документов, фиксированные типы вопросов и нет требований к отношениям, графовая схема может добавить больше обслуживания, чем пользы.
Когда Knowledge Graph действительно не нужен?
Он не нужен, если ваши запросы в основном сводятся к поиску похожих инструкций, краткому пересказу документов или подбору примеров по теме. Также от него можно отказаться, если команда не готова поддерживать словарь сущностей, правила разрешения дубликатов и процесс исправления неверных связей.
Не внедряйте граф только потому, что он выглядит более «архитектурно зрелым». Сначала измерьте ошибки обычного RAG. Если проблемы связаны с плохим разбиением текста, отсутствием фильтров или слабым качеством embedding, граф не устранит первопричину.
Пошаговая проверка на собственных данных
Шаг 1. Зафиксируйте типы запросов
Составьте набор из 30–50 реальных вопросов, разделив их на семантические, сущностные, многошаговые и аудиторские. Число 30–50 здесь является рекомендуемым размером тестовой выборки, а не универсальным нормативом: если у вас есть история обращений, используйте её вместо искусственных примеров.
Шаг 2. Определите единицу результата
Для векторного слоя результатом может быть фрагмент документа с источником и метаданными. Для графового слоя — путь, список узлов, утверждение с датой действия и ссылка на источник. Если вы не определите формат результата заранее, сравнение будет субъективным.
Шаг 3. Запустите базовый векторный прототип
Используйте одинаковую модель embedding для индексации и запросов. Запишите размер фрагмента, правило перекрытия, фильтры и параметр количества кандидатов. Не меняйте сразу несколько переменных: иначе вы не поймёте, что именно улучшило выдачу.
Шаг 4. Выделите минимальную схему графа
Выберите только сущности и отношения, которые нужны для ответов. Для каждой связи добавьте источник, дату извлечения, дату действия и уровень доверия. Если связь невозможно подтвердить исходным фрагментом, не передавайте её модели как установленный факт.
Шаг 5. Проверьте разрешение сущностей
Проверьте, что «Московский офис», «офис в Москве» и внутренний идентификатор подразделения не превращаются в три независимых узла. Ошибки идентификации часто вреднее, чем отсутствие части связей: неверная связь создаёт убедительный, но ложный путь.
Шаг 6. Соберите гибридный маршрут
Для каждого запроса определите, какой слой начинает поиск. Семантический запрос может идти напрямую в Vector Database. Запрос по известной сущности может начинаться с графа. Сложный вопрос может использовать векторный поиск для обнаружения документов, а граф — для проверки цепочки.
Шаг 7. Проведите нагрузочное и качественное сравнение
Измеряйте задержку, полноту, число ложных связей, стоимость вызовов моделей и трудоёмкость обновления. Сравнивайте решения только на одном наборе данных. Результаты, полученные на разных корпусах, нельзя превращать в универсальный рейтинг технологий.
Шаг 8. Проверьте удаление и права доступа
Удалите тестовый документ и убедитесь, что его фрагменты, embeddings, графовые факты, кэш и резервные копии обрабатываются по единой политике. Затем проверьте пользователя, который имеет право видеть документ, но не имеет права видеть связанную конфиденциальную сущность.
Роль AI Memory в производственном Agent
Для AI Memory обычно полезно разделять воспоминания по стабильности. Событийные записи, похожие диалоги и текстовые эпизоды хорошо подходят для векторного поиска. Устойчивые факты — должность пользователя, принадлежность к проекту, ограничения, зависимости и подтверждённые предпочтения — удобнее хранить как структурированные сущности и связи.
Такой подход не требует помещать каждый разговор в граф. Векторный слой отвечает на вопрос «что было похоже на текущую ситуацию», а графовый — «какие факты считаются связанными и действующими сейчас». Временные атрибуты особенно важны: предпочтение пользователя, актуальное шесть месяцев назад, не обязательно должно использоваться сегодня.
Если вы проектируете долговременную память агента, сначала определите политику записи, исправления, забывания и подтверждения фактов. Для тестового окружения можно использовать временную аренду Mac и проверить одинаковый набор запросов на собственном коде и данных без покупки отдельного оборудования. Если нужна дополнительная информация о рабочем окружении для таких экспериментов, её можно найти в русскоязычном разделе Kvmzen.
Итоговый выбор для команды
Выбирайте Vector Database, когда главная задача — быстро находить похожий текст, запускать RAG-прототип и работать с неструктурированными документами без тяжёлой схемы.
Выбирайте Knowledge Graph, когда ответ зависит от сущностей, отношений, временных ограничений, многошаговых переходов и аудита происхождения фактов.
Выбирайте комбинацию, когда агент должен одновременно находить релевантные фрагменты, помнить устойчивые факты, проверять отношения и формировать объяснимый ответ. Но внедряйте её поэтапно: сначала измерьте базовый векторный поиск, затем добавьте только те графовые связи, которые исправляют конкретные ошибки.
Если текущая система построена только на Vector Database, её слабые места обычно проявляются в смешении сущностей, непроверенных многошаговых выводах и сложном контроле доступа. Если вы сразу строите полноценный граф, основными проблемами становятся длительная подготовка схемы, нормализация данных и стоимость поддержки. Для временного PoC или проверки новой архитектуры рациональнее использовать отдельную тестовую среду и прогнать одинаковый набор запросов на своём коде и данных. Это позволит проверить, действительно ли вам нужен графовый слой, прежде чем превращать эксперимент в постоянную эксплуатацию.