01 — Кейс · ML Нейросети

GraphRAG и граф знаний цепочки поставок для оптового дистрибьютора

Мы разработали GraphRAG-систему для группы компаний оптовой дистрибуции, работающей в трёх странах. Связи бизнеса — клиенты, заказы, товары, комплектующие, поставщики — собраны в граф знаний Neo4j из 14 источников: 12 млн узлов и 89 млн связей. Сотрудник задаёт многошаговый вопрос обычными словами, система переводит его в обход графа и в среднем за 1,8 секунды даёт ответ, который можно проверить по исходным данным.

NDA

Обновлено: 22 октября 2026 г.

Смотреть кейс

функциональных модулей: 8
этапов разработки: 6
ключевых технологий: 6

GraphRAG и граф знаний цепочки поставок для оптового дистрибьютора

02 — Контекст

Задача проекта

Исходная ситуация, ограничения и проблемы, которые должна была решить новая система.

Дистрибьютору нужно было отвечать на вопросы, которые проходят через всю цепочку поставок: от клиента к заказам, от заказов к товарам, от товаров к комплектующим, от комплектующих к поставщикам. Данные для этого лежали в 14 источниках, среди них — CRM Salesforce, каталоге товаров в SAP, системе закупок, службе доставки, биллинге Stripe, а также в письмах, обращениях в поддержку и договорах в PDF.

Действующая RAG-система хорошо искала по документам, но на вопросы о связях вроде «Какие поставщики дают комплектующие для товаров, которые чаще всего заказывают наши ключевые клиенты?» возвращала нерелевантные результаты: векторный поиск по сходству не понимает отношений между сущностями. Такие ответы собирали вручную, сверяя выгрузки из разных систем часами.

Граф знаний стал реляционным слоем общей платформы данных компании, где быстрые справки обслуживает CAG, а поиск по документам — классический RAG. Платформу целиком мы описали в отдельном кейсе. Здесь речь о графе: проектировании схемы, извлечении и сопоставлении сущностей, конвейере GraphRAG и маршрутизации запросов.

Векторный поиск не видит связей
RAG находит похожие по смыслу фрагменты текста, но не умеет пройти путь «клиент — заказ — товар — комплектующая — поставщик». На многошаговые вопросы система отвечала нерелевантными документами.
Один контрагент — четыре написания
Один и тот же клиент значился как «Acme Industries» в SAP, «Acme Industries Inc.» в Salesforce, «ACME IND» у службы доставки, а в Stripe — только адресом почты. Без сопоставления записей связать данные между системами было нельзя.
Часы ручной сверки
Вопросы о влиянии поставщиков на ключевых клиентов, сквозные агрегаты и цепочки между сущностями требовали выгрузок из нескольких систем и ручного сопоставления. Самые ценные для бизнеса вопросы оставались самыми дорогими.

03 — Возможности

Что делает система

Ключевые сценарии и рабочие модули, собранные в единую систему.

