Jak pokonać graph RAG-a: Badawcza ciekawość kontra praktyczne zastosowanie

Łączenie dużych modeli językowych (LLM) z grafami wiedzy (Knowledge Graphs) to nic nowego. Od lat brzmi to jak idealny sposób na rozwiązanie największego problemu LLM-ów, czyli „halucynacji”, poprzez osadzenie ich w naszej logicznej strukturze informacji.

Mimo to, chociaż grafy wiedzy sprawdzają się na ogromną skalę (jak w Google, Amazon czy Wikipedii), wciąż nie są tak popularne, jak byśmy się spodziewali. Pełne zintegrowanie tych dwóch światów – reprezentacji danych ciągłych (LLM) i dyskretnych (KG) – okazało się trudniejsze, niż myśleliśmy.

Przyjrzymy się jednemu z szeroko omawianym zastosowań tej współpracy: systemom RAG. Zaprezentujemy szczegółowe wyniki przeprowadzonego przez nas eksperymentu i udowodnimy, dlaczego prostota i dogłębne zrozumienie danych mogą być kluczem do sukcesu. No i oczywiście – kiedy warto jednak zastosować bardziej zaawansowane podejścia grafowe.

RAG, czyli?

Retrieval-Augmented Generation to metoda, która łączy moc LLM-ów z zewnętrznymi, zaufanymi źródłami wiedzy. Dzięki temu model odpowiada na pytania, opierając się na danych, które mu dostarczamy, a nie tylko na danych, na których został wytrenowany przez jego twórców. A najlepsze jest to, że takie systemy można bez problemu zbudować w całości na własnych serwerach lub w prywatnej chmurze, więc nie musimy się martwić o wyciek poufnych danych. To praktyczny system, na który widzimy od paru lat spore zapotrzebowanie.

Ale, co ciekawe, tradycyjne RAG-i, które opierają się na wyszukiwaniu wektorowym, często mają kłopoty z pytaniami, które wymagają zebrania informacji z wielu, luźno powiązanych dokumentów. Wyobraź sobie, że pytasz:

Podsumuj najważniejsze wydarzenia z Doliny Krzemowej z ostatniego tygodnia.

Modele wektorowe szukają tekstów, które są semantycznie podobne do Twojego pytania, więc bez problemu znajdzie np.

Nvidia wczoraj zapowiedziała, że ich najnowszy układ…

Taki system może wyrzucić miliony wiadomości. Ale jak ustalić, które faktycznie dotyczą Doliny Krzemowej, skoro nie wszystkie wspominają o lokalizacji? I co ważniejsze – które są naprawdę ważne?

Światła, kamera, GraphRAG!

W 2024 roku Microsoft opublikował swój grafowy RAG o nazwie… cóż, „GraphRAG”, dając nadzieję na rozwiązanie tych wyzwań. Nie był to pierwszy „RAG na grafach”, ale odbił się chyba największym echem w społeczności AI. Zamiast indeksować bazę danych na podstawie semantyki, tutaj LLM generował logiczne powiązania między ludźmi, miejscami, wydarzeniami, tworząc logiczną sieć faktów. Ten pomysłowy, nieco skomplikowany system działał, ale miał swoje minusy, zwłaszcza jeśli chodzi o dużą skalę: wysokie koszty i kłopoty z utrzymaniem, gdy baza wiedzy się rozrastała.

W Sii od dawna obserwujemy ten trend, ale podchodzimy do niego z naszą charakterystyczną mieszanką badawczej ciekawości i pragmatyzmu. Chcieliśmy sprawdzić, czy ta obiecująca technologia jest na tyle dojrzała, żebyśmy mogli ją wdrożyć u naszych klientów.
Niestety, benchmarki i analizy porównawcze od twórców innowacji AI często bywają… niewiarygodne, bo są nastawione na pokazanie przewagi ich rozwiązania.

Dlatego postanowiliśmy postawić GraphRAG-owi godnego rywala. Nasz eksperyment nie miał być tylko akademickim testem. To był praktyczny test bojowy, który miał dać nam prostą odpowiedź: czy ten nowy, modny trend faktycznie jest lepszy od prostszego, bardziej konserwatywnego podejścia?

