Граф RAG отвечает там, где обычный поиск по фрагментам сдаётся: на вопросах о связях между людьми, договорами, продуктами и событиями, разбросанными по разным документам, и на вопросах о корпусе в целом. Идея в том, чтобы сначала извлечь из текстов сущности и отношения, собрать из них граф, а потом искать по нему. Выигрыш бывает заметным, но цена высока, поэтому решать нужно на тестах: мода плохой советчик.
Когда нужен граф
Граф оправдан, когда ответ складывается из связей между сущностями или требует целостной картины корпуса. Для вопросов с ответом в одном абзаце хватает обычного поиска по фрагментам.
По документации Microsoft GraphRAG, подход превосходит классический RAG в двух случаях: когда нужно связать разрозненные фрагменты через общие атрибуты и когда требуется целостное понимание больших коллекций документов. Обычный поиск возвращает несколько похожих абзацев и теряет всё, что лежит за их пределами.
Сигнал для графа проще всего заметить по поведению сотрудников. Если они задают вопросы, на которые приходится собирать ответ из пяти документов вручную, или просят «общую картину по всем обращениям», обычный поиск исчерпал возможности. Если вопросы короткие и точные, граф только усложнит жизнь и удорожит поддержку.
- Вопрос о связях: кто участвует в проекте, какие договоры затрагивают поставщика, как продукты зависят друг от друга.
- Вопрос о корпусе: какие темы доминируют в обращениях, как менялась проблематика, что общего у этих отчётов.
- Вопрос о цепочке: через кого и через какие документы связаны два события.
- Контрпример: «какой срок возврата указан в регламенте» решает обычный поиск, граф тут лишний.
Базовую схему обычной системы мы разбирали в статье RAG: как устроена система, и это точка отсчёта: граф стоит вводить после того, как обычный вариант упёрся в потолок на ваших вопросах.
Что строится
Индексация графа отличается от индексации обычной базы фрагментов. Вместо одних векторов создаётся целая структура, и каждый её слой требует проверки.
- Корпус делится на текстовые единицы, чтобы каждое извлечённое утверждение можно было привязать к месту в документе.
- Из каждой единицы извлекаются сущности, отношения между ними и ключевые утверждения.
- Одинаковые сущности, названные по-разному, объединяются, иначе граф рассыплется на дубли.
- Иерархическая кластеризация собирает граф в сообщества: группы тесно связанных сущностей.
- Для каждого сообщества и его составляющих создаётся краткая сводка, от нижних уровней к верхним.
Объединение одинаковых сущностей заслуживает отдельного внимания. Компания, названная в одном документе полным именем, в другом аббревиатурой, а в третьем с опечаткой, превращается в три узла, и связи между ними теряются. Заведите словарь синонимов для ключевых сущностей вашей области и проверяйте на выборке, как они объединились.
Именно так описывает индексацию справка проекта: деление на текстовые единицы, извлечение, кластеризация иерархическим методом Лейдена и сводки сообществ. Практический вывод для команды: качество графа определяется качеством извлечения, поэтому его нужно просматривать глазами на небольшой выборке до запуска на всём корпусе.
Режимы поиска
Справка выделяет четыре режима поиска, и выбор режима важнее выбора модели. Для каждого типа вопроса подходит свой.
| Режим | Для какого вопроса | Что используется |
|---|---|---|
| Глобальный | О корпусе в целом: темы, тенденции, общая картина | Сводки сообществ |
| Локальный | О конкретной сущности и её окружении | Сущность и соседи по графу |
| DRIFT | Локальный вопрос с широким контекстом | Локальный поиск плюс сведения о сообществах |
| Базовый | Обычный вопрос по тексту | Классический векторный поиск по фрагментам |
Вопрос, поставленный в неподходящем режиме, даёт слабый ответ даже при отличном графе. Глобальный режим на вопрос о конкретном договоре расплывается общими словами, а локальный на вопрос о тенденциях видит лишь часть картины. Поэтому режим стоит выбирать явно, а в интерфейсе для сотрудников лучше показывать подсказку, какой тип вопроса куда направлять.
Практическое правило: заведите базовый режим как контрольный, он нужен для сравнения. Если на ваших вопросах он справляется так же хорошо, граф вам пока лишний, и экономия на индексации очевидна.
Сравнение на тестах
Решение о графе принимается по данным. Договоритесь заранее о критерии успеха: например, граф берём, если он выигрывает на вопросах о связях и держит прежний уровень на остальных. Соберите набор вопросов трёх типов: на связи, на корпус целиком и на простые факты. Прогоните их через обычный поиск и через граф, ответы оцените вслепую.
- Для вопросов на связи заранее запишите ожидаемую цепочку документов и сущностей.
- Для вопросов о корпусе попросите эксперта составить список главных тем и сверьте с ответом.
- Простые вопросы нужны как контроль: на них граф обязан сохранять прежнее качество.
- Оценивайте цитаты: каждое утверждение должно вести к документу, одной сводки сообщества мало.
- Фиксируйте, сколько обращений к модели и времени ушло на индексацию, и сравнивайте с выигрышем.
Оценивайте вслепую буквально: уберите из ответов пометки о том, какая система их выдала, перемешайте и дайте эксперту. Знание о том, что ответ получен «умным графом», бессознательно повышает оценку, и без слепой проверки вы получите приятную, но ложную картину. Два-три эксперта и десяток вопросов каждого типа дают уже осмысленное сравнение.
Если выигрыш виден только на вопросах о корпусе, возможно, вам нужен регулярный отчёт по темам, а граф избыточен. Оценка самой поисковой части описана в материале RAG поиск: оценка релевантности и нулевая выдача, используйте те же приёмы.
Какие вопросы к вашим документам требуют связей между сущностями?
Цена и риски
Главный риск графа в том, что он выглядит убедительно. Красивая схема связей и гладкая сводка создают ощущение понимания, а ошибки извлечения прячутся внутри. Одна неверная связь, повторённая в сводке сообщества, становится «фактом», который трудно заметить.
Каждое утверждение в ответе графовой системы должно вести к исходному фрагменту документа. Ответ, опирающийся только на сводку сообщества, считается непроверенным и возвращается на доработку.
- Индексация требует множества обращений к модели, поэтому сначала запустите её на небольшом срезе и оцените расход.
- Обновление графа сложнее обновления обычной базы: изменённый документ затрагивает сущности и сообщества.
- Права доступа переносятся на граф с трудом: сводка сообщества может смешать открытое и закрытое.
- Подготовка данных важнее, чем у обычного RAG, см. RAG данные: подготовка корпуса и обновление.
Отдельный вопрос: кто отвечает за граф после запуска. Извлечение зависит от модели, а модели обновляются; сводки зависят от корпуса, а корпус растёт. Назначьте владельца, который раз в месяц прогоняет контрольный набор и сообщает, как изменилось качество. Без владельца система тихо деградирует, и это обнаруживается по жалобам пользователей.
Для компании разумный путь такой: сначала обычная система, затем тест на ваших вопросах, затем граф для того класса вопросов, где он выиграл. Если нужно оценить, окупится ли граф на вашем корпусе, такую оценку, с набором вопросов и честным сравнением, мы делаем в проектах по внедрению ИИ-агентов.