Blog/RAG és keresés

GraphRAG és knowledge-graph RAG: mikor veri a gráf a vektoros keresést

Mit csinál valójában a Microsoft GraphRAG és a LightRAG, mennyibe kerül az indexelés, és mikor jobb a tudásgráf a vektoros RAG-nál: multi-hop, globális kérdések, termékkatalógus.

Balázs Csorba·2026. október 2.·13 perc olvasás

GraphRAG
Knowledge graphs
LightRAG
RAG

A lényeg röviden

A GraphRAG a chunkolás fölé egy LLM-mel épített tudásgráfot, Leiden-közösségeket és közösségi jelentéseket tesz. Az erőssége a teljes korpuszra vonatkozó globális kérdés, nem az egyes tények jobb megtalálása.
Az ár az indexelés: chunkonként legalább egy LLM-hívás a kinyerésre, plusz összefoglaló minden entitáshoz és közösséghez. A Microsoft maga figyelmeztet, hogy a GraphRAG sok LLM-erőforrást fogyaszthat.
A lokális keresés (entitás-környezet) a kapcsolati és multi-hop kérdéseken segít, a globális keresés (map-reduce a közösségi jelentéseken) a témákon és áttekintéseken. Egyszerű tény-lekérdezéshez általában elég a vektoros RAG rerankerrel.
Léteznek könnyebb változatok: a LightRAG inkrementális frissítéssel, a LazyGraphRAG vektoros RAG-os indexelési költséggel, a HippoRAG olcsó multi-hop kereséssel. Kezeld ezeket paper-eredményként, amíg a saját adatodon nem mérted le.
B2B katalógusokban a kapcsolatok (leváltja, része, kompatibilis) már ott vannak a PIM-ben vagy az ERP-ben. Töltsd be őket gráfként ahelyett, hogy LLM-mel újra felfedeztetnéd, a szabad szövegre pedig használj vektoros keresést.

Pár havonta valaki megmutat egy szép tudásgráf-vizualizációt, és kijelenti, hogy a vektoros RAG elavult. Eleget építettem keresőrendszereket ahhoz, hogy a mondat mindkét felében kételkedjek. A gráfok valóban megoldanak olyan problémákat, amelyeket a chunk-hasonlóság nem tud, és valódi pénzbe és valódi komplexitásba kerülnek olyan problémákért, amelyeket egy hibrid keresés rerankerrel már kezel.

Ez a cikk elmagyarázza, mit csinál valójában a Microsoft GraphRAG a motorháztető alatt, mit változtat a LightRAG, a LazyGraphRAG és a HippoRAG, honnan jön az indexelés költsége, és milyen kérdések indokolnak gráfot. Egy pragmatikus B2B példával zárul katalógusadatokból, ahol a tanácsom szándékosan unalmas: használd a gráfot, amid már van.

Ha még nincs szilárd baseline-od, kezdd a chunkolással, hibrid kereséssel és rerankinggel és a 2026-os RAG-áttekintéssel. A gráf egy működő pipeline kiegészítése, nem a helyettesítője.

Mit csinál valójában a Microsoft GraphRAG

A hátterében a From Local to Global: A Graph RAG Approach to Query-Focused Summarization paper áll, Darren Edge és kollégái munkája a Microsoft Researchnél (2024 április). A kiindulópont a hagyományos RAG egy korlátja: nehezen kezeli a teljes korpuszra vonatkozó globális kérdéseket, például azt, hogy „Melyek az adathalmaz fő témái?”. A hasonlósági keresés a kérdéshez legközelebbi chunkokat adja vissza, a mindenről szóló kérdésnek viszont nincs legközelebbi chunkja.

A nyílt forráskódú implementáció az indexelést lépésenként dokumentálja. A dokumentumokat text unitokra vágja (alapértelmezés szerint 1200 token). Egy LLM kinyeri az entitásokat címmel, típussal és leírással, valamint a köztük lévő kapcsolatokat, opcionálisan állításokat (claimeket) is. Az ismétlődő leírásokat összevonja. A hierarchikus Leiden-algoritmus ezután több részletességi szinten közösségekbe fürtözi a gráfot. Végül az LLM minden közösséghez jelentést ír, a text unitokat, az entitásleírásokat és a jelentéseket pedig beágyazza egy vektortárba.

A drága rész egyszer, indexeléskor történik; a két keresési mód ugyanazon index különböző elemeit olvassa.

