Průvodce GraphRAG: Kdy graf znalostí porazí vektorové RAG (a kdy ne)

Průvodce GraphRAG: Kdy graf znalostí porazí vektorové RAG (a kdy ne)

GraphRAG není mrtvý, ale není to ani výchozí volba. microsoft/graphrag vydal 2026-07-18 verzi v3.1.1 s 35 088 hvězdičkami na GitHubu a tři benchmarkové studie z roku 2026 teď otevřeně uvádějí, že často prohrává s obyčejným vektorovým vyhledáváním. Tento průvodce GraphRAG proto odpovídá na jedinou zbývající otázku: vyplatí se graf znalostí za svůj indexační účet?

Měli byste GraphRAG používat? Krátká odpověď

GraphRAG použijte, když vaše dotazy propojují entity nebo zahrnují celý korpus, třeba „kterým dodavatelům také prodává náš největší zákazník?". U jednoskokových faktických dotazů, rychle se měnících dokumentů a těsných latencí zůstaňte u obyčejného nebo hybridního RAG. Graf se zaplatí u víceskokových dotazů a všude jinde stojí jen peníze.

GraphRAG není mrtvý a není to výchozí volba. Svůj indexační účet si obhájí, když jsou vaše dotazy víceskokové nebo globální pro celý korpus, a proděláváte na něm, když nejsou.

Krátká verze:

• GraphRAG vyhrává u víceskokových dotazů a dotazů napříč celým korpusem; obyčejné RAG vyhrává u jednoskokových dotazů.
• Benchmarky z roku 2026 jsou nejednoznačné: grafy pomáhají u agregací, ale mohou škodit u detailních sumářů.
• Náklady vznikají při indexaci, v LLM voláních pro extrakci, ne při dotazování.
• Než cokoli postavíte, spusťte na vlastním korpusu Basic Search jako kontrolu.

Pokud už provozujete funkční pipeline vektorového RAG, jediným rozhodnutím je, jestli se graf navrch sám uživí. Níže uvedená tabulka shrnuje celou argumentaci do šesti řádků, a tam, kde říká zůstat u klasiky, je to upřímná odpověď, častěji, než prodejci přiznávají. Hybridní vyhledávání BM25 plus vektory pokrývá většinu těchto případů úplně bez grafu.

Co GraphRAG vlastně je: Od chunků ke komunitám

GraphRAG je retrieval-augmented generation nad grafem znalostí místo nad nepropojenými chunky. Při indexaci LLM extrahuje z dokumentů entity a vztahy, algoritmus Leiden tyto entity seskupí do komunit a každá komunita dostane souhrn. Při dotazování graf spolu s těmito souhrny odpovídá na otázky, na které okno top_k nad chunky ze své podstaty odpovědět nedokáže.

Celá pipeline od začátku do konce:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Práci odvádějí dvě fáze. Indexační fáze je ta drahá: každý chunk stojí LLM volání na vytažení entit a vztahů a souhrny komunit stojí další volání navrch. Fáze dotazování je místo, kde se ukáže přínos. Protože graf ukládá vztahy explicitně, otázka jako „kterým dodavatelům také prodává náš největší zákazník?" se stane průchodem grafem místo naděje, že ty správné dva chunky skončí ve stejném okně top_k.

Na souhrnech záleží, protože právě je ve skutečnosti čte Global Search: otázky napříč celým korpusem se zodpovídají z předem napsaného textu komunit, ne ze syrových chunků. A každá hrana je úsudek LLM, uložený jako trojice, kterou byste na skutečné grafové databázi mohli dotazovat v Cypheru. Kvůli tomuto návrhu také indexace tvoří většinu nákladů, což čísla níže dokládají konkrétně.

Rámec, který si zaslouží své místo: obyčejné RAG načítá pasáže a GraphRAG načítá strukturu. Vaše volba embeddingového modelu je stále důležitá pro vektorovou vrstvu a vaše vektorová databáze stále ukládá popisy, ale graf je nová nosná část. Oficiální dokumentace Index Overview popisuje každou fázi podrobně.

Jaké jsou čtyři dotazovací metody GraphRAG?