Граф знаний цепочки поставок
Схема повторяет реальную цепочку: клиент размещает заказ (PLACED), заказ содержит товары (CONTAINS), товар требует комплектующих (REQUIRES), комплектующая закупается у поставщика (SOURCED_FROM). Отдельные узлы — договоры, обращения в поддержку и регионы. Количество, цена и дата заказа хранятся прямо на связях, поэтому средний чек по товарам поставщика считается без соединения внешних таблиц.
Потоковая синхронизация с учётными системами
Структурированные источники — клиенты из Salesforce, каталог товаров из SAP, поставщики из системы закупок — попадают в граф через CDC-конвейеры на Apache Kafka. Когда менеджер правит карточку клиента в Salesforce, соответствующий узел в Neo4j обновляется за секунды. Граф не устаревает между выгрузками и отражает текущее состояние учётных систем.
Извлечение сущностей из писем и договоров
Письма, обращения в поддержку и договоры в PDF обрабатывает языковая модель: находит упоминания сущностей и привязывает их к узлам, которые уже есть в графе. Фраза из обращения «заказ промышленных насосов за IV квартал» превращается в ссылки на конкретный заказ и конкретные товары. Неструктурированные источники обновляются ежедневной пакетной обработкой.
Сопоставление записей между системами
Система сводит разные написания одного контрагента в единую сущность по нескольким признакам сразу: налоговые идентификаторы, домен почты, телефон, адрес, нечёткое сравнение названий. Модель обучили на 2 400 вручную подтверждённых совпадениях. Исправления сотрудников возвращаются в обучение, и доля автоматического сопоставления выросла с 98 до 99,3 %.
Перевод вопроса в запрос к графу
Языковая модель разбирает вопрос: какие сущности и связи в нём упомянуты и в каком виде нужен ответ. Затем вопрос относится к одному из примерно 30 типовых паттернов, у каждого — параметризованный шаблон на Cypher. Модель не пишет запрос с нуля, а подставляет параметры в проверенный шаблон, и точность генерации превышает 96 %.
Обход графа с бюджетом
Запрос выполняется в Neo4j с ограничениями: глубина обхода по умолчанию — три шага, для аналитических запросов — до пяти, не больше 500 узлов в результате, лимит узлов на каждый шаг и в сумме, таймауты. Если обход выходит за бюджет, система возвращает частичный результат с объяснением, а не обрывается молча. Один хорошо связанный клиент не утащит за собой полграфа.
Ответ с проверяемым следом
Языковая модель получает исходный вопрос и структурированный результат обхода, а не сырой вывод Cypher, и формулирует ответ обычным языком. К каждому ответу прикладываются сам Cypher-запрос и идентификаторы узлов, из которых он собран, а также отметка о свежести данных. Любое утверждение можно проверить по исходным записям.
Маршрутизация между CAG, RAG и GraphRAG
AI-классификатор определяет намерение вопроса, а не ищет ключевые слова. «Расскажи об Acme» уходит в CAG за базовой справкой, «Расскажи о наших отношениях с Acme» — в RAG за документами, «Покажи всех поставщиков товаров, которые заказывает Acme» — в граф. Составные вопросы разбираются по всем трём контурам, а агент-синтезатор сводит результаты в один ответ.

04 — Архитектура

Технологический стек

Технологии выбраны под нагрузку, интеграции и дальнейшее развитие продукта.

Зачем в проекте · 01 / 06

Neo4j + Cypher

Графовая СУБД хранит бизнес вместе со связями: обход «клиент — заказ — товар — комплектующая — поставщик» выполняется напрямую, без цепочки соединений таблиц. Cypher — язык запросов Neo4j, на нём написаны около 30 шаблонов, в которые языковая модель подставляет параметры вместо того, чтобы сочинять запрос целиком.

Зачем в проекте · 02 / 06

Apache Kafka

CDC-конвейеры на Kafka переносят изменения из Salesforce, SAP и системы закупок в граф почти в реальном времени. Правка в учётной системе отражается в Neo4j за секунды, поэтому ответы на вопросы о связях опираются на текущие данные, а не на вчерашнюю выгрузку.

Зачем в проекте · 03 / 06

Claude

Языковая модель работает на трёх участках конвейера: разбирает вопрос и выбирает шаблон запроса, извлекает сущности из писем, обращений и договоров, а затем формулирует ответ по структурированному результату обхода графа — с приложенным запросом и идентификаторами узлов.

Зачем в проекте · 04 / 06

Python + LangChain

Python — общий язык конвейеров извлечения, сопоставления сущностей и обработки запросов. LangChain связывает шаги GraphRAG в одну цепочку: разбор вопроса, генерацию Cypher, обход графа и синтез ответа, а также объединение результатов при составных вопросах.

Зачем в проекте · 05 / 06

FastAPI

