GraphRAG, wyszukiwanie po grafie wiedzy

GraphRAG, czyli pytania, na które wyszukiwanie wektorowe nie odpowie

Wyszukiwanie po podobieństwie znaczeniowym świetnie odpowiada na pytania punktowe: gdzie opisano procedurę zwrotu, jaki jest limit dla planu podstawowego. Zawodzi przy pytaniach obejmujących cały zbiór: jakie są główne wątki w tych stu raportach, kto z kim współpracował, co się powtarza w zgłoszeniach z ostatniego kwartału.

Powód jest prosty. Odpowiedź na takie pytanie nie leży w żadnym pojedynczym fragmencie, więc nawet idealne wyszukiwanie zwróci pięć fragmentów, z których nie da się jej złożyć.

GraphRAG podchodzi do tego inaczej: buduje z dokumentów graf encji i relacji, grupuje go w społeczności, streszcza każdą z nich, a potem odpowiada na pytania globalne, korzystając ze streszczeń zamiast z fragmentów.

Jak to działa

Przepływ ma dwie fazy o zupełnie różnym koszcie i warto je rozdzielić od początku.

Faza indeksowania jest kosztowna. Model przechodzi przez wszystkie dokumenty i wydobywa z nich encje: osoby, organizacje, produkty, pojęcia. Potem wydobywa relacje między nimi. Powstaje graf, który algorytm wykrywania społeczności dzieli na skupiska powiązanych ze sobą encji, a model streszcza każde skupisko.

Faza odpowiadania korzysta z tego, co powstało. Pytanie punktowe idzie do wyszukiwania lokalnego, obejmującego encję i jej najbliższe otoczenie w grafie. Pytanie globalne idzie do streszczeń społeczności, z których model składa odpowiedź obejmującą cały zbiór.

Ten podział jest sednem. Wyszukiwanie lokalne odpowiada na pytania o konkret, globalne na pytania o całość, a różnica leży w tym, z czego korzysta odpowiedź.

Koszt, czyli główna przeszkoda

Trzeba to powiedzieć wprost: pierwotna wersja jest droga. Wydobycie encji i relacji ze wszystkich dokumentów oznacza przepuszczenie całego zbioru przez model, a potem jeszcze streszczenie każdej społeczności.

Przy tysiącu dokumentów to koszt liczony w setkach dolarów, przy dziesięciu tysiącach w tysiącach. To jednorazowy koszt indeksowania, ale wraca przy każdej większej zmianie w zbiorze i przy zmianie modelu.

Odpowiedzią na ten problem są warianty odkładające część pracy do momentu zapytania. Zamiast streszczać wszystkie społeczności z góry, robią to dla tych, które okażą się istotne przy konkretnym pytaniu. Koszt indeksowania spada wtedy do poziomu porównywalnego ze zwykłym wyszukiwaniem wektorowym, a jakość odpowiedzi zostaje.

Powstały też lżejsze implementacje o zbliżonym pomyśle i niższych wymaganiach. Przy planowaniu wdrożenia warto zacząć od nich, bo pierwotna wersja jest przede wszystkim pracą badawczą pokazującą, że podejście działa, a nie najtańszą drogą do wyniku.

Kiedy to ma sens

Warto rozdzielić rodzaje pytań, bo od tego zależy cała decyzja.

Pytania punktowe obsługuje zwykłe wyszukiwanie wektorowe i robi to taniej. Jeśli Twoi użytkownicy pytają o konkretne procedury, wartości i przepisy, dokładanie grafu nie poprawi odpowiedzi, a zwiększy koszt.

Pytania o całość to obszar, w którym graf wygrywa. Podsumowanie tematów w zbiorze raportów, znalezienie powtarzających się wątków w zgłoszeniach, opisanie, jak coś zmieniało się w czasie w serii dokumentów.

Pytania o powiązania to drugi taki obszar. Kto jest połączony z kim, przez co i jak daleko. Tego wyszukiwanie wektorowe nie zrobi, bo podobieństwo znaczeniowe nie niesie informacji o relacjach.

