Czy zdarzyło Ci się, że Twój system RAG zwraca trafne fragmenty, a odpowiedź nadal jest nieprawidłowa? Pytasz, kto zatwierdził umowę nr 2024-0034, a system odnajduje dokument o procesach zatwierdzania i dokument zawierający numer umowy — ale nie łączy faktu, że zatwierdzającym była konkretna osoba wymieniona w trzecim dokumencie. Każdy krok ma odpowiedź gdzieś indziej. Problem nie tkwi w wyszukiwaniu — problem tkwi w brakujących relacjach.
Właśnie do tego rodzaju pytań powstał GraphRAG — rozszerzenie klasycznego retrieval-augmented generation o graf wiedzy (knowledge graph). To nie jest drop-in upgrade, który wystarczy włączyć. To wybór architektoniczny z realnymi kosztami i realną wartością — ale tylko dla określonej klasy problemów. W tym artykule przyjrzymy się, co GraphRAG rozwiązuje, jak działa technicznie, jaki jest rzeczywisty koszt i dla jakich przypadków naprawdę się opłaca.
Czego klasyczny RAG nie potrafi
Standardowy pipeline RAG działa dobrze, gdy odpowiedź na pytanie leży w jednym lub dwóch bliskich fragmentach tekstu. Bierzesz pytanie, konwertujesz je na embedding, znajdujesz k-najbliższych chunków w bazie wektorowej, podajesz je modelowi i otrzymujesz odpowiedź.
To podejście ma martwą strefę: relacje między encjami w różnych dokumentach. Klasyczny RAG nie wie, że osoba wymieniona w dokumencie A jest tą samą co w dokumencie C, że zdarzenie opisane w raporcie jest przyczyną problemu analizowanego w innym raporcie, ani że dostawca z faktury jest powiązany własnościowo z firmą z reklamacji. Podobieństwo wektorowe dopasowuje tekst, nie powiązania semantyczne.
Właśnie tu wchodzi GraphRAG. Zamiast izolowanych fragmentów pracuje z grafem — węzłami (encje: osoby, firmy, produkty, procesy, lokalizacje) i krawędziami (relacje: zatwierdził, dostarcza, odpowiada za, spowodował, należy do). Retrieval to już nie tylko „znajdź podobny tekst", lecz „znajdź ścieżkę lub podgraf istotny dla tego pytania".
Jak GraphRAG działa technicznie
Oryginalna implementacja Microsoftu, która spopularyzowała ten termin, składa się z dwóch faz: indeksowania i odpytywania.
Faza indeksowania
To najdroższy krok. Dla każdego dokumentu w korpusie wywoływany jest LLM (lub seria wywołań LLM), który ekstrahuje encje i relacje. Ze zdania *„Inżynier Nowak zatwierdził wymianę pompy P-12 na linii 3 w dniu 14 stycznia"* ekstrahuje węzły Nowak (osoba), P-12 (urządzenie), Linia 3 (lokalizacja) oraz krawędzie zatwierdził → wymiana, znajduje się na → Linia 3.
Na tak zbudowanym grafie stosowana jest następnie detekcja społeczności (algorytmy takie jak Leiden lub Louvain), która grupuje powiązane encje w klastry — na przykład wszystkie encje dotyczące linii 3 albo wszystkie transakcje z konkretnym dostawcą. Dla każdej społeczności generowany jest zbiorczy opis (tzw. community report), który służy jako high-level kontekst przy odpowiadaniu na pytania globalne.
Faza odpytywania
Gdy nadchodzi pytanie, system decyduje między dwiema strategiami:
Local search — pytanie dotyczy konkretnych encji lub lokalnych relacji. System odnajduje trafne węzły i przechodzi podgraf w ich otoczeniu. Odpowiednie dla pytań typu „kto zatwierdził to zamówienie" lub „jakie urządzenia są powiązane z tą awarią".
Global search — pytanie wymaga syntezy informacji z całego korpusu. System pracuje z community reports zamiast surowych dokumentów. Odpowiednie dla pytań takich jak „jakie są główne wzorce awarii na liniach w ostatnim roku" lub „zidentyfikuj dostawców z powtarzającymi się opóźnieniami dostaw".
W porównaniu z klasycznym RAG GraphRAG dodaje zatem całą warstwę struktury semantycznej — ale ta warstwa nie jest darmowa.
Realne koszty indeksowania
Tu wielu zainteresowanych GraphRAG zaskakuje rzeczywistość. Microsoft w swoich badaniach raportował, że indeksowanie dużych zbiorów danych przy użyciu oryginalnej implementacji kosztowało rzędu dziesiątek tysięcy USD — zależnie od rozmiaru korpusu i wybranego modelu. Powód: każdy dokument (lub każdy chunk) wymaga wywołania LLM w celu ekstrakcji encji. Przy setkach tysięcy dokumentów liczba tokenów szybko rośnie do astronomicznych wartości.
Ma to konkretny skutek: indeksowanie nie jest jednorazowe. Gdy dokument się zmienia lub pojawia się nowy, trzeba zaktualizować graf. W odróżnieniu od bazy wektorowej, gdzie wystarczy ponownie zembeddować nowe chunki, aktualizacja grafu może wymagać ponownego przejścia otoczenia zmienionego węzła.
To fundamentalny powód, dla którego GraphRAG nie nadaje się do dynamicznych korpusów z wysoką częstotliwością aktualizacji.
LazyGraphRAG i alternatywy open-source
Microsoft był świadomy problemu kosztowego i wydał LazyGraphRAG — wariant, który odkłada ekstrakcję encji i relacji przez LLM. Zamiast ekstrahować encje dla każdego dokumentu podczas indeksowania, buduje podstawowy graf tańszymi metodami (ekstrakcja NLP, keyword extraction) i wywołania LLM wykonuje dopiero w czasie odpytywania, tylko dla odpowiedniej podgrupy. Wynik: znacznie niższe koszty indeksowania przy porównywalnej jakości odpowiedzi dla wielu typów pytań.
Społeczność stworzyła tymczasem kilka alternatywnych implementacji z różnymi kompromisami:
- LightRAG — kładzie nacisk na efektywność, mniej wywołań LLM podczas indeksowania, dobre wyniki na dokumentach technicznych
- HippoRAG — inspirowany pamięcią hipokampalną, interesujący dla long-term knowledge retention
- Fast-GraphRAG — skoncentrowany na szybkości przy zachowaniu struktury grafowej
Żadna z tych alternatyw nie jest „zwycięzcą w każdym wymiarze" — każda przyjmuje inne kompromisy między kosztami indeksowania, jakością grafu a szybkością odpytywania. Do wdrożeń produkcyjnych zalecamy przetestowanie konkretnej alternatywy na własnym realnym korpusie, a nie na benchmarkowych zbiorach danych.
Kiedy GraphRAG się opłaca
To kluczowe pytanie, które należy zadać przed jakąkolwiek decyzją o adopcji.
GraphRAG ma realną wartość przy:
- Pytaniach multi-hop — odpowiedź wymaga połączenia informacji z trzech lub więcej dokumentów wzdłuż łańcucha relacji. „Który technolog odpowiada za urządzenie, które spowodowało awarię na linii z najwyższym OEE?" — trzy encje, dwie krawędzie, trzy dokumenty.
- Analizie wpływu — „jakie procesy zostaną dotknięte, jeśli wymienimy dostawcę X?" — wymaga przejścia grafu zależności.
- Podsumowaniach po encjach — „podsumuj wszystkie incydenty dotyczące produktu Y za ostatnie dwa lata" — klastry w grafie poradzą sobie z tym lepiej niż chunki z bazy wektorowej.
- Wykrywaniu wzorców — „zidentyfikuj powtarzające się wzorce w reklamacjach według dostawcy i kategorii urządzenia" — global search przez community reports.
- Compliance i audit trails — „wykaż łańcuch zatwierdzeń dla umowy Z" — bezpośrednie zadanie dla grafowego przechodzenia.
GraphRAG prawdopodobnie nie jest Ci potrzebny, jeśli:
- Twoje pytania są w większości faktyczne, a odpowiedź leży w jednym fragmencie („jaka jest maksymalna temperatura dla pompy P-12?").
- Twój korpus zmienia się codziennie lub wielokrotnie dziennie — koszty re-indeksowania będą prohibicyjne.
- Masz mniej niż kilka tysięcy dokumentów — klasyczny hybrid search z rerankiem poradzi sobie z większością przypadków za ułamek ceny i złożoności.
- Nie masz jasno zdefiniowanej ontologii encji i relacji — graf wyekstrahowany z nieustrukturyzowanego tekstu bez kontekstu domenowego będzie zawierał dużo szumu.
Liczba raportowana przez Microsoft — GraphRAG osiąga około 80% poprawnych odpowiedzi na pytaniach multi-hop w porównaniu z około 50% dla naiwnego RAG — jest orientacyjna i dotyczy konkretnego typu syntetycznych pytań benchmarkowych. Realna poprawa na Twoim korpusie może być inna. Zawsze mierz na własnych danych.
Integracja z istniejącym stosem RAG
GraphRAG nie jest zamiennikiem dla bazy wektorowej — jest jej uzupełnieniem. Nowoczesne systemy produkcyjne, które go adoptują, zazwyczaj prowadzą architekturę hybrydową:
- 1.Baza wektorowa (np.
Qdrant) dla dense retrieval — szybkie, tanie, odpowiednie dla pytań faktycznych. - 2.Warstwa grafowa (neo4j, Amazon Neptune lub in-memory graf dla mniejszych korpusów) dla zapytań relacyjnych.
- 3.Router/orkiestrator — klasyfikuje nadchodzące pytanie i decyduje, której warstwy użyć (lub połączyć obie).
Orkiestracja takiego systemu jest bardziej złożona. LangGraph (framework dla stanowych grafów agentów) jest naturalnym wyborem dla tego wzorca — pozwala definiować węzły decyzyjne, które dynamicznie decydują, czy zapytanie trafi do bazy wektorowej, do warstwy grafowej, czy potrzebuje obu. Do ewaluacji wyników warto przyjrzeć się metrykom RAGAS — zob. jak ewaluować RAG.
Ważna uwaga dotycząca narzędzi: LlamaIndex w aktualnych wersjach ma natywne wsparcie dla indeksowania GraphRAG, co znacznie obniża barierę implementacji w porównaniu z ręcznym budowaniem pipeline.
Gdzie widzimy GraphRAG w praktyce przemysłowej
Z wdrożeń realizowanych u klientów z sektora produkcyjnego i inżynieryjnego, GraphRAG lub hybrydowe podejścia grafowe okazują się uzasadnione w następujących scenariuszach:
Zarządzanie dokumentacją techniczną — duże przedsiębiorstwa z tysiącami instrukcji technicznych, SOP-ów, raportów serwisowych i protokołów rewizyjnych. Pytanie „jaka jest procedura przy awarii pompy typu X w strefie ATEX II?" wymaga połączenia instrukcji urządzenia, protokołu ATEX strefy, BHP SOP i historii interwencji serwisowych. Klasyczny RAG nie poda tego niezawodnie.
Compliance i regulacyjne audit trails — w branżach regulowanych (farmacja, energetyka, przemysł spożywczy) trzeba wykazać łańcuch odpowiedzialności i zatwierdzeń. Graf jest naturalną strukturą danych dla „kto zatwierdził, kiedy, na jakiej podstawie, z odwołaniem do jakiego przepisu".
Analiza łańcucha dostaw — powiązania między dostawcami, komponentami, reklamacjami i awariami. „Ile krytycznych komponentów pochodzi od dostawców, którzy w ostatnim roku mieli opóźnienia powyżej 10 dni?" — multi-hop przez cztery typy encji.
Z kolei dla wewnętrznych chatbotów nad dokumentacją FAQ lub wyszukiwania w katalogu produktów GraphRAG to zbędna złożoność. Zob. również architektury agentic RAG, gdzie warstwa grafowa naturalnie łączy się z retrieval kontrolowanym przez agenta.
Praktyczny przewodnik: jak zacząć
Jeśli zdecydowałeś się wypróbować GraphRAG, zalecamy podejście przyrostowe:
- 1.Zdefiniuj ontologię — przed jakąkolwiek implementacją jawnie określ, jakie typy encji i relacji chcesz mieć w grafie. Bez tego kroku otrzymasz głośny graf pełen nieistotnych węzłów.
- 2.Zacznij od małego korpusu — 1 000–5 000 dokumentów wystarczy do weryfikacji, czy struktura grafowa odpowiada Twoim pytaniom. Indeksowanie będzie wykonalne nawet z LazyGraphRAG.
- 3.Porównaj z punktem odniesienia — dla każdego typu pytania (faktyczne, multi-hop, podsumowanie) mierz precyzję GraphRAG vs hybrid search. Jeśli GraphRAG nie dodaje >15% na Twoich realnych pytaniach, rozważ, czy złożoność jest uzasadniona.
- 4.Zaplanuj cykl aktualizacji — zdecyduj, jak będziesz utrzymywać graf aktualny. Batch re-indeksowanie raz w tygodniu? Aktualizacja przyrostowa przy dodawaniu dokumentów? Ta decyzja wpłynie na całą architekturę.
- 5.Nie zapomnij o fallbacku — w systemie produkcyjnym zawsze miej klasyczny vector retrieval jako zabezpieczenie na przypadki, gdy zapytanie grafowe nie zwróci wystarczająco wiarygodnych wyników.
Najczęstsze pytania
Czy GraphRAG jest lepszy od klasycznego RAG?
Zależy od rodzaju pytań. Dla pytań multi-hop wymagających łączenia encji w różnych dokumentach — tak, zdecydowanie. Dla prostych pytań faktycznych z odpowiedzią w jednym fragmencie GraphRAG jest niepotrzebnie drogi i wolniejszy. Zawsze mierz na swoim konkretnym przypadku użycia.
Ile kosztuje indeksowanie GraphRAG w praktyce?
Oryginalna implementacja Microsoftu raportuje koszty rzędu dziesiątek tysięcy USD dla dużych korpusów. LazyGraphRAG i alternatywy open-source (LightRAG, Fast-GraphRAG) znacznie obniżają te koszty. Dokładna cena zależy od rozmiaru korpusu, wybranego LLM i granularności ekstrakcji encji.
Czy muszę mieć specjalną bazę grafową?
Niekoniecznie. Dla mniejszych grafów (do rzędu milionów węzłów) sprawdza się reprezentacja in-memory lub biblioteki takie jak networkx. Dla większych wdrożeń produkcyjnych Neo4j, Amazon Neptune lub TigerGraph to standardowe wybory. Niektóre implementacje (np. LlamaIndex GraphRAG) abstrahują warstwę storage i umożliwiają wybór backendu.
Czy GraphRAG działa dla polskich dokumentów?
Ekstrakcja encji zależy od jakości LLM, który ją wykonuje. Modele frontier (Claude, GPT, Gemini) dobrze radzą sobie z językiem polskim. Przy użyciu mniejszych modeli lokalnych należy zweryfikować jakość ekstrakcji na próbce polskiego tekstu przed wdrożeniem. Sama struktura grafowa jest language-agnostic.
Kiedy zdecydować się na nieużywanie GraphRAG?
Jeśli Twój korpus zmienia się codziennie, masz mniej niż kilka tysięcy dokumentów, Twoje pytania są w większości jednoetapowe lub nie masz zasobów do zdefiniowania i utrzymania ontologii encji. W tych przypadkach klasyczny hybrid search z rerankiem da Ci 90% rezultatu za 10% kosztów i złożoności.
*GraphRAG nie jest dla każdego projektu — ale dla projektów, w których relacje między encjami decydują o poprawności odpowiedzi, jest to narzędzie bez alternatywy. W MP Industrial Solutions pomagamy firmom ocenić, czy ich konkretny przypadek użycia jest kandydatem do GraphRAG, zaprojektować ontologię i oszacować realne koszty indeksowania jeszcze przed jakimkolwiek zobowiązaniem. Jeśli mierzysz się ze złożonymi pytaniami dotyczącymi dokumentacji lub compliance, zacznij od oceny.*