Сервисный слой на Python, через который платформа и маршрутизатор обращаются к конвейеру GraphRAG. Тот же язык, что и у остальных конвейеров, поэтому API, извлечение сущностей и обработка запросов живут в одной кодовой базе.

Зачем в проекте · 06 / 06

PostgreSQL, Redis, OpenAI Embeddings

Инфраструктура общей платформы, в которую встроен граф: хранилище данных, быстрый слой CAG для типовых справок и векторные представления для документного RAG. Благодаря им граф получает только те 7 % вопросов, которым действительно нужен обход связей.

Ещё в проекте

GraphRAG

05 — Процесс

Как шла разработка

Последовательность работ от исследования задачи до запуска и проверки результата.

Каталог сущностей и схема графа
Самое важное решение проекта — что станет узлом, что связью, а что свойством. Мы описали все типы сущностей в 14 источниках и сопоставили их реальные связи: клиенты, заказы, товары, комплектующие, поставщики, договоры, обращения и регионы.
Прореживание графа: с 40 до 12 млн узлов
В первых итерациях узлами были и строки счетов, и события доставки, и цепочки писем — граф разросся до 40 млн узлов, обходы замедлились. Правило «справочное значение — это свойство, а не узел» перенесло трек-номера в свойства заказа, а суммы счетов — на связи. Граф сократился до 12 млн узлов, обходы заметно ускорились.
Конвейеры данных и сопоставление сущностей
Настроили CDC на Kafka для учётных систем, извлечение сущностей языковой моделью для писем и договоров и сопоставление контрагентов по нескольким признакам. Первичная сборка графа из 14 источников заняла восемь недель вместо запланированных четырёх: время ушло не на загрузку в Neo4j, а на очистку, нормализацию и сопоставление данных.
Конвейер GraphRAG: от 77 до 96 % точности
Сначала модель писала Cypher напрямую по вопросу — правильные запросы получались примерно в 77 % случаев. Мы перешли на около 30 параметризованных шаблонов, где модель только подставляет значения, и подняли точность выше 96 %. Добавили ограничения глубины и объёма обхода, синтез ответа и след из запроса и узлов.
Маршрутизация и обратная связь
Встроили граф в общую платформу через AI-классификатор. На старте он верно выбирал контур в 84 % случаев — чаще всего ошибочно отправлял в RAG вопросы, которым нужен граф. Ответы с низкой оценкой разбираются, каждый неверно направленный запрос становится обучающим примером, и за три месяца точность выросла до 96 %.
Эксплуатация и развитие схемы
Когда бизнесу понадобился новый тип узла — местоположение склада, — пришлось пересмотреть пути обхода, обновить шаблоны и прогнать регрессию. Теперь схема графа версионируется, а перед каждым изменением автоматически прогоняются наборы контрольных запросов. Ответы помечают, когда обновлялись данные, на которых они построены.

06 — Итог

Результаты

Что создано в рамках проекта: рабочий контур, реализованные возможности и подтверждённые факты.

выручки под риском нашли продажи в первый месяц: $340 000
в среднем на сложный запрос вместо часов ручной сверки: 1,8 с
узлов и 89 млн связей в графе знаний: 12 млн
точность маршрутизации запросов (на старте — 84 %): 96 %

GraphRAG обрабатывает 7 % ежедневных запросов — те, где нужны многошаговые рассуждения о связях: анализ влияния поставщиков, сквозные агрегаты по сущностям, закономерности во времени и поиск путей между сущностями. Это самые ценные для бизнеса вопросы, и раньше на каждый из них уходили часы ручной сверки между системами. Теперь ответ приходит в среднем за 1,8 секунды.

Уже в первый месяц отдел продаж нашёл $340 000 выручки под риском: запросы к графу выявили клиентов, которые стали заказывать реже, пока компании из их отрасли заказывали больше, и проследили причину по цепочке поставок до конкретных поставщиков и товаров. Генерация Cypher по шаблонам точна в 96 % боевых запросов, маршрутизатор в 96 % случаев выбирает верный контур, а 99,3 % записей из разных систем сопоставляются автоматически.

