Ghid GraphRAG: Când graful de cunoștințe bate RAG-ul vectorial (și când nu)

Ghid GraphRAG: Când graful de cunoștințe bate RAG-ul vectorial (și când nu)

GraphRAG nu a murit, dar nici nu este opțiunea implicită. microsoft/graphrag a lansat v3.1.1 pe 2026-07-18, la 35.088 de stele pe GitHub, iar trei lucrări de benchmark din 2026 raportează acum, deschis, că pierde frecvent în fața recuperării vectoriale simple. Așadar, acest ghid GraphRAG răspunde la singura întrebare rămasă: merită un graf de cunoștințe costul indexării?

Ar trebui să folosești GraphRAG? Răspunsul scurt

Folosește GraphRAG când întrebările tale traversează entități sau acoperă întregul corpus, de exemplu „căror furnizori le vinde și cel mai mare client al nostru?" Rămâi la RAG vanilla sau hibrid pentru căutări de fapte pe un singur salt, documente care se schimbă rapid și bugete strânse de latență. Graful își plătește costul la întrebările multi-hop și pierde bani oriunde altundeva.

GraphRAG nu a murit și nu este nici opțiunea implicită. Își câștigă costul de indexare când întrebările sunt multi-hop sau globale la nivel de corpus și pierde bani când nu sunt.

Versiunea scurtă:

• GraphRAG câștigă la întrebări multi-hop și la nivel de corpus; RAG-ul vanilla câștigă la căutările pe un singur salt.
• Benchmark-urile din 2026 sunt contradictorii: graful ajută la agregare, dar poate dăuna sumarizării fine.
• Costul apare la indexare, în apelurile LLM de extracție, nu la interogare.
• Rulează Basic Search ca grup de control pe propriul corpus înainte să construiești orice.

Dacă ai deja un pipeline RAG vectorial funcțional, singura decizie este dacă un graf deasupra își câștigă locul. Tabelul de mai jos este întregul argument în șase rânduri, iar acolo unde spune să rămâi la vanilla, acela este răspunsul sincer, mai des decât admit furnizorii. Recuperarea hibridă BM25 plus vectorială acoperă majoritatea acestor cazuri fără niciun graf.

Ce este de fapt GraphRAG: De la chunk-uri la comunități

GraphRAG este generare augmentată prin recuperare peste un graf de cunoștințe, nu peste chunk-uri deconectate. La indexare, un LLM extrage entități și relații din documentele tale, algoritmul Leiden grupează acele entități în comunități, iar fiecare comunitate primește o sumarizare. La interogare, graful plus acele sumarizări răspund la întrebări pe care o fereastră top_k peste chunk-uri nu le poate structura.

Pipeline-ul, cap-coadă:

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

Două faze fac treaba. Faza de indexare este cea scumpă: fiecare chunk costă un apel LLM pentru extragerea entităților și relațiilor, iar sumarizările de comunitate costă și mai multe apeluri. Faza de interogare este cea în care apare câștigul. Pentru că graful stochează relațiile explicit, o întrebare precum „căror furnizori le vinde și cel mai mare client al nostru?" devine o parcurgere, nu o speranță că cele două chunk-uri potrivite aterizează în aceeași fereastră top_k.

Sumarizările contează pentru că ele sunt ceea ce citește de fapt Global Search: întrebările la nivel de corpus primesc răspuns din textul de comunitate pre-scris, nu din chunk-uri brute. Și fiecare muchie este o judecată a LLM-ului, stocată ca triplet pe care l-ai putea interoga în Cypher pe o bază de date de graf reală. Acest design este și motivul pentru care indexarea domină costul, ceea ce cifrele de mai jos concretizează.

Încadrarea care își câștigă locul: RAG-ul vanilla recuperează pasaje, iar GraphRAG recuperează structură. Alegerea modelului de embedding contează în continuare pentru stratul vectorial, iar baza de date vectorială stochează în continuare descrierile, dar graful este noua piesă portantă. Documentația oficială Index Overview descrie fiecare etapă complet.

Care sunt cele patru metode de interogare GraphRAG?

Motorul de interogare GraphRAG livrează patru metode: Local Search, Global Search, DRIFT Search și Basic Search. Local Search raționează pornind de la entități specifice, Global Search agregă sumarizările de comunitate peste întregul corpus, DRIFT Search le combină recursiv pe cele două, iar Basic Search este o linie de bază vectorială simplă. O a cincea funcție, Question Generation, stă deasupra motorului, nu lângă el.

