Graph RAG je prístup retrieval-augmented generation, ktorý ukladá znalosti nie (len) ako vektory, ale ako knowledge graph z entít a ich vzťahov. Zatiaľ čo klasický RAG zodpovedá otázku cez sémantickú podobnosť — hľadá textové pasáže ležiace najbližšie k dopytu — Graph RAG nasleduje explicitné spojenia medzi entitami. To ho robí silným tam, kde sú vzťahy a viacstupňové úsudky (multi-hop) dôležitejšie než čistá textová podobnosť.

• Čo to je: RAG variant, ktorý ako zdroj znalostí využíva knowledge graph (entity plus relácie) — samostatne alebo navyše k vektorovému indexu.
• Kedy pomáha: Pri multi-hop otázkach, otázkach na vzťahy a globálnych prehľadových otázkach o celom korpuse.
• Čo stojí: Vyššie náklady na indexovanie a údržbu než vektorový RAG, pretože extrakcia grafu prebieha s podporou LLM.

Prečo čistá podobnosť naráža na hranice

Klasický RAG pracuje dvojstupňovo: V indexovacej ceste sa dokumenty parsujú, rozkladajú na chunky, prevádzajú embedding modelom na vektory a zapisujú do vektorovej databázy. V dopytovacej ceste sa otázka tiež embeduje, najpodobnejšie chunky (top-k) sa získajú, voliteľne sa cez hybrid search skombinujú s BM25 a cez re-ranker spresnia, a nakoniec všetko skončí v prompte generátora. Tento vzor je robustný a pre väčšinu znalostných otázok postačujúci. Anthropic Contextual Retrieval napríklad ukazuje, že chyby retrievalu sa dajú znížiť až o 67 % cez chunk-špecifické kontextové hlavičky a reranking (Anthropic, stav 09/2024).

Slepé miesto vzniká pri dvoch typoch otázok:

• Multi-hop otázky: „Ktorí dodávatelia nášho najväčšieho zákazníka sú sami zasiahnutí sankciami?" si vyžaduje reťaz úsudkov — zákazník -> dodávatelia -> stav sankcií —, ktorá nie je obsiahnutá v žiadnom jednotlivom chunku. Top-k podobnosť tu často poskytne len fragmenty, bez vytvorenia spojenia.
• Globálne prehľadové otázky: „Čo sú tých päť centrálnych tém naprieč všetkými 2 000 support-tiketmi?" sa nedá zodpovedať tým, že sa získa päť až desať podobných chunkov. Odpoveď vyžaduje agregáciu cez celý korpus.

Práve tu nastupuje Graph RAG: namiesto hľadania izolovaných kúskov textu naviguje explicitnú znalostnú štruktúru.

Zostavenie knowledge graph namiesto (alebo navyše k) vektorovému indexu

Jadrom Graph RAG je indexovanie. Zo zdrojových dokumentov sa pomocou LLM extrahuje graf:

1. Extrakcia entít: LLM identifikuje entity (osoby, organizácie, produkty, miesta, koncepty) a opisuje ich.
2. Extrakcia vzťahov: Rozpozná vzťahy medzi týmito entitami („dodáva do", „je dcérou", „spôsobuje") vrátane opisu a prípadne váhy.
3. Konštrukcia grafu: Entity sa stávajú uzlami, vzťahy hranami. Viackrát spomenuté entity sa zlúčia.

Microsoftov open-source prístup GraphRAG (Microsoft Research) rozširuje tento základný vzor o dva centrálne kroky (stav 2026):

• Community-detection: Cez graph-clustering (napríklad Leiden algoritmus) sa tesne prepojené uzly zoskupujú do hierarchických „communities" — tematických podgrafov.
• Community-summaries: Pre každú community vytvorí LLM už v čase indexovania zhrnutie. Tieto summaries sú kľúčom pre globálne otázky: pri prehľadovej otázke sa nevyužívajú jednotlivé chunky, ale community-summaries ako stavebné prvky map-reduce odpovede.

Z toho vyplývajú dva režimy dopytovania: Local Search zodpovedá zacielené otázky o určitej entite a jej okolí v grafe; Global Search zodpovedá tematické otázky naprieč celým korpusom cez community-summaries.

Pseudokód: indexovanie a dopytovanie

```text

Indexovanie (offline, náročné na LLM)

for dokument in korpus:
entity, vztahy = LLM_extrahuj(dokument)
graf.merge(entity, vztahy)

communities = cluster(graf) # napr. Leiden
for c in communities:
c.summary = LLM_zhrn(c) # community-summary

Dopytovanie (online)

if otazka_je_globalna(otazka):
ciastkove_odpovede = [LLM(otazka, c.summary) for c in relevantne_communities]
odpoved = LLM_reduce(otazka, ciastkove_odpovede) # Global Search
else:
subgraf = graf.traverzuj(start=entity_z(otazka), hops=2)
odpoved = LLM(otazka, subgraf + prislusne_chunky) # Local Search
```

Graph RAG vs. vektorový RAG v priamom porovnaní

Rozhodnutie nie je otázkou buď-alebo, ale otázkou typu otázky a rozpočtu. Nasledujúca matica zhŕňa rozdiely.

Hodnoty latencie a hybridu pre klasický RAG pochádzajú z výskumnej základne Blck Alpaca (porovnávacia matica RAG architektúr). Charakteristika Graph RAG vychádza z overených všeobecných znalostí o projekte GraphRAG a o knowledge-graph indexoch vo frameworkoch ako LlamaIndex.

Náklady a komplexnosť kalkulované úprimne

Najväčší rozdiel je v indexingu. Pri vektorovom RAG je najdrahšou jednorazovou operáciou embedding na chunk — ako rádový údaj výskumná základňa uvádza náklady na indexovanie okolo 0,02–0,13 amerického dolára na jeden milión tokenov, s Anthropic prompt-cachingom pre Contextual Retrieval približne 1,02 amerického dolára na milión document-tokenov (stav 09/2024). Graph RAG navyše vyžaduje viacero LLM prechodov na dokument: extrakciu entít, extrakciu vzťahov a community-summaries. To znásobuje náklady na indexovanie aj dĺžku indexovania.

Konkrétny príklad výpočtu

Predpokladajme, že agentúra indexuje pre zákazníka znalostný korpus 50 000 dokumentov:

• Vektorový RAG: Jednorazový embedding plus hybridný index. Hlavnými nákladmi sú embedding API a hosting vektorovej DB. Aktualizácie prebiehajú inkrementálne cez stabilné doc-ID.
• Graph RAG: Na každý dokument pripadá viacero volaní LLM na extrakciu, potom volania LLM na každú community pre summaries. Už pri strednej veľkosti korpusu tak vzniká násobok nákladov na indexovanie oproti vektorovému RAG — plus dodatočná prevádzková náročnosť na graf-schému, deduplikáciu entít a re-indexovanie pri väčších zmenách.

Pravidlo palca: Graph RAG sa vyplatí, keď pridaná hodnota odpovedí založených na vzťahoch ospravedlňuje vyššiu náročnosť — nie ako default. Výskum Blck Alpaca vo všeobecnosti varuje pred anti-patternom „RAG ako silver bullet"; to platí pre Graph RAG v zostrenej forme, pretože tu je total cost of ownership výrazne vyššia.

Kedy Graph RAG, kedy nie

Vhodný, keď:

• odpovede musia prepájať informácie naprieč mnohými dokumentmi (dodávateľské reťazce, org-štruktúry, compliance siete, výskumné a patentové krajiny).
• explicitné vzťahy medzi entitami sú odborne centrálne.
• majú sa zodpovedať globálne prehľadové a tematické otázky o celom korpuse.

Skôr nie, keď:

• otázky sa prevažne týkajú jednotlivých faktov alebo úzko vymedzených pasáží — tu stačí hybridný RAG s re-rankingom.
• korpus je malý alebo sa často kompletne prepisuje (údržba grafu sa stáva úzkym hrdlom).
• rozpočet neunesie LLM-náročné indexovanie.

V praxi je najudržateľnejšia hybridná architektúra: vektorový, resp. hybridný retrieval poskytuje široké sémantické pokrytie, knowledge graph sa cielene pripája pre otázky na vzťahy a multi-hop otázky. Tak zostáva Graph RAG presnou nadstavbou namiesto drahej kompletnej náhrady.

DACH upozornenie: ochrana údajov platí aj v grafe

Pre DACH podniky Graph RAG nemení nič na zásadách GDPR. Entity a vzťahy s osobnou väzbou treba — rovnako ako embeddings a chunky pri klasickom RAG — spravovať ako adresovateľné, vymazateľné záznamy. Platí účelová viazanosť a minimalizácia údajov (čl. 5), právny základ na spracúvanie (čl. 6) a právo na vymazanie (čl. 17). Oddelenie mandantov, koncept rolí/oprávnení a hosting v EU regióne zostávajú povinnosťou. Datenschutzkonferenz adresuje tieto požiadavky vo svojej orientačnej pomôcke k RAG (stav 2024/2025). Tieto údaje sú informatívne a nepredstavujú právne poradenstvo.

Pre agentúry a B2B rozhodovateľov

Graph RAG nie je hype-náhrada za vektorový RAG, ale špecializovaný nástroj pre znalosti náročné na vzťahy. Pre agentúry to znamená: začnite s hybridným RAG plus re-rankingom ako solídnym štandardným základom a Graph RAG zavádzajte len tam, kde multi-hop alebo prehľadové otázky prinášajú preukázateľnú obchodnú hodnotu. Pre B2B rozhodovateľov nie je centrálnou otázkou „Ktorá technika je novšia?", ale „Aké otázky naši používatelia naozaj kladú — a potrebujú tieto odpovede vzťahy alebo len podobnosť?". Blck Alpaca podporuje pri tomto rozlíšení, úprimne kalkuluje TCO a buduje RAG architektúry v súlade s GDPR, ktoré rastú so skutočnou potrebou — od štíhleho vektorového indexu až po hybridný knowledge-graph systém.