GraphRAG-opas: Milloin tietoverkot voittavat vektor-RAGin (ja milloin eivät)

GraphRAG-opas: Milloin tietoverkot voittavat vektor-RAGin (ja milloin eivät)

GraphRAG ei ole kuollut, mutta se ei ole myöskään oletusvalinta. microsoft/graphrag julkaisi version v3.1.1 18.7.2026, GitHub-tähtiä on kertynyt 35 088, ja kolme vuoden 2026 benchmark-tutkimusta raportoi nyt ääneen, että se häviää usein tavalliselle vektorihaulle. Tämä GraphRAG-opas vastaa ainoaan jäljellä olevaan kysymykseen: onko tietoverkko indeksointilaskunsa arvoinen?

Kannattaako GraphRAGia käyttää? Lyhyt vastaus

Käytä GraphRAGia, kun kysymyksesi ylittävät entiteettien rajat tai kattavat koko aineiston, kuten "mitä toimittajia suurin asiakkaamme myös myy?" Pysy tavallisessa tai hybridissä RAGissa, kun kyse on yksittäisten faktojen hauista, nopeasti muuttuvista dokumenteista ja tiukoista viivebudjeteista. Tietoverkko maksaa itsensä takaisin monivaiheisissa kysymyksissä ja maksaa rahaa kaikkialla muualla.

GraphRAG ei ole kuollut eikä se ole oletusvalinta. Se ansaitsee indeksointilaskunsa, kun kysymyksesi ovat monivaiheisia tai kattavat koko aineiston, ja se tuottaa tappiota, kun ne eivät ole.

Lyhyt versio:

• GraphRAG voittaa monivaiheisissa ja koko aineiston kattavissa kysymyksissä; tavallinen RAG voittaa yksittäisten faktojen hauissa.
• Vuoden 2026 benchmarkit ovat ristiriitaisia: tietoverkot auttavat aggregoinnissa, mutta voivat heikentää hienojakoista tiivistämistä.
• Kustannukset syntyvät indeksointivaiheessa, LLM-ekstraktiokutsuissa, eivät kyselyaikana.
• Aja Basic Search vertailukohtana omalla aineistollasi ennen kuin rakennat mitään.

Jos sinulla on jo toimiva vektoripohjainen RAG-putki, ainoa päätös on se, ansaitseeko päälle rakennettu tietoverkko paikkansa. Alla oleva taulukko on koko argumentti kuudella rivillä, ja kohdissa, joissa se kehottaa pysymään tavallisessa RAGissa, se on rehellinen vastaus, useammin kuin toimittajat myöntävät. BM25:n ja vektorien yhdistävä hybridihaku kattaa suurimman osan näistä tapauksista kokonaan ilman tietoverkkoa.

Mitä GraphRAG todella on: lohkoista yhteisöihin

GraphRAG on hakupohjaista generointia, joka tehdään tietoverkon eikä irtonaisten lohkojen päällä. Indeksointivaiheessa LLM poimii dokumenteista entiteetit ja niiden väliset suhteet, Leiden-algoritmi ryhmittelee entiteetit yhteisöihin, ja jokainen yhteisö saa tiivistelmän. Kyselyaikana tietoverkko ja nämä tiivistelmät vastaavat kysymyksiin, joihin top_k-ikkuna lohkojen yli ei rakenteellisesti pysty.

Putki alusta loppuun:

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

Kaksi vaihetta tekevät työn. Indeksointivaihe on kallis: jokainen lohko maksaa LLM-kutsun entiteettien ja suhteiden poimimiseksi, ja yhteisötiivistelmät maksavat lisäksi omat kutsunsa. Kyselyvaiheessa hyöty näkyy. Koska tietoverkko tallentaa suhteet eksplisiittisesti, kysymyksestä "mitä toimittajia suurin asiakkaamme myös myy?" tulee läpikäynti sen sijaan, että toivottaisiin oikeiden kahden lohkon osuvan samaan top_k-ikkunaan.

Tiivistelmät ovat tärkeitä, koska juuri niitä Global Search todella lukee: koko aineiston kattaviin kysymyksiin vastataan valmiiksi kirjoitetusta yhteisöproosasta, ei raaoista lohkoista. Ja jokainen kaari on LLM:n harkintapäätös, joka tallennetaan kolmikkona, jonka voisi kysyä Cypherillä oikeassa graafitietokannassa. Tämän rakenteen vuoksi indeksointi hallitsee kustannuksia, minkä alla olevat luvut tekevät konkreettiseksi.

