AI И НЕЙРОСЕТИ

Cassie Shum: GraphRAG упирается не в LLM, а в данные

50-минутный доклад Cassie Shum на QCon AI показал, где GraphRAG полезнее обычного RAG и почему без нормальных данных агенты мало что решают.

✍️ Редакция iTech News | 02.07.2026 | ⏱ 5 мин | Источник: InfoQ
🌐

50-минутный доклад Cassie Shum на QCon AI свел хайп вокруг графового RAG к неприятно земной мысли: дело не в том, что LLM внезапно стали глупыми, а в том, что корпоративные данные по-прежнему плохо подготовлены для сложных запросов. Для русскоязычной IT-аудитории это звучит особенно знакомо: можно сколько угодно обсуждать агентов, но если внизу бардак из документов, таблиц и разрозненных правил, магии не будет.

Выступление Graph RAG: Building Smarter Retrieval Workflows with Knowledge Graphs опубликовано 1 июля 2026 года; по данным InfoQ, его провела Cassie Shum, VP of Field Engineering в RelationalAI и бывший участник ThoughtWorks Technology Advisory Board. Ее тезис прост: классический векторный RAG по-прежнему полезен, но начинает буксовать там, где компании ждут от ИИ не красивого ответа, а воспроизводимой логики. Shum перечисляет четыре проблемные зоны: отсутствие глобального контекста, слабая работа со связями между сущностями, сбои на многошаговых цепочках рассуждений и плохая объяснимость. Иными словами, модель может найти похожий фрагмент текста, но ей куда сложнее показать, почему поставщик связан с дочерней компанией, та — с конкретным контрактом, а контракт — с риском в другом подразделении.

При этом спикер не делает вид, будто рынок застрял в 2023 году. Она отдельно оговаривает, что за последние шесть месяцев большие модели заметно прибавили: выросли контекстные окна, стало проще скармливать пачки документов, изображения и видео, а качество многошаговых ответов местами стало лучше. Но, по ее версии, это не отменяет главной проблемы enterprise-сценариев: модель можно накормить десятью документами и получить вменяемый вывод, но от нее все еще трудно добиться устойчивого ответа на вопрос уровня «что это значит для всей системы» или «каким путем мы пришли к этому заключению». Для финансов, здравоохранения, legal и других зарегулированных отраслей это не эстетическая придирка, а вопрос аудита, трассировки и ответственности.

Отсюда и разворот в сторону knowledge graph. Shum описывает графовый RAG не как «еще один способ хранить узлы и ребра», а как перенос части логики из оркестрации в слой данных. В ее формулировке ценность графа не в самой форме, а в семантике: сущности, отношения, бизнес-ограничения и правила задаются явно, а не прячутся в промптах и цепочках вызовов. Чем больше такой структуры, тем меньше система зависит от удачи при очередном retrieval. Это важный сдвиг для разработчиков и архитекторов: вместо бесконечной настройки пайплайнов и prompt engineering появляется шанс сначала привести в порядок модель предметной области, а уже потом подключать LLM как слой вывода.

Отдельно Shum показывает, как это выглядит на инженерном уровне. В RelationalAI используют то, что она называет graph normal form: не «широкие» таблицы с кучей полей, а длинные отношения между двумя концептами или сущностями, которые проще обходить и расширять. В докладе она несколько раз возвращается к идее, что knowledge graph должен быть не снимком на один день, а накапливаемой структурой. Новый документ не просто индексируется для поиска, а проходит через пайплайн извлечения сущностей, сверки с уже существующими узлами и пополнения онтологии. В результате система не забывает историю на миллионах документов и не начинает каждый раз с чистого листа, как это часто происходит в классических RAG-сценариях.

Практический кусок тоже получился не декоративным. В демо Shum использует Snowflake Intelligence и knowledge graph внутри экосистемы Snowflake, подчеркивая не столько сам выбор вендора, сколько архитектурный принцип: данные, governance, безопасность и графовая модель должны жить в одном контролируемом контуре. На таком основании уже можно задавать более насыщенные вопросы вроде «у какого магазина есть жалобы и почему» или искать группы клиентов через стандартные графовые алгоритмы. В одном из фрагментов она упоминает Weakly Connected Components, а в вопросах из зала объясняет, что поверх графа можно выводить новые сущности вроде «инфлюенсера», если алгоритмы показывают, что один клиент связан с множеством других. Это уже не поиск похожего текста, а попытка достроить саму картину предметной области.

Самый полезный для бизнеса момент прозвучал ближе к финалу. Shum довольно жестко разводит понятия «память агента» и «корректность данных». Агент, по ее словам, умеет хранить контекст, вызывать API, ходить в базы и раскладывать задачу на шаги, но это еще не делает его носителем доменной логики. Он знает, что у него есть инструмент, но не обязательно понимает, какой из двух похожих инструментов действительно нужен и почему. Планирование тоже не равно интеллекту в предметной области: агент исполняет заданный control flow, а не внезапно становится экспертом по цепочкам поставок, скорингу или юридическим ограничениям. Поэтому ставка «сейчас прикрутим побольше агентов, и они разберутся» в ее версии выглядит наивно.

Для российских команд здесь нет никакой экзотики. Если у компании накопились CRM-выгрузки, договоры, тикеты, почта, BI-отчеты и полуформальные справочники, то графовый RAG интересен не как модная надстройка над LLM, а как способ наконец собрать предметную область в связную структуру. Вопрос только в том, готовы ли компании инвестировать не в очередной «умный чат», а в скучный, дорогой и очень полезный фундамент: семантическую модель данных, онтологию, правила и историю изменений. Доклад Shum как раз неприятен тем, что не обещает легкой победы. Проверить исходное выступление можно в InfoQ — хотя главный вывод там читается и без демо: у агентов короткая дорога к разочарованию, если под ними нет нормальной структуры данных.

Поделиться: Telegram X LinkedIn