Платформа обрабатывает 2 400 вопросов на естественном языке в день от 180 активных пользователей. Трёхуровневая архитектура держит расходы под контролем: 71 % запросов закрывает CAG, 22 % — классический RAG и только 7 % — GraphRAG, поэтому вычисления на графе тратятся лишь там, где без обхода связей не обойтись.

Детали проекта

Почему кейс без имени клиента

Название заказчика мы не раскрываем: это группа компаний оптовой дистрибуции, работающая в трёх странах. Граф знаний описывает её цепочку поставок целиком — кто из клиентов что покупает, у каких поставщиков и на каких условиях, — поэтому имя компании, её клиентов и поставщиков, а также внутренние показатели остаются закрытыми.

При этом мы открыто рассказываем, как устроена система: схема графа, конвейеры CDC и извлечения сущностей, шаблоны Cypher, ограничения обхода и маршрутизация между CAG, RAG и GraphRAG, а также цифры, которые не раскрывают бизнес заказчика. Рекомендацию клиента можем предоставить по запросу при подписании NDA.

FAQ

Вопросы о проекте

Обычный RAG ищет фрагменты текста, похожие на вопрос по смыслу, и хорошо справляется с поиском по документам. Но векторное сходство не понимает связей между сущностями, поэтому на вопрос «какие поставщики дают комплектующие для товаров наших ключевых клиентов» он возвращает нерелевантные документы. GraphRAG хранит бизнес как граф и отвечает обходом связей: от клиента к заказам, товарам, комплектующим и поставщикам.

Мы начинали именно так, и модель писала правильный запрос примерно в 77 % случаев — для эксперимента неплохо, для работы с реальными данными недостаточно. Поэтому вопросы относятся к одному из примерно 30 типовых паттернов, у каждого есть параметризованный шаблон на Cypher, а модель лишь подставляет значения. Точность на боевых запросах — выше 96 %.

Через сопоставление по нескольким признакам: налоговые идентификаторы, домены почты, телефоны, адреса и нечёткое сравнение названий. Модель обучили на 2 400 вручную подтверждённых совпадениях, и сразу после запуска она автоматически сопоставляла 98 % записей. Исправления сотрудников возвращаются в обучение, и за три месяца доля выросла до 99,3 %.

Решает AI-классификатор по намерению вопроса. Если в нём есть сущности и связи между ними, он уходит в GraphRAG, если нужен текст документов — в RAG, если нужна справка по текущим данным — в CAG. Составные вопросы разбираются по нескольким контурам, а агент-синтезатор сводит ответы. В итоге 71 % запросов закрывает CAG, 22 % — RAG и 7 % — граф.

Ограничения обхода. По умолчанию глубина — три шага, для аналитических запросов — до пяти, в результате не больше 500 узлов, есть лимит узлов на каждый шаг и в сумме, а также таймауты. Если запрос упирается в бюджет, система возвращает частичный результат и объясняет, что именно было ограничено, вместо того чтобы молча оборваться по таймауту.

Зависит от источника. Учётные системы — Salesforce, SAP, система закупок — синхронизируются почти в реальном времени через CDC-конвейеры на Kafka: правка записи отражается в графе за секунды. Письма и договоры проходят ежедневную пакетную обработку. Чтобы это было прозрачно, ответ показывает, когда последний раз обновлялись данные о связях, на которых он построен.

Да. Модель формулирует ответ по структурированному результату обхода, а не по собственным знаниям, и к каждому ответу прикладывается Cypher-запрос и идентификаторы узлов, из которых он собран. Любое утверждение можно сверить с исходными записями в графе — это важно, когда по ответу принимают решения о клиентах и поставщиках.