Przewodnik GraphRAG: kiedy grafy wiedzy pokonują vector RAG (a kiedy nie)

Przewodnik GraphRAG: kiedy grafy wiedzy pokonują vector RAG (a kiedy nie)

GraphRAG nie jest martwy, ale nie jest też wyborem domyślnym. microsoft/graphrag wydał v3.1.1 2026-07-18 przy 35 088 gwiazdkach na GitHubie, a trzy artykuły benchmarkowe z 2026 roku otwarcie raportują, że często przegrywa ze zwykłym wyszukiwaniem wektorowym. Ten przewodnik GraphRAG odpowiada więc na jedyne pytanie, jakie zostało: czy graf wiedzy jest wart rachunku za indeksowanie?

Czy warto używać GraphRAG? Krótka odpowiedź

Używaj GraphRAG, gdy Twoje pytania łączą encje lub obejmują cały korpus, na przykład „którym dostawcom sprzedaje też nasz największy klient?". Przy jednoskokowych wyszukiwaniach faktów, szybko zmieniających się dokumentach i ciasnych budżetach latencji zostań przy klasycznym lub hybrydowym RAG. Graf zwraca się przy pytaniach wieloskokowych, a wszędzie indziej kosztuje.

GraphRAG nie jest martwy i nie jest domyślny. Zwraca rachunek za indeksowanie, gdy pytania są wieloskokowe lub obejmują cały korpus, a traci pieniądze, gdy takie nie są.

Wersja skrócona:

• GraphRAG wygrywa przy pytaniach wieloskokowych i obejmujących cały korpus; klasyczny RAG wygrywa przy wyszukiwaniach jednoskokowych.
• Benchmarki z 2026 roku są niejednoznaczne: grafy pomagają w agregacji, ale mogą szkodzić szczegółowym podsumowaniom.
• Koszt pojawia się w momencie indeksowania, w wywołaniach LLM do ekstrakcji, a nie w czasie zapytania.
• Zanim cokolwiek zbudujesz, uruchom Basic Search jako grupę kontrolną na własnym korpusie.

Jeśli masz już działający pipeline vector RAG, jedyną decyzją jest to, czy graf na wierzchu na siebie zarobi. Poniższa tabela to cała argumentacja w sześciu wierszach, a tam gdzie mówi „zostań przy klasyce", jest to szczera odpowiedź, częściej niż przyznają dostawcy. Hybrydowe wyszukiwanie BM25 plus wektory pokrywa większość tych przypadków całkowicie bez grafu.

Czym naprawdę jest GraphRAG: od fragmentów do społeczności

GraphRAG to generacja wspomagana wyszukiwaniem po grafie wiedzy, a nie po niepołączonych fragmentach. W fazie indeksowania LLM wyodrębnia encje i relacje z Twoich dokumentów, algorytm Leiden grupuje te encje w społeczności, a każda społeczność dostaje podsumowanie. W fazie zapytania graf plus te podsumowania odpowiadają na pytania, których okno top_k nad fragmentami strukturalnie nie jest w stanie obsłużyć.

Pipeline, od początku do końca:

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

Całą pracę wykonują dwie fazy. Faza indeksowania jest tą drogą: każdy fragment kosztuje wywołanie LLM, które wyciąga encje i relacje, a podsumowania społeczności dokładają kolejne wywołania. Faza zapytania to moment, w którym widać zwrot. Ponieważ graf przechowuje relacje wprost, pytanie typu „którym dostawcom sprzedaje też nasz największy klient?" staje się przejściem po grafie, a nie nadzieją, że dwa właściwe fragmenty wylądują w tym samym oknie top_k.

Podsumowania mają znaczenie, bo to właśnie je faktycznie czyta Global Search: pytania o cały korpus dostają odpowiedź z napisanych wcześniej opisów społeczności, a nie z surowych fragmentów. A każda krawędź to osąd LLM, zapisany jako trójka, którą można odpytać w Cypherze na prawdziwej bazie grafowej. Ten projekt wyjaśnia też, dlaczego indeksowanie dominuje w kosztach, co konkretyzują liczby poniżej.

