Tudásgráf kinyerése LLM-ekkel: ontológia, entitásfeloldás, eredet

A tudásgráf kinyerése LLM-ekkel a strukturálatlan dokumentumokat olyan entitásokká és típusos kapcsolatokká alakítja, amelyeket egy gráflekérdezés vagy egy GraphRAG-rendszer használni tud. A kinyerő hívás a könnyebbik rész; bármely képes modell hihető hármasokat ad vissza. Hogy a gráf hasznos-e, azt minden más dönti el körülötte: egy lekérdezhetően kicsi séma, egy entitásfeloldás, amely összevonja a háromféleképpen leírt ugyanazon beszállítót, egy eredetkövetés, amely minden élt visszavezet egy mondatra, és egy költségmodell, amely kibír egy újbóli kinyerést.

Ez a cikk az építési oldalról szól: minimális ontológia, a kinyerési lépés, entitásfeloldás, eredetkövetés és növekményes frissítés, kiértékelés és tárolás. Hogy egyáltalán gráf kell-e vektoros visszakeresés helyett, azt a GraphRAG kontra vektoros RAG című cikk vitatja meg, a Microsoft eszközét pedig a GraphRAG-ismertető mutatja be végig. A verziók és számok 2026 októberi állapotot tükröznek.

Mi kell a felépítéshez

Minden LLM-mel épített gráf ugyanazt a folyamatot követi: dokumentumok elemzése, szövegegységekre bontása, egységenként entitások és kapcsolatok kinyerése, a duplikátumok összevonása és feloldása, végül az eredmény betöltése. A Microsoft GraphRAG alapértelmezett adatfolyama jó referencia: 1200 tokenes szövegegységek, egységenkénti kinyerés, az azonos címmel és típussal rendelkező entitások összevonása, összefoglalt leírások, opcionális állításkinyerés, majd közösségfelismerés és jelentések (GraphRAG adatfolyam). Minden kinyert elem hivatkozik a szövegegységekre, így „visszavezeti az eredetet az eredeti forrásszöveghez”.

A minőség nagy részét két lépés dönti el: az ontológia, amely meghatározza, mit lehet kinyerni, és az entitásfeloldás, amely eldönti, hogy az eredmény egyetlen gráf lesz-e vagy közel azonos csomópontok halmaza. A kinyerő modell kevésbé számít, mint bármelyik. Maga a GraphRAG ma már nagyrészt karbantartási módban van: a README demonstrációként írja le, nem hivatalosan támogatott termékként, és figyelmeztet, hogy az indexelés drága lehet (GraphRAG).

Gráfot akkor érdemes építeni, ha a kérdések kapcsolatokról szólnak, nem szövegrészekről: mely beszállítók szállítanak egy adott szabvány szerint tanúsított alkatrészeket, mely szerződések hivatkoznak egy visszavont előírásra, mely üzemek használnak közös alkatrészt. A vektoros visszakeresés arra válaszol, hogy „keress ehhez hasonló szöveget”; a gráf arra, hogy „kövesd ezeket a kapcsolatokat”. Ha a felhasználók többnyire az első fajta kérdést teszik fel, a lenti kinyerési költség keveset hoz.

Kezdjen minimális ontológiával

Kezdjen azzal a néhány entitás- és kapcsolattípussal, amelyre ténylegesen lekérdez, mert a séma határozza meg a gráf méretét és hasznosságát is. A Microsoft automatikus hangolásról szóló bejegyzése megmutatja, mennyire: ugyanazon a podcastkorpuszon, GPT-4-Turbóval a GraphRAG hírekre szabott alapértelmezett promptja 1796 entitást, 2851 kapcsolatot és 352 közösséget adott, a területre hangolt promptok viszont 4896-ot, 8210-et és 1027-et (automatikus hangolás). A több nem automatikusan jobb; csak akkor jobb, ha a többlet entitásokra a kérdéseinek szüksége van.