Ebből két dolog következik. A gráf nem kézzel modellezett ontológia, hanem az, amit a kinyerő prompt megtalált, ezért a minősége a domainre hangolt promptoktól függ (a dokumentáció ezt kifejezetten kimondja). A közösségi jelentések pedig a korpuszod előre kiszámolt, hierarchikus összefoglalói, és éppen ettől válaszolhatók meg a globális kérdések.

A paper kísérleteiben, két körülbelül 1 millió tokenes adathalmazon (podcast-átiratok és hírcikkek) a GraphRAG-változatok LLM-mel értékelt összehasonlításokban verték a vektoros RAG baseline-t: 72–83 százalékos nyerési arány az átfogóságban és 62–82 százalék a sokszínűségben, adathalmaztól és változattól függően. A közösségek gyökérszintű összefoglalói emellett 9–43-szor kevesebb tokent igényeltek, mint a forrásszöveg összefoglalása. A szerzők óvatosak a hatókörrel: az értékelés két korpusz sensemaking-kérdéseire vonatkozik, és szerintük további munka kell annak megértéséhez, mennyire általánosítható.

Globális, lokális és DRIFT keresés

A lekérdezési módok közti különbség a leghasznosabb dolog, amit érdemes megérteni, mert megmutatja, mely kérdések indokolják az indexet.

Mód	Milyen kérdésre felel	Mit olvas	Költségprofil
Lokális keresés	Konkrét dolgokról: „Mit tudunk az X ügyfélről és a szerződéseiről?”	A kérdéshez illő entitások, szomszédaik, kapcsolatok, forrás text unitok és közösségi jelentések	Egy keresés és egy válasz, hasonló a nagyobb kontextusú RAG-hoz
Globális keresés	A teljes korpuszról: „Melyek a fő kockázatok az összes jelentésben?”	Közösségi jelentések, map és reduce lépésben feldolgozva	Sok LLM-hívás; az alacsonyabb közösségi szint alaposabb, de lassabb és drágább
DRIFT keresés	Széles kezdés, konkrét folytatás	Először releváns közösségi jelentések, majd lokális keresés a követő kérdésekre	A kettő között; a dokumentáció szerint átfogóbb a sima lokális keresésnél
Vektoros RAG	Hol áll ez?	A top-k leghasonlóbb chunk	A legolcsóbb indexeléskor és lekérdezéskor

A globális keresést érdemes közelebbről megnézni. A dokumentáció map-reduce-t ír le a közösségi jelentéseken: a jelentéseket chunkokra bontja, minden chunk köztes választ ad fontossági értékeléssel, a reduce lépés pedig szűri és összesíti ezeket. A közösségi szint megválasztása közvetlen szabályozó a mélység és a költség között, ezért egy éles rendszernek ki kell vezetnie, nem beledrótoznia.

A lokális keresés az a mód, amelyre a csapatoknak valójában a legtöbbször szükségük van, és amelyik a leginkább hasonlít a klasszikus keresési pipeline-hoz. Beágyazza a kérdést, megkeresi a kapcsolódó entitásokat, és behúzza a kapcsolódó entitásokat, kapcsolatokat, kovariánsokat, forrás chunkokat és közösségi jelentéseket, egyetlen kontextusablakra szabva.

LightRAG, LazyGraphRAG, HippoRAG és a többiek

Az eredeti terv alapos és drága, és több projekt éppen ezt támadja. Rövid tájékoztató, a szokásos fenntartással, hogy az alábbi számok mind a szerzőktől származnak:

A LightRAG (2024 októberi paper, az EMNLP 2025-ön bemutatva, MIT-licenc) gráf- és vektorindexet épít kétszintű kereséssel, támogatja az inkrementális frissítést és a dokumentumtörlést, és local, global, hybrid, naive és mix lekérdezési módokat kínál. Fut PostgreSQL-en, Neo4j-n, MongoDB-n, Milvuson, Qdranton vagy OpenSearchön. A paper a keresés pontosságának és hatékonyságának javulását közli, a GraphRAG-gal való, azonos alapú költség-összehasonlítást viszont nem tudtam ellenőrizni, ezért ezt nyitva hagyom. Az inkrementális frissítés az a funkció, ami engem érdekel: a minden alkalommal újraépített index rosszul illik az élő dokumentumállományokhoz.
A LazyGraphRAG (Microsoft Research, 2024. november 25.) kihagyja az előzetes összefoglalást. A Microsoft szerint az indexelési költsége megegyezik a vektoros RAG-éval, és a teljes GraphRAG költségének 0,1 százaléka, a munka a lekérdezés idejére tolódik. Ez a jó csere nagy korpusznál és kevés gráfot érdemlő kérdésnél.
A HippoRAG (NeurIPS 2024) egy LLM-mel épített tudásgráfot Personalized PageRankkel kombinál. A szerzők akár 20 százalékos javulást közölnek multi-hop kérdésmegválaszolásban, az egylépéses keresés pedig eléri vagy túlszárnyalja az iteratív keresést, miközben 10–30-szor olcsóbb és 6–13-szor gyorsabb. A multi-hop kérdéseket célozza, nem a globálisakat.