Ujęcie, które zasługuje na miejsce: klasyczny RAG pobiera fragmenty tekstu, a GraphRAG pobiera strukturę. Twój wybór modelu embeddingowego wciąż ma znaczenie dla warstwy wektorowej, a Twoja baza wektorowa wciąż przechowuje opisy, ale to graf jest nowym elementem nośnym. Oficjalna dokumentacja Index Overview opisuje każdy etap szczegółowo.

Jakie są cztery metody zapytań GraphRAG?

Silnik zapytań GraphRAG dostarcza cztery metody: Local Search, Global Search, DRIFT Search i Basic Search. Local Search rozumuje na zewnątrz od konkretnych encji, Global Search agreguje podsumowania społeczności w całym korpusie, DRIFT Search rekurencyjnie łączy oba podejścia, a Basic Search to zwykła baza wektorowa. Piąta funkcja, Question Generation, leży na warstwie powyżej silnika, a nie obok niego.

Sprawdziliśmy aktualną dokumentację na microsoft.github.io/graphrag/query/overview/ 2026-07-30 i liczba wynosi cztery. Większość rankingowych poradników wymienia dwie lub trzy. Ta sama kontrola znalazła słowo „lazy" zero razy na obu stronach przeglądowych Index i Query, co ma znaczenie dla sekcji o kosztach poniżej.

Wiersz, który zasługuje na Twoją uwagę, to ostatni. Basic Search to wbudowana baza w postaci klasycznego wyszukiwania wektorowego i istnieje po to, abyś mógł porównać graf ze zwykłym wyszukiwaniem na własnym korpusie i sprawdzić, czy graf zarabia na swój rachunek. To nie jest ciekawostka; to cała procedura decyzyjna tego przewodnika zamknięta w jednej funkcji. Najpierw uruchom Basic Search. Jeśli Local, Global ani DRIFT Search nie biją go na pytaniach, które faktycznie dostajesz, graf jest kosztem, a nie ulepszeniem.

Co naprawdę wykazały benchmarki z 2026 roku?

Trzy artykuły benchmarkowe z 2026 roku stwierdzają, że GraphRAG pomaga w zadaniach wieloskokowych i agregacji wielu faktów, ale poza tym często ustępuje klasycznemu RAG. Jeden z nich buduje benchmark specjalnie po to, by znaleźć miejsca, w których grafy przegrywają. Wszystkie trzy zgadzają się, że wygrana zależy od typu pytań, a nie od rozmiaru korpusu. Dowody mówią, że GraphRAG jest sytuacyjny, a nie domyślny.

Czwarte przedsięwzięcie, GraphRAG-Bench (repozytorium), ocenia dziewięć metod GraphRAG w 16 dziedzinach i 20 podręcznikach i dochodzi do tego samego wniosku z szerszej perspektywy.

Wszystkie trzy artykuły zbiegają się w jednym punkcie: graf zwraca swój koszt przy agregacji wieloskokowej i traci go przy szczegółowym przypominaniu faktów.

Nasza interpretacja: cykl hype'u narobił szkód, a te artykuły są korektą. Żaden z nich nie mówi, że grafy są bezużyteczne. Mówią natomiast konsekwentnie, że krok agregacji, dzięki któremu GraphRAG jest dobry w tematach całego korpusu, jest tym samym krokiem, który rozmywa drobne szczegóły. WildGraphBench jest najjaśniejszym przykładem: grafy pomogły agregacji wielu faktów z umiarkowanej liczby źródeł i zaszkodziły precyzji podsumowań w tej samej ewaluacji. To nie jest sprzeczność; to jeden mechanizm pojawiający się dwa razy.

Praktyczna konsekwencja jest taka, że nie da się tego rozstrzygnąć samą literaturą. Artykuły mówią, które typy pytań testować, a nie czy Twój korpus należy do któregoś z nich. Do tego właśnie służy kontrola przez Basic Search z sekcji o metodach powyżej.