Kehys, joka ansaitsee paikkansa: tavallinen RAG hakee kappaleita, GraphRAG hakee rakennetta. Upotusmallin valinnalla on yhä väliä vektorikerroksessa, ja vektoritietokanta tallentaa yhä kuvaukset, mutta tietoverkko on uusi kantava osa. Virallinen Index Overview -dokumentaatio kuvaa jokaisen vaiheen yksityiskohtaisesti.

Mitkä ovat GraphRAGin neljä kyselytapaa?

GraphRAGin kyselymoottori sisältää neljä tapaa: Local Search, Global Search, DRIFT Search ja Basic Search. Local Search päättlee tiettyjen entiteettien ympäriltä, Global Search koostaa yhteisötiivistelmiä koko aineiston yli, DRIFT Search yhdistää nämä kaksi rekursiivisesti, ja Basic Search on tavallinen vektoripohjainen vertailukohta. Viides ominaisuus, Question Generation, istuu moottorin päällä eikä sen rinnalla.

Tarkistimme live-dokumentaation osoitteessa microsoft.github.io/graphrag/query/overview/ 30.7.2026, ja määrä on neljä. Useimmat sijoittuvat oppaat nimeävät kaksi tai kolme. Sama tarkistus löysi sanan "lazy" nolla kertaa sekä Index- että Query-yleiskatsaussivuilta, mikä on oleellista alla olevan kustannusosion kannalta.

Rivi, joka ansaitsee huomiosi, on viimeinen. Basic Search on sisäänrakennettu tavallisen vektorin vertailukohta, ja se on olemassa, jotta voit A/B-testata tietoverkkoa tavallista hakua vastaan omalla aineistollasi ja selvittää, ansaitseeko tietoverkko laskunsa. Se ei ole triviaalia; se on tämän oppaan koko päätösproseduuri yhdessä ominaisuudessa. Aja Basic Search ensin. Jos Local, Global tai DRIFT ei voita sitä kysymyksissä, joita todella saatte, tietoverkko on kustannus eikä parannus.

Mitä vuoden 2026 benchmarkit oikeasti osoittivat?

Kolme vuoden 2026 benchmark-tutkimusta osoittaa, että GraphRAG auttaa monivaiheisissa ja monen faktan aggregointitehtävissä, mutta jää usein tavallisesta RAGista muualla. Yksi niistä rakentaa benchmarkin nimenomaan löytääkseen, missä tietoverkot häviävät. Kaikki kolme ovat yhtä mieltä siitä, että voitto riippuu kysymystyypistä eikä aineiston koosta. Todisteiden mukaan GraphRAG on tilannesidonnainen eikä oletusvalinta.

Neljäs hanke, GraphRAG-Bench (repositorio), arvioi yhdeksää GraphRAG-tapaa 16 tieteenalalla ja 20 oppikirjalla ja päätyy samaan johtopäätökseen laajemmasta kulmasta.

Kaikki kolme tutkimusta kohtaavat yhdessä pisteessä: tietoverkko ansaitsee hintansa monivaiheisessa aggregoinnissa ja menettää sen hienojakoisessa muistamisessa.

Tulkintamme: hype-sykli teki vahingon, ja nämä tutkimukset ovat korjausliike. Yksikään niistä ei sano, että tietoverkot olisivat hyödyttömiä. Ne sanovat johdonmukaisesti, että aggregointivaihe, joka tekee GraphRAGista hyvän koko aineiston teemoissa, on sama vaihe, joka sumentaa hienojakoiset yksityiskohdat. WildGraphBench on selkein esimerkki: tietoverkot auttoivat monen faktan aggregoinnissa kohtuullisesta määrästä lähteitä ja heikensivät tiivistämisen tarkkuutta samassa arvioinnissa. Se ei ole ristiriita; se on yksi mekanismi, joka näkyy kahdesti.

Käytännön seuraus on, että tätä ei voi päättää pelkästään kirjallisuuden perusteella. Tutkimukset kertovat, mitä kysymystyyppejä kannattaa testata, eivät sitä, kuuluuko sinun aineistosi niihin. Juuri siihen menetelmäosiosta tuttu Basic Search -vertailukohta on tarkoitettu.

Paljonko GraphRAG maksaa? (Ja LazyGraphRAG-varaus, jonka kaikki toistavat väärin)

