Графовая или векторная БД - что выбрать под задачу?

Графовая и векторная базы данных решают разные классы задач, хотя обе часто появляются рядом с ИИ и поиском. Граф хранит сущности и связи: «кто с кем связан», «какой путь короче», «какие узлы образуют сообщество». Векторное хранилище держит эмбеддинги и ищет похожие фрагменты по смыслу. В 2026 году ошибка выбора дорого обходится: неправильный тип БД тянет за собой слабое извлечение, лишнюю инфраструктуру, переписывание пайплайна и незапланированные месяцы разработки сверх бюджета.

• Графовая БД - связи, пути, зависимости, граф знаний, fraud / рекомендации по графу
• Векторная БД - семантический поиск, RAG, похожие документы, изображения, код
• Не взаимозаменяемы - граф не заменяет ANN-поиск, векторы не заменяют обход рёбер
• Гибрид - часто лучший ответ: граф для структуры, векторы для смысла
• Выбор - от вопроса, который система должна отвечать стабильно

В чём разница на уровне модели данных

Графовая БД (Neo4j, Amazon Neptune, Memgraph, JanusGraph и др.) моделирует мир как узлы и рёбра. Запрос обычно звучит как: «найди все компании, связанные с этим человеком через не более чем N шагов» или «покажи цепочку поставок до поставщика X».

Векторная БД (Qdrant, Pinecone, Chroma, Weaviate, pgvector и др.) хранит dense-векторы и отвечает на запрос «найди Top-K ближайших по cosine / Euclidean (метрикам сходства векторов)». Текст, картинка или кусок кода превращаются в эмбеддинг; смысл важнее точного совпадения слов.

Коротко:

Что это значит для владельца бизнеса

Выбор БД - не только техническое решение, а статья бюджета и сроков. Отдельная графовая или векторная СУБД - это ещё один сервис в инфраструктуре, навыки, которых может не быть в команде, и дополнительная нагрузка на поддержку. Прежде чем утверждать проект, спросите у команды: какую бизнес-задачу решает база (поиск, рекомендации, антифрод), сколько стоит её эксплуатация и можно ли сначала проверить гипотезу на более простом и дешёвом решении.

Когда нужна графовая БД

Берите граф, если ценность в связях, а не только в содержимом документов:

• граф знаний продукта, оргструктуры, нормативно-справочных данных;
• fraud detection и антифрод: цепочки счетов, устройств, адресов;
• рекомендации «люди, которые купили X, также связаны с Y через Z»;
• зависимости в коде, инфраструктуре, поставках, правах доступа;
• вопросы вида «через сколько хопов» и «какие общие соседи».

Признаки, что граф уместен:

1. В ТЗ часто встречаются слова «связь», «цепочка», «зависимость», «путь», «сообщество».
2. Ответ нельзя получить одним поиском по id или одним SQL JOIN без боли.
3. Данные естественно выглядят как сеть, а не как плоская таблица документов.

Не берите граф «потому что модно», если задача - чат по PDF и wiki. Для RAG граф сам по себе не даст семантический поиск.

Когда нужна векторная БД

Берите векторы, если ценность в смысловом сходстве:

• RAG по документации, договорам, тикетам, базе знаний;
• семантический поиск по каталогу, коду, логам, медиа;
• дедупликация и поиск похожих сущностей по тексту/изображению;
• рекомендательные сценарии на эмбеддингах контента;
• ассистенты, где LLM отвечает по найденному контексту.

Признаки, что векторная БД уместна:

1. Пользователь формулирует запрос свободно, не зная точных терминов.
2. Нужен Top-K релевантных фрагментов за сотни миллисекунд.
3. Качество сильнее зависит от нарезки на фрагменты и модели эмбеддингов, чем от схемы связей.

Не заменяйте граф векторами, если критичны точные отношения и многошаговый обход. «Похожие» узлы - не то же самое, что «связанные» узлы.

Типичные ошибки выбора

Ошибка 1: «Сделаем всё на векторах».
Связи «сотрудник → отдел → проект → клиент» через эмбеддинги получаются хрупкими. Модель угадывает близость, но не гарантирует путь.

Ошибка 2: «Сложим документы в граф и будет умный поиск».
Без эмбеддингов граф хорошо отвечает на структурные вопросы и плохо - на «найди похожий абзац про SLA».

Ошибка 3: Выбор движка раньше постановки вопроса.
Сначала зафиксируйте 10-20 реальных вопросов пользователей. Если большинство - про смысл текста, стартуйте с векторов. Если большинство - про связи и пути, стартуйте с графа.

Ошибка 4: Игнорировать метаданные и фильтры.
И в графе, и в векторном хранилище нужны tenant, язык, дата, тип сущности. Без них поиск «правильный по смыслу, но из чужого кабинета».

Гибридный подход: когда нужны оба

В 2026 году зрелые системы часто комбинируют оба типа:

1. Векторное извлечение находит кандидатов по смыслу.
2. Граф уточняет контекст: связанные сущности, политики, зависимости, разрешённые пути.
3. LLM получает и фрагменты текста, и структурированные факты из графа.

