Graph RAG: разработка на графах знаний для точного multi-hop поиска

Graph RAG: почему обычный поиск ломается на длинных цепочках вопросов

Обычный поиск по документам режет корпус на фрагменты, считает близость каждого к формулировке вопроса и отдаёт верхние несколько в контекст модели. Схема работает, пока ответ лежит внутри одного абзаца. Как только вопрос требует пройти три-четыре связи между сущностями, близость перестаёт быть мерой релевантности: в вопросе сформулирован итог, а каждое звено цепочки говорит о своём.

Отсюда два класса провалов в ответах. Первый — фрагмент с нужным звеном не попадает в верхнюю часть выдачи: он не похож на вопрос ни лексически, ни по смыслу, потому что описывает промежуточное событие или свойство. Второй — вопрос собирательный («что общего у этих случаев», «какие направления пересекаются»), и выборка из нескольких абзацев не покрывает корпус. Модель отвечает частично или достраивает связь сама — убедительно и мимо факта.

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

Дальше разбираем, из каких решений складывается такая система и где проходят её границы.

Что даёт граф знаний: точность и устойчивость ответов

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

Доля верных ответов на составных вопросах

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

Проверяемая цепочка рассуждения

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

Объём контекста на один запрос

Обычный поиск подкладывает в запрос полтора десятка фрагментов «на всякий случай» — модель размывается на шуме. Граф отдаёт три-пять узлов, связанных именно с цепочкой, и объём контекста сокращается в разы при более высоком качестве ответов. Заодно дешевеет сам вызов модели: меньше входных данных — стабильнее время отклика.

Устойчивость выдачи

Переформулировка вопроса не меняет набор узлов: маршрут идёт по связям, а не по словам. Доля запросов, где ответ «плывёт» при смене формулировки, снижается — результат перестаёт зависеть от того, как пользователь спросил.

Способы связывать факты: граф, векторы или гибрид

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

Как режимы ведут себя на реальных данных

Что определяет выбор схемы

Смотрим на характер данных и тип вопроса. Если ответ собирается из нескольких документов и важен порядок связей, одной близости мало — нужен граф. Если запросы живут формулировками пользователя, граф без вектора даёт промахи на перефразировании. На практике выбор схемы редко бывает строгим «или-или»: гибрид закрывает оба класса запросов, но платит за это синхронизацией индексов при каждом обновлении данных.

Как мы строим граф знаний: этапы инженерной работы

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

1. Аудит источников. Сводим регламенты, тикеты, базу знаний и таблицы в одну карту: объём, дубли, права доступа, частота изменений. Здесь же определяем поля, по которым сущности сшиваются между собой.
2. Проектирование схемы. Фиксируем типы узлов и рёбер, обязательные атрибуты, направление связей и правила слияния дублей. Схема утверждается до первой загрузки: иначе извлечение сущностей даёт несовместимые типы.
3. Извлечение сущностей и связей. Правила закрывают предсказуемые поля, языковая модель — формулировки в тексте. После разрешения сущностей один реальный объект получает один узел, а не три похожих.
4. Сборка графа. Загружаем узлы и рёбра в хранилище, добавляем иерархию разделов, веса связей и обратные ссылки на исходный фрагмент — по ним проверяется каждая цитата.
5. Контрольный набор. Берём реальные вопросы сотрудников с эталонными цепочками ответов. На них измеряем полноту извлечения и точность многошаговых запросов, отдельно — на части, невидимой при настройке.
6. Передача команде. Отдаём схему, регламент обновления, переиндексацию при изменении источника и панель качества: доля корректных цепочек и время ответа.

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

Схема графа, политики доступа и передача документации

Проект заканчивается не удачным демо-запросом, а состоянием, в котором ваша команда сама подключает новые источники, правит связи и не ломает при этом доступы. Поэтому приёмка идёт по перечню артефактов: каждый лежит рядом с кодом, версионируется вместе с ним и проверяется на стенде до передачи.