GraphRAGin kustannukset ovat indeksointivaiheen lasku, eivät kyselyaikainen, ja juuri siksi ne yllättävät ihmiset. LLM-kutsut, jotka poimivat entiteetit ja suhteet jokaisesta lohkosta, sekä yhteisöjen tiivistysvaihe tekevät siitä kalliin. Maksat etukäteen, ennen kuin yksikään kysely ajetaan. Kyselyaika on halvempaa mutta ei ilmaista: Global Search haarautuu yhteisötiivistelmien yli yhdellä LLM-kutsulla yhteisöä kohden, minkä vuoksi yllä oleva menetelmätaulukko merkitsee sen korkeaksi.

Ainoat julkiset kovat luvut tulevat Microsoft Researchilta. 25.11.2024 tiimi raportoi, että LazyGraphRAGin indeksointikustannus oli identtinen vektoripohjaisen RAGin kanssa ja 0,1 % täyden GraphRAGin kustannuksista, ja että 4 %:lla GraphRAGin global searchin kyselykustannuksista se voitti testatut kilpailevat menetelmät sekä paikallisissa että globaaleissa kyselytyypeissä (Microsoft Research). Nuo ovat Microsoftin lukuja Microsoftin blogista, ja raportoimme ne sellaisina; emme ole itse ajaneet hinnoiteltua indeksointia.

Tässä on korjaus, jonka useimmat kirjoitukset ohittavat. LazyGraphRAG ei ole pip-asennusvaihtoehto. Microsoftin oman 6.6.2025 toimituksen huomautuksen mukaan se toimitettiin Microsoft Discoveryyn ja Azure Localiin, ei avoimen lähdekoodin pakettiin. Tarkistimme viralliset Index Overview- ja Query Overview -sivut 30.7.2026: sana "lazy" esiintyy nolla kertaa molemmilla. Jos siis jokin opas listaa LazyGraphRAGin varianttina, jonka voi käynnistää tänä iltapäivänä, se toistaa väitettä, joka lakkasi olemasta totta avoimen lähdekoodin maailmassa.

Mitä voit tehdä tänään: aja ekstraktiomalli paikallisesti. Indeksointivaiheen osoittaminen paikalliseen malliin Ollaman kautta poistaa tokenikohtaiset API-maksut kalleimmasta vaiheesta, ja sen yhdistäminen itse ylläpidettyyn vektorivarastoon pitää loput laskusta lähellä nollaa.

Mitä GraphRAG-kirjastoa oikeasti ylläpidetään?

Kahteen kuudesta viitatuimmasta GraphRAG-kirjastosta ei ole tehty pushia kuuteen eikä yhdeksään kuukauteen. Vedimme nämä luvut GitHub APIsta 30.7.2026, ja alla oleva katsaus on tarkistus, jonka vanhemmat koosteet ohittavat, mukana komento sen uudelleenajamiseksi ennen kuin sitoudut yhteen. LightRAG ja microsoft/graphrag ovat aktiiviset; nano-graphrag ja fast-graphrag ajautuvat kohti abandonwarea.

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

Tulkintamme: tähdet ovat turhamaisuusmittari; push-päiväys on se ratkaiseva luku. LightRAGia ja microsoft/graphragia ylläpidetään molempia aktiivisesti, Graphiti lähellä perässä aikaulottuvuuden graafikulmalla. nano-graphrag ja fast-graphrag ovat ne kaksi, joita vanhemmat kirjoitukset suosittelevat yhä maineen perusteella, eikä kumpikaan ole julkaissut puoleen vuoteen.

Miten valita: valitse microsoft/graphrag, jos haluat referenssitoteutuksen neljällä virallisella kyselytavalla, LightRAG, jos haluat aktiivisimman projektin ja kevyemmän jalanjäljen, ja toimittajan ylläpitämä kirjasto kuten neo4j-graphrag-python, jos sinulla on jo kyseisen toimittajan tietokanta. Vältä kaikkea, jonka viimeisin push on puoli vuotta projektiasi vanhempi.

Graphiti ansaitsee yhden rajatun huomautuksen: sen aikasidonnaisen graafin suunnittelu on rakennettu hakua varten aikatajuisesta datasta, ja se menee päällekkäin agenttimuistin kanssa, jota käsittelemme erikseen oppaassamme Graphiti ja aikasidonnainen graafimuisti. Laajempaan kenttään tutustu laajemmassa RAG-työkalukentässä.