Praktyczny wniosek jest taki, że decyzję warto oprzeć na prawdziwych pytaniach użytkowników. Jeśli wśród stu zapytań dziewięćdziesiąt jest punktowych, buduj zwykłe wyszukiwanie i rozważ graf dla pozostałych dziesięciu. Jeśli proporcja jest odwrotna, sytuacja wygląda inaczej.

Układ mieszany

Najczęstsze rozwiązanie produkcyjne nie polega na wyborze jednego podejścia, tylko na skierowaniu pytania tam, gdzie zostanie obsłużone najlepiej.

Warstwa kierująca rozpoznaje rodzaj pytania i wybiera ścieżkę. Pytanie o konkret idzie do bazy wektorowej pokroju Qdranta. Pytanie o liczby idzie do zwykłego zapytania do bazy relacyjnej. Pytanie o całość idzie do streszczeń społeczności.

Ten podział ma sens także ekonomiczny. Ścieżka najtańsza obsługuje większość ruchu, a droga uruchamia się tylko wtedy, gdy jest potrzebna. Odwrotny układ, w którym wszystko idzie przez graf, płaci najwyższą stawkę za pytania, które jej nie wymagają.

Warstwę kierującą można zbudować prostym klasyfikatorem na tańszym modelu. Koszt jednego dodatkowego wywołania jest niewielki wobec różnicy między ścieżkami, a trafność klasyfikacji da się zmierzyć na zestawie prawdziwych pytań.

Uruchomienie na próbę

Zanim policzysz koszt dla całego zbioru, warto zbudować graf dla jego niewielkiej części. To zajmuje godzinę i odpowiada na pytania, których nie rozstrzygnie żadna lektura.

pip install graphrag
graphrag init --root ./projekt
graphrag index --root ./projekt

Konfiguracja obejmuje wybór modelu do wydobywania encji, modelu do osadzeń i typów encji, których szukać. Ten ostatni parametr jest najważniejszy przy dokumentach specjalistycznych, bo domyślnie narzędzie szuka wyłącznie organizacji, osób, miejsc i zdarzeń.

extract_graph:
  entity_types: [osoba, organizacja, produkt, technologia, umowa]

Nazwa sekcji zmieniła się wraz z wydaniem pierwszej wersji stabilnej: starsze poradniki podają entity_extraction, a bieżące wydanie czyta extract_graph. Samo narzędzie wymaga też Pythona w wersji od 3.11 do 3.13, więc na starszym albo najnowszym interpreterze instalacja się nie powiedzie.

Uruchomienie indeksowania na dwudziestu dokumentach pokazuje trzy rzeczy. Ile kosztuje jeden dokument, czyli podstawę do pomnożenia. Jakie encje faktycznie wychodzą, czyli czy typy są dobrane. Jak wygląda graf, czyli czy relacje mają sens.

Ta próba zwykle prowadzi do dwóch albo trzech poprawek w konfiguracji, po których wynik jest wyraźnie lepszy. Uruchomienie od razu na całości oznacza zapłacenie pełnej stawki za wersję, którą i tak trzeba będzie powtórzyć.

Warto też sprawdzić, jak zachowuje się wyszukiwanie globalne przy tak małym zbiorze. Przy dwudziestu dokumentach społeczności są nieliczne, więc odpowiedzi na pytania o całość bywają ubogie, a to nie jest wada metody, tylko skutek rozmiaru próbki.

Jakość grafu

Cała konstrukcja stoi na tym, jak dobrze model wydobył encje i relacje, więc warto wiedzieć, gdzie to zawodzi.

Pierwszy problem to ta sama encja pod różnymi nazwami. Firma występująca raz z pełną nazwą, raz ze skrótem i raz z literówką staje się trzema węzłami zamiast jednym, przez co relacje się rozpraszają. Krok scalający encje jest tu obowiązkowy, a nie opcjonalny.

