GraphRAG: От локално към глобално обобщаване, фокусирано върху заявки

Научният доклад за GraphRAG на Microsoft се появи през април 2024 г. и бързо се превърна в основна референция за всеки, който се пита дали графите на знанието могат да спасят RAG от неговия най-очевиден режим на провал: въпроси, които изискват синтезиране на целия корпус, а не извличане на конкретен пасаж. Чета го сега, защото предишният запис за FinAuditing разкри как големите езикови модели (LLM) се затрудняват с многодокументни XBRL структури — и подходът на GraphRAG с резюмета на общности е най-известният съществуващ отговор на точно такъв вид проблем с глобалните разсъждения.

Докладът

„From Local to Global: A Graph RAG Approach to Query-Focused Summarization“ от Дарън Едж, Ха Трин, Нюман Ченг, Джошуа Брадли, Алекс Чао, Апурва Моди, Стивън Труит, Даша Метрополитански, Робърт Осазува Нес и Джонатан Ларсън (Microsoft, arXiv:2404.16130), предлага двустепенен работен процес, задвижван от LLM, за отговор на това, което авторите наричат „въпроси за глобално осмисляне“ — заявки като „Кои са основните теми в този набор от данни?“, на които стандартният векторен RAG не може да отговори, тъй като нито един пасаж не съдържа отговора.

Подходът преминава през две фази. По време на индексирането, LLM извлича ентитети, връзки и твърдения от всеки текстов блок, сглобява ги в претеглен граф на ентитети и след това изпълнява Leiden алгоритъм за откриване на общности, за да раздели графа в йерархия от свързани клъстери, генерирайки резюме на естествен език за всяка общност на всяко ниво. По време на заявка, всяко резюме на общност независимо генерира частичен отговор (стъпка map), тези частични отговори се класират по оценка за полезност и се сглобяват до границата на прозореца на контекста (стъпка reduce), а резултатът е окончателен синтезиран отговор.

Ключови идеи

• Leiden йерархичното откриване на общности структурира корпуса в четири нива на детайлност (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 са принципен начин за заобикаляне на проблема, а йерархията, базирана на Leiden, е реален избор в дизайна, който ви позволява да навигирате от общи глобални резюмета до детайлни резюмета на клъстери в зависимост от допустимите разходи.

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

Разходите за индексиране също са истинско препятствие. Един практически анализ цитира разходи за изграждане на индекс, достигащи 47,9 долара с GPT-4o за корпуси с умерен размер. Вариантът LazyGraphRAG на Microsoft, пуснат като продължение, намалява това до 0,1% от цената на пълния GraphRAG чрез отлагане на извличането на графа до момента на заявката — което е негласно признание, че първоначалният бюджет за индексиране е непрактичен за много реални внедрявания.

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

Защо това е важно за финансовия ИИ

Главната книга на Beancount е точно такъв корпус, в който естествено възникват въпроси за глобално осмисляне: „Кои са най-големите ми категории разходи през последните три години?“ или „Кои сметки на доставчици са нараснали с повече от 20% на годишна база?“. Стандартният RAG не може да отговори на тях, защото нито един запис не съдържа отговора — агентът трябва да синтезира информация от хиляди трансакции.

Подходът на GraphRAG с резюмета на общности се вписва в това: ако възлите в графа на знанието са сметки, получатели и категории трансакции, а ребрата са съвместни появи или връзки между родителски сметки, тогава резюметата на общностите се превръщат в предварително изчислени агрегирани изгледи над главната книга. Йерархията също отразява начина, по който дървото на сметките в Beancount вече структурира данните — Активи, Разходи и Приходи се разлагат рекурсивно, което е естествено подходящо за йерархично клъстериране в стил Leiden.

Въпреки това, констатациите за предразположение при оценяването са предупреждение: впечатляващите нива на победа в доклада може да не се запазят при строго контролирано тестване, а разходите за индексиране правят това по-тежък инженерен залог, отколкото изглежда. Конкретно за 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.