RAG kontra Agentic RAG kontra Graph RAG: jak wybrać odpowiednią architekturę wyszukiwania
Dowiedz się, dlaczego prosty model RAG zawodzi przy pytaniami wieloetapowymi i danych strukturalnych, oraz w jaki sposób pętle agencyjne i systemy wyszukiwania oparte na grafach rozwiązują różne słabości.
Problem, który ma rozwiązać RAG
Każdy duży model językowy posiada wiedzę, której gromadzenie ustaje po zakończeniu treningu, i może rozumować jedynie na podstawie tego, co mieści się w jego oknie kontekstowym. Technika Retrieval-Augmented Generation rozwiązuje ten problem poprzez dodanie zewnętrznej pamięci, do której model może się odwoływać podczas odpowiadania na pytania. Zamiast polegać wyłącznie na tym, czego nauczył się podczas treningu, model pobiera istotne teksty z zbiorów dokumentów i wykorzystuje je do uzupełnienia swojej odpowiedzi.
Kroki leżące u podstaw tej techniki są prawdopodobnie już wam znane:
- Dokumenty źródłowe są dzielone na mniejsze fragmenty i przekształcane w wektorowe embeddingi.
- Ty te embeddingi są przechowywane w bazie danych wektorowej — popularnymi wyborami są Pinecone, Weaviate, pgvector i podobne narzędzia.
- Gdy użytkownik wysyła zapytanie, jest ono również przekształcane za pomocą tej samej metody.
Cała ta sekwencja jest wykonywana raz, od początku do końca: jedno pobieranie danych, jedna generacja. Jest tania w utrzymaniu, jej zachowanie jest łatwe do zrozumienia, a w szerokim zakresie zastosowań — wyszukiwanie dokumentów wewnętrznych, odpowiadanie na pytania klientów na podstawie bazy wiedzy lub obsługa pytań i odpowiedzi przy użyciu statycznej kolekcji dokumentów — sprawdza się doskonale.
Gdzie prosty RAG zawodzi
Gdy ten prosty proces zawodzi, problemy zazwyczaj należą do kilku rozpoznawalnych kategorii:
- Zadania wymagające połączenia kilku faktów. Pytanie typu „którzy dostawcy odnowili umowy po aktualizacji polityki w trzecim kwartale?” wymaga dwóch oddzielnych informacji, które prawie na pewno znajdują się w różnych fragmentach tekstu. Podobieństwo wektorowe identyfikuje fragmenty semantycznie podobne do zapytania, a nie konkretną kombinację faktów potrzebną do udzielenia odpowiedzi.
- System zawsze zwraca swoje najlepsze k fragmenty, niezależnie od tego, czy faktycznie zawierają one odpowiedź. Gdy prawdziwa odpowiedź znajduje się poza tym zestawem, model albo wymyśla coś wiarygodnego, albo udziela niejednoznacznej, bezużytecznej odpowiedzi.
- Jeśli początkowe wyszukiwanie nie przynosi rezultatu, nic w procesie nie wykrywa tego błędu i nie próbuje sformułować zapytania w lepszy sposób. Po prostu kontynuuje pracę z tym, co uzyskało.
Żadne z tych problemów nie jest tak naprawdę błędem; są to naturalne konsekwencje podstawowego założenia leżącego u podstaw architektury — mianowicie że wyszukiwanie na podstawie podobieństwa w niepowiązanych fragmentach tekstu wystarcza jako zamiennik prawdziwej relevancji. Agentic RAG oraz Graph RAG adresują odpowiednio różne słabe punkty tego założenia.
Agentic RAG: Dodanie pętli decyzyjnej do procesu wydobywania informacji
Agentic RAG zastępuje sztywną sekwencję „wydobyć informacje, a następnie je przetworzyć” pętlą, w której LLM pełni rolę koordynatora — decydującego, co należy sprawdzić, czy potrzebne są dodatkowe poszukiwania oraz kiedy zgromadzono już wystarczająco dużo danych, by sformułować odpowiedź.
Zamiast jednego kroku pobierania informacji, proces wygląda bardziej w ten sposób:
- Model czyta zapytanie i analizuje, jakie informacje faktycznie są potrzebne.
- Określa, czy pobieranie informacji w ogóle jest konieczne, a jeśli tak, tworzy zapytanie wyszukiwawcze — możliwe, że rozkłada skomplikowane pytanie na mniejsze podpytania.
- Pobiera wyniki, ocenia, czy są one wystarczające, a jeśli nie, przepisuje zapytanie i ponownie je wysyła.
- W razie potrzeby może korzystać z kilku różnych źródeł — magazynu wektorowego, bazy danych SQL, API do wyszukiwania w internecie, usługi wewnętrznej — w zależności od tego, czego wymaga pytanie.
- Dopiero po stwierdzeniu, że ma wystarczające dowody, podaje ostateczną odpowiedź.
Faktycznie oznacza to umieszczenie RAG wewnątrz pętli agencyjnej, wykorzystując ten sam wzorzec wywoływania narzędzi co asystenci programistyczni: planowanie, działanie, obserwacja wyniku, a następnie decyzja o kontynuowaniu. Pobieranie informacji przestaje być obowiązkowym pierwszym krokiem i staje się jedynie jednym z kilku narzędzi, wywoływanym selektywnie, a nie automatycznie przy każdej prośbie.
Korzyścią jest elastyczność. Proste pytanie powoduje jedno wyszukiwanie; pytanie wymagające trzech kolejnych wyszukań w różnych systemach otrzymuje dokładnie to. Takie rozwiązanie umożliwia również samokorektę – jeśli pobrane fragmenty są wyraźnie błędne, agent może to zauważyć i wysłać inne zapytanie zamiast odpowiadać na podstawie niepewnego kontekstu.
Ta elastyczność ma swoją rzeczywistą cenę. Każdy krok planowania i każda ocena stanowią odrębną próbę uruchomienia modelu, więc w rezultacie na jedno zapytanie przypada więcej wywołań LLM, większy opóźnienie oraz profil kosztów, którego trudno jest z góry przewidzieć. Agentic RAG sprawdza się dobrze, gdy złożoność zapytań znacznie się różni pomiędzy poszczególnymi prośbami, ponieważ stała metoda przetwarzania w jednej rundzie albo marnuje zasoby na proste pytania, albo nie radzi sobie z trudniejszymi. Jest to słabszy wybór, gdy potrzebny jest konsekwentnie niski opóźnienie lub gdy zapytania są na tyle specyficzne, że dobrze dostrojony retriever typu single-shot już je skutecznie obsługuje.
Graph RAG: Odzyskiwanie struktury niszczonej przez dzielenie na fragmenty
Graph RAG adresuje zupełnie inny problem: zwykłe wyszukiwanie wektorowe w fragmentach nie zawiera wbudowanej koncepcji pokazującej, jak elementy są ze sobą powiązane.
Zamiast polegać wyłącznie na indeksie wektorowym (chociaż może go nadal używać równolegle), Graph RAG buduje graf wiedzy bezpośrednio z materiału źródłowego. Polega to na wyodrębnianiu entytetów — osób, produktów, organizacji, koncepcji — wraz z relacjami je łączącymi, takimi jak praca dla, zależność od, spowodowanie przez lub jest wersją. W ten sposób wyszukiwanie przestaje być czystym poszukiwaniem podobieństwa i staje się częściowo problemem przemieszczania się po grafie: wychodząc od istotnej entytety, system może przechodzić do powiązanych entytetów i pozyskiwać informacje, które nigdy nie pojawiłyby się przy użyciu samego dopasowywania słów kluczowych lub wektorów, po prostu dlatego, że znajdują się one kilka relacji dalej w zupełnie innym dokumencie.
Badania Microsoftu nad GraphRAG stanowią najczęściej cytowaną implementację tego podejścia i wprowadzają dodatkową funkcję szczególnie przydatną dla jednego typu zapytań: wykrywania grup. System dzieli graf na klastry ściśle powiązanych ze sobą entytetów i uprzednio oblicza streszczenie dla każdego klastra. Dzięki temu Graph RAG ma przewagę w przypadku szerokich zapytań obejmujących całe korpusy – takich jak „Jakie są powtarzające się tematy we wszystkich tych raportach?” – co jest dokładnie kategorią, z którą ma największe trudności prosty RAG, ponieważ żaden pojedynczy fragment nie zawiera pełnej odpowiedzi; odpowiedź pojawia się jedynie poprzez syntezę danych z całego zbioru.
Koszty w tym przypadku są strukturalne, a nie incydentalne. Budowa grafu jest kosztowna, ponieważ wymaga przeprowadzenia procesu wyodrębniania podmiotów i relacji w całym korpusie, zwykle przy użyciu modelu językowego typu LLM, plus dodatkowego kroku generowania streszczeń społeczności. Nie nadaje się również do korpusów, które często ulegają zmianom, ponieważ graf musi być odbudowywany lub aktualizowany stopniowo za każdym razem, gdy zmieniają się dokumenty — co jest znacznie bardziej złożoną operacją niż proste dodanie nowego wektora do indeksu embeddingów.
Porównanie trzech podejść
Warto zaznaczyć, że te podejścia nie są wzajemnie wykluczające. Powszechnym wzorcem w praktyce jest pętla agentowa wyposażona zarówno w narzędzie do wyszukiwania wektorów, jak i narzędzie do wyszukiwania w grafach, co pozwala agencie wybierać między nimi lub używać obu w zależności od wymagań zapytania. Warstwa agentowa jest w rzeczywistości strategią orkiestracji działającą nad dowolnym mechanizmem wyszukiwania, więc naturalnie integruje się z Graph RAG zamiast konkurować z nim.
Pрактиczna struktura podejmowania decyzji
Zamiast wybierać dane podejście tylko dlatego, że jest obecnie popularne, pomocne jest przejście przez konkretny proces decyzyjny:
- Zacznij od prostego RAG. To najtańsza opcja pod względem budowy i rozwiązywania problemów, a w przypadku dużej części zastosowań w praktyce jest już wystarczająca. Unikaj dodawania złożoności, dopóki nie masz dowodów na to, że faktycznie jest ona potrzebna.
- Zmień na Agentic RAG, gdy zauważysz określone wzorce awarii: pytania wymagające pobierania informacji z kilku źródeł, odpowiedzi błędne, ponieważ model musiał wyszukiwać, oceniać znalezione dane i szukać ponownie, lub obciążenie pracy łączące proste i trudne zapytania w taki sposób, że pojedynczy, stały proces staje się albo nadmierny, albo niewystarczający.
Główny wniosek odzwierciedla wzorzec występujący w całym projektowaniu systemów: bardziej zaawansowana architektura nie jest z natury lepsza, jest lepsza tylko w przypadku określonego rodzaju problemów. Proste rozwiązanie RAG ma trudności z rozumowaniem wieloetapowym i pytaniami relacyjnymi. Rozwiązanie typu Agentic RAG eliminuje tę lukę poprzez wprowadzenie iteracji. Graph RAG radzi sobie z problemami relacyjnymi poprzez wprowadzenie struktury. Prawidłowa diagnoza tego, z jakim problemem faktycznie się mierzysz, jest kluczowa.
Literatura pokrewna
- Dlaczego koszty agencyjnego AI rosną: model kosztów oparty na architekturze — Wyjaśnia, dlaczego koszty agentów opartych na LLM należy mierzyć według ukończonych zadań, a nie według połączeń, oraz przedstawia narzędzia architektoniczne takie jak routowanie modeli, budżety kontekstowe i cache do kontrolowania wydatków.
- Drugi mózg: przekształcanie transkryptów spotkań w graf wiedzy dostępną do zapytań — Opisuje, jak system agencyjny wydobywa entity z transkryptów spotkań i przechowuje je w Cosmos DB, umożliwiając wyszukiwanie za pomocą języka naturalnego oraz eksplorację grafu wiedzy.