Dotazovací engine GraphRAG nabízí čtyři metody: Local Search, Global Search, DRIFT Search a Basic Search. Local Search uvažuje od konkrétních entit směrem ven, Global Search agreguje souhrny komunit napříč celým korpusem, DRIFT Search obě rekurzivně kombinuje a Basic Search je obyčejná vektorová baseline. Pátá funkce, Question Generation, stojí nad enginem, ne vedle něj.

2026-07-30 jsme zkontrolovali živou dokumentaci na microsoft.github.io/graphrag/query/overview/ a počet je čtyři. Většina návodů v žebříčcích uvádí dvě nebo tři. Stejná kontrola zjistila slovo „lazy" nulakrát na stránkách Index i Query overview, což je důležité pro sekci o nákladech níže.

Řádek, který si zaslouží vaši pozornost, je ten poslední. Basic Search je vestavěná baseline obyčejného vektorového vyhledávání a existuje proto, abyste mohli na vlastním korpusu A/B otestovat graf proti obyčejnému vyhledávání a zjistit, jestli si graf svůj účet zaslouží. To není maličkost; je to celý rozhodovací postup tohoto průvodce v jediné funkci. Spusťte Basic Search jako první. Pokud ho Local, Global ani DRIFT search neporazí na otázkách, které skutečně dostáváte, graf je náklad, ne vylepšení.

Co vlastně zjistily benchmarky z roku 2026?

Tři benchmarkové studie z roku 2026 zjišťují, že GraphRAG pomáhá u víceskokových úloh a úloh s agregací více faktů, ale jinde často zaostává za obyčejným RAG. Jedna z nich postavila benchmark přímo proto, aby našla, kde grafy prohrávají. Všechny tři se shodují, že výhra závisí na typu otázky, ne na velikosti korpusu. Důkazy říkají, že GraphRAG je situační, ne výchozí.

Čtvrtá práce, GraphRAG-Bench (repozitář), hodnotí devět metod GraphRAG napříč 16 obory a 20 učebnicemi a dochází ke stejnému závěru ze širšího úhlu.

Všechny tři studie se shodují v jednom bodě: graf si své náklady obhájí u víceskokové agregace a prodělává na nich u detailního vybavování.

Náš pohled: hype cyklus napáchal škody a tyto studie jsou náprava. Žádná z nich neříká, že grafy jsou k ničemu. Co říkají konzistentně, je, že agregační krok, díky kterému je GraphRAG dobrý u témat napříč celým korpusem, je tentýž krok, který rozmazává detail. WildGraphBench je nejjasnější příklad: grafy pomohly agregaci více faktů ze středního počtu zdrojů a ve stejném hodnocení uškodily přesnosti sumarizace. To není rozpor; je to jeden mechanismus, který se projevuje dvakrát.

Praktický důsledek je, že se o tom nemůžete rozhodnout jen z literatury. Studie vám říkají, které typy otázek testovat, ne jestli je váš korpus jedním z nich. Přesně k tomu slouží kontrola pomocí Basic Search ze sekce o metodách výše.

Kolik GraphRAG stojí? (A caveat LazyGraphRAG, který všichni opakují špatně)

Náklady GraphRAG jsou účet v čase indexace, ne v čase dotazování, a přesně proto lidi překvapují. LLM volání, která extrahují entity a vztahy z každého chunku, plus průchod sumarizace komunit, jsou tím, co je dělá drahými. Platíte předem, než proběhne jediný dotaz. Čas dotazování je levnější, ale ne zdarma: Global Search se rozbíhá přes souhrny komunit s jedním LLM voláním na komunitu, proto ho tabulka metod výše označuje jako vysoký.

Jediná tvrdá veřejná čísla pocházejí od Microsoft Research. 2024-11-25 tým uvedl, že indexační náklady LazyGraphRAG byly shodné s vektorovým RAG a činily 0,1 % nákladů plného GraphRAG a že při 4 % nákladů na dotazování globálního vyhledávání GraphRAG překonal testované konkurenční metody u lokálních i globálních typů dotazů (Microsoft Research). Jsou to čísla Microsoftu z blogu Microsoftu a my je tak i uvádíme; vlastní cenově změřenou indexaci jsme nespouštěli.

Tady je oprava, kterou většina článků přehlíží. LazyGraphRAG není varianta, kterou nainstalujete přes pip. Podle vlastní editorské poznámky Microsoftu z 2025-06-06 se dostal do Microsoft Discovery a Azure Local, ne do open-source balíčku. 2026-07-30 jsme zkontrolovali oficiální stránky Index Overview a Query Overview: slovo „lazy" se na obou vyskytuje nulakrát. Takže pokud nějaký průvodce uvádí LazyGraphRAG jako variantu, kterou můžete odpoledne rozjet, opakuje tvrzení, které v open-source světě přestalo platit.