Drugi to encje wydobyte z fragmentów bez kontekstu. Model widzący pojedynczy akapit nie wie, że wymieniona osoba to ta sama, o której mowa trzy strony wcześniej. Większe fragmenty poprawiają to kosztem ceny.

Trzeci to dziedzina. Model ogólny wydobywa encje ogólne, a przy dokumentach specjalistycznych warto podać mu listę typów, których szukać. Bez tego z dokumentacji medycznej wyjdą osoby i daty zamiast substancji i interakcji.

Warto obejrzeć graf po zbudowaniu, zanim uznasz sprawę za zamkniętą. Kilkanaście minut przeglądania encji pokazuje zwykle dwa albo trzy systematyczne błędy, których poprawienie zmienia jakość odpowiedzi bardziej niż jakiekolwiek strojenie promptu.

Do samego przeglądania wygodniej jest wczytać wynik indeksowania do bazy grafowej, bo narzędzie zapisuje graf jako pliki z tabelami, a szukanie w nich powtórzonych encji jest mozolne. Neo4j nadaje się do tego dobrze, bo zapytanie w Cypherze wprost wyciąga węzły o zbliżonych nazwach albo takie, które nie mają żadnej relacji. Przy szukaniu dokumentacji przydaje się jedna informacja: projekt przeszedł na wersje kalendarzowe, więc nie ma czegoś takiego jak Neo4j 6, a materiały mówiące o szóstce pochodzą sprzed tej zmiany albo są nieporozumieniem.

Aktualizacja zbioru

Dokumenty się zmieniają, a przebudowa całego grafu przy każdej zmianie jest niewykonalna finansowo. To pytanie warto rozstrzygnąć przed wdrożeniem, a nie po pierwszej aktualizacji.

Dokładanie przyrostowe polega na wydobyciu encji tylko z nowych dokumentów i wpięciu ich do istniejącego grafu. Działa dobrze, dopóki nowe treści nie zmieniają obrazu całości, bo społeczności i ich streszczenia pozostają te same.

Problem pojawia się, gdy nowe dokumenty przesuwają strukturę. Nowy dział w firmie, nowa linia produktów albo zmiana, po której dotychczasowe skupiska przestają być trafne, wymagają ponownego wykrycia społeczności i przeliczenia streszczeń.

Praktyczne rozwiązanie polega na rozdzieleniu obu przypadków. Dokładanie przyrostowe przy każdej zmianie i pełna przebudowa raz na kwartał albo po większej zmianie w organizacji zbioru. Ta druga jest wtedy planowana i wliczona w budżet, a nie odkrywana jako konieczność.

Warto też zdecydować, co robić z dokumentami usuniętymi. Encja wydobyta z dokumentu, którego już nie ma, zostaje w grafie i wpływa na odpowiedzi, więc usunięcie musi obejmować także graf, a nie tylko magazyn dokumentów.

Ile to daje w liczbach

Trudność w ocenie tego podejścia polega na tym, że przewaga jest widoczna wyłącznie na pytaniach określonego typu, a tam bywa duża.

Na pytaniach punktowych różnica wobec zwykłego wyszukiwania jest zwykle w granicach szumu pomiarowego. To spodziewane, bo obie metody sięgają po ten sam fragment, tylko inną drogą.

Na pytaniach o całość różnica jest jakościowa, a nie ilościowa. Zwykłe wyszukiwanie zwraca pięć fragmentów i model produkuje odpowiedź opartą na pięciu przykładach, przedstawiając ją jako obraz całości. To gorsze niż brak odpowiedzi, bo brzmi wiarygodnie i wprowadza w błąd.

Ten mechanizm jest wart uwagi przy ocenie istniejącego systemu. Jeśli użytkownicy zadają pytania o całość, a system odpowiada płynnie, warto sprawdzić, na ilu fragmentach oparta jest odpowiedź. Miary opisane w tekście o Ragas tego nie wychwycą, bo odpowiedź jest wierna wobec podanego kontekstu, tylko kontekst jest niereprezentatywny.