LightRAG – nowy, lepszy GraphRAG?

Od czasu słynnego GraphRAG-a wiele się zmieniło, więc w naszym badaniu porównaliśmy go z jednym z jego następców-konkurentów.

LightRAG to nowoczesny framework, który stał się popularny, bo naprawiał wiele problemów poprzednika, takich jak wysokie koszty i kłopotliwą skalowalność. Jego architektura jest hybrydowa, łączy wyszukiwanie grafowe z wektorowym. Wielką zaletą jest też to, że działa z różnymi dostawcami i ma przyrostowe indeksowanie, co bardzo ułatwia aktualizowanie baz wiedzy.

Architektura LightRAGa jest bardzo ciekawa, choć wymaga chwili, aby się w niej połapać.

Jak LightRAG indeksuje dane

1. Ekstrakcja i podsumowanie: LLM przetwarza dokumenty, wyciągając z nich encje (np. nazwy firm, osoby, daty) i relacje między nimi (np. „Google Inc.” <— „został założony” <— „14 września 1998”). Potem, każdą encję i relację opisuje w kilku zdaniach.
2. Tworzenie słownika: Encje (np. „Google”) stają się kluczami szczegółowymi (low-level keys), a relacje ogólnymi kluczami (high-level keys) np. „Założenie Google”. Opisy, które LLM wygenerował w poprzednim punkcie, stają się wartościami tych kluczy.
3. Tworzenie grafu: Encje z punktu 1. to teraz węzły w grafie, a relacje to krawędzie. Ten krok jest najważniejszy i jednocześnie najbardziej problematyczny, bo jakość grafu zależy wyłącznie od tego, jak skrupulatnie LLM wyciągnął wszystkie informacje.
4. Indeksowanie: Wygenerowane klucze trafiają aż do trzech baz danych:
   • wektorowej, gdzie można je znaleźć po semantycznym podobieństwie ich opisów,
   • grafowej, gdzie na podstawie relacji można znaleźć logicznie powiązane klucze,
   • słownikowej, gdzie klucze można szybko wyszukać, a opisy zwrócić.

Brzmi skomplikowanie? Bo tak jest! Ale jest też bardzo użytecznie. Taki graf można przeglądać, odpytywać, np. językiem zapytań Cypher i analizować, co daje nam świetny wgląd w naszą bazę wiedzy. Co więcej, LightRAG pozwala modyfikować ten indeks, więc możemy poprawiać błędy LLM-a, dodawać własną logikę (np. łączyć fakty, których nie było w tekście) czy usuwać duplikaty, wpływając na wyniki RAG-a.

Zbudujmy godnego przeciwnika

Nasz kontrkandydat zbudowany specjalnie na tę okazję, nazwijmy go VectorRAG, nie był prostą, naiwną implementacją, do których nowi autorzy często porównują swoje rozwiązania.

W duchu naszych innowacji ulepszyliśmy go za pomocą zaawansowanych technik, żeby stworzyć naprawdę solidny punkt odniesienia i zobaczyć prawdziwą różnicę. Przekonaliśmy się, że można osiągnąć świetne rezultaty bez sięgania po skomplikowane struktury grafowe, skupiając się na optymalizacji już istniejących rozwiązań.

Nasza strategia opierała się na:

• Wyszukiwaniu hybrydowym (ang. Hybrid Search): Połączyliśmy wyszukiwanie semantyczne oparte na wektorach z wyszukiwaniem słów kluczowych. Dzięki temu znaleźliśmy zarówno fragmenty tematycznie powiązane, jak i te, które zawierały konkretne, unikalne frazy. To dało nam większą elastyczność!
• Re-rankingu: Po wstępnym wyszukiwaniu użyliśmy mocniejszego modelu do ponownej oceny i sortowania fragmentów pod kątem ich użyteczności. Dzięki temu do głównego LLM-a trafiały tylko najbardziej adekwatne fragmenty, tworząc wartościowy kontekst.
• Zaawansowanej segmentacji (ang. chunking) i wzbogacaniu tekstu (ang. chunk enrichment): Zamiast dzielić dokumenty na losowe kawałki, tworzyliśmy segmenty logiczne (np. całe paragrafy czy sekcje) i dodawaliśmy do nich podsumowania kontekstowe. To dało naszemu VectorRAGowi dużo większe szanse na znalezienie odpowiednich, kompletnych fragmentów tekstu. Ale więcej o tym później.