Co dnes udělat můžete: spustit extrakční model lokálně. Když indexační krok nasměrujete přes Ollamu na lokální model, odstraníte poplatky za API podle tokenů z nejdražší fáze a v kombinaci se samostatně hostovaným vektorovým úložištěm udržíte zbytek účtu blízko nule.

Která knihovna GraphRAG je vlastně udržovaná?

Dvě ze šesti nejcitovanějších knihoven GraphRAG neměly push šest, respektive devět měsíců. Tato čísla jsme vytáhli z GitHub API 2026-07-30 a soupis níže je kontrola, kterou starší přehledy přeskakují, včetně příkazu, jak ji zopakovat, než se pro jednu rozhodnete. LightRAG a microsoft/graphrag jsou aktivní; nano-graphrag a fast-graphrag se posouvají směrem k abandonwaru.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Náš pohled: hvězdičky jsou metrika pro marnivost; datum pushe je číslo, na kterém záleží. LightRAG i microsoft/graphrag se aktivně udržují, Graphiti je těsně za nimi s úhlem temporálního grafu. nano-graphrag a fast-graphrag jsou ty dvě, které starší články stále doporučují jen na základě reputace, a ani jedna půl roku nic nevydala.

Jak vybrat: zvolte microsoft/graphrag, pokud chcete referenční implementaci se čtyřmi oficiálními dotazovacími metodami, LightRAG, pokud chcete nejaktivnější projekt a lehčí stopu, a knihovnu udržovanou výrobcem jako neo4j-graphrag-python, pokud už databázi daného výrobce provozujete. Vyhněte se čemukoli, jehož poslední push předchází váš projekt o půl roku.

Graphiti si zaslouží jednu vymezenou poznámku: jeho návrh temporálního grafu je postavený na vyhledávání nad časově proměnnými daty a překrývá se s pamětí agentů, kterou pokrýváme samostatně v průvodci Graphiti a temporální grafová paměť. Pro širší pole se podívejte na širší přehled nástrojů pro RAG.

Co se rozbije po dni 200: Grafový drift a re-extrakce

Grafový drift je daň, kterou platíte po spuštění, a je to námitka praktiků číslo jedna, a to z dobrého důvodu. Každý návod se ke grafu chová jako k věci, kterou postavíte jednou. Reálné týmy uvíznou v den 200.

Tři věci degradují. Zaprvé, přeindexování při aktualizacích dokumentů. Když se změní 40 dokumentů, nemůžete je jen přegenerovat do vektorů; musíte znovu spustit LLM extrakci na změněných chuncích, sladit nové entity se starým grafem a přepočítat dotčené komunity a jejich souhrny. Jeden návod na Mediumu nazývá inkrementální aktualizaci snadnou. Praktici na r/Rag nesouhlasí. Autor vlákna z 2026-04-25, který provozuje BM25 plus BGE-M3 nad přibližně 600 dokumenty, to řekl přímo: „Extrakce entit a vztahů pomocí LLM je zašuměná a přeindexování při aktualizacích dokumentů vypadá bolestivě."

Zadruhé, degradace rozlišení entit. „Acme Corp", „Acme" a „ACME Corporation" dorazí v různých dokumentech měsíce od sebe a rozdělí se do tří uzlů, které by měly být jeden. Nic je automaticky nespojí.

Zatřetí, vztahy, které byly pravdivé v době extrakce a tiše přestaly platit. Nikdo nedostane alert, když hrana reports_to zestárne.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Kódová báze je nejhorší případ a ten nejzajímavější. Našeptávání teď nabízí „graphrag for codebase", „graphrag claude code" a „graphrag mcp server" a kódová báze je graf, který se mění každou hodinu: každý commit přepisuje hrany volání, přesouvá symboly a maže funkce. To je grafový drift podle plánu, který žádné noční přeindexování plně nezachytí. Je to také důvod, proč se seriózní nástroje pro grafové zpracování kódu opírají o deterministické parsery jako tree-sitter a LSP pro hrany a LLM si nechávají na text kolem nich: na docstringy, zprávy commitů a vlákna review. Pokud grafujete repo, grafujte pomalu se měnící vrstvu pomocí LLM a tu rychle se měnící pomocí parseru.

