Когда вы уже поняли, что ваши данные — это граф (связей «многие-ко-многим» больше, чем самих сущностей, и запросы идут «по цепочке»), встаёт следующий вопрос: где именно графовая СУБД оправдывает отдельную базу в эксплуатации. Neo4j — самая известная из них: модель property graph (у вершин и рёбер есть метки и свойства), запросы на языке Cypher. Разберём типовые области, где её берут, и отдельно — свежую, из-за которой про графы снова заговорили: GraphRAG для языковых моделей.
Что Neo4j делает хорошо
Одна идея объясняет все применения ниже: в графовой СУБД ребро — это прямая ссылка от вершины к вершине, а не строка в таблице связей, которую надо искать по индексу. Поэтому обход «на N шагов вглубь» стоит примерно столько, сколько реально пройдено рёбер, и почти не зависит от общего размера базы. Там, где в SQL был бы рекурсивный запрос из нескольких табличных выражений, в Cypher получается короткий шаблон связей. Neo4j выстреливает не когда данных много, а когда много запросов-обходов и они — ядро продукта.
Рекомендации
Классика: «с этим товаром часто покупают», «людям, похожим на вас, понравилось». Данные здесь естественно графовые — пользователи, товары, покупки, оценки соединены рёбрами. Рекомендация — это обход на два-три шага: от пользователя к его покупкам, от них к другим покупателям, от тех — к товарам, которых у исходного пользователя ещё нет. В Neo4j такой обход выражается коротким шаблоном и считается на лету, а не пересчитывается ночным заданием по всей базе.
Антифрод и расследования
Мошенничество почти всегда видно не в одной записи, а в связях: один и тот же телефон у десятка «независимых» аккаунтов, кольцо переводов, возвращающее деньги отправителю через цепочку счетов, общий адрес доставки у заявок, которые не должны пересекаться. Такие вопросы — «есть ли путь от счёта А к счёту Б», «сколько сущностей завязано на этот идентификатор» — это обход графа переменной глубины. Банки и платёжные системы держат под это графовую базу именно потому, что подозрительную цепочку надо находить в момент операции, а не в отчёте наутро.
Социальные графы
«Друзья друзей», «общие связи», «кратчайшая цепочка знакомств между двумя людьми», лента на основе того, что читают близкие по графу. Это буквально та задача, ради которой понятие «граф» и придумали. Когда социальные связи — не второстепенная деталь, а суть продукта, хранить их рёбрами и обходить графовым языком удобнее, чем городить самосоединения таблицы связей.
Граф знаний
Граф знаний (knowledge graph) — единая связная модель предметной области: сущности (люди, компании, товары, документы, понятия) и типизированные связи между ними, собранные из разных источников в одну сеть. На него опираются, когда надо отвечать на вопросы, соединяющие разрозненные факты: «какие продукты зависят от этой библиотеки и кто их сопровождает», «через какие компании связаны эти два человека». Neo4j часто выступает хранилищем такого графа — новую связь добавляют просто новым ребром с новой меткой, без переделки схемы.
Сети и инфраструктура
Топология сети, зависимости микросервисов, состав изделия, маршруты доставки — всё это графы, и типичный вопрос к ним про влияние: «если упадёт этот узел, что перестанет работать», «какие сервисы зависят от этой базы напрямую и по цепочке». Обход по зависимостям — родная для графовой СУБД операция, поэтому её берут для карт инфраструктуры и анализа последствий сбоя.
GraphRAG: граф знаний как память для языковой модели
Самая обсуждаемая сейчас область. Чтобы языковая модель отвечала по вашим документам, а не выдумывала, применяют подход RAG (retrieval-augmented generation): документы режут на куски, для вопроса находят куски, похожие по смыслу (векторный поиск), и подают их модели как контекст. Слабое место — факты про один объект разбросаны по разным кускам, а связи между объектами теряются: модель видит похожие абзацы, но не видит, как они соотносятся. На «многошаговых» вопросах («как A влияет на C через B») отсюда пробелы и выдумки.
GraphRAG добавляет к этому граф знаний. Из документов заранее вытаскивают сущности и связи (обычно той же языковой моделью) и складывают в граф. При запросе система не только ищет похожие куски, но и ходит по графу вокруг найденных сущностей: собирает соседей, цепочки связей, а иногда заранее посчитанные сводки по кластерам графа. Модель получает не мешок абзацев, а связную карту предметной области — точнее отвечает на вопросы про отношения и реже галлюцинирует.
Почему тут именно Neo4j. Граф знаний надо где-то хранить и быстро обходить — это его прямая работа. Вдобавок в Neo4j держат векторные индексы прямо на узлах графа, так что поиск похожего и обход по связям идут в одной базе: находим релевантные сущности векторным поиском и тут же расширяем ответ их графовым окружением. Эта комбинация «вектора + связи в одном месте» и сделала графовые СУБД заметными в теме языковых моделей.
Где это применяется
Общее правило: Neo4j оправдан там, где обход связей — повседневная и массовая операция, а не разовая. Рекомендации, антифрод, социальные фичи, граф знаний, карты зависимостей, GraphRAG — во всех этих случаях вопрос «как связано» задаётся постоянно и на переменную глубину, и ради него не жалко отдельной базы.
Где спотыкаются начинающие:
- Берут графовую СУБД под одну иерархию. Дерево категорий или оргструктура — это рекурсивный SQL в той базе, что уже есть, а не повод заводить вторую систему.
- Забывают цену второй базы. Репликация, бэкапы, мониторинг, ещё одна модель в голове у команды — та же плата, что за любое полиглотное хранилище. Она окупается ядром продукта, а не одной фичей.
- Ждут от GraphRAG магии. Качество ответов упирается в качество графа: если сущности и связи вытащены из документов небрежно, обход соберёт мусор. Граф знаний — это данные, за которыми надо следить, а не бесплатный побочный эффект.
- Дублируют весь граф без нужды. Если графовые запросы — 5 % нагрузки, честнее оставить данные в PostgreSQL (вершины и рёбра двумя таблицами), а не синхронизировать две базы.
Что почитать дальше: SQL или графовая СУБД — сама развилка «нужен ли граф вообще»; PostgreSQL или MongoDB — соседний выбор модели данных; графы и взвешенные графы — как устроены обходы и кратчайшие пути, на которых всё это стоит.