> Tudásgráf építése LLM-ekkel: minimális ontológia, kinyerő promptok, entitásfeloldás, eredetkövetés, növekményes frissítés, kiértékelés és tárolás.
>
> Web page: https://balazscsorba.com/hu/blog/knowledge-graph-extraction-llm · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/knowledge-graph-extraction-llm.md) · [Deutsch](https://balazscsorba.com/de/blog/knowledge-graph-extraction-llm.md)
> Author: Balázs Csorba · Published: 2026-09-25 · Updated: 2026-10-12 · Keywords: knowledge graph extraction with LLMs, GraphRAG indexing, entity resolution knowledge graph, triple extraction prompt, ontology design for LLM extraction, entity deduplication embeddings, knowledge graph provenance, incremental knowledge graph updates, GraphRAG cost, Neo4j SimpleKGPipeline

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

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

Tudásgráf építése LLM-ekkel: minimális ontológia, kinyerő promptok, entitásfeloldás, eredetkövetés, növekményes frissítés, kiértékelés és tárolás.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. szeptember 25.·frissítve 2026\. október 12.·8 perc olvasás

-   Knowledge graphs
-   GraphRAG
-   Entity resolution
-   RAG
-   Neo4j

![Csomópontok lépnek ki egy lapkötegből, és hálót alkotnak, ahol két kör eggyé olvad.](https://balazscsorba.com/images/blog/knowledge-graph-extraction-llm/cover.webp?v=8a8d21666a)

## A lényeg röviden

-   Gráfot építeni LLM-mel annyi, mint elemezni, darabolni, kinyerni, feloldani és betölteni; a minőséget az ontológia és az entitásfeloldás sokkal inkább meghatározza, mint a modell.
-   A séma határozza meg a gráf méretét: egy podcastkorpuszon a GraphRAG alapértelmezett promptja 1796 entitást adott, az automatikusan hangolt promptok 4896-ot.
-   A GraphRAG beépített feloldása pontos egyezés címre és típusra; a valódi korpuszokhoz fuzzy vagy beágyazásalapú egyeztetés kell, a bizonytalan párokra pedig LLM-es vagy emberi döntés.
-   Minden csomóponton és élen tartsa meg a forrás szövegegységet, hogy auditálni, törölni és csak a változottakat újra kinyerni tudjon, ne az egész gráfot kelljen újraépíteni.
-   A teljes GraphRAG-indexelés drága: a Microsoft szerint a LazyGraphRAG indexelése ennek 0,1 százaléka, ezért mielőtt fizet a kinyerésért, ellenőrizze, megéri-e a gráf.

Ezen az oldalon

1.  [Mi kell a felépítéshez](https://balazscsorba.com/#what-it-takes-to-build-one)
2.  [Kezdjen minimális ontológiával](https://balazscsorba.com/#start-with-a-minimal-ontology)
3.  [A kinyerési lépés a gyakorlatban](https://balazscsorba.com/#the-extraction-step-in-practice)
4.  [Entitásfeloldás és deduplikálás](https://balazscsorba.com/#entity-resolution-and-deduplication)
5.  [Eredetkövetés és növekményes frissítés](https://balazscsorba.com/#provenance-and-incremental-updates)
6.  [Mibe kerül](https://balazscsorba.com/#cost)
7.  [A kinyerés minőségének értékelése](https://balazscsorba.com/#evaluating-extraction-quality)
8.  [Tárolási lehetőségek](https://balazscsorba.com/#storage-choices)
9.  [Építési ellenőrzőlista](https://balazscsorba.com/#a-build-checklist)
10.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

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](https://balazscsorba.com/hu/blog/graphrag-knowledge-graph-rag) című cikk vitatja meg, a Microsoft eszközét pedig [a GraphRAG-ismertető](https://balazscsorba.com/hu/blog/graphrag) 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](https://github.com/microsoft/graphrag/blob/main/docs/index/default_dataflow.md)). Minden kinyert elem hivatkozik a szövegegységekre, így „visszavezeti az eredetet az eredeti forrásszöveghez”.

![Tudásgráf-építési folyamat Öt lépés balról jobbra: a dokumentumokat eredetazonosítóval ellátott szövegegységekre bontja; egy LLM egységenként entitásokat és kapcsolatokat nyer ki egy rögzített séma szerint; a kinyert elemeket összevonja, leírásaikat összefoglalja; az entitásfeloldás egyezteti a duplikátumokat, előbb pontosan, aztán fuzzy vagy beágyazásalapú módon, a bizonytalan párokról LLM vagy ember dönt; végül a tisztított gráfot minden csomóponton és élen forrásazonosítóval tölti be.](https://balazscsorba.com/images/blog/knowledge-graph-extraction-llm/diagram-4.webp?v=3980bee16d)

A minőség két ponton dől el: a sémánál a kinyerés előtt, és az entitásfeloldásnál a betöltés előtt.

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](https://github.com/microsoft/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](https://www.microsoft.com/en-us/research/blog/graphrag-auto-tuning-provides-rapid-adaptation-to-new-domains/)). 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](https://neo4j.com/docs/neo4j-graphrag-python/current/user_guide_kg_builder.html)). É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](https://neo4j.com/docs/neo4j-graphrag-python/current/user_guide_kg_builder.html)).

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](https://github.com/google/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](https://balazscsorba.com/hu/blog/llm-product-data-enrichment).

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](https://github.com/microsoft/graphrag/blob/main/docs/index/default_dataflow.md)), 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](https://neo4j.com/docs/neo4j-graphrag-python/current/user_guide_kg_builder.html)).

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](https://github.com/moj-analytical-services/splink)). Ugyanez az egyeztetési probléma a termékkatalógusokban is felmerül, lásd [PIM-adatminőség LLM-ekkel](https://balazscsorba.com/hu/blog/pim-data-quality-llm).

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.

**A feloldók lecserélik a csomópontokat**

A Neo4j feloldói lecserélik a folyamat által írt csomópontokat, vagyis a feloldás nem csak olvasó lépés. Futtassa megismételhető módon: jelölje meg a feloldott entitásokat, adjon meg egy szűrőlekérdezést, például `WHERE NOT entity:Resolved`, hogy az újrafuttatás csak az újakat érintse, és őrizze meg az eredeti említéseket a szövegegységeikkel, hogy egy hibás összevonás visszavonható legyen.

## 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](https://github.com/microsoft/graphrag/blob/main/docs/index/byog.md)). 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](https://arxiv.org/abs/2501.13956)), lásd [a Zep-ismertetőt](https://balazscsorba.com/hu/blog/zep).

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](https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)). 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 gráf építésének és lekérdezésének relatív költsége Négy vízszintes sáv a LazyGraphRAG indexeléséhez viszonyítva. A vektoros RAG indexelése nagyjából annyiba kerül, mint a LazyGraphRAG-é, ez egy egység. A teljes GraphRAG-indexelés kb. ezerszer ennyibe, mivel a LazyGraphRAG ennek 0,1 százaléka. Lekérdezési oldalon a GraphRAG globális keresése több mint 700-szor annyiba kerül, mint egy hasonló minőségű LazyGraphRAG-lekérdezés. Egy megjegyzés jelzi, hogy prompt- vagy sémaváltáskor a kinyerés költsége újra felmerül.](https://balazscsorba.com/images/blog/knowledge-graph-extraction-llm/diagram-26.webp?v=ed5799926b)

Relatív költségek a Microsoft LazyGraphRAG-bejegyzéséből, logaritmikus skálán; dokumentumonkénti abszolút árat nem közöltek.

## 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](https://arxiv.org/abs/2502.09956)). A GraphEval a tartalmat hármasokként ábrázolja, hogy hármasszinten találja meg a valószínű hallucinációkat ([GraphEval](https://arxiv.org/abs/2407.10793)).

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

Komponens

Szerep

Licenc

Eredet

Entitásfeloldás

Microsoft GraphRAG 3.3

teljes folyamat, karbantartási mód

MIT

szövegegységek

pontos cím és típus

neo4j-graphrag

moduláris gráfépítő

Apache-2.0

lexikai gráf

pontos, spaCy szemantikus, fuzzy

LangExtract

forráshoz kötött kinyerés

Apache-2.0

karaktertartományok

nincs beépítve

Splink

rekordösszekapcsolás

MIT

n. a.

valószínűségi, több mező

Neo4j, Kùzu, NetworkX

gráftárolás

változó; a Kùzu archivált

tulajdonságként

a saját folyamaton át

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](https://github.com/kuzudb/kuzu)), 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](https://balazscsorba.com/hu/expertise/ai-engineer).

## Források

1.  [Microsoft GraphRAG: default dataflow](https://github.com/microsoft/graphrag/blob/main/docs/index/default_dataflow.md)
2.  [Microsoft GraphRAG on GitHub](https://github.com/microsoft/graphrag)
3.  [Microsoft Research: LazyGraphRAG (Nov 2024)](https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)
4.  [Microsoft Research: GraphRAG auto-tuning (Sep 2024)](https://www.microsoft.com/en-us/research/blog/graphrag-auto-tuning-provides-rapid-adaptation-to-new-domains/)
5.  [neo4j-graphrag-python on GitHub](https://github.com/neo4j/neo4j-graphrag-python)
6.  [Neo4j GraphRAG: knowledge graph builder guide](https://neo4j.com/docs/neo4j-graphrag-python/current/user_guide_kg_builder.html)
7.  [Splink on GitHub](https://github.com/moj-analytical-services/splink)
8.  [Google LangExtract on GitHub](https://github.com/google/langextract)
9.  [KGGen (arXiv 2502.09956)](https://arxiv.org/abs/2502.09956)
10.  [GraphEval (arXiv 2407.10793)](https://arxiv.org/abs/2407.10793)
11.  [Zep temporal knowledge graph (arXiv 2501.13956)](https://arxiv.org/abs/2501.13956)
12.  [Kùzu on GitHub](https://github.com/kuzudb/kuzu)

## Gyakori kérdések

Hogyan építsek tudásgráfot LLM-mel?

Bontsa a dokumentumokat szövegegységekre, minden egységből nyerjen ki LLM-mel entitásokat és kapcsolatokat egy rögzített séma szerint, vonja össze és deduplikálja az entitásokat, majd töltse be az eredményt egy gráftárba úgy, hogy minden csomópont és él visszamutasson a forrásszövegére. A minőség nagy részét a séma és a deduplikálás dönti el.

Mi az entitásfeloldás egy tudásgráfban?

Annak eldöntése, mely kinyert említések ugyanarra a valós entitásra utalnak, például „Siemens AG”, „Siemens” és „a müncheni beszállító”. A lehetőségek a pontos névegyezéstől a fuzzy és beágyazásalapú hasonlóságon át a bizonytalan párok LLM-es vagy emberi elbírálásáig terjednek. Nélküle a gráf megtelik duplikált csomópontokkal.

Mennyibe kerül a GraphRAG-indexelés?

A Microsoft nem ad abszolút árat, csak relatív számokat: 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 teljes indexelés szövegegységenként több LLM-hívást végez, ezért mielőtt mindent indexelne, mérje meg a korpusza egy mintáján.

Hagyjam, hogy az LLM találja ki a sémát?

Kezdjen egy kicsi, rögzített ontológiával azokból az entitás- és kapcsolattípusokból, amelyekre ténylegesen lekérdez, és az LLM ezt töltse ki. A kötetlen kinyerés sok típust és közel azonos kapcsolatot hoz létre, amelyeket nehéz lekérdezni. A Neo4j folyamata egyszer levezethet egy sémát a szövegből, majd minden darabnál újrahasznosítja.

Hogyan tartsam naprakészen a tudásgráfot?

Minden csomóponton és élen tárolja a forrás szövegegységet és a dokumentumazonosítót, csak az új vagy módosult dokumentumokat nyerje ki, és az új entitásokat a meglévő gráfhoz képest oldja fel, ne építse újra az egészet. A Neo4j feloldói szűrőlekérdezést fogadnak, így az újrafuttatás csak a feloldatlan entitásokat érinti.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026)
-   [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking)
-   [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions)
-   [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)