Co o GraphRAG skutečně říkají vývojáři?

Pracující vývojáři jsou rozdělení a Google to zřejmě ví: vlákno na Redditu se umisťuje na druhé pozici na dotaz „graphrag vs rag", což je způsob, jak vám vyhledávač říká, že toto téma chce názor komunity, ne text od prodejců.

Skepse je reálná. Ve vláknu r/Rag z roku 2024 „Would you always recommend (knowledge) graph RAG over normal RAG?" (10 bodů, 86 % upvotů) napsal u/EncartaIt: „Všechny návody, které jsem našel, jsou příliš zjednodušující a nedělají pro vzor s grafem znalostí žádnou silnou obhajobu." u/Prestigious_Run_4049 byl ostřejší: „Myslím, že graph rag je jen hype. Lidé o tom rádi mluví a zní to cool, ale nikdo to ve skutečnosti nepoužívá v reálných use cases." Ne všichni souhlasí. u/pytheryx, argumentující z produkce, poznamenal, že grafové vyhledávání vyhrává u otázek typu seznam, které potřebují kontext z více chunků, než kolik vrací top_k; jeho korpus bílých knih potřebuje pro úplnou odpověď kolem 50 chunků.

Vlákno z roku 2026 je umírněnější. u/Popular_Sand2773: „Většina nasazení graph rag ve velkém měřítku jen podvádí. Spustíte standardní vektorové nebo metadata vyhledávání, najdete počáteční uzly a pak se procházíte kolem." u/ggone20, provozující systém s přibližně 300 miliony artefaktů: „Ve velkém měřítku se bez nich doslova neobejdete, chcete-li odpovídat na reálné otázky."

Náš pohled se shoduje s nejostřejším argumentem v obou vláknech: zlomovým bodem je složitost vašich otázek, ne velikost vašeho korpusu. To je i to, co zjistily benchmarky výše, proto se stavíme na stranu praktiků, kteří nástroj vymezují na víceskokovou práci, spíš než těch, kteří ho prohlašují za mrtvý.

Jak k tomu přistupuje Techsy

Tady je postup, který používáme u klientských projektů, a je záměrně nudný.

Zaprvé, dokažte strop hybridního vyhledávání. Většina požadavků „potřebujeme graf", které slýcháme, je ve skutečnosti problém s chunkováním nebo rerankingem v přestrojení. Pipeline BM25 plus vektory se slušným rerankerem odpoví na víc, než týmy čekají.

Zadruhé, spusťte Basic Search jako kontrolu na vlastním korpusu, než cokoli postavíte. Přesně k tomu čtvrtá dotazovací metoda slouží: baseline obyčejného vektorového vyhledávání, vůči které můžete A/B testovat graf, na svých datech, se svými otázkami.

Zatřetí, graf postavte, teprve když změřená třída otázek na této kontrole selže. Pokud víceskokové dotazy nebo dotazy napříč celým korpusem selžou, máte reálný případ. Pokud ne, právě jste si ušetřili indexační účet a problém s driftem.

Chcete na svůj vyhledávací stack druhý pár očí? Získejte bezplatnou konzultaci.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů pro LLM, který tým Techsy skutečně používá v produkci. U klientských projektů dělá rozhodnutí o architektuře vyhledávání: kdy stačí hybridní vyhledávání a kdy korpus skutečně potřebuje graf. Spojte se s ním na LinkedInu.

Často kladené otázky

Jak GraphRAG funguje?

GraphRAG indexuje vaše dokumenty do grafu znalostí. LLM extrahuje z každého chunku entity a vztahy, algoritmus Leiden tyto entity seskupí do komunit a každá komunita dostane souhrn. V čase dotazování engine prohledává graf a tyto souhrny, takže dokáže propojit fakta, která leží v různých chuncích.

Čím se GraphRAG liší od RAG?

Standardní RAG načte top-k nejpodobnějších chunků a předá je modelu. GraphRAG načítá strukturu: entity, vztahy mezi nimi a předem napsané souhrny komunit. Právě tato struktura navíc mu umožňuje odpovídat na víceskokové dotazy a dotazy napříč celým korpusem a je to také to, co dělá indexaci pomalejší a dražší.