Типичные гибридные сценарии:

• корпоративный RAG + knowledge graph (GraphRAG-подход);
• поиск похожих инцидентов + граф зависимостей сервисов;
• рекомендации: эмбеддинги контента + граф взаимодействий пользователей;
• соответствие требованиям: семантический поиск по документам + граф прав и ролей.

Гибрид дороже в разработке и эксплуатации. Как ориентир (а не строгий порог): оправдан, когда один тип БД стабильно не закрывает примерно 20-30% ключевых вопросов.

Практическая схема выбора

Ответьте на четыре вопроса:

Короткое правило:

1. Документы и свободный язык - векторная БД.
2. Сеть сущностей и пути - графовая БД.
3. И то и другое в одном продукте - гибрид, но не с первого дня: сначала закройте основной класс вопросов.
4. Не уверены - соберите пилот: 50 вопросов, замер доли попаданий / правильности путей, стоимость и задержка.

Для многих SMB достаточно PostgreSQL + pgvector на старте и отдельного графа только когда связи станут отдельным продуктовым слоем. Для высоконагруженного RAG чаще выбирают специализированное векторное хранилище. Для антифрода и сложных связей - графовый движок.

Когда не стоит внедрять ни то, ни другое

Не берите ни графовую, ни векторную БД, если:

• обычный полнотекстовый поиск (Postgres, Elasticsearch) уже даёт приемлемый результат, а каталог или база знаний небольшие;
• в команде нет ресурса поддерживать ещё один специализированный сервис в проде;
• бизнес-вопрос ещё не сформулирован - сначала соберите реальные запросы пользователей, а не выбирайте технологию заранее;
• это MVP или пилот, где важнее скорость запуска, чем идеальная архитектура поиска.

В этих случаях правильный шаг - отложить решение и вернуться к нему, когда появится измеримая потребность.

Итог

Графовая и векторная БД - не конкуренты в одной нише, а разные инструменты. Граф отвечает на вопросы о структуре. Векторы - о смысле. Выбор под задачу начинается с формулировки вопросов, которые система должна закрывать надёжно.

Если нужен семантический поиск и RAG - берите векторную БД. Если критичны связи, пути и зависимости - графовую. Если продукт требует и то и другое - проектируйте гибрид осознанно, а не «на всякий случай».

Если нужно спроектировать пилот или выбрать между графом, вектором и гибридом под ваш продукт - свяжитесь со мной.

Часто задаваемые вопросы

Можно ли заменить графовую БД векторной?

Обычно нет. Векторы хорошо находят похожие тексты и объекты, но не гарантируют точные многошаговые связи. Для fraud, оргструктуры, зависимостей сервисов и граф знаний с жёсткими рёбрами нужен граф или хотя бы реляционная модель связей.

Можно ли делать RAG только на графовой БД?

Плохо как единственный слой извлечения. Граф полезен для структурированных фактов и обхода связей, но семантический поиск по свободным вопросам почти всегда требует эмбеддингов. На практике GraphRAG = граф + векторы, а не «только Neo4j вместо Qdrant».

С чего начать, если нужны и связи, и смысловой поиск?

С доминирующего класса вопросов. Если 70% запросов - «найди похожий документ/ответ», сначала векторное хранилище и метаданные. Если 70% - «покажи цепочку и зависимости», сначала граф. Гибрид подключайте, когда пилот упирается в пробел второго типа.

Neo4j или Qdrant - что ближе для корпоративной базы знаний?

Зависит от сценария. FAQ и поиск по регламентам - ближе Qdrant/векторный стек. Карта процессов, ролей, систем и их связей - ближе Neo4j/граф. Часто в KB нужны оба слоя: векторы для текста, граф для модели предприятия.

Достаточно ли PostgreSQL вместо отдельной графовой и векторной БД?

На старте - часто да. pgvector закрывает умеренный семантический поиск; связи можно держать в таблицах и рекурсивных CTE. Отдельные движки оправданы при росте объёма, сложных traversal, жёстких SLA по ANN-поиску или когда граф/векторы становятся ядром продукта, а не вспомогательной функцией.

Термины в статье

эмбеддинги — embeddings — числовые векторы, отражающие смысл текста

RAG — Retrieval-Augmented Generation — генерация с дополненным поиском

ANN-поиск — ANN search — приближённый поиск ближайших соседей по векторам

top-k — keep only the k most likely next tokens when sampling — при генерации оставляют только k самых вероятных токенов

LLM — Large Language Model — большая языковая модель

SLA — Service Level Agreement — соглашение об уровне обслуживания

tenant — isolated customer account in a shared platform — изолированный клиент на общей платформе

knowledge graph — network of entities and relations for structured facts — сеть сущностей и связей для структурированных фактов

SMB — Small and Medium Business — малый и средний бизнес

MVP — Minimum Viable Product — минимально жизнеспособный продукт

GraphRAG — RAG that combines graph relations with vector search — RAG, который сочетает граф связей и векторный поиск

Qdrant — vector database for similarity search — векторная БД для поиска по сходству