LightRAG kontra VectorRAG – pierwsze spojrzenie

Przeprowadziliśmy nasz eksperyment na prawdziwych danych – czterech latach raportów finansowych (Form 10-K) firm z grupy FAANG (Facebook, Amazon, Apple, Netflix, Google), pełnych złożonych tabel z liczbami, pojęciami domenowymi.

Aby porównanie było sprawiedliwe, tam gdzie było to możliwe, użyliśmy w obu zbudowanych przez nas RAG-ach – LightRAG-u (grafowym) i VectorRAG-u (bezgrafowym) – tych samych modeli: gpt-4o-mini do indeksowania, gpt-4o do odpowiadania na pytania i ewaluacji („LLM as a judge”), text-embedding-3-large do wektoryzacji tekstu. Oba podejścia używały Doclinga do inteligentnej segmentacji tekstu.

LightRAG szybko pokazał wady automatycznie generowanych grafów wiedzy. Główny problem? Proces generowania grafu przez LLM.

• Problem duplikatów i fragmentaryzacji: Mimo swojej „inteligencji”, modele językowe miały problemy z tworzeniem spójnych encji. Zauważyliśmy mnóstwo duplikatów, np. „Jeff Williams” i „Jeffrey Williams” były traktowane jak dwie różne osoby. Taka fragmentaryzacja sprawiała, że węzły były odizolowane i nie dało się skutecznie połączyć wszystkich kropek.
• Błędy ekstrakcji: Czasami LLM po prostu pomijały kluczowe fakty, które nasz VectorRAG znajdował bez problemu. To jest powszechny problem w systemach, gdzie LLM-y generują grafy bez ludzkiego nadzoru.
• Koszty i skalowalność: Proces indeksowania w LightRAG-u jest o wiele droższy i wolniejszy niż w VectorRAG-u, ponieważ wymaga wysyłania wielu ciężkich zapytań do LLM-ów. Chociaż LightRAG poprawił to względem poprzedników, różnica jest nadal znaczna. Nawet jeśli nieco wyższy koszt jest dla nas akceptowalny, to dłuższy czas indeksowania może być sporą przeszkodą w przypadku dużych, często aktualizowanych baz danych.

Wszystkie trzy powyższe problemy są spotykane we wszystkich nam znanych graphRAG-ach generujących swój graf za pomocą LLM-a, więc LightRAG nie jest tu jakoś bardziej winny niż inne.

A jak na jego tle wypadł nasz kontrkandydat – VectorRAG?

Co tak naprawdę wyszło z naszego eksperymentu?

Nasz test pokazał to, czego się do końca nie spodziewaliśmy: w przypadku naszych zadań to zoptymalizowany VectorRAG wypadł często lepiej niż grafowy LightRAG. Spodziewaliśmy się niewielkiej, ale jednak przewagi dzięki grafom.

Okazało się, że wbrew temu, co często się słyszy, wyszukiwanie wektorowe daje radę nawet ze skomplikowanymi pytaniami – trzeba tylko dobrze je przygotować. Tak naprawdę, cała magia RAG-a polega na tym, jak przygotujesz dane, które wrzucasz do bazy i jak dobrze znasz swój use-case.

Co odkryliśmy w testach

• Jakość grafu to klucz! Największą bolączką LightRAG-a była kiepska jakość automatycznie generowanego grafu. Modele językowe nie umiały spójnie identyfikować tych samych podmiotów. Na przykład, „Jeff Williams” i „Jeffrey Williams” to dla nich dwie różne osoby.