A Neo4j hivatalos GraphRAG-csomagja kifejezetté teszi a sémát: csomóponttípusok, kapcsolattípusok és megengedett minták, például ("Supplier","SUPPLIES","Product"). Az alapértelmezett schema="EXTRACTED" esetén egy LLM egyszer levezet egy sémát a szövegből, és minden darabnál újrahasznosítja; a schema="FREE" beállításnál egyáltalán nincs kötés (Neo4j). Éles használathoz írja meg a sémát maga, tartsa verziókezelésben, és a változtatást kezelje migrációként. A Jira MCP-szerverem a másik oldalról ugyanezen az elven működik: egy kicsi, típusos, 20 eszközből álló felületet kapó modell abbahagyja a találgatást.

A kinyerési lépés a gyakorlatban

A kinyerési lépés szövegegységenként egy LLM-hívás, amely strukturált formában adja vissza az entitásokat és kapcsolatokat, néha további menetekkel kiegészítve, amelyek elkapják, amit az első kihagyott. Használjon strukturált kimenetet, ahol a szolgáltató támogatja: a Neo4j folyamata strukturált kimenetet kínáló modelleknél egy Pydantic gráfmodellhez ellenőrzi az eredményt, ahelyett hogy utólag javítaná a JSON-t, a gráfmetszője pedig eldobja a sémát sértő vagy tulajdonság nélküli csomópontokat és kapcsolatokat (Neo4j).

A forráshoz kötés a másik védőháló. A Google LangExtract minden kinyerést a forrásbeli pontos karaktertartományához rendel, és ha a modell egy kinyerést nem talál meg a bemenetben, az nem kap karakterintervallumot, és ki kell szűrni (LangExtract). Ez az egyetlen szabály eltünteti a kitalált kapcsolatok többségét. Ugyanez a minta érvényes a termékadatokra, ahol forrástartomány nélküli érték nem kerülhet a katalógusba, lásd termékadatok gazdagítása LLM-ekkel.

A darabméret többet számít, mint amilyennek látszik. A kisebb egységek hívásonként kevesebb olvasnivalót adnak a modellnek, és általában növelik az entitások recallját, de szétválasztják azokat a kapcsolatokat, amelyek két vége különböző bekezdésben van; a nagyobb egységek ezeket együtt tartják, és hívásonként többe kerülnek. A GraphRAG 1200 tokenes alapértéke észszerű kezdés; csak azután módosítsa, hogy a dokumentumai egy mintáján megmérte, hány kapcsolat lépi át az egységhatárokat.

# Sketch with neo4j-graphrag: fixed schema, extraction, then resolution limited to new entities
from neo4j_graphrag.experimental.pipeline.kg_builder import SimpleKGPipeline
from neo4j_graphrag.experimental.components.resolver import SinglePropertyExactMatchResolver

schema = {
    "node_types": ["Supplier", "Product", "Standard", "Plant"],
    "relationship_types": ["SUPPLIES", "COMPLIES_WITH", "PRODUCED_AT"],
    "patterns": [("Supplier", "SUPPLIES", "Product"),
                 ("Product", "COMPLIES_WITH", "Standard"),
                 ("Product", "PRODUCED_AT", "Plant")],
}
pipeline = SimpleKGPipeline(llm=llm, driver=driver, embedder=embedder, schema=schema, from_pdf=False)
await pipeline.run_async(text=document_text)            # chunks keep their ids in the lexical graph

resolver = SinglePropertyExactMatchResolver(driver, filter_query="WHERE NOT entity:Resolved")
await resolver.run()                                    # only touches entities from this run

Entitásfeloldás és deduplikálás

Az entitásfeloldás dönti el, hogy a „Siemens AG”, a „Siemens” és „a müncheni beszállító” egy csomópont lesz-e vagy három. A GraphRAG beépített logikája csak az azonos címmel és típussal rendelkező entitásokat vonja össze (GraphRAG adatfolyam), ami egy bemutatóhoz elég, valódi korpuszokhoz kevés. A Neo4j csomagja háromféle feloldót kínál: pontos egyezést egy tulajdonságon, szemantikus egyezést spaCy-beágyazásokkal és koszinusz-hasonlósággal, valamint fuzzy egyezést RapidFuzz-zal, amely gyorsabb, de kevésbé pontos (Neo4j).

