GraphRAG: gdy wiedza jako graf pobija same wektory

Firma produkująca dokumentację techniczną dla kilkunastu linii produktowych zauważa problem: asystent RAG świetnie cytuje fragmenty, ale nie potrafi odpowiedzieć na pytanie „które komponenty ze starszej linii X są kompatybilne z nową linią Y i jakie certyfikaty obejmuje ta kombinacja?”. To pytanie wieloetapowe, które wymaga połączenia informacji z trzech różnych dokumentów. Wyszukiwanie semantyczne zwraca najlepiej dopasowane fragmenty osobno, ale nie buduje między nimi mostu.

To jest właśnie nisza GraphRAG.

Graf wiedzy to struktura danych złożona z węzłów (encji) i krawędzi (relacji). W kontekście firmowym: węzły to produkty, procesy, działy, regulacje, klienci; krawędzie to relacje w rodzaju „wymaga”, „zastępuje”, „podlega”, „produkowany przez”.

Budowanie grafu z dokumentów przebiega w trzech krokach.

Ekstrakcja encji i relacji. Model językowy czyta każdy fragment dokumentu i wyciąga pary (encja, relacja, encja). Na przykład ze zdania „Komponent A-7 wymaga certyfikatu CE przed wdrożeniem w UE” model wyciąga węzły A-7 i CE oraz krawędź „wymaga”. To najbardziej kosztowna część: przy 10 000 fragmentów i modelu lokalnym liczysz od kilkudziesięciu do kilkuset minut przetwarzania.

Deduplikacja i normalizacja. Ten sam produkt może pojawić się jako „A-7”, „komponent A7”, „moduł A-7 rev.2”. Bez normalizacji graf fragmentuje się zamiast łączyć wiedzę. Tu potrzebna jest decyzja: słownik synonimów pisany ręcznie przez domenowych ekspertów albo dodatkowy krok LLM rozpoznający aliasy. Obydwa mają koszty.

Indeks + baza wektorowa. W pełnym GraphRAG nie pozbywasz się embeddingów: przechowujesz równolegle graf relacyjny (np. Neo4j, Memgraph, lub lżejszy NetworkX dla mniejszych korpusów) i indeks wektorowy do wyszukiwania punktu wejścia. Zapytanie trafia najpierw do wektora, żeby znaleźć bliskie encje, a potem do grafu, żeby prześledzić relacje.

Wyszukiwanie wektorowe mierzy podobieństwo semantyczne. Graf mierzy połączenia. To różne pytania.

Pytania wieloetapowe (multi-hop). „Jakie regulacje dotyczą produktu X, który sprzedajemy do sektora Y?” Wektor zwraca dokumenty tematycznie bliskie zapytaniu. Graf potrafi przejść ścieżkę: produkt X → certyfikat CE → dyrektywa maszynowa → artykuł 12 → obowiązek audytu. Każdy krok to krawędź w grafie, niekoniecznie wyraźnie obecna w jednym fragmencie dokumentu.

Zapytania zorientowane na encje. „Wymień wszystkich dostawców komponentów używanych w linii produktowej Z.” Wektor przeszuka fragmenty i może pominąć dostawców wzmiankowanych marginalnie. Graf z krawędziami „dostawca-komponent-linia” odpowie kompletnie, pod warunkiem że graf jest kompletny.

Spójność wiedzy między dokumentami. Gdy ta sama encja pojawia się w dokumentach z różnych lat i jej atrybuty się zmieniły, graf pomaga śledzić historię i wersje. Klasyczny RAG może zwrócić sprzeczne fragmenty bez żadnego sygnału o sprzeczności.

Eksplanacja i ślad decyzyjny. Odpowiedź wygenerowana z grafu może pokazać dosłowną ścieżkę węzłów: „Ta odpowiedź wynika z relacji A→B→C”. To istotne dla systemów, które AI Act klasyfikuje jako wysokie ryzyko i które muszą spełniać wymóg wyjaśnialności.