Az olvasatom: a „graph RAG” egy család, nem egy termék. A hasznos kérdés az, hogy a három feladat közül melyikre van szükséged: globális összefoglalókra, kapcsolat-tudatos multi-hop keresésre vagy inkrementálisan frissített tudásra. Ahhoz válassz változatot.

Az indexelés számlája

A Microsoft saját bevezető oldala arra figyelmeztet, hogy a GraphRAG sok LLM-erőforrást fogyaszthat, és azt javasolja, hogy előbb a tutorial adathalmazzal és olcsóbb modellekkel próbálkozz. Ez a becsületes összefoglalás. Olyan árat nem tudok mondani millió tokenenként, amely tartósan igaz marad, mert a modelltől és a promptoktól függ, de megmutathatom, honnan jönnek a hívások:

Kinyerés: text unitonként legalább egy LLM-hívás, önreflexiós („gleaning”) körökkel több. A paper szerint a kinyerés recallja javul a további körökkel és a kisebb chunkokkal: GPT-4-gyel egy 600 tokenes chunk majdnem kétszer annyi entitás-említést adott, mint egy 2400 tokenes.
Leírások összefoglalása: minden entitás és kapcsolat, amely sok chunkban előfordul, egy LLM-mel összevont leírást kap.
Közösségi jelentések: közösségenként egy LLM által írt jelentés, minden hierarchiaszinten.
Embeddingek: text unitok, entitásleírások és jelentéstartalom. Ez az egyetlen rész, amelyért egy vektoros RAG pipeline is fizet.

A méret is számít. A paper gráfjai a körülbelül 1 millió tokennyi szövegre 8564 csomóponttal és 20 691 éllel (podcastok), illetve 15 754 csomóponttal és 19 520 éllel (hírek) készültek. Szorozd meg a saját korpuszoddal és minden újraindexeléssel. A költségek itt halmozódnak: ha a dokumentumok hetente változnak, egy inkrementális terv, mint a LightRAG, vagy egy igény szerinti, mint a LazyGraphRAG, jobban változtat a gazdaságosságon, mint bármilyen prompt-hangolás.

Mikor nyernek a gráfok, és mikor nem

A GraphRAG-Bench tanulmány (2025 június) egy kényelmetlen megfigyeléssel indul: a GraphRAG sok valós feladaton gyakran gyengébben teljesít az egyszerű RAG-nál. Ezután a tényközlést, az összetett következtetést, az összefoglalást és a kreatív generálást vizsgálja, hogy megtalálja, milyen feltételek mellett térül meg a gráf. Ez egyezik a tapasztalatommal. A döntés a kérdés alakjától függ.

Kérdéstípus	Vektoros RAG + reranker	Graph RAG	Az én döntésem
Egyetlen tény („Mekkora a Z modell nyomatéka?”)	Erős, olcsó	Ritkán jobb	Vektor
Multi-hop („Melyik beszállító gyártja az X-et leváltó alkatrészt?”)	Kihagyja a második hopot, hacsak egy ügynök nem iterál	Erős, ha a kapcsolat explicit	Gráf vagy ügynöki keresés
Globális („Milyen témák ismétlődnek 5000 jegyben?”)	Gyenge: nincs legközelebbi chunk	Az eset, amire a GraphRAG készült	Gráf, vagy összefoglalás fürtözéssel
Kapcsolatos katalógus („Mi illik hozzá, mi váltja le, mi része?”)	Szöveget talál, szerkezetet nem	Erős, és az adat már strukturált	Gráf strukturált adatból
Gyorsan változó dokumentumok	Könnyű frissíteni	Drága, hacsak nem inkrementális	Vektor, vagy LightRAG-jellegű frissítés
Kis korpusz, ami belefér a kontextusba	Nem kell	Nem éri meg	Hosszú kontextus

A minta: a gráfok akkor segítenek, ha a válasz több, kapcsolatokkal összekötött darabból vagy a korpusz egészéből áll össze. Nem segítenek, ha a válasz egyetlen szövegrészben van. Építés előtt írj le húsz valódi felhasználói kérdést, és sorold mindegyiket tény, multi-hop vagy globális kategóriába. Ha 80 százalék tény, jobb chunkolásra és rerankingre van szükséged, nem gráfra. Az eredményt a termékedhez kötött evalokkal mérd, ne egy demóval.