Am verificat documentația live la microsoft.github.io/graphrag/query/overview/ pe 2026-07-30, iar numărul este patru. Majoritatea ghidurilor din topuri numesc două sau trei. Aceeași verificare a găsit cuvântul „lazy" de zero ori pe ambele pagini de prezentare Index și Query, ceea ce contează pentru secțiunea de cost de mai jos.

Rândul care merită atenția ta este ultimul. Basic Search este linia de bază vectorială vanilla integrată și există ca să poți compara graful cu recuperarea simplă pe propriul corpus și să afli dacă graful își câștigă costul. Nu este un detaliu; este întreaga procedură decizională a acestui ghid într-o singură funcție. Rulează Basic Search primul. Dacă Local, Global sau DRIFT search nu îl bat la întrebările pe care le primești de fapt, graful este un cost, nu un upgrade.

Ce au descoperit de fapt benchmark-urile din 2026?

Trei lucrări de benchmark din 2026 constată că GraphRAG ajută la sarcinile de agregare multi-hop și multi-fact, dar subperformează frecvent față de RAG-ul vanilla în alte părți. Una dintre ele construiește un benchmark special pentru a găsi unde pierd grafele. Toate trei sunt de acord că câștigul depinde de tipul întrebării, nu de dimensiunea corpusului. Dovezile spun că GraphRAG este situațional, nu implicit.

Un al patrulea efort, GraphRAG-Bench (repository), evaluează nouă metode GraphRAG pe 16 discipline și 20 de manuale și ajunge la aceeași concluzie dintr-un unghi mai larg.

Toate trei lucrările converg asupra unui singur punct: graful își câștigă costul la agregarea multi-hop și îl pierde la recall-ul fin.

Lectura noastră: ciclul de hype a făcut stricăciunea, iar aceste lucrări sunt corecția. Niciuna nu spune că grafele sunt inutile. Ceea ce spun, în mod consecvent, este că pasul de agregare care face GraphRAG bun la teme la nivel de corpus este același pas care estompează detaliile fine. WildGraphBench este exemplul cel mai clar: grafele au ajutat agregarea multi-fact dintr-un număr moderat de surse și au dăunat preciziei sumarizării în aceeași evaluare. Nu este o contradicție; este un singur mecanism care apare de două ori.

Consecința practică este că nu poți decide asta doar din literatură. Lucrările îți spun ce tipuri de întrebări să testezi, nu dacă corpusul tău este unul dintre ele. Exact pentru asta este grupul de control Basic Search din secțiunea de metode de mai sus.

Cât costă GraphRAG? (Și avertismentul LazyGraphRAG pe care toată lumea îl repetă greșit)

Costul GraphRAG este o factură de timp de indexare, nu de timp de interogare, ceea ce este exact motivul pentru care surprinde oamenii. Apelurile LLM care extrag entități și relații din fiecare chunk, plus pasul de sumarizare a comunităților, sunt cele care îl fac scump. Plătești în avans, înainte ca o singură interogare să ruleze. Timpul de interogare este mai ieftin, dar nu gratuit: Global Search se ramifică peste sumarizările de comunitate cu un apel LLM per comunitate, motiv pentru care tabelul de metode de mai sus îl marchează drept ridicat.

Singurele cifre publice concrete vin de la Microsoft Research. Pe 2024-11-25, echipa a raportat că costul de indexare al LazyGraphRAG a fost identic cu cel al RAG-ului vectorial și 0,1% din costul GraphRAG complet și că, la 4% din costul de interogare al Global Search GraphRAG, a întrecut metodele concurente testate, atât la tipurile de interogări locale, cât și la cele globale (Microsoft Research). Acestea sunt cifrele Microsoft, de pe blogul Microsoft, și le raportăm ca atare; nu am rulat un index cu prețuri proprii.

Iată corecția pe care majoritatea articolelor o ratează. LazyGraphRAG nu este o opțiune de instalare prin pip. Conform propriei note editoriale Microsoft din 2025-06-06, a fost livrat în Microsoft Discovery și Azure Local, nu în pachetul open-source. Am verificat paginile oficiale Index Overview și Query Overview pe 2026-07-30: cuvântul „lazy" apare de zero ori pe ambele. Deci, dacă un ghid listează LazyGraphRAG ca o variantă pe care o poți porni în această după-amiază, repetă o afirmație care a încetat să fie adevărată în lumea open-source.