Leginkább a rétegzett megközelítés működik: a pontos egyezéseket vonja össze automatikusan, a küszöb fölötti fuzzy és beágyazásalapú egyezéseket javasolja, a bizonytalan középsávot pedig mindkét jelölt kontextusával küldje egy LLM-nek vagy egy embernek. Több strukturált mezővel rendelkező entitásoknál a Splink valószínűségi rekordösszekapcsolása kiforrott, és nagyjából egymillió rekordot kapcsol össze egy laptopon körülbelül egy perc alatt, de a README szerint nem egyetlen, „szózsákot” tartalmazó oszlopra tervezték, így a csak névvel rendelkező entitáscsomópontok kívül esnek az erősségén (Splink). Ugyanez az egyeztetési probléma a termékkatalógusokban is felmerül, lásd PIM-adatminőség LLM-ekkel.

A blokkolás megfizethetővé teszi a feloldást. Minden entitás összevetése minden mással négyzetesen nő, ezért előbb csoportosítsa a jelölteket egy olcsó kulcs szerint, például entitástípus és normalizált névelőtag alapján, vagy a beágyazási tér legközelebbi szomszédai szerint, és csak ezeken a csoportokon belül hasonlítson. A küszöböt ezután címkézett párminta alapján határozza meg, ne megérzésből, mert a helyes vágás más cégnevekre, termékkódokra és személyekre.

Eredetkövetés és növekményes frissítés

Az eredetkövetés az a gerinc, amely karbantarthatóvá teszi a gráfot. Minden csomóponton és élen tartsa meg a szövegegység- és dokumentumazonosítót, hogy egy válasz hivatkozhasson a mondatára, egy törölt dokumentum pontosan a saját hozzájárulásait távolíthassa el, egy módosult dokumentum pedig a többi érintése nélkül legyen újra kinyerhető. A GraphRAG szövegegységei és a Neo4j lexikai gráfja, amely a darabokat a belőlük kinyert entitásokhoz köti, egyaránt ezt a szerkezetet adják.

A GraphRAG jelenlegi dokumentációjában nem találtam dokumentált növekményes indexelési módot; ami dokumentált, az a saját gráf behozatala és csak a közösségi munkafolyamatok futtatása rajta (BYOG). A gyakorlatban a növekményes működés azt jelenti, hogy csak az új vagy módosult dokumentumokat nyeri ki, és az entitásaikat a meglévő gráfhoz képest oldja fel. Az időben követett tényeket tároló gráfok élenként érvényességi ablakot adnak hozzá; a Zep Graphiti motorja így tartja meg a történeti kapcsolatokat ágensmemóriához (Zep-tanulmány), lásd a Zep-ismertetőt.

Az újbóli kinyerés az a költség, amellyel számolni kell. A séma vagy a kinyerő prompt módosítása minden, a régi alatt keletkezett hármast érvénytelenít, ezért a promptokat kezelje kódként, minden kinyert elemen rögzítse a promptverziót, és a teljes újrakinyerést migrációként tervezze, ne meglepetésként.

Mibe kerül

A Microsoft nem közöl dokumentumonkénti abszolút árat a GraphRAG-hez, csak relatív számokat, és ezek nagyok. A LazyGraphRAG indexelése nagyjából annyiba kerül, mint a vektoros RAG, és a teljes GraphRAG-indexelés 0,1 százaléka, a LazyGraphRAG-lekérdezések pedig hasonló minőség mellett több mint 700-szor olcsóbbak a GraphRAG globális keresésénél (LazyGraphRAG). A gyakorlati szabály: nyerjen ki egy reprezentatív mintát, mérje meg maga a dokumentumonkénti tokenszámot, és szorozzon, mielőtt a teljes korpuszra vállalkozik.

A kinyerés minőségének értékelése