Pragmatikus B2B példa: termékek és alkatrészek

Ez az a helyzet, amellyel B2B e-commerce és ERP projektekben találkozom. Egy gyártó vagy nagykereskedő gépeket, alkatrészeket és kiegészítőket árul. Az értékesítő vagy egy ügyfél megkérdezi: „A P-150 szivattyúnk kifutott. Melyik szivattyú váltja le, és milyen tömítőszett kell most?” A válaszhoz három hop kell: az utódtermék, annak alkatrészlistája, és egy kifutott alkatrész aktuális pótlása. Rokon kérdések: „Mi kompatibilis ezzel a karimával?” és „Melyik kézikönyv fedi le ezt a változatot?”.

Az adatlapokon végzett vektoros keresés megtalálja a P-150 oldalát és talán a P-200-ét. Nem követi megbízhatóan a „leváltja” kapcsolatot a helyes tömítőszettig, mert ez a tény rekordok közötti kapcsolat, nem a kérdéshez hasonló mondat. Ez klasszikus gráf-eset. De figyeld meg, honnan kell jönnie a gráfnak.

A kapcsolatok már mezők egy PIM-ben vagy ERP-ben; csak a kézikönyvhöz kell szövegkeresés.

Egy PIM-ben vagy ERP-ben, mint a Pimcore, a Spryker vagy az SAP, ezek a kapcsolatok már strukturált adatként léteznek: utód-hivatkozások, darabjegyzékek, kompatibilitási táblák. LLM-mel kifizettetni, hogy PDF-ekből újra kinyerje őket, lassabb, drágább és pontatlanabb, mint a mezők beolvasása. Az ajánlott architektúrám ezért:

Építsd a gráfot strukturált adatból. A csomópontok termékek, alkatrészek és dokumentumok; az élek a törzsadataid által már definiált kapcsolattípusok (leváltja, része, kompatibilis, dokumentálja). A csomópont-azonosító legyen azonos az SKU-val vagy cikkszámmal.
A szöveghez használj vektoros vagy hibrid keresést. A kézikönyvek, adatlapok és jegyek chunkolt indexben maradnak. Minden chunk hordozza az általa említett termékazonosítókat, így egy gráfbejárás pontosan a releváns chunkokat tudja lekérni.
Először entitásfeloldás, aztán bejárás. Az ügynök vagy a keresési lépés a „P-150”-et egy csomóponthoz rendeli (cikkszámoknál a pontos egyezés jobb az embeddingnél), egy–három hopot jár be típusos lekérdezéssel, és a kapott rekordokat a kapcsolódó chunkokkal együtt adja át a modellnek.
LLM-es kinyerést csak a hiányokra adj hozzá, például olyan kompatibilitási megjegyzésekre, amelyek csak szabad szövegben léteznek, és jelöld az ilyen éleket kevésbé megbízhatónak.
A készletet a rendelkező rendszerből ellenőrizd. A készlet, az ár és az érvényesség az ERP-é, amelyet válaszadáskor eszközként hívsz meg, a gráfba sosem kerül. Hogy merre tart ez, azt lásd az agentic commerce protokollok cikkben.

Ez graph RAG a drága rész nélkül. Ráadásul jobban auditálható: a válasz minden hopja egy rekord, amit bárki megnyithat. Ha ilyen rendszereket építesz: a B2B e-commerce munkám pontosan a törzsadatok és a keresés ilyen kombinációja.

Ellenőrzőlista, mielőtt gráfot építesz

Gyűjts össze húsz–ötven valódi kérdést, és címkézd őket tény, multi-hop vagy globális kategóriával.
Építsd meg és mérd a baseline-t: hibrid keresés rerankinggel és rendes chunkolással.
Ellenőrizd, léteznek-e már a kapcsolatok strukturált adatként. Ha igen, importáld őket, ne kinyerd.
Ha globális kérdések kellenek, pilotálj GraphRAG-ot vagy LazyGraphRAG-ot egy mintán, és extrapold a költséget, az újraindexelést is beleértve.
Ha a dokumentumaid gyakran változnak, először inkrementális megoldásokat, például LightRAG-et teszteld.
Hangold a kinyerő promptot a domainedre, és nézz át kézzel egy mintát a kinyert entitásokból.
Hasonlítsd a baseline-hoz a saját kérdéseiden, LLM-bíróval és emberi szúrópróbával.
A keresési módot (vektor, lokális, globális) tedd routerdöntéssé, ne kényszeríts minden lekérdezést a gráfon át.

