Microsoft GraphRAG: tudásgráfos RAG, előre kifizetve

A GraphRAG a Microsoft Research MIT-licencű pipeline-ja, amely egy korpuszt tudásgráffá alakít, Leiden-algoritmussal klaszterez, és a kérdések feltevése előtt közösségenként írat egy összefoglalót a modellel. Az itt képviselt álláspont az, hogy ez a legjobban dokumentált Graph-RAG, és hogy az érdekes rész már nem a konstrukció: a repository karbantartási módban van, és amit egy csapatnak tényleg meg kell válaszolnia, az az, hogy az indexelési számla megáll-e a vektorkereséssel szemben.

A sima vektorkereséssel, a könnyebb graph-pipeline-okkal, például a LightRAG-gel, valamint a LlamaIndex- és Neo4j-eszközök beépített graph-lekérdezésével verseng. A különbség azért számít, mert a GraphRAG nem szolgáltatás: egy Python-csomag, amely az olvasó saját tokenjeit költi az index felépítésére, majd négy lekérdezési módot kínál könyvtári függvényként. A Microsoft semmit nem számláz és semmit nem üzemeltet, a README pedig azt mondja, hogy a kód bemutató, nem hivatalosan támogatott Microsoft-termék.

Mi ez

A dizájn szándékosan előre tölti a munkát. A dokumentumok TextUnitokra hasadnak, a modell kinyeri az entitásokat és kapcsolatokat minden egységből, a duplikált leírásokat összefésüli és összefoglalja, a Leiden-klaszterezés a graffot közösségi hierarchiába rendezi, majd további egy modellkör közösségenként és szintenként ír egy jelentést. Csak ezután fut egy kérdés, és addigra a költséges munka már ki van fizetve.

• MIT licenc, a PyPI-n graphrag csomagként, jelenlegi kiadás 3.2.0 (2026. szeptember 23.), Python 3.11–3.13.
• Körülbelül 36.200 star, 3.800 fork és 495 commit a GitHubon, továbbá 49 nyitott issue és pull request.
• A TextUnitok alapból 1.200 tokenesek: a nagyobb chunkok gyorsabban indexelnek, de kevésbé precízen extrahálnak.
• A közösségek felismerése hierarchikus Leiden-algoritmussal történik, és nem kerül modellhívásba; minden közösség összefoglalása már igen.
• Négy lekérdezési mód van a csomagban — global, local, DRIFT és basic —, plusz a dinamikus közösségválasztás a globális kereséshez.
• A CLI négy indexelési módot nevez meg: standard, fast, standard-update és fast-update, és van külön update parancs a módosult dokumentumokhoz.
• Minden hívás a saját végpontunkra megy — Azure OpenAI, OpenAI vagy kompatibilis szolgáltatás —, így a költség a modellár és a korpusz méretének függvénye.

Kettő következik ebből. Az index eszközzé válik, nem melléktermékké: az entitásleírások és a közösségi jelentések olvasható produktumok, amelyeket bármilyen más kimenethez hasonlóan át lehet nézni, meg lehet osztani és lehet versionálni. A gráf pedig csak annyira jó, amennyire az extrakciós kör, tehát olyan korpusznál, ahol az entitástípusok számítanak, az első teljes futás előtt kell hangolni, nem utána.

Hogyan működik

Az indexelés rögzített sorrend: darabolás, extrakció, összefésülés, klaszterezés, összefoglalás, beágyazás. Minden szakasz vagy egységenként egy modellhívást fizet, vagy semmit, és pontosan ez a határ termeli a számlát — egy extrakciós hívás TextUnitonként, egy összefoglaló hívás összefésült entitáson vagy kapcsolatonként, és egy jelentéshívás közösségenként a hierarchia minden szintjén.

A négy mód a termék felülete. A globális keresés map-reduce-t futtat a közösségi jelentések felett, és ezt a módot a vektorkeresés nem tudja utánozni, mert egyetlen chunk sem tartalmaz korpuszszintű választ. A helyi keresés a gráfot járja be elnevezett entitások körül, és nagyjából annyiba kerül, mint a vektor-lekérdezés plusz a bejárás. A DRIFT a legrelevánsabb jelentésekből indul, kérdéseket generál, és mindegyiket helyben megválaszolja. A basic keresés a csomag saját vektorkeresése, hogy egy csapat mérni tudja, mit veszít a gráf a saját adatain.