Dla większości firmowych wdrożeń RAG sam indeks wektorowy z wyszukiwaniem hybrydowym wystarczy. Graf ma sens, gdy:

• korpus ma wyraźną strukturę encja-relacja-encja, którą da się sensownie wyekstrahować (dokumentacja produktowa, rejestry prawne, bazy wiedzy domenowej);
• pytania użytkowników rzeczywiście wymagają łączenia informacji z wielu źródeł przez wspólne węzły;
• masz zasoby na utrzymanie grafu, bo każda aktualizacja dokumentu wymaga reekstrakcji lub łatania krawędzi.

Nie wdrażaj GraphRAG, gdy:

• korpus to luźne dokumenty opisowe bez jasnych encji (raporty strategiczne, notatki ze spotkań, korespondencja);
• pytania są głównie opisowe i koncepcyjne (tu wyszukiwanie semantyczne radzi sobie dobrze);
• masz mniej niż kilka tysięcy dokumentów i klasyczny RAG daje recall powyżej 0,85 na golden secie;
• budżet tokenów i czas ekstrakcji są ograniczone, a timeline wdrożenia krótki.

My w Cashcrown domyślnie rekomendujemy zacząć od klasycznego RAG z wyszukiwaniem hybrydowym i mierzyć recall. GraphRAG wchodzi w grę wtedy, gdy dane pomiarowe wskazują konkretną klasę zapytań, których wektor nie obsługuje.

Ekstrakcja grafu z 50 000 fragmentów przy modelu lokalnym (np. llama3.1:70b na Ollama) to realnie 8-24 godziny i koszt utrzymania pamięci GPU. Przy API komercyjnym to kilkadziesiąt do kilkuset dolarów za jednorazową ekstrakcję, plus podobny koszt przy każdej większej aktualizacji korpusu. Liczby zależą silnie od długości fragmentów i złożoności promptu ekstrakcyjnego: podajemy widełki, nie gwarancję.

Typowy stos GraphRAG w 2026 wygląda tak:

Krok 1: chunking i ekstrakcja. Dokumenty trafiają przez chunking do modelu ekstrakcyjnego. Prompt każe modelowi zwrócić ustrukturyzowany JSON z parami (podmiot, predykat, obiekt). Warto użyć structured output z walidacją JSON Schema, bo surowy tekst modelu przy ekstrakcji relacji bywa niespójny.

Krok 2: budowa grafu. Ekstrahy trafiają do bazy grafowej lub prostej struktury in-memory. Przy mniejszych korpusach (do kilku tysięcy węzłów) NetworkX w Pythonie wystarcza. Przy większych i przy potrzebie zapytań Cypher warto rozważyć Neo4j lub Memgraph z self-hostingiem.

Krok 3: retrieval. Zapytanie użytkownika trafia do indeksu wektorowego (punkt wejścia w grafie). Z top-k węzłów wektorowych system ekspanduje sąsiedztwo w grafie: pobiera węzły odległe o 1-2 krawędzie. Ten zestaw trafia do kontekstu LLM.

Krok 4: generacja z cytatem ścieżki. Model generuje odpowiedź, podając ścieżkę węzłów jako źródło. To nie jest wymóg techniczny, ale mocno podnosi zaufanie użytkowników i spełnia wymogi wyjaśnialności przy systemach podlegających AI Act.

Krok 5: observability. Mierz osobno recall zapytań wektorowych (ile trafień w top-5) i recall ścieżek grafowych (czy multi-hop pytania dają kompletne odpowiedzi). Bez rozdzielenia tych metryk nie wiesz, który komponent wymaga optymalizacji.

Podobny wzorzec opisujemy w kontekście doboru bazy wektorowej w artykule jak wybrać bazę wektorową oraz przy omawianiu rerankownia fragmentów w rerankingu jako warstwie jakości RAG.

Ekstrakcja grafu ma trzy kosztowe pułapki, o których rzadko mówią artykuły techniczne.

