GraphRAG: Від локального до глобального узагальнення, орієнтованого на запити

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

Стаття

У статті «From Local to Global: A Graph RAG Approach to Query-Focused Summarization» авторів Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness та Jonathan Larson (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 вже структурує дані — Активи, Витрати та Доходи розкладаються рекурсивно, що ідеально підходить для ієрархічної кластеризації за Лейденом.

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

Що почитати далі

• LazyGraphRAG (блог Microsoft Research, 2024) — варіант Microsoft зі зниженою вартістю, що відкладає вилучення графа; безпосередньо стосується того, чи можна розгорнути підхід GraphRAG у масштабах реальної бухгалтерської книги без надмірних витрат на індексування.
• «How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG» (arXiv:2506.06331) — систематичний аудит упередженості; обов’язкове читання перед прийняттям будь-яких цифр коефіцієнта перемог з оцінювань методів резюмування за допомогою LLM.
• «Towards Verifiably Safe Tool Use for LLM Agents» (arXiv:2601.08012, ICSE 2026) — наступний пункт у списку читання; перехід від узагальнення до безпеки запису даних, що є більш нагальною невирішеною проблемою для агентів Beancount.