Mikä hajoaa päivän 200 jälkeen: graafin ryömintä ja uudelleenekstraktio

Graafin ryömintä on vero, jonka maksat julkaisun jälkeen, ja se on ykkössyy käytännön toimijoiden vastustukseen syystä. Jokainen tutoriaali käsittelee tietoverkkoa asiana, jonka rakentaa kerran. Oikeat tiimit jumittuvat päivänä 200.

Kolme asiaa rapistuu. Ensimmäinen, uudelleenindeksointi dokumenttipäivitysten yhteydessä. Kun 40 dokumenttia muuttuu, et voi vain upottaa niitä uudelleen; sinun täytyy ajaa LLM-ekstraktio uudelleen muuttuneille lohkoille, sovittaa uudet entiteetit vanhaan tietoverkkoon ja laskea uudelleen vaikuttuneet yhteisöt ja niiden tiivistelmät. Eräs Medium-opas kutsuu inkrementaalista päivitystä helpoksi. r/Ragin käytännön toimijat ovat eri mieltä. 25.4.2026 ketjun aloittaja, joka ajaa BM25:tä ja BGE-M3:ta noin 600 dokumentin yli, sanoi suoraan: "LLM-pohjainen entiteettien ja suhteiden ekstraktio on kohinaista, ja uudelleenindeksointi dokumenttipäivityksissä näyttää tuskalliselta."

Toinen, entiteettiresoluution rapistuminen. "Acme Corp", "Acme" ja "ACME Corporation" saapuvat eri dokumenteissa kuukausien välein ja jakautuvat kolmeksi solmuksi, joiden pitäisi olla yksi. Mikään ei yhdistä niitä automaattisesti.

Kolmas, suhteet, jotka olivat totta ekstraktiohetkellä ja lakkasivat hiljaa olemasta totta. Kukaan ei saa hälytystä, kun reports_to-kaari vanhenee.

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)

Koodipohja on pahin tapaus ja kiinnostavin. Autocomplete tarjoaa nyt "graphrag for codebase", "graphrag claude code" ja "graphrag mcp server", ja koodipohja on tietoverkko, joka muuttuu tunneittain: jokainen commit kirjoittaa kutsukaaria uudelleen, siirtää symboleja ja poistaa funktioita. Se on graafin ryömintää aikataululla, jota yksikään öittäinen uudelleenindeksointi ei täysin pysy perässä. Juuri siksi vakavat koodigraafityökalut nojaavat deterministisiin parsereihin kuten tree-sitter ja LSP kaarien osalta ja varaavat LLM:n niitä ympäröivälle proosalle: docstringit, commit-viestit, review-ketjut. Jos graafitat repoa, graafita hidasliikkeinen kerros LLM:llä ja nopeasti liikkuva parserilla.

Mitä kehittäjät oikeasti sanovat GraphRAGista?

Työskentelevät kehittäjät ovat jakautuneet, ja Google näyttää tietävän sen: Reddit-ketju sijoittuu toiseksi haulla "graphrag vs rag", mikä on hakukoneen tapa kertoa, että tämä aihe kaipaa vertaisten mielipidettä eikä toimittajien myyntipuhetta.

Skeptisyys on todellista. r/Ragin vuoden 2024 ketjussa "Would you always recommend (knowledge) graph RAG over normal RAG?" (10 pistettä, 86 % ylösääniä) u/EncartaIt kirjoitti: "Kaikki löytämäni tutoriaalit ovat liian yksinkertaistettuja eivätkä ne todellakaan esitä vahvaa perustelua tietoverkkomallille." u/Prestigious_Run_4049 oli suorempi: "Minusta graph rag on pelkkää hypeä. Ihmiset rakastavat puhua siitä ja se kuulostaa siistiltä, mutta kukaan ei oikeasti käytä sitä todellisissa käyttötapauksissa." Kaikki eivät ole samaa mieltä. u/pytheryx, tuotantokokemuksen pohjalta, huomautti, että graafihaku voittaa listatyyppisissä kysymyksissä, jotka tarvitsevat kontekstia useammasta lohkosta kuin top_k palauttaa; hänen whitepaper-aineistonsa tarvitsee noin 50 lohkoa täydelliseen vastaukseen.