• Połączenia w grafie, czyli relacje, też nie były tworzone w sposób konsekwentny i wiele faktów nie zostało nawet połączonych choćby pośrednio ze swoimi głównymi węzłami jak np. nazwa firmy. Dopiero po wzbogaceniu naszych „chunków” o podsumowania opisujące, jakiej firmy dany fragment dotyczy, z jakiego roku itp. Graf, a za tym – odpowiedzi zaczęły być bardziej kompletne. Więc nie dajmy się nabrać na kompletność RAG-owych rozwiązań.
• Brak dostępu do źródła. Kolejny problem LightRAG-a? Nie ma dostępu do oryginalnego tekstu. Wyszukiwanie opiera się na opisach, które LLM sobie sam wygenerował, a nie na prawdziwych fragmentach dokumentów. W efekcie, niektóre fakty potrafiły zaginąć, bo model nie umieścił ich w opisie, przez co nigdy nie trafiły do kontekstu odpowiedzi.
• Trudniejszy kontekst. Nawet jeśli informacje zostały wyciągnięte podczas indeksowania i graf dobrze łączy fakty, to LLM jeszcze musi potrafić to zrozumieć. Niestety przełożenie zgrabnej logiki grafu na tekst nie jest zbyt czytelne i w efekcie kontekst, który LLM otrzymuje od LightRAG-a, jest skomplikowany. Znajdują się tam opisy poszczególnych węzłów, ich relacji, a LLM nie wszystkie zawiłości dobrze interpretuje. To jak próbowanie wyjaśnić samymi słowami, kto z kim jak jest spokrewniony w „Modzie na sukces”. Być może nowsze LLM-y sobie z tym lepiej poradzą.
• Koszty i czas. Indeksowanie w systemach grafowych RAG jest dużo droższe i wolniejsze niż w VectorRAG-u. Dlaczego? Bo wymaga wielu zapytań do LLM-ów. Choć LightRAG trochę to poprawił, różnica nadal jest spora. Dłuższy czas indeksowania to duża bariera, zwłaszcza gdy pracujesz z ogromną, ciągle zmieniającą się bazą dokumentów.

• Pytania ogólne i wielowątkowe i tak sprawiały problemy LightRAG-owi w nie mniejszym stopniu niż VectorRAGowi. Np. pytając „jak różnią się strategie B&R różnych firm FAANG na przestrzeni ostatnich pięciu lat”, grafowy LightRAG dał mniej kompletną, mniej zróżnicowaną odpowiedź. I generalnie, choć odpowiedzi często wyglądały na bardzo dobre, bazowały na niepełnych informacjach z bazy, np. pominiętych firmach, osobach, latach i liczbach.

Ulepszmy RAG od podstaw!

Skąd ta pewność? Jak tłumaczyliśmy wcześniej, aby porównanie było sensowne, nie mogliśmy stworzyć dla LightRAG-a po prostu „dobrego” konkurenta. Chcieliśmy wycisnąć z niego maksimum możliwości w krótkim czasie. Dlatego w VectorRAG-u skupiliśmy się na usprawnieniach w samym sercu procesu – na danych. To właśnie te ulepszenia przyniosły najlepsze efekty.

Nasza implementacja wyróżnia się dzięki:

• Inteligentnemu dzieleniu dokumentów (ang. chunking): Zamiast kroić dokumenty na losowe fragmenty, użyliśmy narzędzia Docling, które tnie tekst na logiczne części – akapity, sekcje, tabele. Dzięki temu każdy kawałek ma sens i łatwiej znaleźć to, czego szukamy.
• Wzbogacaniu fragmentów (ang. chunk enrichment): Nasz LLM tworzył dodatkowe podsumowanie każdego fragmentu, osadzając go w szerszym kontekście. Ten proces (oparty na contextual retrieval od Anthropic) sprawia, że kawałki tekstu nie są „wyrwane z kontekstu”. To pomaga RAG-owi „połączyć kropki” i dawać bardziej złożone odpowiedzi.
• Wyszukiwaniu hybrydowemu i re-rankingowi: Połączyliśmy wyszukiwanie semantyczne (text-embedding-3-large) ze słowami kluczowymi (BM42). Potem użyliśmy silniejszego modelu (jina-reranker-v1-turbo-en), który ponownie ocenił i posortował wyniki, żeby do głównego LLM-a trafiły tylko te najtrafniejsze.