A kinyerés minősége nyitott kutatási kérdés, nem megoldott. A KGGen szerzői megjegyzik, hogy az automatikusan kinyert gráfok minősége kérdéses, és kevés az összevetésre alkalmas, ember által készített gráf; entitásklaszterezéssel csökkentik a ritkaságot, és közzéteszik a szövegből gráfba kinyerést mérő MINE benchmarkot (KGGen). A GraphEval a tartalmat hármasokként ábrázolja, hogy hármasszinten találja meg a valószínű hallucinációkat (GraphEval).

A saját gráfhoz egyszerű protokoll működik: futásonként vegyen mintát 50 hármasból, egy ember jelölje mindegyiket helyesnek, hibásnak vagy a forrástartománya által alá nem támasztottnak, és kövesse ezt a pontosságot a prompt- és sémaverziókon át. Egy LLM-bíró előszűrhet, de előbb kalibrálja az emberi címkékhez. Futásonként naplózza az entitások, kapcsolatok, összevonások és az elutasított, forrás nélküli hármasok számát, valamint a promptverziót, hogy egy hirtelen ugrás látható legyen.

A gráfot azokon a kérdéseken is értékelje, amelyek miatt létezik. Írjon tíz-húsz ismert válaszú kapcsolati kérdést, minden újraépítés után futtassa le őket a gráflekérdezésein vagy a GraphRAG-keresésen, és vesse össze az eredményt. A hármaspontosság megmutatja, helyes-e a kinyerés; a kérdéspontosság pedig azt, hogy a séma és a feloldás olyan gráfot hozott-e létre, amely meg tudja válaszolni, amire építette.

Tárolási lehetőségek

Tárolásra a Neo4j a szokásos szerveroldali választás, és a hivatalos GraphRAG-csomag is ezt célozza. A Kùzut, egy MIT licencű beágyazott gráfadatbázist, amely helyi folyamatokhoz vonzó volt, archiválták, a README szerint a csapat valami újon dolgozik (Kùzu), ezért ne kezdjen rá új munkát. Kis gráfokhoz vagy kísérletekhez elég a memóriában futó NetworkX és lemezen Parquet-fájlok, maga a GraphRAG is Parquet-táblákat ír, amelyek bármelyikbe betölthetők.

Bármelyik tárat választja, a kinyert entitásokat és kapcsolatokat mellette egyszerű fájlokként is tartsa meg, promptverzióval és forrásazonosítókkal. Ez az export teszi lehetővé, hogy a kinyerés újbóli kifizetése nélkül újraépítse a tárat, motort váltson vagy újrafuttassa a feloldást.

Építési ellenőrzőlista

1. Írjon minimális sémát a feltenni kívánt kérdésekből, és verziózza.
2. Kezelje a kinyerő promptokat kódként, és minden elemen rögzítse a verziót.
3. Használjon strukturált kimenetet, és dobja el a forrástartomány nélküli hármasokat.
4. Rétegesen oldja fel az entitásokat, és őrizze meg az eredeti említéseket.
5. Minden csomóponton és élen tartsa meg a szövegegység- és dokumentumazonosítót.
6. Futásonként mérje a pontosságot 50 mintavételezett hármason.
7. A teljes korpusz indexelése előtt árazza be a kinyerést egy mintán.
8. Csak az új vagy módosult dokumentumokat nyerje ki, és a meglévő gráfhoz képest oldja fel őket.

Ha dokumentumokból épít tudásgráfot, és azt szeretné, hogy az első bemutató után is tiszta maradjon, nézze meg a MI-mérnöki munkámat.

Források

1. Microsoft GraphRAG: default dataflow
2. Microsoft GraphRAG on GitHub
3. Microsoft Research: LazyGraphRAG (Nov 2024)
4. Microsoft Research: GraphRAG auto-tuning (Sep 2024)
5. neo4j-graphrag-python on GitHub
6. Neo4j GraphRAG: knowledge graph builder guide
7. Splink on GitHub
8. Google LangExtract on GitHub
9. KGGen (arXiv 2502.09956)
10. GraphEval (arXiv 2407.10793)
11. Zep temporal knowledge graph (arXiv 2501.13956)
12. Kùzu on GitHub