Czym jest knowledge graph (graf wiedzy)?
Graf wiedzy zapisuje encje i relacje między nimi. Wyjaśniamy różnicę wobec bazy wektorowej i kiedy RAG bez grafu nie odpowie na Twoje pytanie.

Knowledge graph (graf wiedzy) to sposób zapisania wiedzy jako sieci: encje są punktami, a relacje między nimi krawędziami. Zamiast trzymać wyłącznie zdanie „umowa 14/2024 dotyczy podwykonawcy Kowalski i kończy się 2026-12-31”, graf może zapisać encje umowy i podwykonawcy, relację między nimi oraz datę zakończenia jako atrybut — dzięki czemu da się o te elementy pytać jawnie.
Różnica wydaje się akademicka, dopóki nie zadasz pytania, na które wyszukiwanie fragmentów nie umie odpowiedzieć.
Kiedy wyszukiwanie fragmentów przestaje wystarczać
RAG może pobierać fragmenty trafne dla pytania. Dobrze pasuje do pytań typu „jaka jest nasza procedura reklamacji”. Samo wyszukiwanie fragmentów może jednak nie wystarczyć, gdy odpowiedź nie jest zapisana w jednym miejscu, tylko wynika z połączenia kilku faktów:
- „Które umowy z podwykonawcami kończą się przed najbliższym audytem?”
- „Kto w firmie pracował przy projektach dla klientów z branży transportowej?”
- „Jakie systemy zależą od tej jednej integracji, którą chcemy wyłączyć?”
Jeśli odpowiedź nie występuje w jednym fragmencie, trzeba połączyć kilka faktów. Graf jest jedną z architektur, które ułatwiają takie przejście i pokazanie ścieżki.
Graf wiedzy a baza wektorowa
| Baza wektorowa (RAG) | Knowledge graph | |
|---|---|---|
| Co przechowuje | fragmenty tekstu i ich znaczenie | encje i relacje między nimi |
| Odpowiada na | „gdzie jest o tym napisane” | „jak to się ze sobą wiąże” |
| Pytanie wieloetapowe | zależy od sposobu wyszukiwania i narzędzi | naturalnie wspiera przejście po relacjach |
| Koszt przygotowania | zależy od źródeł i ewaluacji | dochodzi model relacji i ujednolicanie encji |
| Aktualizacja | dodaj dokument | trzeba wpasować w schemat |
| Wyjaśnialność | „to z tego dokumentu” | „to z tej ścieżki powiązań” |
Te podejścia można łączyć, ale nie jest to automatycznie najlepszy wybór. Graf pomaga przy relacjach i agregacji, a wyszukiwanie tekstowe dostarcza fragmenty do cytowania. Jedną z implementacji takiego wzorca jest Microsoft GraphRAG, który wyodrębnia z tekstu encje, relacje i twierdzenia. Koszt indeksowania oraz utrzymania grafu trzeba jednak uzasadnić pytaniami, których prostszy RAG nie obsługuje.
Z czego składa się graf wiedzy
Trzy pojęcia i koniec teorii:
- Encja — rzecz, o której mówisz: klient, umowa, produkt, osoba, projekt, system. Ma typ i identyfikator.
- Relacja — nazwane połączenie: „umowa dotyczy klienta”, „osoba pracowała w projekcie”, „system zależy od integracji”. Relacja ma kierunek.
- Atrybut — właściwość encji: data, kwota, status.
Istotna część pracy leży w decyzji, co jest encją, relacją i atrybutem. Granice trzeba rozstrzygnąć z osobami znającymi dziedzinę, a potem sprawdzić je na realnych pytaniach; sama poprawna składnia grafu nie zapewnia użyteczności.
Jak buduje się graf z dokumentów
Kolejność, którą stosujemy:
- Model dziedziny. Wypisujemy typy encji i dozwolone relacje. Bez jawnych zasad rośnie ryzyko niespójnych nazw, duplikatów i zapytań, których wynik trudno interpretować.
- Ekstrakcja. Model językowy może czytać dokumenty i proponować encje oraz relacje zgodnie z modelem. Automatyzacja ogranicza koszt ręcznej pracy przy dużym zbiorze, ale jej wynik nadal wymaga kontroli jakości.
- Ujednolicenie encji. „Jan Kowalski”, „J. Kowalski” i „Kowalski Jan” mogą oznaczać tę samą osobę. Reguła łączenia potrzebuje identyfikatorów i obsługi niepewności, aby nie scalić dwóch różnych osób.
- Weryfikacja. Próbka relacji sprawdzana przez człowieka, plus reguły spójności („umowa nie może kończyć się przed rozpoczęciem”).
- Odpytywanie. Zapytania po grafie plus warstwa językowa, która zamienia pytanie użytkownika na zapytanie do grafu.
Kiedy knowledge graph się nie sprawdzi
Uczciwie, bo to narzędzie łatwo przesadzić:
- Gdy pytania są proste i faktograficzne. „Jaka jest procedura X” nie potrzebuje grafu. Sam RAG wystarczy i będzie tańszy.
- Gdy dziedzina jest niestabilna. Graf wymaga schematu. Jeśli co miesiąc zmienia się to, czym w ogóle są encje, schemat będzie ciągle nieaktualny.
- Gdy nie ma kto rozstrzygać modelu dziedziny. Bez osoby, która wie, jak firma naprawdę działa, powstanie graf zgodny z dokumentami i niezgodny z rzeczywistością.
- Gdy dane są rozsypane i sprzeczne. Graf nie naprawia bałaganu — utrwala go w postaci, która wygląda na precyzyjną. To gorsze niż bałagan widoczny.
Co to daje w praktyce
Trzy efekty, dla których warto rozważyć graf i sprawdzić go na realnych pytaniach:
- Odpowiedzi na pytania „przez kilka kroków” bez przekopywania folderów.
- Możliwość prześledzenia podstawy. Widać ścieżkę relacji wykorzystaną przez zapytanie. Przy decyzjach obarczonych ryzykiem pomaga to weryfikować wynik, ale nie zastępuje kontroli poprawności danych i reguł.
- Lepsza kontrola podstawy odpowiedzi. Ścieżka w grafie i cytat ułatwiają weryfikację, ale nie gwarantują poprawności ekstrakcji ani generacji.
Ile to kosztuje
Graf jest zwykle modułem większego projektu second brain, a nie osobnym zakupem. W naszych widełkach na sierpień 2026 r. pilotaż kosztuje 12 000–30 000 zł netto, a system produkcyjny 30 000–120 000 zł netto. Graf zwiększa zakres o model dziedziny, ujednolicanie encji i testy relacji.
Najczęstsze pytania
Czy potrzebujemy specjalnej bazy danych?
Nie zawsze. Przy mniejszych grafach relacje mieszczą się w zwykłym PostgreSQL. Dedykowaną bazę grafową bierzemy, gdy zapytania robią się głębokie i wydajność zaczyna mieć znaczenie.
Kto utrzymuje graf po wdrożeniu?
Ekstrakcję nowych dokumentów można automatyzować, ale ktoś musi rozstrzygać przypadki wątpliwe i zmiany modelu dziedziny. Właściciela oraz częstotliwość przeglądu ustala się według ryzyka i tempa zmian.
Czy da się zacząć bez grafu i dołożyć go później?
Tak i zwykle to rekomendujemy. Start z RAG, pomiar, na jakich pytaniach system się wykłada, i dopiero wtedy graf tam, gdzie realnie brakuje relacji. Odwrotna kolejność to budowanie na wyczucie.
Grafy wiedzy budujemy również dla siebie — nasze narzędzia knowledge-graph opisujemy w laboratorium. To nie jest cudze wdrożenie, o którym czytaliśmy, tylko rzecz, którą utrzymujemy w praktyce. Jeśli Twoje pytania wymagają relacji, a nie tylko wyszukiwania, porozmawiajmy.

Autor
Maciej Szukalski
Założyciel Condictor · architekt systemów · badania i rozwój
Od 2014 roku projektuje i buduje produkty cyfrowe. Specjalizuje się w architekturze, badaniach oraz aplikacjach z warstwami automatyzacji i inteligencji.
Poznaj doświadczenie i sposób pracyMasz problem do rozwiązania?
Sprawdźmy, od czego warto zacząć
Opisz sytuację w kilku zdaniach. Wrócimy z pytaniami lub propozycją konkretnego następnego kroku.
