Graph RAG: gdy relacje są ważniejsze niż podobieństwo

Graph RAG to podejście typu Retrieval-Augmented Generation, które przechowuje wiedzę nie (tylko) w postaci wektorów, lecz jako graf wiedzy złożony z encji i relacji między nimi. Klasyczny RAG odpowiada na pytanie na podstawie podobieństwa semantycznego, wyszukując fragmenty tekstu najbliższe zapytaniu, natomiast Graph RAG podąża za jawnymi powiązaniami między encjami. Dzięki temu sprawdza się tam, gdzie relacje i wnioskowanie wieloetapowe (multi-hop) są ważniejsze niż samo podobieństwo tekstu.

• Czym jest: wariant RAG, który wykorzystuje graf wiedzy (encje plus relacje) jako źródło wiedzy, samodzielnie lub obok indeksu wektorowego.
• Kiedy pomaga: przy pytaniach typu multi-hop, pytaniach o relacje i globalnych pytaniach przeglądowych dotyczących całego korpusu.
• Ile kosztuje: wyższe koszty indeksowania i utrzymania niż w wektorowym RAG, ponieważ ekstrakcja grafu odbywa się z użyciem LLM.

Dlaczego samo podobieństwo ma swoje granice

Klasyczny RAG działa dwuetapowo: na ścieżce indeksowania dokumenty są parsowane, dzielone na chunki, zamieniane na wektory przez model embeddingowy i zapisywane w wektorowej bazie danych. Na ścieżce zapytania pytanie również jest zamieniane na embedding, pobierane są najbardziej podobne chunki (top-k), opcjonalnie łączone z BM25 w ramach wyszukiwania hybrydowego i doprecyzowywane przez re-ranker, a na koniec wszystko trafia do promptu generatora. Ten wzorzec jest solidny i wystarcza przy większości pytań o wiedzę. Contextual Retrieval firmy Anthropic pokazuje na przykład, że błędy wyszukiwania można ograniczyć nawet o 67% dzięki nagłówkom kontekstowym dopasowanym do każdego chunka i re-rankingowi (Anthropic, stan na 09/2024).

Martwy punkt pojawia się przy dwóch typach pytań:

• Pytania typu multi-hop: pytanie „Którzy dostawcy naszego największego klienta sami są objęci sankcjami?” wymaga łańcucha wniosków (klient -> dostawcy -> status sankcyjny), którego nie ma w żadnym pojedynczym chunku. Podobieństwo top-k dostarcza tu często tylko fragmenty, nie tworząc powiązania.
• Globalne pytania przeglądowe: na pytanie „Które pięć tematów jest kluczowych w całym zbiorze 2000 zgłoszeń do supportu?” nie da się odpowiedzieć, pobierając od pięciu do dziesięciu podobnych chunków. Odpowiedź wymaga agregacji w obrębie całego korpusu.

Właśnie tu wkracza Graph RAG: zamiast wyszukiwać odizolowane fragmenty tekstu, porusza się po jawnej strukturze wiedzy.

Budowa grafu wiedzy zamiast indeksu wektorowego (lub obok niego)

Sercem Graph RAG jest indeksowanie. Z dokumentów źródłowych za pomocą LLM wyodrębniany jest graf:

1. Ekstrakcja encji: LLM identyfikuje encje (osoby, organizacje, produkty, miejsca, pojęcia) i je opisuje.
2. Ekstrakcja relacji: rozpoznaje relacje między tymi encjami („dostarcza do”, „jest spółką zależną”, „powoduje”) wraz z opisem i ewentualnie wagą.
3. Budowa grafu: encje stają się węzłami, relacje krawędziami. Encje wymienione wielokrotnie są scalane.

Podejście open source GraphRAG firmy Microsoft (Microsoft Research) rozszerza ten podstawowy schemat o dwa kluczowe kroki (stan na 2026 r.):

