GraphRAG: от локального к глобальному суммаризированию по запросам

Статья Microsoft о GraphRAG появилась в апреле 2024 года и быстро стала основным справочным материалом для всех, кто задавался вопросом, могут ли графы знаний спасти RAG от его самого очевидного провала: вопросов, требующих синтеза всего корпуса текстов, а не извлечения конкретного отрывка. Я читаю её сейчас, потому что предыдущая запись в журнале о FinAuditing показала, как тяжело LLM даются многодокументные структуры XBRL — и подход GraphRAG с суммаризацией сообществ является наиболее заметным ответом именно на такого рода задачи глобального логического вывода.

Статья

В работе «От локального к глобальному: подход Graph RAG к суммаризированию по запросам», написанной Дарреном Эджем, Ха Тринем, Ньюманом Ченгом и другими исследователями из Microsoft (arXiv:2404.16130), предлагается двухэтапный конвейер на базе LLM для ответа на то, что авторы называют «вопросами глобального осмысления» (global sensemaking questions). Это такие запросы, как «Каковы основные темы в этом наборе данных?», на которые стандартный векторный RAG не может ответить, поскольку ни один отдельный фрагмент текста не содержит полного ответа.

Подход реализуется в две фазы. Во время индексации LLM извлекает сущности, отношения и утверждения из каждого текстового блока, объединяет их в взвешенный граф сущностей, а затем запускает алгоритм Лейдена для обнаружения сообществ, чтобы разделить граф на иерархию связанных кластеров. На каждом уровне для каждого сообщества генерируется резюме на естественном языке. В момент запроса каждое резюме сообщества независимо генерирует частичный ответ (шаг map), эти частичные ответы ранжируются по показателю полезности и собираются в пределах окна контекста (шаг reduce), в результате чего формируется окончательный синтезированный ответ.

Ключевые идеи

• Иерархическое обнаружение сообществ Лейдена структурирует корпус на четыре уровня детализации (C0–C3), позволяя пользователям балансировать между глубиной ответа и стоимостью токенов — резюме корневого уровня требовали на 97% меньше токенов, чем прямая обработка исходного текста.
• На двух тестовых корпусах — транскриптах подкастов (~1 млн токенов, 8 564 сущности, 20 691 ребро отношений) и новостных статьях (~1,7 млн токенов, 15 754 сущности, 19 520 ребер) — GraphRAG достиг доли побед 72–83% по полноте и 62–82% по разнообразию в сравнении с векторным RAG при парном сопоставлении с использованием LLM в качестве судьи.
• Дизайн map-reduce позволяет избежать вызовов LLM с длинным контекстом во время запроса: сводки сообществ вычисляются заранее, поэтому поиск сводится к извлечению готового резюме, а не к повторной обработке исходных документов.
• В статье сравниваются шесть условий: четыре уровня иерархии GraphRAG, суммаризация текста (TS) и семантический поиск (SS). Глобальные условия GraphRAG стабильно превосходят SS в вопросах осмысления; SS лучше справляется с конкретными поисковыми запросами.
• Эксперименты по извлечению утверждений показали, что глобальные условия извлекали в среднем 31–34 утверждения на ответ против 25–26 у векторного RAG, что указывает на более широкий тематический охват независимо от предпочтений LLM-судьи.
• Конвейер не требует специфической для домена схемы или онтологии — извлечение сущностей, маркировка отношений и суммаризация сообществ выполняются исключительно на основе промптов.

Что подтверждается, а что нет

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

Однако к оценке есть серьезные вопросы. Недавнее независимое исследование (arXiv:2506.06331) провело аудит методологии «LLM-как-судья», использованной в GraphRAG и его последователях, и выявило три систематические ошибки: предвзятость позиции (доля побед меняется более чем на 30% просто при изменении порядка ответов в промпте), предвзятость длины (разница в 25 токенов при ответе в 200 токенов создает разрыв в 50 пунктов в доле побед) и предвзятость попыток (идентичные оценки дают противоречивые результаты в разных запусках). После корректировки этих факторов заявленные преимущества в производительности рушатся — например, сообщаемый показатель побед LightRAG в 66,7% над обычным RAG корректируется до 39,06%. Собственные показатели полноты GraphRAG в 72–83%, скорее всего, страдают от тех же методологических проблем.

Стоимость индексации также является серьезным препятствием. Один из анализов практиков указал на затраты на создание индекса, достигающие $47,9 при использовании GPT-4o для корпусов среднего размера. Собственный вариант Microsoft — LazyGraphRAG, выпущенный позже, снижает эти затраты до 0,1% от стоимости полного GraphRAG за счет переноса извлечения графа на момент запроса, что является косвенным признанием того, что первоначальный бюджет индексации непрактичен для многих реальных сценариев.

Два оценочных корпуса также довольно узки: два англоязычных набора данных по 1–1,7 млн токенов каждый. Авторы признают, что обобщаемость на другие домены и масштабы неизвестна. Для структурированных или полуструктурированных данных — финансовых отчетов, выгрузок из учетных книг — промпты для извлечения сущностей, оптимизированные для повествовательного текста, могут упускать табличные и иерархические связи, которые наиболее важны на практике.

Почему это важно для финансового ИИ

Гроссбух Beancount — это именно тот корпус, где вопросы глобального осмысления возникают естественным образом: «Каковы мои самые крупные категории расходов за последние три года?» или «Какие счета поставщиков росли быстрее, чем на 20% в год?». Стандартный RAG не может на них ответить, так как ни одна запись не содержит ответа — агенту нужно синтезировать данные из тысяч транзакций.

Подход GraphRAG с суммаризацией сообществ хорошо накладывается на это: если узлами графа знаний являются счета, получатели платежей и категории транзакций, а ребрами — их совместная встречаемость или отношения «родительский счет», то резюме сообществ становятся предварительно вычисленными агрегированными представлениями гроссбуха. Иерархия также отражает то, как дерево счетов Beancount уже структурирует данные — Активы (Assets), Расходы (Expenses) и Доходы (Income) декомпозируются рекурсивно, что идеально подходит для иерархической кластеризации в духе Лейдена.

Тем не менее, выводы об ошибках оценки служат предупреждением: впечатляющие показатели побед в статье могут не подтвердиться при строгом контролируемом тестировании, а стоимость индексации делает этот инженерный выбор более рискованным, чем кажется. Конкретно для Beancount структурированная агрегация — SQL-запросы или pandas поверх экспортированного гроссбуха — может превзойти суммаризацию сообществ на базе LLM в задачах детерминированной аналитики. Ценность GraphRAG будет максимальной для вопросов с упором на повествование, таких как анализ примечаний к транзакциям и имен поставщиков в масштабе, где существует подлинная двусмысленность, которую не могут разрешить структурированные запросы.

Что почитать дальше

• LazyGraphRAG (блог Microsoft Research, 2024) — вариант Microsoft с уменьшенной стоимостью, откладывающий извлечение графа; напрямую относится к вопросу о возможности развертывания подхода GraphRAG в масштабе реальных гроссбухов без непомерных затрат на индексацию.
• «Насколько значительны реальные выигрыши в производительности? Непредвзятая структура оценки для GraphRAG» (arXiv:2506.06331) — систематический аудит предвзятости; обязательное чтение перед тем, как принимать любые цифры доли побед из оценок суммаризации методом «LLM-как-судья».
• «На пути к верифицируемо безопасному использованию инструментов LLM-агентами» (arXiv:2601.08012, ICSE 2026) — следующий пункт в списке чтения; переход от суммаризации к безопасности записи данных, что является более насущной нерешенной проблемой для агентов Beancount.