Ile kosztuje GraphRAG? (I zastrzeżenie dotyczące LazyGraphRAG, które wszyscy powtarzają źle)

Koszt GraphRAG to rachunek z fazy indeksowania, a nie z fazy zapytań, i właśnie dlatego ludzi to zaskakuje. Wywołania LLM, które wyciągają encje i relacje z każdego fragmentu, plus przebieg podsumowania społeczności, to jest to, co czyni go drogim. Płacisz z góry, zanim padnie choćby jedno zapytanie. Czas zapytania jest tańszy, ale nie darmowy: Global Search rozchodzi się po podsumowaniach społeczności z jednym wywołaniem LLM na społeczność, dlatego tabela metod powyżej oznacza go jako kosztowny.

Jedyne twarde publiczne liczby pochodzą od Microsoft Research. 2024-11-25 zespół zaraportował, że koszt indeksowania LazyGraphRAG był identyczny jak w vector RAG i wynosił 0,1% kosztu pełnego GraphRAG, oraz że przy 4% kosztu zapytań global search GraphRAG przebił testowane metody konkurencyjne, zarówno na lokalnych, jak i globalnych typach zapytań (Microsoft Research). To są liczby Microsoftu, z bloga Microsoftu, i tak je raportujemy; sami nie uruchomiliśmy wycenionego indeksu.

Oto korekta, którą większość opracowań pomija. LazyGraphRAG nie jest opcją do zainstalowania przez pip. Zgodnie z własną notą redakcyjną Microsoftu z 2025-06-06, trafił do Microsoft Discovery i Azure Local, a nie do pakietu open source. Sprawdziliśmy oficjalne strony Index Overview i Query Overview 2026-07-30: słowo „lazy" pojawia się zero razy na obu. Jeśli więc jakiś poradnik wymienia LazyGraphRAG jako wariant, który możesz uruchomić dziś po południu, powtarza twierdzenie, które przestało być prawdziwe w świecie open source.

Co możesz zrobić dzisiaj: uruchomić model ekstrakcyjny lokalnie. Skierowanie kroku indeksowania na lokalny model przez Ollamę usuwa opłaty API za token z najdroższej fazy, a sparowanie tego z samodzielnie hostowanym magazynem wektorowym trzyma resztę rachunku blisko zera.

Która biblioteka GraphRAG jest naprawdę rozwijana?

Dwie z sześciu najczęściej cytowanych bibliotek GraphRAG nie miały pusha od sześciu i dziewięciu miesięcy. Pobraliśmy te dane z API GitHuba 2026-07-30, a poniższy spis to kontrola, którą starsze zestawienia pomijają, wraz z poleceniem do ponownego uruchomienia, zanim zdecydujesz się na którąś. LightRAG i microsoft/graphrag to te aktywne; nano-graphrag i fast-graphrag dryfują w stronę porzucenia.

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

Nasza interpretacja: gwiazdki to metryka próżności; data pusha jest liczbą, która się liczy. LightRAG i microsoft/graphrag są obie aktywnie rozwijane, a Graphiti depcze im po piętach z podejściem grafu temporalnego. nano-graphrag i fast-graphrag to te dwie, które starsze wpisy wciąż polecają na podstawie samej reputacji, a żadna nie wydała nic od pół roku.

Jak wybrać: wybierz microsoft/graphrag, jeśli chcesz implementacji referencyjnej z czterema oficjalnymi metodami zapytań, LightRAG, jeśli chcesz najaktywniejszego projektu i lżejszego śladu, a bibliotekę utrzymywaną przez dostawcę, taką jak neo4j-graphrag-python, jeśli już korzystasz z bazy tego dostawcy. Unikaj wszystkiego, czego ostatni push jest o pół roku starszy niż Twój projekt.

Graphiti zasługuje na jedną precyzyjną uwagę: jego projekt grafu temporalnego jest zbudowany pod wyszukiwanie po danych świadomych czasu i nakłada się z pamięcią agentów, którą omawiamy osobno w naszym przewodniku po Graphiti i temporalnej pamięci grafowej. Dla szerszego pola zobacz szerszy krajobraz narzędzi RAG.