Az utolsó pont spórol pénzt. Egy olcsó osztályozó vagy egy kis modell a tény-kérdéseket a vektoros keresésre irányítja, és csak a globális vagy kapcsolati kérdéseket küldi a gráfnak. A pipeline így annyiba kerül, amennyit az adott kérdés megérdemel.

Merre tart ez

Hosszú kontextusablakokkal és ügynöki kereséssel egy ügynök egy sima indexen is iterálhat, és közelítheti a multi-hop következtetést, kérdésenként több hívás árán. A gráfok ezt a munkát az indexelés idejére helyezik át. Egyik sem nyer mindenhol, ezért 2026-ban a minta egy router több keresési stratégia fölött.

Az ajánlásom: maradj szkeptikus és empirikus. Kezdd a baseline-nal, gráfot csak azokra a kérdéstípusokra adj hozzá, amelyeknek kell, az éleit amikor csak lehet, strukturált adatból vedd, és tartsd láthatóan az indexelés számláját. Az a gráf, amely egy kérdésosztályt jobban, ismert áron válaszol meg, érték. Az a gráf, amelyet azért építettek, mert jól mutat a diagramon, költség.

Források

Gyakori kérdések

Mi a GraphRAG, és miben különbözik a hagyományos RAG-tól?

A hagyományos RAG a dokumentumokat chunkokra bontja, beágyazza, és a leghasonlóbbakat kéri le. A Microsoft Research által közzétett GraphRAG először egy LLM-mel entitásokat és kapcsolatokat nyer ki a chunkokból, a kapott gráfot a Leiden-algoritmussal közösségekbe fürtözi, és minden közösséghez LLM-összefoglalót ír. A lekérdezés ezután használhatja egy entitás gráfbeli környezetét (lokális keresés) vagy a közösségi összefoglalókat (globális keresés), nem csak hasonló chunkokat.

Mi a különbség a GraphRAG lokális és globális keresése között?

A lokális keresés a kérdéshez illő entitásokból indul, és behúzza a kapcsolódó entitásokat, kapcsolatokat, a forrásszöveget és a közösségi jelentéseket. Konkrét dolgokra vonatkozó kérdésekhez való. A globális keresés map-reduce-t futtat a közösségi jelentéseken, és a teljes adathalmazra vonatkozó kérdésekhez való, például a fő témákhoz. A DRIFT-keresés a kettőt kombinálja: közösségi jelentésekkel indul, és lokális kereséssel finomít.

Mennyibe kerül a GraphRAG indexelése?

Sokkal többe, mint a chunkok beágyazása, mert egy LLM végigolvassa az összes chunkot, hogy entitásokat és kapcsolatokat nyerjen ki, majd leírásokat és közösségi jelentéseket ír. A Microsoft szerint a GraphRAG sok LLM-erőforrást fogyaszthat, ezért kicsiben és olcsóbb modellekkel érdemes kezdeni. A LazyGraphRAG, egy későbbi változat, a vektoros RAG-gal azonos indexelési költséget és a teljes GraphRAG 0,1 százalékát közli.

Mikor jobb a GraphRAG a vektoros RAG-nál?

Ha a kérdések kapcsolatokon vagy a teljes korpuszon múlnak: multi-hop kérdések, korpuszszintű témák és áttekintések, valamint explicit kapcsolatokat tartalmazó adatok, például termék- és alkatrész-hierarchiák. Egyszerű tény-lekérdezésnél gyakran nem. A GraphRAG-Bench tanulmány szerint a GraphRAG sok valós feladaton gyakran gyengébb az egyszerű RAG-nál, ezért a saját kérdéseiden mérj.

Jó alternatíva a LightRAG a Microsoft GraphRAG helyett?

Könnyebb, MIT-licenccel elérhető graph RAG keretrendszer kétszintű (lokális és globális) kereséssel, inkrementális frissítéssel és több tárolási háttérrel, például PostgreSQL-lel és Neo4j-jel. Érdemes kipróbálni, ha a dokumentumaid gyakran változnak. A publikált összehasonlításokat a szerzők maguk végezték, ezért a döntés előtt teszteld a saját baseline-odhoz képest.

Kell gráfadatbázis a GraphRAG-hoz?

Nem feltétlenül. A Microsoft GraphRAG táblákat és embeddingeket ír, a LightRAG pedig teszteléshez memóriabeli gráftárolót tartalmaz, éles használathoz PostgreSQL-t támogat. A dedikált gráfadatbázis, például a Neo4j akkor hasznos, ha sokat járod be a kapcsolatokat, vagy amúgy is modellezed őket, például termék–alkatrész szerkezetekben.