Przewodnik

GraphRAG: graf wiedzy w retrieval

Klasyczny RAG znajduje podobne fragmenty. To świetne, dopóki pytanie nie wymaga relacji. GraphRAG dodaje warstwę grafu — z prowencją i ścieżką dowodową.

Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Wiedza i źródła i ma formę Przewodnik. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal SSOT i hierarchię źródeł (co jest kanoniczne, co pomocnicze).
  • Zaprojektuj retrieval: filtry, hybryda (keyword+semantics), reranking.
  • Wprowadź cytowania i atrybucję (proweniencja w odpowiedzi).
  • Zadbaj o świeżość i konflikty źródeł (zasady rozstrzygania).
  • Monitoruj jakość retrieval (trafność, pokrycie, dryft).
  • Zastosuj uprawnienia, redakcję danych i logowanie zapytań.

Najczęstsze pułapki

  • RAG bez cytowań – nie da się audytować, skąd wzięła się teza.
  • Chunking „na oko” – zbyt duże lub zbyt małe fragmenty psują trafność.
  • Brak polityki świeżości – model miesza stare i nowe wersje informacji.
  • Ignorowanie uprawnień – wycieki danych przez zbyt szeroki kontekst.

Artefakty w Luage

context_packet sources:ssot citations_contract retrieval_metrics access_policy

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

W skrócie
  • GraphRAG łączy encje i relacje, gdy „podobny akapit” to za mało
  • wymaga entity linking, grafu z provenance i planera zapytań
  • bez provenance graf jest nieaudytowalny i nie powinien zasilać odpowiedzi
  • mierzyć trzeba coverage, precision, dowodowość i stabilność
Jeśli to ma wejść do procesu, proszę traktować ten rozdział jako standard operacyjny.
Teza: wektory dobrze znajdują „podobne fragmenty”. Graf dobrze znajduje „powiązane fakty”. GraphRAG łączy jedno z drugim, gdy odpowiedź zależy od relacji, a nie tylko od podobieństwa tekstu.

1. Kiedy GraphRAG ma sens

GraphRAG jest sensowny, gdy:

  • pytania wymagają łączenia encji (osoba → projekt → decyzja → dokument),
  • liczą się ścieżki dowodowe („dlaczego tak?”),
  • retrieval wektorowy daje szum, bo w dokumentach jest dużo podobnych akapitów,
  • potrzebujesz restrykcji typu: „tylko dokumenty z tej jednostki, z tej wersji, z tej relacji”.

2. Architektura wysokopoziomowa

GraphRAG — graf + wektory

W praktyce GraphRAG oznacza dodatkowe komponenty:

  • ekstrakcję encji i relacji (entity linking),
  • utrzymanie grafu (wersjonowanie, provenance),
  • planner zapytań (kiedy graf, kiedy wektory, kiedy hybryda),
  • fuzję wyników i cytowania (dowód dla każdej tezy).

3. Model danych: encje, relacje, provenance

Minimalny standard grafu, który da się audytować:

  • Entity: id, typ, aliasy, źródła, wersja,
  • Relation: typ relacji, kierunek, confidence (jeśli liczysz),
  • Provenance: skąd relacja pochodzi (doc_id + fragment + wersja).
Pułapka: graf bez provenance szybko zamienia się w „drugą prawdę”, której nie da się zweryfikować. Jeśli nie da się wskazać źródła relacji, nie należy jej używać w odpowiedziach.

4. Jakość: jak mierzyć, czy graf pomaga

  • Coverage: czy GraphRAG rozwiązuje pytania, z którymi wektory sobie nie radziły.
  • Precision: czy zmniejsza liczbę nietrafnych fragmentów.
  • Dowodowość: czy rośnie odsetek odpowiedzi z kompletnymi cytowaniami.
  • Stabilność: czy wyniki nie „pływają” po zmianach indeksu.

5. Operacje i governance

GraphRAG jest wymagający operacyjnie. Dobrą praktyką jest:

  • wersjonowanie grafu tak samo jak dokumentów (SSOT),
  • reindeksacja grafu w rytmie (nie ad‑hoc),
  • testy regresji na pytania relacyjne (golden set),
  • kontrola dostępu: graf nie może obejść RBAC dokumentów.

6. Powiązane rozdziały

Na tej stronie
Spis
Następny krok

Jeśli źródła mają być stabilne, dopnij SSOT i statusy dokumentów.

Przejdź do SSOT