Prejsť na hlavný obsah

GraphRAG: Od lokálnej po globálnu sumarizáciu zameranú na dopyty

· 6 minút čítania
Mike Thrift
Mike Thrift
Marketing Manager

Práca o GraphRAG od Microsoftu sa objavila v apríli 2024 a rýchlo sa stala kľúčovou referenciou pre každého, kto sa pýtal, či by znalostné grafy mohli zachrániť RAG pred jeho najzjavnejším zlyhaním: otázkami, ktoré si vyžadujú syntézu celého korpusu namiesto vyhľadania konkrétnej pasáže. Čítam si ju teraz, pretože predchádzajúci záznam o FinAuditing odhalil, ako modely LLM bojujú s viacdokumentovými štruktúrami XBRL – a prístup GraphRAG založený na súhrnoch komunít je najvýznamnejšou existujúcou odpoveďou práve na tento druh problému s globálnym uvažovaním.

Odborná práca

2026-06-04-graphrag-local-to-global-query-focused-summarization

"From Local to Global: A Graph RAG Approach to Query-Focused Summarization" od autorov: Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness a Jonathan Larson (Microsoft, arXiv:2404.16130), navrhuje dvojfázový potrubný proces (pipeline) riadený LLM na odpovedanie na to, čo autori nazývajú „globálne otázky o zmysle údajov“ (global sensemaking questions) – dopyty ako „Aké sú hlavné témy v tomto súbore údajov?“, na ktoré štandardný vektorový RAG nedokáže odpovedať, pretože žiadna jednotlivá pasáž neobsahuje odpoveď.

Prístup prebieha v dvoch fázach. Počas indexovania LLM extrahuje entity, vzťahy a tvrdenia z každého textového bloku, zostavuje ich do váženého grafu entít a potom spúšťa detekciu komunít pomocou Leidenského algoritmu na rozdelenie grafu do hierarchie súvisiacich klastrov, pričom pre každú komunitu na každej úrovni generuje súhrn v prirodzenom jazyku. V čase dopytu každý súhrn komunity nezávisle vygeneruje čiastočnú odpoveď (krok map), tieto čiastočné odpovede sú zoradené podľa skóre užitočnosti a zostavené až do limitu kontextového okna (krok reduce), pričom výsledkom je finálna syntetizovaná odpoveď.

Kľúčové myšlienky

  • Hierarchická detekcia komunít pomocou Leidenského algoritmu štruktúruje korpus do štyroch úrovní podrobnosti (C0 – C3), čo používateľom umožňuje vymeniť hĺbku odpovede za náklady na tokeny – súhrny na koreňovej úrovni vyžadovali o 97 % menej tokenov ako priame spracovanie zdrojového textu.
  • V dvoch testovacích korpusoch – prepisoch podcastov (~1 mil. tokenov, 8 564 entít, 20 691 hrán vzťahov) a novinových článkoch (~1,7 mil. tokenov, 15 754 entít, 19 520 hrán) – dosiahol GraphRAG 72 – 83 % mieru víťazstiev v komplexnosti a 62 – 82 % v diverzite v porovnaní s vektorovým RAG pri párových porovnaniach posudzovaných LLM.
  • Dizajn map-reduce zabraňuje volaniam LLM s dlhým kontextom v čase dopytu: súhrny komunít sú vopred vypočítané, takže vyhľadávanie sa stáva získaním súhrnu namiesto opätovného spracovania nespracovaných dokumentov.
  • Práca porovnáva šesť podmienok: štyri úrovne hierarchie GraphRAG, sumarizáciu textu (TS) a sémantické vyhľadávanie (SS). Globálne podmienky GraphRAG konzistentne prekonávajú SS v otázkach zameraných na zmysel údajov; SS dosahuje lepšie výsledky pri špecifických vyhľadávacích dopytoch.
  • Experimenty s extrakciou tvrdení zistili, že globálne podmienky extrahovali v priemere 31 – 34 tvrdení na odpoveď oproti 25 – 26 pri vektorovom RAG, čo naznačuje širšie tematické pokrytie nezávislé od preferencií skórovania LLM sudcu.
  • Potrubný proces (pipeline) nevyžaduje žiadnu doménovo špecifickú schému ani ontológiu – extrakcia entít, označovanie vzťahov a sumarizácia komunít pochádzajú výhradne z dopytovaného odvodzovania (prompted inference).

Čo obstojí — a čo nie

Základný architektonický poznatok je správny: RAG založený na kosínusovej podobnosti nedokáže odpovedať na otázky na úrovni korpusu, pretože neexistuje žiadny jednotlivý blok, ktorý by reprezentoval celok. Vopred vypočítané súhrny komunít v GraphRAG sú principiálnym riešením a hierarchia založená na Leidenskom algoritme je skutočnou dizajnovou voľbou, ktorá vám umožňuje prechádzať od hrubých globálnych súhrnov k detailným súhrnom klastrov v závislosti od tolerancie nákladov.