• Схема графа — типы узлов и рёбер, обязательные атрибуты, правила слияния дублей сущностей, а также что связывается автоматически, а что подтверждает человек.
• Правила обогащения — какие источники обходят и с какой периодичностью, как разрешается конфликт между ними и по какому признаку запись считается более достоверной.
• Настройки извлечения и связывания — размер разбираемого фрагмента, модель представления текста, порог уверенности для ребра, веса типов связей. С ними ответ поиска воспроизводится, а не «получается по-разному».
• Политики доступа — роли, ограничения на чтение отдельных узлов и целых подграфов, маскирование полей в ответе, журнал запросов с субъектом и временем обращения.
• Регламент обновления — что пересобирается частями, что требует полного пересчёта графа, кто запускает процесс и как проверяется соответствие версии связей версии источников.
• Набор оценочных вопросов — многошаговые сценарии с ожидаемыми путями в графе; прогон по ним показывает просадку точности сразу после правок, а не через жалобы пользователей.
• Инструкция по эксплуатации — восстановление связей после сбоя загрузки, откат на предыдущую версию графа, типовые ошибки и порядок эскалации.
• Документация решения — архитектурная схема, описание контуров и журнал принятых решений: почему структура связей именно такая и что менялось по ходу.

Такой комплект позволяет передать сопровождение вашей команде или вернуться к развитию через месяцы без разбора по коду.

Кейс: как выросла точность ответов на связных вопросах

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

Что показали замеры до

На эталонном наборе из 300 связных вопросов доля верных ответов составляла 52%. В 41% случаев терялась минимум одна связь, и ответ выглядел правдоподобно, но не содержал нужного пункта — самая дорогая категория ошибок, потому что её замечал только эксперт-предметник. Сборка выдачи занимала до 3,1 с, а ручная проверка ответа забирала у инженера несколько минут.

Что изменили

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

Что стало на том же наборе

Доля верных ответов выросла до 88%, потери связей сократились до 4%, время подготовки выдачи — до 0,9 с. Сплошную ручную проверку заменили выборочной: инженер смотрит один ответ из десяти вместо каждого. На расширенном наборе вопросов метрики держатся — граф пополняется вместе с документацией, а не деградирует по мере роста базы.

Чем Graph RAG отличается от обычного векторного поиска

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

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

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

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

Выбор делаем по замерам на реальных запросах: набор типовых вопросов, сравнение полноты ответов, доля случаев, где цепочка фактов не собирается из отдельных фрагментов. Neo4j и подобные хранилища подключаем, только когда замеры подтверждают, что связность действительно нужна.

Технические сомнения: данные, качество, сопровождение

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

Как обновляется граф при правках в документах?

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

Можно ли развернуть решение в закрытом контуре?

Да. Модели, индекс и граф размещаются на вашей инфраструктуре, внешние вызовы закрывает политика сети, доступы раздаются по ролям. Логи запросов остаются внутри контура: для чувствительных данных это условие, а не опция.

По каким критериям принимается качество?

Приёмка идёт на наборе вопросов из ваших сценариев: отдельно простые, отдельно требующие обхода нескольких связей. Считаем долю верных ответов, точность ссылок на источник и полноту обхода, фиксируем классы ошибок. Если метрики не достигнуты, дорабатываем разбор документов и схему графа, а не подгоняем ответы.

Обсудим задачу и вернёмся с планом работ

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

Что нужно от вас на первом разборе задачи:

• 20–30 реальных вопросов пользователей, включая составные, где ответ собирается из нескольких документов.
• Корпус источников как есть: регламенты, договоры, каталоги, техническая документация, переписка.
• Перечень сущностей и связей, важных в предметной области: клиент, объект, договор, версия документа.
• Описание того, как поиск ошибается сейчас: где теряется связь между документами и что считается неверным ответом.
• Ограничения по контуру: где разворачиваем решение, какие системы отдают данные и по каким доступам.
• Желаемый горизонт запуска и то, кто с вашей стороны принимает результат.

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

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