Pułapka 1: jakość ekstrakcji spada przy dokumentach niskiej jakości. Skany OCR, dokumenty z tabelami, listy punktowane bez kontekstu zdaniowego dają chaotyczne relacje. Przed ekstrakcją grafu warto zadbać o jakość chunkingu, co opisujemy w artykule o przygotowaniu danych pod RAG.

Pułapka 2: graf jest nieaktualny po każdej aktualizacji dokumentów. Przy klasycznym RAG aktualizujesz embedding fragmentu, co zajmuje sekundy. Przy GraphRAG musisz re-ekstrahy ować relacje z tego fragmentu i zaktualizować krawędzie w grafie. Jeśli dokumenty zmieniają się często, koszty utrzymania szybko rosną. Wzorzec inkrementalny (aktualizuj tylko zmienione dokumenty) działa, ale wymaga bookkeepingu wersji.

Pułapka 3: graf może utrwalać błędy. Jeśli model ekstrakcyjny źle zinterpretuje relację, ta relacja siedzi w grafie i wpływa na odpowiedzi do czasu ręcznej korekty. Klasyczny RAG źle wybiera fragment, ale błąd nie jest strukturalnie utrwalony. Przy GraphRAG warto co jakiś czas przeprowadzać audyt próbki krawędzi. To praca człowieka, nie automatyczna.

Nie. To uzupełnienie, nie zamiennik. W większości firmowych wdrożeń RAG wektorowy z wyszukiwaniem hybrydowym pokrywa 80-90 procent przypadków użycia. GraphRAG wchodzi jako dodatkowa warstwa dla konkretnej klasy zapytań wieloetapowych. Wdrożenia, które zastąpiły wektor samym grafem, zazwyczaj wracały do hybrydowego podejścia po kilku tygodniach.

Microsoft udostępnił open-source bibliotekę GraphRAG (Python), która automatyzuje ekstrakcję encji i budowę grafu z plików tekstowych. LangChain i LlamaIndex mają integracje z bazami grafowymi (Neo4j, Memgraph). Do samodzielnego wdrożenia bez zewnętrznych API wystarczy Ollama z modelem lokalnym do ekstrakcji i NetworkX do przechowywania grafu przy korpusach poniżej kilkudziesięciu tysięcy węzłów. Przy większych zbiorach dedykowana baza grafowa z interfejsem Cypher istotnie przyspiesza zapytania.

Widełki są szerokie i zależą od modelu oraz długości dokumentów. Przy modelu lokalnym (llama3.1:70b na Ollama): 8-24 godziny ekstrakcji, zero kosztu tokenów. Przy API komercyjnym (GPT-4o lub Claude Sonnet): 50-300 dolarów jednorazowo za ekstrakcję, plus podobny koszt przy aktualizacjach. Dodaj koszt normalizacji encji (zwykle 1-2 dni pracy domenowego eksperta przy pierwszej ekstrakcji) i zaplanuj czas na audyt próbki krawędzi. Podajemy widełki na podstawie typowych projektów, nie konkretną wycenę bez analizy danych.

Ścieżka węzłów jako ślad decyzyjny ułatwia spełnienie wymogu wyjaśnialności (art. 13 AI Act). To jednak nie wystarczy samo w sobie: wymagana jest również dokumentacja systemu, rejestr przypadków testowych i human-gate przy decyzjach nieodwracalnych. GraphRAG poprawia wyjaśnialność mechanizmu retrieval, ale nie zwalnia z obowiązków compliance po stronie wdrożeniowca.

Gdy corpus ma złożoną ontologię (wiele typów encji i relacji), dokumenty są niskiej jakości strukturalnej (skany, legacy PDF), albo timeline jest krótki. Ekstrakcja relacji wymaga kilku iteracji prompt-engineeringu dopasowanego do domeny, sprawdzenia próbki i korekty. My w Cashcrown oceniamy gotowość techniczną i dane przed rekomendacją architektury, bo firmowy RAG zbudowany na złej ekstrakcji grafu daje gorsze wyniki niż prosty wektor z wyszukiwaniem semantycznym.