Ale vyhodnotenie má vážne problémy. Nedávna nezávislá štúdia (arXiv:2506.06331) auditovala metodiku LLM-ako-sudca použitú v GraphRAG a jeho nástupcoch a zistila tri systematické skreslenia: skreslenie pozície (miera víťazstiev sa posunie o viac ako 30 % jednoducho zámenou toho, ktorá odpoveď sa v prompte objaví ako prvá), skreslenie dĺžky (rozdiel 25 tokenov v 200-tokenovej odpovedi vytvorí 50-bodový posun v miere víťazstiev) a skreslenie pokusov (identické vyhodnotenia produkujú protichodné výsledky naprieč spusteniami). Po korekcii týchto faktorov sa deklarované výkonnostné výhody zrútia – uvádzaná 66,7 % miera víťazstiev LightRAG nad naivným RAG sa po oprave zmení na 39,06 %. Vlastné čísla komplexnosti GraphRAG na úrovni 72 – 83 % takmer určite trpia rovnakou metodikou.

Náklady na indexovanie sú tiež reálnou prekážkou. Analýza jedného odborníka z praxe uvádza náklady na konštrukciu indexu dosahujúce 47,9 USD pri modeli GPT-4o pre stredne veľké korpusy. Vlastný variant LazyGraphRAG od Microsoftu, vydaný ako nadväzujúca práca, to znižuje na 0,1 % nákladov plného GraphRAG tým, že odkladá extrakciu grafu na čas dopytu – čo je implicitné priznanie, že pôvodný rozpočet na indexovanie je pre mnohé reálne nasadenia nepraktický.

Dva vyhodnocovacie korpusy sú tiež úzko zamerané: dva súbory údajov v angličtine s celkovým počtom 1 – 1,7 mil. tokenov každý. Autori pripúšťajú, že zovšeobecnenie na iné domény a škály nie je známe. Pre štruktúrované alebo pološtruktúrované údaje – finančné výkazy, exporty účtovných kníh – môžu prompty na extrakciu entít optimalizované pre naratívny text prehliadnuť tabuľkové a hierarchické vzťahy, ktoré sú v praxi najdôležitejšie.

Prečo je to dôležité pre finančnú AI

Účtovná kniha Beancount je presne tým korpusom, kde sa prirodzene vynárajú globálne otázky o zmysle údajov: „Aké sú moje najväčšie kategórie výdavkov za posledné tri roky?“ alebo „Ktoré účty dodávateľov rástli rýchlejšie ako o 20 % medziročne?“ Štandardný RAG na ne nedokáže odpovedať, pretože žiadny jednotlivý záznam neobsahuje odpoveď – agent potrebuje syntetizovať informácie naprieč tisíckami transakcií.

Prístup GraphRAG so súhrnmi komunít sa na toto hodí: ak sú uzlami znalostného grafu účty, príjemcovia a kategórie transakcií a hranami sú vzťahy spoločného výskytu alebo vzťahy materských účtov, potom sa súhrny komunít stávajú vopred vypočítanými agregovanými pohľadmi na účtovnú knihu. Hierarchia tiež odzrkadľuje to, ako strom účtov v Beancount už štruktúruje údaje – Aktíva (Assets), Výdavky (Expenses) a Príjmy (Income) sa rozkladajú rekurzívne, čo sa prirodzene hodí pre hierarchické klastrovanie v štýle Leidenského algoritmu.

Napriek tomu sú zistenia o skreslení vyhodnocovania varovaním: pôsobivé miery víťazstiev v práci nemusia platiť pri prísnom kontrolovanom testovaní a náklady na indexovanie robia z tohto riešenia náročnejšiu inžiniersku stávku, než sa zdá. Špeciálne pre Beancount môže štruktúrovaná agregácia – dopyty v štýle SQL alebo pandas nad exportovanou účtovnou knihou – prekonať sumarizáciu komunít riadenú LLM pri deterministickej analytike. Hodnota GraphRAG by bola najvyššia pri naratívne náročných otázkach, ako je uvažovanie nad poznámkami k transakciám a názvami dodávateľov vo veľkom rozsahu, kde existuje skutočná nejednoznačnosť, ktorú štruktúrované dopyty nedokážu vyriešiť.

Čo si prečítať ďalej

  • LazyGraphRAG (blog Microsoft Research, 2024) – variant od Microsoftu so zníženými nákladmi, ktorý odkladá extrakciu grafu; priamo relevantné pre to, či je prístup GraphRAG nasaditeľný v reálnom rozsahu účtovnej knihy bez neúnosných nákladov na indexovanie.
  • „How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG“ (arXiv:2506.06331) – audit systematického skreslenia; povinné čítanie pred prijatím akéhokoľvek čísla miery víťazstiev z vyhodnotení metód sumarizácie pomocou LLM-ako-sudcu.
  • „Towards Verifiably Safe Tool Use for LLM Agents“ (arXiv:2601.08012, ICSE 2026) – ďalšia položka v zozname čítania; prechod od sumarizácie k bezpečnosti spätného zápisu, čo je pálčivejší nevyriešený problém pre agentov Beancount.