Когда векторного поиска уже недостаточно бизнесу?

В какой-то момент все корпоративные ассистенты начинают вести себя одинаково: красиво перефразируют фрагменты документов, но не видят связи между людьми, договорами, процессами и событиями. Вы задаёте нормальный управленческий вопрос — «кто отвечает за этот риск и как он связан с конкретными SKU и поставщиками?» — а в ответ получаете аккуратный пересказ регламента или презентации; по форме всё отлично, по сути впустую.

На этом фоне закономерно появляются статьи и доклады про Graph — подход, где к LLM и векторному поиску добавляют граф знаний: сущности, отношения, пути, сообщества. В бенчмарках Graph даёт в среднем заметный прирост точности и почти двукратное улучшение ответов на сложные multi-hop и relationship-вопросы по сравнению с классическим . В enterprise-настройках на основе графов знаний фиксируют кратный рост точности по бизнес-критичным вопросам от KPI-аналитики до стратегического планирования.

В БизнесМатике это хорошо видно на проектах в ритейле и FMCG, где от ассистента ждут не «умного поиска по PDF», а понимания цепочек поставок, клиентских путей и операционных рисков. Компания позиционирует себя как интегратор ИИ-трансформации для ритейла, FMCG и производства, а ключевые заказчики — C-level и IT-руководители, которым важны ROI, скорость внедрения и управляемость рисков. Поэтому вопрос обычно звучит не «что моднее — или Graph?», а «где векторного поиска уже недостаточно, и как не закопаться в инфраструктуре, если всё-таки нужен граф знаний предприятия?».

Что умеет классический — и почему он теряет связи

Если убрать маркетинговую обвязку, классический устроен довольно просто: документы режутся на чанки, для них строятся эмбеддинги, при запросе ищутся наиболее близкие фрагменты, и они подаются в контекст LLM. В продакшене к этому добавляют гибридный поиск, фильтрацию по метаданным и re-ranking, но базовая логика остаётся прежней: модель видит мир через отдельные куски текста.

Такой подход отлично работает там, где ответ локален. Если нужно найти сроки SLA, правила эскалации, порядок согласования или фрагмент из базы знаний, закрывает задачу быстро и относительно дёшево. Именно поэтому уже стал базовым инструментом для корпоративных FAQ, внутреннего helpdesk, поиска по Confluence и документации.

Но у него есть фундаментальное ограничение: не знает, что «этот поставщик» в договоре — тот же самый контрагент, который фигурирует в ERP, CRM и WMS; что «эта акция» связана с конкретными SKU и регионами; что «этот инцидент» влияет на определённую цепочку поставок. Для это просто текст, а связи между сущностями распадаются на уровне чанков и разных источников. Поэтому на multi-hop запросах и кросс-документных вопросах классический закономерно проседает: он находит похожие куски, но не строит целостную причинно-следственную модель.

Когда классического достаточно

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

К таким задачам относятся:

• поиск по регламентам, политикам и инструкциям, где ответ живёт в одном документе или узкой группе документов;
• FAQ и базы знаний службы поддержки, где важно быстро снять нагрузку с первой линии;
• локальные базы знаний департаментов, например IT, маркетинга или HR, где не требуется моделировать сложные связи между сущностями.

В этих сценариях лучше инвестировать в качество разметки, метаданные, гибридный поиск и контроль качества ответов, чем тащить в архитектуру графовую БД и онтологию. Для многих компаний именно такой путь даёт первые ощутимые эффекты: сокращение времени на поиск знаний, снижение нагрузки на поддержку и быстрый time-to-value без многомесячного инфраструктурного проекта.

Где начинает ломаться

Проблемы начинаются там, где бизнес задаёт вопросы не про документы, а про связи между объектами.

В ритейле и FMCG это выглядит очень узнаваемо:

• «Если ключевой поставщик задержит поставку на две недели, какие SKU, РЦ, магазины и промо это затронет?»
• «Какие кампании реально повлияли на churn клиентов этого сегмента, а какие просто дали красивую отчётность?»
• «Какие договоры, ответственные и регуляторные требования были связаны с этим инцидентом?»

На такие вопросы редко существует один документ с готовым ответом. Нужно пройти по цепочке:

поставщик → SKU → РЦ → магазины → промо → финансовый эффект, или клиент → сегмент → покупки → коммуникации → изменение поведения.

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

Именно на таких задачах Graph и графовые подходы показывают серьёзный прирост точности: в обзорах и бенчмарках речь идёт о кратном выигрыше на вопросах, где ответ зависит от структуры и отношений, а не от одного документа. И это как раз те вопросы, от которых зависит P&L, риски и отношения с регуляторами.

Что такое Graph по‑деловому

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

Для предприятия граф знаний — это формальная модель предметной области. В ритейле и FMCG в нём естественно живут клиенты, сегменты, SKU, бренды, категории, магазины, склады, поставщики, договоры, кампании, промо, инциденты и ответственные. Между ними фиксируются отношения: «поставляет», «покупал», «участвует в кампании», «хранится в РЦ», «отвечает за», «связан с инцидентом».

За счёт этого Graph превращает LLM из «пересказчика найденных абзацев» в интерфейс к операционной памяти предприятия. Система может не просто найти текст, а собрать связанный подграф объектов, пройти по релевантным путям и уже потом сгенерировать ответ на естественном языке. Для бизнеса это означает две практические вещи: holistic-видимость по сложным цепочкам и explainability, то есть возможность показать, на каких связях основан вывод модели.

Архитектура Graph: как это устроено в enterprise