Ce poți face azi: rulează modelul de extracție local. Direcționarea pasului de indexare către un model local prin Ollama elimină taxele API per token din cea mai scumpă fază, iar combinarea lui cu un magazin vectorial auto-găzduit ține restul facturii aproape de zero.

Care bibliotecă GraphRAG este de fapt întreținută?

Două dintre cele șase biblioteci GraphRAG cele mai citate nu au avut un push de șase, respectiv nouă luni. Am extras aceste cifre din API-ul GitHub pe 2026-07-30, iar recensământul de mai jos este verificarea pe care roundup-urile mai vechi o sar, cu comanda pentru a o re-rula înainte să te decizi la una. LightRAG și microsoft/graphrag sunt cele active; nano-graphrag și fast-graphrag se îndreaptă spre abandonware.

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

Lectura noastră: stelele sunt o metrică de vanitate; data push-ului este cifra care contează. LightRAG și microsoft/graphrag sunt ambele întreținute activ, cu Graphiti aproape în urmă pe un unghi de graf temporal. nano-graphrag și fast-graphrag sunt cele două pe care postările mai vechi încă le recomandă doar pe reputație și niciuna nu a livrat de jumătate de an.

Cum alegi: alege microsoft/graphrag dacă vrei implementarea de referință cu cele patru metode oficiale de interogare, LightRAG dacă vrei cel mai activ proiect și o amprentă mai ușoară, iar o bibliotecă întreținută de furnizor precum neo4j-graphrag-python dacă rulezi deja baza de date a acelui furnizor. Evită orice al cărui ultim push precede proiectul tău cu jumătate de an.

Graphiti merită o notă delimitată: designul său de graf temporal este construit pentru recuperare peste date conștiente de timp și se suprapune cu memoria agenților, pe care o acoperim separat în ghidul nostru despre Graphiti și memoria de graf temporal. Pentru peisajul mai larg, vezi peisajul mai larg al instrumentelor RAG.

Ce se strică după ziua 200: Deriva grafului și re-extracția

Deriva grafului este taxa pe care o plătești după lansare și este obiecția numărul unu a practicienilor, cu motiv. Fiecare tutorial tratează graful ca pe un lucru pe care îl construiești o dată. Echipele reale se blochează în ziua 200.

Trei lucruri se degradează. Primul, re-indexarea la actualizările documentelor. Când 40 de documente se schimbă, nu le poți doar re-embedui; trebuie să re-rulezi extracția LLM pe chunk-urile modificate, să reconciliezi noile entități cu graful vechi și să recalculezi comunitățile afectate și sumarizările lor. Un ghid de pe Medium numește actualizarea incrementală ușoară. Practicienii de pe r/Rag nu sunt de acord. OP-ul unui fir din 2026-04-25 care rulează BM25 plus BGE-M3 pe aproximativ 600 de documente a spus-o direct: „Extracția de entități/relații bazată pe LLM este zgomotoasă, iar re-indexarea la actualizări de documente pare dureroasă."

Al doilea, degradarea rezoluției de entități. „Acme Corp", „Acme" și „ACME Corporation" sosesc în documente diferite, la luni distanță, și se împart în trei noduri care ar trebui să fie unul. Nimic nu le fuzionează automat.

Al treilea, relații care erau adevărate la momentul extracției și au încetat să mai fie adevărate în liniște. Nimeni nu primește o alertă când o muchie reports_to devine expirată.

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)

Un cod-sursă este cazul cel mai dificil și cel mai interesant. Autocompletarea sugerează acum „graphrag for codebase", „graphrag claude code" și „graphrag mcp server", iar un cod-sursă este un graf care se schimbă la fiecare oră: fiecare commit rescrie muchiile de apel, mută simboluri și șterge funcții. Asta este derivă de graf pe un program pe care nicio re-indexare nocturnă nu îl poate urmări complet. Este și motivul pentru care instrumentele serioase de graf de cod se bazează pe parsere deterministe precum tree-sitter și LSP pentru muchii și rezervă LLM-ul pentru textul din jurul lor: docstring-uri, mesaje de commit, fire de review. Dacă grafezi un repository, grafează stratul lent cu LLM-ul și pe cel rapid cu un parser.