Vuoden 2026 ketju on harkitumpi. u/Popular_Sand2773: "Useimmat graph rag -setups vain huijaavat skaalassa. Ajat tavallisen vektori- tai metadatahaun löytääksesi siemensolmut ja sitten kävelet ympäriinsä." u/ggone20, joka ajaa noin 300 miljoonan artefaktin järjestelmää: "Skaalassa et kirjaimellisesti voi elää ilman niitä vastataksesi oikeisiin kysymyksiin."

Tulkintamme vastaa molempien ketjujen terävintä argumenttia: käännekohta on kysymystesi monimutkaisuus, ei aineistosi koko. Sen osoittivat myös yllä olevat benchmarkit, minkä vuoksi olemme samaa mieltä niiden käytännön toimijoiden kanssa, jotka rajaavat työkalun monivaiheiseen työhön, emmekä niiden, jotka julistavat sen kuolleeksi.

Näin Techsy lähestyy tätä

Tässä on järjestys, jota käytämme asiakasprojekteissa, ja se on tarkoituksella tylsä.

Ensiksi, todista hybridin haun katto. Useimmat "tarvitsemme tietoverkon"-pyynnöt, joita kuulemme, ovat todellisuudessa lohkomis- tai uudelleenjärjestelyongelma valepuvussa. BM25-ja-vektori-putki kelvollisella rerankerilla vastaa useampaan kysymykseen kuin tiimit odottavat.

Toiseksi, aja Basic Search vertailukohtana omalla aineistollasi ennen kuin rakennat mitään. Juuri siihen neljäs kyselytapa on tarkoitettu: tavallinen vektoripohjainen vertailukohta, jota vasten voit A/B-testata tietoverkkoa, omalla datallasi, omilla kysymyksilläsi.

Kolmanneksi, rakenna tietoverkko vasta, kun mitattu kysymysluokka epäonnistuu tuossa vertailukohdassa. Jos monivaiheiset tai koko aineiston kattavat kyselyt epäonnistuvat, sinulla on todellinen peruste. Jos ne eivät epäonnistu, säästit juuri itseltäsi indeksointilaskun ja ryömintäongelman.

Haluatko toisen parin silmiä hakupinoosi? Hanki ilmainen konsultaatio.

Tietoja kirjoittajasta

Mert Batur on Techsy.io:n perustajajäsen, ja tiimi toimittaa tekoälyagentteja, automaatiojärjestelmiä ja ääni-/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi todella käyttää tuotannossa. Asiakasprojekteissa hän tekee hakuarkkitehtuuripäätökset: milloin hybridihaku riittää ja milloin aineisto todella tarvitsee tietoverkon. Ota yhteyttä LinkedInissä.

Usein kysytyt kysymykset

Miten GraphRAG toimii?

GraphRAG indeksoi dokumenttisi tietoverkoksi. LLM poimii entiteetit ja suhteet jokaisesta lohkosta, Leiden-algoritmi klusteroi entiteetit yhteisöihin, ja jokainen yhteisö saa tiivistelmän. Kyselyaikana moottori hakee tietoverkosta ja näistä tiivistelmistä, joten se voi yhdistää faktoja, jotka sijaitsevat eri lohkoissa.

Miten GraphRAG eroaa tavallisesta RAGista?

Tavallinen RAG hakee top-k samankaltaisimmat lohkot ja syöttää ne mallille. GraphRAG hakee rakennetta: entiteetit, niiden väliset suhteet ja valmiiksi kirjoitetut yhteisötiivistelmät. Juuri tämä lisärakenne mahdollistaa monivaiheisiin ja koko aineiston kattaviin kysymyksiin vastaamisen, ja se tekee myös indeksoinnista hitaampaa ja kalliimpaa.

Milloin GraphRAGia kannattaa käyttää?

Käytä sitä, kun kysymyksesi ylittävät entiteettien rajat tai kattavat koko aineiston, kuten toimittajien päällekkäisyyskysymykset tai toistuvien teemojen analyysi tuhansien dokumenttien yli. Jätä se väliin yksittäisten faktojen hauissa, nopeasti muuttuvissa aineistoissa ja tiukoissa viive- tai kustannusbudjeteissa. Jos tavallinen hybridiputki vastaa jo kysymysluokkaan, tietoverkko lisää kustannuksia lisäämättä arvoa.

Onko GraphRAG kuollut?