Első lépések

A belépési pont egy könyvtár, egy init parancs és két fájl. Az alábbi sorrend létrehoz egy munkaterületet, egy használható modellre állítja, indexeli a kis input mappát, és feltesz egy globális kérdést; a settings.yaml-ben dől el a számla, az első futásnak ezért kis korpusznál és olcsó modellnél kell maradnia, amíg a promptok nincsenek hangolva.

python -m venv .venv && source .venv/bin/activate
python -m pip install graphrag

mkdir ragtest && cd ragtest
graphrag init -r . -m gpt-4.1 -e text-embedding-3-large
# write GRAPHRAG_API_KEY into the .env that init created
# drop a few .txt or .md files into ./input, then index:
graphrag index -r . -m standard

# global is the default; this prunes reports before the map-reduce step
graphrag query "What are the top themes across these documents?" -r . \
  --dynamic-community-selection

graphrag query "Who is the main character?" -r . -m local
graphrag update -r . -m standard-update

Két szokás tartja kicsiben az első számlát. Mintát indexelj a teljes korpusz helyett, mert a pipeline egységenként és közösségi szintenként hívja a modellt, bármilyen is a modell ára; és a skálázás előtt futtasd a prompt-tune parancsot, mert a dokumentáció szerint a kész promptok ritkán adják a legjobb eredményt.

Mennyibe kerül az indexelés

Nincs licencdíj és nincs üzemeltetett szolgáltatás, így a teljes költség modellhívás. Az extrakció egyszer fut TextUnitonként, a jelentéskészítés közösségenként és szintenként, vagyis a számla a korpusz méretével és a Leiden-hierarchia által előállított közösségek számával nő. Az alábbi számok egy 2026 márciusában megjelent, GPT-4-es árakon számolt független összehasonlításból származnak, nem Microsoft-árból:

A Microsoft Research által publikált ellenszer a LazyGraphRAG, amely a modellalapú extrakciót névszó-kivonatra cseréli, és minden modellhívást a lekérdezés idejére halaszt. Az indexelési költségét a vektorkereséssel azonosnak és a teljes GraphRAG 0,1%-aként megadják, ugyanez az értékelés pedig a globális keresés minőségét több mint 700-szor alacsonyabb lekérdezési költségen, illetve annak 4%-áért jobb minőségként jelenti. A megvalósítás a Microsoft Discoveryben és az Azure Localban található, nem a MIT-csomagban, így a nyílt forrású pipeline-t üzemeltető csapat nem telepítheti: a szám irányt mutat, nem polcon lévő opciót.

Mennyibe kerülnek a lekérdezések

A lekérdezési költség az, ahol a módok különböznek, és ahol az index visszakeresi a már befektetett pénzt, vagy sem. A globális keresés a drága, mert kötegenként olvassa a közösségi jelentéseket, majd összefésüli őket; a másik három a gráf töredékét olvassa:

A dinamikus közösségválasztás az első sor publikált megoldása: egy olcsóbb modell a gyökértől kiindulva értékeli a jelentéseket, és a map-reduce előtt kivágja a lényegtelen ágakat. A Microsoft Research 50 globális kérdésen átlagosan 77%-os tokenköltség-csökkenést mért a statikus 1. szintű kereséssel szemben, miközben mintegy 1500 jelentés 470-re csökkent, a minőségben pedig nem volt statisztikailag szignifikáns különbség; ha a minősítés a 3. szintig folytatódott, az átlagosan 34%-kal került többe, és 58,8%-ot nyert a Comprehensiveness, 60,0%-ot az Empowerment mérőszámon. Ezek gyártói számok egyetlen adathalmazon, de az irány nem kérdéses — ne fizessünk olyan jelentésekért, amelyek nem tudják megválaszolni a kérdést.

Miben gyenge