Ce spun de fapt dezvoltatorii despre GraphRAG?

Dezvoltatorii activi sunt împărțiți, iar Google pare să știe asta: un fir de pe Reddit se clasează pe locul doi la „graphrag vs rag", ceea ce este motorul de căutare spunându-ți că acest subiect vrea opinia colegilor, nu text de furnizor.

Scepticismul este real. Pe firul r/Rag din 2024 „Would you always recommend (knowledge) graph RAG over normal RAG?" (10 puncte, 86% voturi pozitive), u/EncartaIt a scris: „Toate tutorialele pe care le-am găsit sunt excesiv de simpliste și nu fac un caz puternic pentru tiparul de graf de cunoștințe." u/Prestigious_Run_4049 a fost mai tranșant: „Cred că graph rag este doar hype. Oamenilor le place să vorbească despre el și sună cool, dar nimeni nu îl folosește de fapt în cazuri de utilizare reale." Nu toată lumea este de acord. u/pytheryx, argumentând din producție, a observat că recuperarea prin graf câștigă la întrebări de tip listă care necesită context din mai multe chunk-uri decât returnează top_k; corpusul său de whitepaper-uri are nevoie de aproximativ 50 de chunk-uri pentru un răspuns complet.

Firul din 2026 este mai măsurat. u/Popular_Sand2773: „Majoritatea configurațiilor graph rag doar trișează la scară. Rulezi o căutare vectorială sau pe metadate standard ca să găsești noduri de pornire, apoi te plimbi prin jur." u/ggone20, rulând un sistem de aproximativ 300 de milioane de artefacte: „La scară, pur și simplu nu poți trăi fără ele ca să răspunzi la întrebări reale."

Lectura noastră se potrivește cu cel mai ascuțit argument din ambele fire: punctul de inflexiune este complexitatea întrebărilor tale, nu dimensiunea corpusului. Asta au constatat și benchmark-urile de mai sus, motiv pentru care suntem de partea practicienilor care încadrează instrumentul la munca multi-hop, nu a celor care îl numesc mort.

Cum abordează Techsy asta

Iată secvențierea pe care o folosim la proiectele pentru clienți și este deliberat de plictisitoare.

Primul, dovedește plafonul recuperării hibride. Majoritatea cererilor „avem nevoie de un graf" pe care le auzim sunt de fapt o problemă de chunking sau de reranking deghizată. Un pipeline BM25-plus-vectorial cu un reranker decent răspunde la mai mult decât se așteaptă echipele.

Al doilea, rulează Basic Search ca grup de control pe propriul corpus înainte să construiești orice. Exact pentru asta este a patra metodă de interogare: o linie de bază vectorială simplă față de care poți compara graful, pe datele tale, cu întrebările tale.

Al treilea, construiește graful doar când o clasă măsurată de întrebări eșuează la acel control. Dacă interogările multi-hop sau la nivel de corpus ratează, ai un caz real. Dacă nu, tocmai ți-ai economisit o factură de indexare și o problemă de derivă.

Vrei o a doua opinie despre stack-ul tău de recuperare? Obține o consultație gratuită.

Despre autor

Mert Batur este cofondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri de voce/SDR pentru clienți B2B. Scrie despre stack-ul de instrumente LLM pe care echipa Techsy îl folosește de fapt în producție. La proiectele pentru clienți, el ia deciziile de arhitectură de recuperare: când căutarea hibridă este suficientă și când un corpus are de fapt nevoie de un graf. Conectează-te cu el pe LinkedIn.

Întrebări frecvente

Cum funcționează GraphRAG?

GraphRAG îți indexează documentele într-un graf de cunoștințe. Un LLM extrage entități și relații din fiecare chunk, algoritmul Leiden clusterizează acele entități în comunități, iar fiecare comunitate primește o sumarizare. La interogare, motorul caută în graf și în acele sumarizări, astfel încât poate conecta fapte care se află în chunk-uri diferite.

Cum diferă GraphRAG de RAG?

RAG-ul standard recuperează cele mai similare top-k chunk-uri și le transmite modelului. GraphRAG recuperează structură: entități, relațiile dintre ele și sumarizări de comunitate pre-scrise. Acea structură suplimentară este cea care îi permite să răspundă la întrebări multi-hop și la nivel de corpus și este tot ceea ce face indexarea mai lentă și mai scumpă.

