27 августа 2026 года The New Stack выпустил разбор о том, почему классический RAG, собранный по схеме «нарезали PDF на чанки, сделали эмбеддинги, положили в векторную базу», хорошо смотрится в демо и заметно хуже ведет себя в проде. Для команд, которые строят поиск и аналитику поверх корпоративных документов, вывод неприятный, но полезный: без связей между сущностями графовый RAG начинает выглядеть не модной опцией, а вполне рабочей необходимостью.
Как пишет The New Stack, автор материала Emmanuel Akita разбирает типичную иллюзию AI-инжиниринга: будто проблему галлюцинаций можно закрыть одним лишь Retrieval-Augmented Generation. В этой логике все просто: документы режутся примерно на 1000 токенов, каждый чанк превращается в вектор, дальше идет cosine similarity, и система якобы уже умеет отвечать на вопросы по внутренней базе знаний. На практике этот рецепт ломается, как только пользователь задает не прямой вопрос по одному фрагменту текста, а запрос, где нужно связать несколько фактов из разных мест.
Ключевой пример в статье предельно прикладной. Допустим, в базе лежат два фрагмента: в одном сказано, что Acme Corp купила BetaTech в 2022 году, в другом, что Sarah Connor стала CEO BetaTech в 2023-м. Вопрос звучит так: «Кто возглавляет компанию, которую приобрела Acme Corp?» Для человека задача на уровне деловой переписки. Для базового RAG уже начинаются неприятности: один чанк семантически ближе к Acme Corp и сделке, другой к CEO и BetaTech, а нужный ответ возникает только если связать обе записи через промежуточную сущность. Иными словами, multi-hop reasoning требует не похожести текста как таковой, а понимания отношений между объектами. Именно здесь, по мысли автора, и заканчивается удобная сказка о том, что «векторный поиск сам все дотащит».
GraphRAG решает эту проблему за счет явной структуры. Вместо того чтобы полагаться только на семантическую близость чанков, система во время индексации извлекает из текста сущности и связи, а затем строит граф знаний. В примере из статьи это уже не два разрозненных куска текста, а понятные отношения вида Acme Corp — ACQUIRED — BetaTech и Sarah Connor — LEADS — BetaTech. Дальше запрос обрабатывается не как одинокая строка для поиска ближайших векторов, а как точка входа в граф, из которой можно пройти по связям и собрать релевантный подграф для ответа модели. На бумаге звучит очевидно. В реальных enterprise-сценариях это и есть разница между «бот что-то нашел» и «бот действительно понял, как факты связаны между собой».
Не серебряная пуля, а более дорогая инженерия
При этом материал не продает GraphRAG как магию. Наоборот, Akita довольно честно перечисляет цену вопроса. Если обычный RAG относительно дешев на этапе ingestion, то графовый RAG заметно дороже: для каждого чанка LLM должна вытащить сущности и отношения. В примере из статьи для этого используется модель GPT-4o, а для эмбеддингов — text-embedding-3-small. Автор отдельно предупреждает, что без rate-limit handler конвейер упрется в ошибки API почти сразу на реальных объемах документов. То есть разговор уже не про «прикрутили еще один пакет», а про полноценную эксплуатационную дисциплину: лимиты, стоимость прогонов, отбор документов, устойчивость пайплайна.
Вторая неприятная, но здравая мысль касается схемы данных. Автор прямо пишет: схема в графе не опциональна. Если оставить LLM свободу именовать сущности как попало, база быстро превратится в склад дублей и фантомов: условные Acme Corp, Acme Corporation и даже опечатки вроде Ame будут жить как разные узлы. В статье для Python-пайплайна на базе neo4j-graphrag предлагается заранее задавать типы сущностей и связи, а не надеяться, что модель сама аккуратно организует корпоративную реальность. Для многих команд это, вероятно, главный холодный душ: AI-слой не отменяет старую добрую работу по моделированию данных, а, скорее, делает ее еще важнее.
Технически разбор опирается на стек Neo4j и пакет neo4j-graphrag. Для извлечения контекста используется VectorCypherRetriever: сначала запрос встраивается в векторное пространство, затем находится входная сущность, после чего система выполняет traversal по графу и возвращает не абстрактно похожие куски текста, а связи между узлами. Автор также отмечает еще один плюс такого подхода: наблюдаемость. Отлаживать наивный RAG часто означает смотреть в большие массивы чисел и гадать, почему алгоритм посчитал этот чанк релевантным. В графовой схеме можно открыть Neo4j и буквально увидеть, какие узлы и ребра построила система. Если LLM галлюцинировала сущность или связь, это хотя бы заметно без гадания на float-массивах.
Что это меняет для команд, которые уже строят AI-поиск
Для разработчиков и продуктовых команд вывод из статьи довольно прямой. Если ваш сценарий сводится к поиску ответа внутри одного документа или одного хорошо сформулированного фрагмента, обычный RAG по-прежнему может быть достаточным и экономически разумным. Но если речь идет о договорах, комплаенс-отчетах, внутренней документации, due diligence, инцидентах безопасности или любой другой базе, где вопрос требует пройти через цепочку фактов, базовый RAG начинает терять почву. Особенно это видно на задачах глобального суммирования вроде «какие основные факторы риска повторяются во всех наших отчетах». Для такого класса вопросов графовый RAG выглядит не как избыточная архитектурная красота, а как попытка привести retrieval к реальной структуре бизнеса.
На этом фоне важен и более широкий тренд: рынок устал от универсального совета «добавьте векторную базу, и LLM перестанет фантазировать». Материал The New Stack аккуратно, но довольно жестко напоминает, что корпоративные данные редко устроены как набор независимых абзацев, а пользователи задают вопросы не по учебнику для эмбеддингов. Следующий этап эволюции enterprise AI, похоже, будет крутиться не вокруг еще одного слоя обвязки над чат-моделью, а вокруг того, насколько хорошо команда умеет превращать неструктурированный текст в осмысленные связи. И здесь главный вопрос уже не в том, нужен ли графовый RAG вообще, а в том, какие компании готовы платить за более дорогую индексацию ради ответов, которые не рассыпаются на втором логическом шаге.