Kdy bych měl GraphRAG použít?

Použijte ho, když vaše dotazy propojují entity nebo zahrnují celý korpus, jako jsou otázky překryvu dodavatelů nebo analýza opakujících se témat nad tisíci dokumenty. Přeskočte ho u jednoskokových faktických dotazů, rychle se měnících korpusů a těsných rozpočtů na latenci nebo náklady. Pokud na třídu otázek už odpovídá obyčejná hybridní pipeline, graf přidává náklady bez přidané hodnoty.

Je GraphRAG mrtvý?

Ne, ale není to ani výchozí volba. Benchmarky z roku 2026 ukazují, že u běžných úloh často zaostává za obyčejným RAG, což zabilo hype, a přitom stále vyhrává u víceskokových a agregačních otázek. Upřímný rámec je situační: GraphRAG si své náklady obhájí u správných typů otázek a u zbytku prodělává.

Jaké jsou dotazovací metody GraphRAG?

Oficiální dotazovací engine nabízí čtyři: Local Search pro otázky zaměřené na entity, Global Search pro agregaci napříč celým korpusem, DRIFT Search pro rekurzivní kombinaci obou a Basic Search pro obyčejné vektorové vyhledávání. Pátá funkce, Question Generation, stojí navrch. Basic Search je nejdůležitější: je to kontrola, vůči které graf A/B testujete.

Kolik stojí indexace GraphRAG?

Náklady vznikají v čase indexace, v LLM voláních, která extrahují entity a vztahy z každého chunku, plus sumarizaci komunit. Microsoft Research uvedl indexaci LazyGraphRAG na 0,1 % nákladů plného GraphRAG a shodnou s vektorovým RAG, ale tato varianta se dostala do produktů Microsoftu, ne do open-source knihovny. My jsme cenově změřenou indexaci sami nespouštěli.

Můžu GraphRAG spustit lokálně s Ollamou?

Ano. Knihovna microsoft/graphrag umožňuje nasměrovat indexaci i dotazování na lokální model servírovaný Ollamou, což odstraní poplatky za API podle tokenů z extrakčního kroku. Vyměníte rychlost a kvalitu za náklady: lokální modely jsou v extrakci entit slabší, takže počítejte se zašumělejšími grafy a delšími indexačními běhy na skromném hardwaru.

Co je lepší, LightRAG, nebo Microsoft GraphRAG?

Optimalizují pro různé věci. LightRAG (38 353 hvězdiček, push 2026-07-30) je nejaktivnější a lehčí na provoz; microsoft/graphrag (35 088 hvězdiček, v3.1.1) je referenční implementace se čtyřmi oficiálními dotazovacími metodami. Zvolte LightRAG pro efektivní produkční graf, Microsoft pro chování věrné specifikaci a kontrolu pomocí Basic Search.

Kdo vytvořil GraphRAG a kdy?

GraphRAG vytvořil Microsoft Research. Tým publikoval studii v roce 2024 a udržuje open-source repozitář microsoft/graphrag pod licencí MIT, s dokumentací na microsoft.github.io/graphrag. Referenční knihovna dosáhla 2026-07-18 verze v3.1.1 a kolem ní vyrostl aktivní ekosystém implementací třetích stran, včetně LightRAG a Graphiti.

Verdikt: Kdy si graf zaslouží své náklady

Důkazy ukazují jedním směrem, takže tady je stanovisko.

• GraphRAG není mrtvý. Je situační a benchmarky z roku 2026 to říkají nahlas.
• Svůj indexační účet si obhájí u víceskokových dotazů na entity a u agregace napříč celým korpusem. U jednoskokových dotazů prodělává.
• Náklady jsou účet v čase indexace a levná varianta, kterou všichni citují, LazyGraphRAG, se do open-source knihovny nikdy nedostala.
• Graf po spuštění degraduje: rozlišení entit driftuje a vztahy stárnou, takže počítejte s přeindexováním.
• Než cokoli postavíte, spusťte na vlastním korpusu Basic Search jako kontrolu.

Jednou větou: graf znalostí si zaslouží své náklady, když jsou vaše dotazy víceskokové nebo globální pro celý korpus, a ne dřív. Pokud chcete druhý názor na svůj vyhledávací stack, získejte bezplatnou konzultaci.