A gyengeségek üzemeltetésiek, nem algoritmikusak. A repository karbantartási módban van, így a promptformátumok, a modell viselkedése és a függőségek elcsúszása az olvasó dolga, a README pedig bemutatónak nevezi a kódot. A frissítés külön parancs, nem háttérfeladat: a dokumentumok változnak, az entitások egyesülnek, a közösségek eltolódnak, és a frissítési módok is modellhívások árán extrahálják a módosult szöveget. A gráf hordozza az ontológiát is, mert az entitás- és kapcsolattípusok a nyílt extrakcióból jönnek, a zajos korpusz tehát zajos grádot ad. A legfontosabb viszont, hogy az index akkor is ki van fizetve, ha érkeznek kérdések — ez a vektorkeresés lekérdezésenkénti fizetési modelljének ellenkezője.

Ezt a táblát annak a kérdésnek az állításaként olvasd, amelyre az egyes rendszerek épülnek. A GraphRAG korpuszszintű és többugrásos kérdésekre válaszol, amelyeket egyetlen chunk sem tartalmaz; a vektorkeresés a keresgélő kérdéseket gyorsabban és olcsóbban oldja meg, ezért szállít a GraphRAG saját basic módot, mintha a gráf mindenhol nyerne. A LightRAG az ésszerű alapértelmezés, ha a lapos gráf a költség töredékéért a legtöbb értéket megadja, a Graphiti pedig ügynök-emlékezethez old meg problémát, nem dokumentumkeresést. Az itt képviselt álláspont az, hogy a legtöbb csapat azért nyúl a teljes pipeline-hoz, mert a benchmarkja meggyőző, miközben a lekérdezéseik zöme keresgélés — a legolcsóbb első lépés pedig lemérni ezt az arányt, mielőtt bármit indexelnénk.

Ítélet

A GraphRAG a megfelelő eszköz olyan korpuszhoz, amelynek kérdései valóban globálisok, és rossz alapértelmezés egy keresőmezőhöz. Ez a legjobban dokumentált Graph-RAG, MIT alatt van, és az index újrafelhasználható produktum, emberek által olvasható jelentésekkel; ugyanakkor karbantartási módban van, előre fizetendő, és lassabban változik, mint amit indexel. Kis első korpuszon és mért lekérdezési aránnyal vezesd be, vagy ne vezesd be.

1. Akkor válaszd, ha a kérdések jelentős része korpuszszintű szintézist igényel: témák, trendek, összehasonlítások mindenen.
2. Akkor válaszd, ha a válasz olyan entitások közötti ugrásokon múlik, amelyek sosem szerepelnek ugyanabban a chunkban.
3. Akkor válaszd, ha magának az indexnek van értéke — jelentések, amelyeket emberek olvasnak, megosztanak és ellenőriznek —, mert ezért fizetsz előre.
4. Ne válaszd keresgéléstől hemzsegő keresőmezőhöz: a vektorkeresés lekérdezésenként olcsóbb, a GraphRAG saját basic módja pedig pont ez a keresés.
5. Ne kezeld fenntartott függőségként; a repository karbantartási módról és új funkciók nélkül beszél.
6. A teljes futás előtt mérd meg a lekérdezési arányt, és indexelj mintát a dinamikus közösségválasztással.

További szempont, hogy hol él az index. Batch-termék, és oda tartozik, ahová a batch-termékek: pipeline építi, versionálja, ellenőrzi és cseréli, nem egy kéréskezelőből épül újra. A gráf tartalmának mechanikája — entitások, TextUnitok, közösségek — egy korábbi írásban szerepel a tudásgráfos RAG -ről; ez az írás a megvalósításról, a módokról és a számláról szól.

GraphRAG indexing can be an expensive operation, please read all of the documentation to understand the process and costs involved, and start small.

Források

1. GraphRAG on GitHub
2. GraphRAG documentation
3. From Local to Global: A Graph RAG Approach to Query-Focused Summarization
4. GraphRAG: Improving global search via dynamic community selection
5. LazyGraphRAG: Setting a new standard for quality and cost
6. Graph RAG in 2026: What Actually Works in Production