Trzecia rzecz to koszt zapytania. Wyszukiwanie globalne przechodzi przez streszczenia wielu społeczności, więc jedno pytanie kosztuje wielokrotnie więcej niż zwykłe. Warianty ograniczające liczbę przeglądanych społeczności obniżają to znacząco, ale zerowe nigdy nie będzie.

GraphRAG kontra alternatywy

Ostatni wiersz zasługuje na uwagę, bo bywa najprostszym rozwiązaniem. Zbiór mieszczący się w oknie kontekstu współczesnego modelu nie wymaga żadnego indeksowania: wrzucasz całość i pytasz. Przy dwustu stronach i kilku pytaniach dziennie to wychodzi taniej niż budowanie grafu.

Granica przebiega przy rozmiarze i częstotliwości. Zbiór przekraczający okno kontekstu albo pytania zadawane setki razy dziennie przesuwają rachunek na korzyść rozwiązań indeksujących.

Typowe błędy

Pierwszy to budowanie grafu bez sprawdzenia, jakie pytania faktycznie zadają użytkownicy. Jeśli wszystkie są punktowe, cała praca nie zmieni odpowiedzi.

Drugi to pominięcie scalania encji. Ta sama firma jako trzy węzły rozprasza relacje i psuje wykrywanie społeczności, przez co streszczenia obejmują przypadkowe zbiory.

Trzeci to uruchomienie pierwotnej wersji na dużym zbiorze bez policzenia kosztu. Rachunek za indeksowanie potrafi przekroczyć roczny budżet na model.

Czwarty to zakładanie, że graf zastąpi wyszukiwanie wektorowe. To uzupełnienie odpowiadające na inny rodzaj pytań, a nie następca.

Piąty to brak planu na aktualizację. Dokumenty się zmieniają, a przebudowa całego grafu przy każdej zmianie jest niewykonalna finansowo, więc warto od początku wiedzieć, jak dokładać nowe dokumenty przyrostowo.

Szósty to ocena jakości po wrażeniu z kilku pytań. Ten sam zestaw miar co przy zwykłym wyszukiwaniu, opisany w tekście o Ragas, stosuje się tu tak samo i bez niego strojenie jest zgadywaniem.

FAQ

Czym GraphRAG różni się od zwykłego RAG?

Zwykłe wyszukiwanie zwraca fragmenty podobne do pytania, więc odpowiada na pytania punktowe. GraphRAG buduje graf encji i relacji, grupuje go w społeczności i streszcza je, dzięki czemu odpowiada też na pytania obejmujące cały zbiór, na które żaden pojedynczy fragment nie odpowie.

Ile kosztuje zbudowanie grafu?

Pierwotna wersja przepuszcza cały zbiór przez model kilka razy, więc przy tysiącu dokumentów to setki dolarów. Warianty odkładające streszczanie do momentu zapytania obniżają ten koszt do poziomu porównywalnego ze zwykłym wyszukiwaniem wektorowym.

Czy to zastępuje bazę wektorową?

Nie, uzupełnia ją. Najczęstszy układ produkcyjny kieruje pytania punktowe do bazy wektorowej, pytania o liczby do bazy relacyjnej, a pytania o całość do streszczeń społeczności, bo każda ścieżka odpowiada na inny rodzaj pytania.

Kiedy nie warto po to sięgać?

Gdy użytkownicy zadają wyłącznie pytania punktowe, gdy zbiór mieści się w oknie kontekstu modelu i pytań jest niewiele, albo gdy budżet nie obejmuje indeksowania. W dwóch pierwszych przypadkach prostsze rozwiązania dają ten sam wynik taniej.

Od czego zacząć?

Od zebrania trzydziestu prawdziwych pytań użytkowników i podzielenia ich na punktowe i globalne. Ta proporcja mówi, czy warto, a przy próbie wdrożenia zacznij od wariantu lżejszego na małym podzbiorze dokumentów, zanim policzysz koszt dla całości.

Kod i dokumentacja stoją w repozytorium projektu, a opis wariantu obniżającego koszt indeksowania znajdziesz we wpisie badawczym.