Co psuje się po 200 dniach: dryf grafu i ponowna ekstrakcja

Dryf grafu to podatek, który płacisz po wdrożeniu, i nie bez powodu jest zastrzeżeniem numer jeden praktyków. Każdy tutorial traktuje graf jak coś, co buduje się raz. Prawdziwe zespoły utykają w dniu 200.

Rozkładają się trzy rzeczy. Po pierwsze, ponowne indeksowanie przy aktualizacjach dokumentów. Gdy zmienia się 40 dokumentów, nie wystarczy przeliczyć dla nich embeddingów; trzeba ponownie uruchomić ekstrakcję LLM na zmienionych fragmentach, uzgodnić nowe encje ze starym grafem i przeliczyć dotknięte społeczności wraz z ich podsumowaniami. Jeden poradnik na Medium nazywa aktualizację inkrementalną łatwą. Praktycy na r/Rag się nie zgadzają. Autor wątku z 2026-04-25, uruchamiający BM25 plus BGE-M3 na około 600 dokumentach, ujął to wprost: „Ekstrakcja encji/relacji przez LLM jest zaszumiona, a reindeksowanie przy aktualizacjach dokumentów wygląda boleśnie."

Po drugie, rozkład uzgadniania encji. „Acme Corp", „Acme" i „ACME Corporation" przychodzą w różnych dokumentach w odstępie miesięcy i rozszczepiają się na trzy węzły, które powinny być jednym. Nic nie scala ich automatycznie.

Po trzecie, relacje, które były prawdziwe w momencie ekstrakcji i po cichu przestały być prawdziwe. Nikt nie dostaje alertu, gdy krawędź reports_to się dezaktualizuje.

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)

Baza kodu jest przypadkiem najgorszym i najciekawszym zarazem. Autouzupełnianie podpowiada teraz „graphrag for codebase", „graphrag claude code" i „graphrag mcp server", a baza kodu to graf, który zmienia się co godzinę: każdy commit przepisuje krawędzie wywołań, przenosi symbole i usuwa funkcje. To jest dryf grafu w harmonogramie, którego żaden nocny reindeks nie jest w stanie w pełni nadążyć. To także powód, dla którego poważne narzędzia grafów kodu opierają się na deterministycznych parserach takich jak tree-sitter i LSP dla krawędzi, a LLM zostawiają dla prozy wokół nich: docstringów, komunikatów commitów, wątków z code review. Jeśli grafujesz repozytorium, grafuj wolno zmieniającą się warstwę przez LLM, a szybko zmieniającą się przez parser.

Co deweloperzy naprawdę mówią o GraphRAG?

Pracujący deweloperzy są podzieleni, a Google zdaje się o tym wiedzieć: wątek na Reddicie zajmuje drugą pozycję na „graphrag vs rag", co jest sygnałem od wyszukiwarki, że ten temat chce opinii rówieśników, a nie copy od dostawcy.

Sceptycyzm jest realny. Na wątku r/Rag z 2024 roku „Would you always recommend (knowledge) graph RAG over normal RAG?" (10 punktów, 86% głosów za), u/EncartaIt napisał: „Wszystkie tutoriale, które znalazłem, są nadmiernie uproszczone i nie budują mocnego uzasadnienia dla wzorca z grafem wiedzy." u/Prestigious_Run_4049 był bardziej dosadny: „Myślę, że graph rag to sam hype. Ludzie uwielbiają o tym mówić i brzmi to fajnie, ale nikt faktycznie nie używa tego w prawdziwych przypadkach użycia." Nie wszyscy się zgadzają. u/pytheryx, argumentując z produkcji, zauważył, że wyszukiwanie grafowe wygrywa przy pytaniach listowych wymagających kontekstu z większej liczby fragmentów, niż zwraca top_k; jego korpus whitepaperów potrzebuje około 50 fragmentów dla pełnej odpowiedzi.