Tak dobre wyniki uzyskaliśmy nawet bez jednej techniki, która też jest absolutnym must-have w dzisiejszych RAG-ach, ale utrudniłaby nam nieco ewaluację – query expansion. Polega na tym, że LLM przed wyszukiwaniem przeformułowuje pytanie użytkownika, dodając synonimy i dodatkowy kontekst, co jest świetnym lekarstwem na skrótowe formułowanie pytań przez „leniwych” użytkowników, którymi przecież, z braku czasu, jesteśmy. Jeśli budujesz RAG-a, dodaj to do listy.

Więc – kiedy warto użyć grafu, a kiedy nie?

Nasz eksperyment pokazał, że graph RAG nie jest uniwersalnym rozwiązaniem dla każdego. Ma spory potencjał, ale wymaga świadomego wyboru. Ma sens, gdy klasyczne metody już nie dają rady, a twój problem wymaga naprawdę głębokiej analizy powiązań. Podejście grafowe jest bardzo rozbudowywalne, jeśli masz na to zasoby i pomysł.

Naszym zdaniem wdrożenie LightRAG-a jest uzasadnione dopiero wtedy, gdy wykorzystasz już potencjał powyższych technik, a wyniki wciąż nie będą zadowalające. Trzeba też zaakceptować to, że indeksowanie jest znacznie wolniejsze i droższe. Co więcej, musisz być gotowy na ciągłe udoskonalanie metody ekstrakcji danych (np. o dedykowane, douczone w tym celu modele) i ręczne poprawki w samej architekturze.

Chcesz pełnię możliwości? Konieczne będzie użycie zaawansowanych algorytmów przeszukiwania po grafie, które wykraczają poza bezpośrednie sąsiedztwo oferowane przez LightRAG. Innymi słowy – potrzebujesz ekspertów!

Ale w zamian LightRAG i jego krewniacy oferują coś unikalnego:

• Pozwalają na wyjście poza semantyczne podobieństwo.
• Dają pełną kontrolę nad indeksem, więc możesz dodawać własną, unikalną logikę do danych.
• Otwierają drzwi do grafowej eksploracji i wizualizacji danych (np. za pomocą języka Cypher).
• Mogą łączyć wyszukiwanie grafowe z wektorowym tak, żebyś nie musiał wybierać. Tyle tylko, że ten komponent wektorowy w LightRAG-u wymagałaby „podkręcenia” do czegoś na miarę naszego VectorRAG-a. Wtedy mogłoby to wyglądać bardzo interesująco.

Alternatywy dla LightRAG-a

A co z innymi opcjami? LightRAG jest przedstawicielem najpopularniejszego nurtu w wykorzystywaniu grafu w RAG-ach. Od czasu naszego eksperymentu coraz więcej mówi się o jeszcze bardziej złożonych koncepcjach, hierarchicznych i agentowych, niemniej podobna jak tutaj ostrożność musi być zachowana, bo łatwo dać się nabrać.

To temat na osobny wpis, ale warto wspomnieć, że dla danych, które są już w formie grafu (np. utrzymujesz już ontologie medyczne, taksonomie produktowe itp.), znacznie lepsze są RAG-i oparte na językach zapytań, np. SPARQL czy Cypher. LLM działa wtedy jak tłumacz, zamieniając twoje pytanie na precyzyjne zapytanie do bazy grafowej.

Pamiętaj jednak, że rzeczywiste grafy szybko rosną do gigantycznych rozmiarów, a nawet nowe LLM-y mają problem z generowaniem poprawnych zapytań, bo muszą trzymać się skomplikowanej struktury (tzw. „schemy”). Mimo to, to ciekawa alternatywa, choć znowu – wymaga dostosowania i ekspertyzy.

Podsumowując…

Nasz eksperyment udowodnił, że choć hype na grafowe systemy RAG jest duży, to ich praktyczne użycie wciąż wymaga sporo pracy. To nie oznacza, że powinniśmy się poddać! Prawdziwe przełomy rodzą się z konfrontacji teorii z rzeczywistością i choć łatwo tego nie zauważyć, postęp w AI jest stopniowy, inkrementalny, więc miejmy realistyczne oczekiwania.

Nasze badanie pokazało, że w świecie AI prostota i pragmatyzm często wciąż wiodą prym, przynajmniej do momentu, gdy pojawi się kolejna rewolucja.