Czym jest Agentic RAG i kiedy przestaje być zwykłym wyszukiwaniem dokumentów?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Agentic RAG to generowanie wspomagane wyszukiwaniem, w którym agent decyduje, jak, kiedy i czy ponownie przeprowadzić wyszukiwanie, zamiast podążać jedną, z góry ustaloną ścieżką.

Proste wyszukiwanie w domowych dokumentach może polegać na osadzeniu pytania, pobraniu fragmentów z najwyższymi wynikami top-k i wygenerowaniu jednej odpowiedzi. Agentic RAG dodaje do tej ścieżki pętlę sterującą: model lub orkiestrator może wybrać narzędzie wyszukiwania, ocenić, czy dowody są wystarczające, przeformułować zapytanie, skierować wyszukiwanie do innego źródła albo je zakończyć. Ta elastyczność jest przydatna w przypadku trudnych pytań dotyczących prywatnych danych, ale zwiększa też opóźnienia, wymaga zarządzania uprawnieniami narzędzi i stanem oraz wprowadza tryby awarii, które nie występują w zwykłym wyszukiwaniu dokumentów.

Prosty RAG korzysta z ustalonej ścieżki wyszukiwania

Konwencjonalny potok RAG zwykle ma określone kroki jeszcze przed pojawieniem się pytania: przekształcenie zapytania, przeszukanie jednego lub kilku indeksów, zebranie kontekstu i poproszenie modelu o odpowiedź. Parametry takie jak top-k lub filtry metadanych mogą się zmieniać, ale sam przebieg działania pozostaje w dużej mierze stały.

Taki projekt często wystarcza w przypadku domowych instrukcji, rachunków, notatek i tekstu z OCR, ponieważ pojedynczy etap wyszukiwania może ujawnić wymagane dowody. Jest przewidywalny, łatwy do oceny i tani w lokalnym uruchomieniu.

Warstwa bazowa wyszukiwania w lokalnej bazie wiedzy może wyodrębniać, indeksować, pobierać i obsługiwać dowody bez przyznawania modelowi kontroli nad całym procesem wyszukiwania.

Agentic RAG pozwala systemowi decydować, kiedy i jak wyszukiwać

Najważniejsza zmiana dotyczy kontroli. Wyszukiwanie staje się działaniem, które agent może wybrać po przeanalizowaniu pytania lub wcześniejszych dowodów, zamiast bezwarunkowym pierwszym etapem.

Agent może wybrać wyszukiwanie, ocenić dokumenty i przeformułować zapytania przed wygenerowaniem odpowiedzi.

Serwer domowy może wykorzystać to rozwiązanie, gdy jedno pytanie wymaga lokalnych notatek, indeksu wektorowego, dokładnego wyszukania nazwy pliku lub narzędzia sprawdzającego stan usługi. Agent może kierować zapytania do różnych opcji, zamiast przepuszczać każde żądanie przez ten sam mechanizm wyszukiwania.

Nie oznacza to jednak, że każda funkcja adaptacyjna jest agentic. Deterministyczny router, który kieruje identyfikatory plików do wyszukiwania leksykalnego, a pytania koncepcyjne do wyszukiwania wektorowego, nadal może być stałym programem, nawet jeśli korzysta z wielu metod wyszukiwania.

Ocena dowodów i przeformułowywanie zapytań tworzą iteracyjną pętlę

Agentic RAG staje się zasadniczo czymś innym, gdy wynik jednego wyszukiwania zmienia kolejne działanie. Słabe dowody mogą wywołać następne zapytanie, wyszukiwanie w nowym źródle lub przeformułowane zapytanie, zamiast trafiać bezpośrednio do etapu generowania.

Agenticzna pętla wyszukiwania może decydować, kiedy i jak wyszukiwać w miarę rozwoju zadania.

W przypadku prywatnego wyszukiwania taka pętla może pomóc rozwiązać pytanie, które zaczyna się szeroko, a następnie po ujawnieniu przez pierwsze dowody brakującego identyfikatora zawęża się do konkretnej faktury z określoną datą, nagrania z kamery lub pliku konfiguracyjnego.

Koszt polega na tym, że ocena musi teraz analizować przebieg działań, a nie tylko jedną uporządkowaną listę wyników. Błędna odpowiedź może wynikać z nieudanego przeformułowania zapytania, wyboru niewłaściwego narzędzia, przedwczesnego zakończenia lub błędu wyszukiwania na późniejszym etapie pętli.

-15% OFF

To przestaje być proste wyszukiwanie, gdy wyszukiwanie staje się stanowym procesem decyzyjnym

Wyraźna granica nie przebiega w miejscu, w którym w potoku pojawia się LLM, ponieważ prosty RAG już wykorzystuje go do generowania. Granica pojawia się wtedy, gdy system utrzymuje stan pośredni i korzysta z decyzji sterowanych przez model, aby wybierać lub powtarzać działania związane ze zbieraniem dowodów.

Kontrola i autonomia agenta pozwalają odróżnić bardziej rozbudowane architektury agentic retrieval od stałych potoków.

Gdy system może zaplanować sekwencję wyszukiwania, wywołać kilka narzędzi, zachować obserwacje i zdecydować, czy dowody są wystarczające, kwestie operacyjne, takie jak limity wykonania, autoryzacja i możliwość śledzenia działań, stają się częścią projektu wyszukiwania.

Potok wieloetapowy nie jest automatycznie agentic, jeśli każda gałąź jest zakodowana na stałe. Kluczową właściwością jest adaptacyjne podejmowanie decyzji, a nie sama liczba komponentów.

Korzystaj z Agentic RAG tylko wtedy, gdy adaptacyjne wyszukiwanie uzasadnia swój koszt

Wyszukiwanie dokumentów rodzinnych, które niezawodnie odpowiada na pytania na podstawie jednego indeksu, niewiele zyskuje dzięki pętli agenta. Większa autonomia oznacza więcej tokenów, większe opóźnienia, konieczność przechowywania stanu, dostęp do narzędzi oraz nowe sposoby zbyt wczesnego zakończenia wyszukiwania lub podążania za nieistotnymi dowodami.

Agentic retrieval sprawdza się najlepiej, gdy pytania są różnorodne, jakość dowodów trzeba oceniać w trakcie działania lub kilka prywatnych źródeł wymaga różnych strategii wyszukiwania. Może też pomóc, gdy w pierwszym zapytaniu brakuje jednostki lub daty potrzebnej do dokładnego wyszukania.

Utrzymuj prostą ścieżkę jako domyślną i kieruj trudne przypadki do ścieżki agentic, gdy mierzalna ocena wykaże lepsze pokrycie dowodami. Agentic RAG jest przydatny dlatego, że może zmienić plan wyszukiwania, a nie dlatego, że każdy problem związany z wyszukiwaniem wymaga większej autonomii.

Planowanie wieloetapowe i powtarzane wyszukiwanie mogą zwiększyć zużycie tokenów i opóźnienia przed ukończeniem odpowiedzi, dlatego adaptacyjna ścieżka powinna uzasadniać dodatkową pracę na rzeczywistym zbiorze testowym prywatnego wyszukiwania.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.