Wątek z 2026 roku jest bardziej wyważony. u/Popular_Sand2773: „Większość instalacji graph rag po prostu oszukuje przy skali. Uruchamiasz standardowe wyszukiwanie wektorowe lub po metadanych, żeby znaleźć węzły startowe, a potem spacerujesz." u/ggone20, prowadzący system na około 300 milionów artefaktów: „Przy skali dosłownie nie da się bez nich odpowiedzieć na prawdziwe pytania."

Nasza interpretacja zgadza się z najostrzejszym argumentem z obu wątków: punktem przegięcia jest złożoność Twoich pytań, a nie rozmiar korpusu. To samo wykazały benchmarki powyżej, dlatego stajemy po stronie praktyków, którzy zawężają narzędzie do pracy wieloskokowej, a nie tych, którzy ogłaszają jego śmierć.

Jak podchodzi do tego Techsy

Oto sekwencja, której używamy przy projektach klienckich, i jest celowo nudna.

Po pierwsze, udowodnij sufit wyszukiwania hybrydowego. Większość próśb „potrzebujemy grafu", które słyszymy, to w rzeczywistości problem fragmentacji lub rerankingu w przebraniu. Pipeline BM25 plus wektory z przyzwoitym rerankerem odpowiada na więcej, niż zespoły oczekują.

Po drugie, uruchom Basic Search jako grupę kontrolną na własnym korpusie, zanim cokolwiek zbudujesz. Dokładnie do tego służy czwarta metoda zapytań: baza w postaci zwykłego wyszukiwania wektorowego, z którą możesz porównać graf, na swoich danych i swoich pytaniach.

Po trzecie, buduj graf dopiero, gdy zmierzona klasa pytań oblewa tę kontrolę. Jeśli zapytania wieloskokowe lub obejmujące cały korpus chybiają, masz prawdziwy przypadek. Jeśli nie, właśnie oszczędziłeś sobie rachunku za indeksowanie i problemu z dryfem.

Chcesz, żeby ktoś drugi spojrzał na Twój stack wyszukiwania? Umów się na bezpłatną konsultację.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y głosowe/SDR dla klientów B2B. Pisze o stacku narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji. W projektach klienckich podejmuje decyzje o architekturze wyszukiwania: kiedy wyszukiwanie hybrydowe wystarcza, a kiedy korpus naprawdę potrzebuje grafu. Skontaktuj się z nim na LinkedIn.

Często zadawane pytania

Jak działa GraphRAG?

GraphRAG indeksuje Twoje dokumenty w grafie wiedzy. LLM wyodrębnia encje i relacje z każdego fragmentu, algorytm Leiden klastruje te encje w społeczności, a każda społeczność dostaje podsumowanie. W czasie zapytania silnik przeszukuje graf i te podsumowania, dzięki czemu może łączyć fakty leżące w różnych fragmentach.

Czym GraphRAG różni się od RAG?

Standardowy RAG pobiera top-k najbardziej podobnych fragmentów i podaje je modelowi. GraphRAG pobiera strukturę: encje, relacje między nimi i napisane wcześniej podsumowania społeczności. Ta dodatkowa struktura pozwala odpowiadać na pytania wieloskokowe i obejmujące cały korpus, i to ona sprawia, że indeksowanie jest wolniejsze i droższe.

Kiedy warto użyć GraphRAG?

Użyj go, gdy Twoje pytania łączą encje lub obejmują cały korpus, na przykład pytania o nakładających się dostawców albo analizę powtarzających się motywów w tysiącach dokumentów. Pomiń go przy jednoskokowych wyszukiwaniach faktów, szybko zmieniających się korpusach i ciasnych budżetach latencji lub kosztów. Jeśli klasyczny pipeline hybrydowy już odpowiada na daną klasę pytań, graf dokłada koszt bez dokładania wartości.

Czy GraphRAG jest martwy?