Când ar trebui să folosesc GraphRAG?

Folosește-l când întrebările tale traversează entități sau acoperă întregul corpus, precum întrebări de suprapunere de furnizori sau analiza temelor recurente peste mii de documente. Sari peste el pentru căutări de fapte pe un singur salt, corpusuri care se schimbă rapid și bugete strânse de latență sau cost. Dacă un pipeline hibrid simplu răspunde deja la o clasă de întrebări, graful adaugă cost fără să adauge valoare.

A murit GraphRAG?

Nu, dar nici nu este opțiunea implicită. Benchmark-urile din 2026 arată că subperformează frecvent față de RAG-ul vanilla la sarcini obișnuite, ceea ce a ucis hype-ul, în timp ce câștigă în continuare la întrebări de agregare și multi-hop. Încadrarea sinceră este situațională: GraphRAG își câștigă costul pentru tipurile potrivite de întrebări și pierde bani pentru restul.

Care sunt metodele de interogare GraphRAG?

Motorul oficial de interogare livrează patru: Local Search pentru întrebări centrate pe entități, Global Search pentru agregare la nivel de corpus, DRIFT Search pentru o combinare recursivă a ambelor și Basic Search pentru recuperare vectorială simplă. O a cincea funcție, Question Generation, stă deasupra. Basic Search contează cel mai mult: este grupul de control față de care compari graful.

Cât costă indexarea GraphRAG?

Costul apare la indexare, în apelurile LLM care extrag entități și relații din fiecare chunk, plus sumarizarea comunităților. Microsoft Research a raportat indexarea LazyGraphRAG la 0,1% din costul GraphRAG complet și identică cu RAG-ul vectorial, dar acea variantă a fost livrată în produsele Microsoft, nu în biblioteca open-source. Nu am rulat un index cu prețuri proprii.

Pot rula GraphRAG local cu Ollama?

Da. Biblioteca microsoft/graphrag îți permite să direcționezi indexarea și interogarea către un model local servit de Ollama, ceea ce elimină taxele API per token din pasul de extracție. Schimbi viteză și calitate pe cost: modelele locale sunt mai slabe la extracția de entități, deci așteaptă-te la grafe mai zgomotoase și rulări de indexare mai lungi pe hardware modest.

Este LightRAG sau Microsoft GraphRAG mai bun?

Optimizează pentru lucruri diferite. LightRAG (38.353 stele, push 2026-07-30) este cel mai activ și mai ușor de rulat; microsoft/graphrag (35.088 stele, v3.1.1) este implementarea de referință cu cele patru metode oficiale de interogare. Alege LightRAG pentru un graf de producție eficient, Microsoft pentru comportament fidel specificației și grupul de control Basic Search.

Cine a creat GraphRAG și când?

Microsoft Research a creat GraphRAG. Echipa a publicat lucrarea în 2024 și întreține repository-ul open-source microsoft/graphrag sub licența MIT, cu documentație la microsoft.github.io/graphrag. Biblioteca de referință a ajuns la v3.1.1 pe 2026-07-18, iar în jurul ei a crescut un ecosistem activ de implementări terțe, inclusiv LightRAG și Graphiti.

Verdictul: Când un graf își câștigă costul

Dovezile indică o singură direcție, deci iată poziția.

• GraphRAG nu a murit. Este situațional, iar benchmark-urile din 2026 o spun cu voce tare.
• Își câștigă factura de indexare la întrebări multi-hop despre entități și la agregarea la nivel de corpus. Pierde bani la căutările pe un singur salt.
• Costul este o factură de timp de indexare, iar varianta ieftină pe care toată lumea o citează, LazyGraphRAG, nu a ajuns niciodată în biblioteca open-source.
• Graful se degradează după lansare: rezoluția entităților derivează și relațiile expiră, deci bugetează pentru re-indexare.
• Rulează Basic Search ca grup de control pe propriul corpus înainte să construiești orice.

O singură propoziție: un graf de cunoștințe își câștigă costul când întrebările tale sunt multi-hop sau globale la nivel de corpus și nu înainte. Dacă vrei o a doua opinie despre stack-ul tău de recuperare, obține o consultație gratuită.