• Wykrywanie społeczności: za pomocą klasteryzacji grafu (np. algorytmem Leiden) silnie powiązane węzły są grupowane w hierarchiczne „społeczności”, czyli tematyczne podgrafy.
• Podsumowania społeczności: dla każdej społeczności LLM tworzy podsumowanie już na etapie indeksowania. Te podsumowania są kluczem do pytań globalnych: przy pytaniu przeglądowym elementami odpowiedzi typu map-reduce są nie pojedyncze chunki, lecz podsumowania społeczności.

Wynikają z tego dwa tryby zapytań: Local Search odpowiada na precyzyjne pytania o konkretną encję i jej sąsiedztwo w grafie; Global Search odpowiada na tematyczne pytania dotyczące całego korpusu na podstawie podsumowań społeczności.

Pseudokod: indeksowanie i zapytanie

```text

Indeksowanie (offline, z intensywnym użyciem LLM)

for dokument in korpus:
encje, relacje = LLM_wyodrębnij(dokument)
graf.merge(encje, relacje)

społeczności = cluster(graf) # np. Leiden
for c in społeczności:
c.summary = LLM_podsumuj(c) # podsumowanie społeczności

Zapytanie (online)

if pytanie_jest_globalne(pytanie):
odpowiedzi_częściowe = [LLM(pytanie, c.summary) for c in istotne_społeczności]
odpowiedź = LLM_reduce(pytanie, odpowiedzi_częściowe) # Global Search
else:
podgraf = graf.przejdź(start=encje_z(pytanie), hops=2)
odpowiedź = LLM(pytanie, podgraf + powiązane_chunki) # Local Search
```

Graph RAG a wektorowy RAG: bezpośrednie porównanie

Wybór nie polega na decyzji albo-albo, lecz zależy od typu pytań i budżetu. Poniższa macierz podsumowuje różnice.

Wartości latencji i wyszukiwania hybrydowego dla klasycznego RAG pochodzą z bazy badawczej Blck Alpaca (macierz porównawcza architektur RAG). Charakterystyka Graph RAG opiera się na sprawdzonej wiedzy ogólnej o projekcie GraphRAG i o indeksach grafu wiedzy we frameworkach takich jak LlamaIndex.

Koszty i złożoność w porównaniu

Największa różnica dotyczy indeksowania. W wektorowym RAG najdroższą jednorazową operacją jest embedding każdego chunka: jako rząd wielkości baza badawcza podaje koszty indeksowania od ok. 0,02 do 0,13 USD za milion tokenów, a przy użyciu prompt cachingu Anthropic dla Contextual Retrieval ok. 1,02 USD za milion tokenów dokumentów (stan na 09/2024). Graph RAG wymaga kilku przebiegów LLM na dokument: ekstrakcji encji, ekstrakcji relacji i podsumowań społeczności. To zwielokrotnia koszty i czas indeksowania.

Przykład: 50 000 dokumentów

Załóżmy, że agencja indeksuje dla klienta korpus wiedzy liczący 50 000 dokumentów:

• Wektorowy RAG: jednorazowy embedding plus indeks hybrydowy. Główne koszty to API do embeddingów i hosting wektorowej bazy danych. Aktualizacje odbywają się przyrostowo dzięki stabilnym identyfikatorom dokumentów.
• Graph RAG: dla każdego dokumentu potrzeba kilku wywołań LLM do ekstrakcji, a potem wywołań LLM dla każdej społeczności, aby utworzyć podsumowania. Już przy średniej wielkości korpusie koszty indeksowania są przez to wielokrotnie wyższe niż w wektorowym RAG, do czego dochodzi dodatkowy nakład operacyjny na schemat grafu, deduplikację encji i ponowne indeksowanie przy większych zmianach.

Praktyczna zasada: Graph RAG opłaca się wtedy, gdy korzyść z odpowiedzi opartych na relacjach uzasadnia dodatkowy nakład, a nie jako rozwiązanie domyślne. Badania Blck Alpaca ogólnie przestrzegają przed antywzorcem „RAG jako panaceum”; w przypadku Graph RAG ta przestroga waży jeszcze więcej, bo całkowity koszt posiadania jest tu znacznie wyższy.

Kiedy Graph RAG, a kiedy nie

Sprawdzi się, gdy:

• odpowiedzi muszą łączyć informacje z wielu dokumentów (łańcuchy dostaw, struktury organizacyjne, sieci powiązań compliance, krajobraz badań i patentów).
• jawne relacje między encjami są merytorycznie kluczowe.
• trzeba odpowiadać na globalne pytania przeglądowe i tematyczne dotyczące całego korpusu.

Raczej nie, gdy:

• pytania dotyczą głównie pojedynczych faktów lub wąsko określonych fragmentów; tu wystarczy hybrydowy RAG z re-rankingiem.
• korpus jest mały lub często przepisywany w całości (utrzymanie grafu staje się wąskim gardłem).
• budżet nie udźwignie indeksowania intensywnie wykorzystującego LLM.

W praktyce najlepiej sprawdza się architektura hybrydowa: wyszukiwanie wektorowe lub hybrydowe zapewnia szerokie pokrycie semantyczne, a graf wiedzy włącza się celowo do pytań o relacje i pytań typu multi-hop. Dzięki temu Graph RAG pozostaje precyzyjną nakładką, a nie kosztownym zamiennikiem całego systemu.

Uwaga dla regionu DACH (Niemcy, Austria, Szwajcaria): ochrona danych obowiązuje także w grafie

W Niemczech i Austrii Graph RAG niczego nie zmienia w zasadach RODO. Encje i relacje zawierające dane osobowe należy, podobnie jak embeddingi i chunki w klasycznym RAG, traktować jako adresowalne, usuwalne rekordy. Obowiązują zasady ograniczenia celu i minimalizacji danych (art. 5), wymóg podstawy prawnej przetwarzania (art. 6) oraz prawo do usunięcia danych (art. 17). Izolacja danych klientów oraz koncepcja ról i uprawnień to typowe środki techniczne i organizacyjne, dzięki którym realizujesz ograniczenie celu i ochronę dostępu zgodnie z art. 25 i art. 32 RODO. Niemiecka Konferencja Ochrony Danych (DSK) wymienia oba te środki jako sprawdzone w swoich wytycznych dotyczących systemów RAG z października 2025 r. Jeśli pracownicy korzystają z systemu do różnych celów, według DSK muszą otrzymać różne role. Hosting w regionie UE jest zalecany, ale nie obowiązkowy: kto hostuje poza EOG, potrzebuje podstawy prawnej z rozdziału V RODO, np. decyzji stwierdzającej odpowiedni stopień ochrony lub standardowych klauzul umownych.

W Austrii właściwym organem jest urząd ochrony danych (Datenschutzbehörde, DSB). Jego stanowisko w sprawie wykorzystania AI przedstawiono w FAQ dotyczącym AI i ochrony danych. W Szwajcarii obowiązuje przede wszystkim znowelizowana ustawa o ochronie danych (revDSG, w mocy od 1 września 2023 r.). RODO ma tam zastosowanie dodatkowo wtedy, gdy przedsiębiorstwo oferuje towary lub usługi osobom w UE albo monitoruje ich zachowanie, o ile to zachowanie ma miejsce w UE (art. 3 ust. 2 RODO). Te informacje mają charakter poglądowy i nie stanowią porady prawnej.

Dla agencji i decydentów B2B

Graph RAG nie jest modnym zamiennikiem wektorowego RAG, lecz wyspecjalizowanym narzędziem do wiedzy, w której kluczowe są relacje. Dla agencji oznacza to: zacznij od hybrydowego RAG z re-rankingiem jako solidnej bazy standardowej i wprowadzaj Graph RAG tylko tam, gdzie pytania typu multi-hop lub pytania przeglądowe przynoszą wymierną wartość biznesową. Dla decydentów B2B kluczowe pytanie nie brzmi „Która technologia jest nowsza?”, lecz „Jakie pytania naprawdę zadają nasi użytkownicy i czy odpowiedzi na nie wymagają relacji, czy tylko podobieństwa?”. Blck Alpaca pomaga w tym rozgraniczeniu, uczciwie kalkuluje TCO i buduje zgodne z RODO architektury RAG, które rosną wraz z rzeczywistymi potrzebami, od prostego indeksu wektorowego po hybrydowy system z grafem wiedzy.