Nie, ale nie jest też domyślny. Benchmarki z 2026 roku pokazują, że często ustępuje klasycznemu RAG w codziennych zadaniach, co zabiło hype, jednocześnie wciąż wygrywając przy pytaniach wieloskokowych i agregacyjnych. Szczere ujęcie jest sytuacyjne: GraphRAG zwraca swój koszt przy właściwych typach pytań i traci pieniądze przy reszcie.

Jakie są metody zapytań GraphRAG?

Oficjalny silnik zapytań dostarcza cztery: Local Search do pytań skupionych na encjach, Global Search do agregacji w całym korpusie, DRIFT Search do rekurencyjnego połączenia obu i Basic Search do zwykłego wyszukiwania wektorowego. Piąta funkcja, Question Generation, leży na warstwie powyżej. Basic Search liczy się najbardziej: to grupa kontrolna, z którą porównujesz graf.

Ile kosztuje indeksowanie GraphRAG?

Koszt pojawia się w momencie indeksowania, w wywołaniach LLM, które wyciągają encje i relacje z każdego fragmentu, plus podsumowania społeczności. Microsoft Research zaraportował indeksowanie LazyGraphRAG na 0,1% kosztu pełnego GraphRAG i identyczne z vector RAG, ale ten wariant trafił do produktów Microsoftu, a nie do biblioteki open source. Sami nie uruchomiliśmy wycenionego indeksu.

Czy można uruchomić GraphRAG lokalnie z Ollamą?

Tak. Biblioteka microsoft/graphrag pozwala skierować indeksowanie i zapytania na lokalny model serwowany przez Ollamę, co usuwa opłaty API za token z kroku ekstrakcji. Zamieniasz szybkość i jakość na koszt: lokalne modele są słabsze w ekstrakcji encji, więc spodziewaj się bardziej zaszumionych grafów i dłuższych przebiegów indeksowania na skromnym sprzęcie.

Co jest lepsze: LightRAG czy Microsoft GraphRAG?

Optymalizują się pod różne rzeczy. LightRAG (38 353 gwiazdek, push 2026-07-30) jest najaktywniejszy i lżejszy w uruchomieniu; microsoft/graphrag (35 088 gwiazdek, v3.1.1) to implementacja referencyjna z czterema oficjalnymi metodami zapytań. Wybierz LightRAG dla wydajnego grafu produkcyjnego, a rozwiązanie Microsoftu dla zachowania zgodnego ze specyfikacją i kontroli przez Basic Search.

Kto i kiedy stworzył GraphRAG?

GraphRAG stworzył Microsoft Research. Zespół opublikował artykuł w 2024 roku i utrzymuje open source'owe repozytorium microsoft/graphrag na licencji MIT, z dokumentacją na microsoft.github.io/graphrag. Biblioteka referencyjna osiągnęła v3.1.1 2026-07-18, a wokół niej wyrosła aktywna ekosystemowa warstwa implementacji trzecich, w tym LightRAG i Graphiti.

Werdykt: kiedy graf zwraca swój koszt

Dowody wskazują jeden kierunek, więc oto stanowisko.

• GraphRAG nie jest martwy. Jest sytuacyjny, a benchmarki z 2026 roku mówią to wprost.
• Zwraca rachunek za indeksowanie przy wieloskokowych pytaniach o encje i agregacji w całym korpusie. Traci pieniądze przy wyszukiwaniach jednoskokowych.
• Koszt to rachunek z fazy indeksowania, a tani wariant, który wszyscy cytują, LazyGraphRAG, nigdy nie trafił do biblioteki open source.
• Graf rozkłada się po wdrożeniu: uzgadnianie encji dryfuje, a relacje się dezaktualizują, więc zaplanuj budżet na reindeksowanie.
• Zanim cokolwiek zbudujesz, uruchom Basic Search jako grupę kontrolną na własnym korpusie.

Jednym zdaniem: graf wiedzy zwraca swój koszt, gdy Twoje pytania są wieloskokowe lub obejmują cały korpus, i nie wcześniej. Jeśli chcesz drugą opinię o swoim stacku wyszukiwania, umów się na bezpłatną konsultację.