Ei, mutta se ei ole myöskään oletusvalinta. Vuoden 2026 benchmarkit osoittavat, että se jää usein tavallisesta RAGista arkisissa tehtävissä, mikä tappoi hypen, samalla kun se voittaa yhä monivaiheisissa ja aggregointikysymyksissä. Rehellinen kehys on tilannesidonnainen: GraphRAG ansaitsee hintansa oikeilla kysymystyypeillä ja tuottaa tappiota lopuissa.

Mitkä ovat GraphRAGin kyselytavat?

Virallinen kyselymoottori sisältää neljä: Local Search entiteettikeskeisille kysymyksille, Global Search koko aineiston aggregoinnille, DRIFT Search näiden kahden rekursiiviselle yhdistelmälle ja Basic Search tavalliselle vektorihaulle. Viides ominaisuus, Question Generation, istuu päällä. Basic Search on tärkein: se on vertailukohta, jota vasten tietoverkkoa A/B-testataan.

Paljonko GraphRAGin indeksointi maksaa?

Kustannukset syntyvät indeksointivaiheessa, LLM-kutsuissa, jotka poimivat entiteetit ja suhteet jokaisesta lohkosta, sekä yhteisöjen tiivistämisessä. Microsoft Research raportoi LazyGraphRAGin indeksoinnin olevan 0,1 % täyden GraphRAGin kustannuksista ja identtinen vektoripohjaisen RAGin kanssa, mutta tuo variantti toimitettiin Microsoftin tuotteisiin, ei avoimen lähdekoodin kirjastoon. Emme ole itse ajaneet hinnoiteltua indeksointia.

Voinko ajaa GraphRAGia paikallisesti Ollamalla?

Kyllä. microsoft/graphrag-kirjasto antaa osoittaa indeksoinnin ja kyselyn paikalliseen malliin, jota Ollama tarjoilee, mikä poistaa tokenikohtaiset API-maksut ekstraktiovaiheesta. Vaihdat nopeutta ja laatua kustannuksiin: paikalliset mallit ovat heikompia entiteettien ekstraktiossa, joten odota kohinaisempia tietoverkkoja ja pidempiä indeksointiajoja vaatimattomilla laitteilla.

Kumpi on parempi, LightRAG vai Microsoft GraphRAG?

Ne optimoivat eri asioihin. LightRAG (38 353 tähteä, push 30.7.2026) on aktiivisin ja kevyempi ajaa; microsoft/graphrag (35 088 tähteä, v3.1.1) on referenssitoteutus neljällä virallisella kyselytavalla. Valitse LightRAG tehokkaaseen tuotantotietoverkkoon, Microsoftin tarkkaan spesifikaation mukaiseen käytökseen ja Basic Search -vertailukohtaan.

Kuka loi GraphRAGin ja milloin?

Microsoft Research loi GraphRAGin. Tiimi julkaisi tutkimuksen vuonna 2024 ja ylläpitää avoimen lähdekoodin microsoft/graphrag-repositoriota MIT-lisenssillä, dokumentaatio osoitteessa microsoft.github.io/graphrag. Referenssikirjasto saavutti version v3.1.1 18.7.2026, ja sen ympärille on kasvanut aktiivinen kolmannen osapuolen toteutusten ekosysteemi, mukaan lukien LightRAG ja Graphiti.

Tuomio: milloin tietoverkko ansaitsee hintansa

Todisteet osoittavat yhteen suuntaan, joten tässä on kantamme.

• GraphRAG ei ole kuollut. Se on tilannesidonnainen, ja vuoden 2026 benchmarkit sanovat sen ääneen.
• Se ansaitsee indeksointilaskunsa monivaiheisissa entiteettikysymyksissä ja koko aineiston aggregoinnissa. Se tuottaa tappiota yksittäisten faktojen hauissa.
• Kustannus on indeksointivaiheen lasku, eikä halpa variantti, jota kaikki lainaavat, LazyGraphRAG, koskaan päätynyt avoimen lähdekoodin kirjastoon.
• Tietoverkko rapistuu julkaisun jälkeen: entiteettiresoluutio ryömii ja suhteet vanhenevat, joten budjetoi uudelleenindeksointi.
• Aja Basic Search vertailukohtana omalla aineistollasi ennen kuin rakennat mitään.

Yksi lause: tietoverkko ansaitsee hintansa, kun kysymyksesi ovat monivaiheisia tai kattavat koko aineiston, eikä ennen sitä. Jos haluat toisen mielipiteen hakupinostasi, hanki ilmainen konsultaatio.