Graph — это не одна библиотека, а несколько слоёв архитектуры, которые должны работать вместе.

Первый слой — ingestion и интеграция данных. Нужно забрать данные из ERP, CRM, WMS, PIM, систем лояльности, документооборота и других источников, а затем выровнять идентификаторы: один и тот же поставщик, SKU или клиент не должен жить в пяти системах как пять разных сущностей. Без этого граф только зафиксирует хаос.

Второй слой — извлечение сущностей и связей. Здесь используются NER, relation extraction и LLM-подходы, которые выделяют из документов, логов и событий сущности и маппят их на онтологию домена.
Так появляются триплеты вроде «поставщик — поставляет → SKU», «SKU — участвует в → кампании», «кампания — проводится в → регионе».

Третий слой — собственно knowledge graph. Это графовая БД и онтология, где определено, какие сущности бывают, какие связи допустимы и какие бизнес-ограничения работают в предметной области. На этом этапе уже нужны governance, версия схемы и владелец онтологии, иначе граф быстро превращается в красивую, но бесполезную схему.

Четвёртый слой — retrieval, и вот здесь важная мысль: в реальной жизни Graph почти всегда оказывается гибридным. Сначала используется векторный поиск, чтобы быстро найти семантически релевантные документы и сущности, затем подключается graph traversal, чтобы собрать структуру связей и сократить риск галлюцинаций. Такой hybrid graph-vector во многих enterprise-кейсах показывает более стабильное качество, чем чистый vector : модель видит и текст, и структуру.

Пятый слой — оркестрация LLM. Оркестратор решает, какому типу retrieval доверить запрос, собирает подграф, подтягивает текстовые фрагменты, формирует финальный контекст для модели и сохраняет traceability — то есть понятный след, на основе чего именно был построен ответ. В supply chain и risk-кейсах к этому уже добавляют агентные сценарии, где один агент ходит по графу, другой проверяет числовые показатели и ограничения, а третий превращает это в ответ для менеджера или аналитика.

Где здесь ROI, а где переинженеринг

Graph даёт ценность не потому, что это «более умный AI», а потому что он снижает стоимость ошибок на задачах, где ключевую роль играют связи между объектами. Это особенно заметно в supply chain, customer 360, риск-аналитике и комплаенсе.

В ритейле и FMCG это может выражаться в:

• снижении out-of-stock и потерь за счёт лучшей видимости цепочек поставок;
• росте выручки за счёт более точного понимания влияния кампаний, сегментов и товарных связок;
• ускорении расследования инцидентов и проверок за счёт связности данных и explainability.

Но там же лежит и главный риск: если у компании нет зрелого MDM, понятной модели сущностей, владельцев данных и ясного use case, Graph превращается в дорогой инфраструктурный эксперимент. Поэтому ошибка №1 — строить граф ради графа. Ошибка №2 — пытаться решать Graph’ом задачи, которые и так закрываются хорошим за меньшие деньги и в разы быстрее.

Как выбрать между , Hybrid и Graph

На практике решение удобно принимать по пяти критериям.

1. Связанность данных.
   Если у вас один основной источник (регламенты, документация, база знаний), чаще всего достаточно . Если нужно регулярно объединять ERP, CRM, WMS, PIM и другие системы, имеет смысл минимум смотреть в сторону гибридного retrieval и knowledge graph.
2. Тип запросов.
   Single-document Q&A и поиск по документации — зона .
   Multi-hop, цепочки влияния и кросс-системные вопросы — зона для Hybrid или Graph.
3. Требования к explainability и комплаенсу.
   Если ассистент помогает сотрудникам читать документацию, ошибки неприятны, но терпимы. Если ответы влияют на кредитные лимиты, закупки, регуляторные отчёты и штрафы, без связного слоя и трассировки цепочек вы рано или поздно упрётесь в ограничения .
4. Команда и бюджет.
   -пилот можно сделать силами небольшой команды разработчиков и ML-инженеров за недели. Graph требует data engineer’ов, архитекторов, knowledge-engineer’ов и долгосрочного владения графом.
5. Где у вас ROI на связях.
   В ритейле и FMCG чаще всего это:

• supply chain и риски (out-of-stock, потери, штрафы),
• customer 360 и персонализация (кросс/апселл),
• комплаенс и аудит (штрафы, скорость проверок).

Именно эти зоны чаще всего оправдывают инвестиции в knowledge graph и, потенциально, Graph. Остальное часто спокойно закрывается улучшенным .

С чего начать на практике

Самая частая ошибка компаний — начинать не с задачи и данных, а с выбора технологии. На рынке легко увлечься графовой БД, новым Graph-фреймворком или красивой demo-схемой, но это не отвечает на вопрос, нужен ли вам вообще граф знаний сейчас.

Более прагматичный путь — сначала провести оценку зрелости. В подходе БизнесМатики это ИИ-аудит по шести измерениям: стратегия, данные, технологии, люди, процессы, governance. Такой аудит позволяет понять:

• где уже можно быстро получить эффект на обычном ;
• где нужен Hybrid как промежуточный шаг;
• какие сценарии действительно оправдывают граф знаний предприятия;
• какие интеграции, модели данных и организационные изменения нужно сделать до серьёзных инвестиций в Graph.

Это особенно важно для среднего и крупного ритейла, где data silos, Excel-процессы и разрозненные системы — не исключение, а норма. В такой ситуации вопрос «строить ли Graph?» почти всегда вторичен по отношению к вопросу «готова ли вообще наша предметная область к связному семантическому слою?».

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

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