Gdzie pipeline’y RAG działają ślepo: mapowanie niepowodzeń na wzorce agentowe
Dowiedz się, który wzorzec agentic RAG pasuje do danego problemu – od przepisywania zapytań i korygujących rozwiązań awaryjnych po routowanie, ocenę odpowiedzi, przegląd przez ludzi, nadzór oraz planowanie.
Źródła: Your RAG Pipeline Doesn’t Need More Retrieval, It Needs Better Decisions
Standardowa procedura generacji wzbogaconej o wyszukiwanie to prosta sekwencja: wyszukiwanie, generowanie, odpowiadanie. Nadaje się do demonstracji, ale pytania w warunkach produkcyjnych szybko ujawniają jej słabe strony. Narzędzie do wyszukiwania zwraca nieistotne fragmenty, użytkownik formułuje pytanie w sposób, którego nigdy nie używają dokumenty, odpowiedź w ogóle nie znajduje się w indeksie lub model pisze coś, czego tekst znaleziony faktycznie nie potwierdza. Dodawanie więcej dokumentów do promptu nic z tego nie naprawia, ponieważ problemem nie jest ilość kontekstu, lecz brak decyzji co robić dalej.
To właśnie warstwa podejmowania decyzji jest tym, co ludzie rozumieją pod pojęciem agentic RAG. Ten przewodnik traktuje ją jako zbiór celowanych odpowiedzi na konkretne rodzaje awarii, a nie jako pojedynczą architekturę, abyś mógł przeanalizować swój własny proces, znaleźć etap, w którym obecnie działa ślepo, i wybrać najprostszy wzorzec, który temu zaradzi.
Dlaczego pipeline typu one-shot zawodzi
Konwencjonalna aplikacja RAG wykonywać określoną sekwencję działań. Bierze pytanie, przeprowadza wyszukiwanie podobieństw w bazie wektorowej, zachowuje najlepsze wyniki, przekazuje je modelowi LLM i zwraca to, co ten model generuje. Ukrytym założeniem jest, że krok wyszukiwania się udał.
Gdy to założenie zostaje złamane, nic w całym pipeline’u tego nie zauważa:
- Nieodpowiednie dokumenty i tak są przekazywane modelowi, który próbuje na ich podstawie udzielić odpowiedzi.
- Zapytanie, którego słownictwo nie odpowiada dokumentom, dostarcza niewiele wartościowych informacji.
- Jeśli baza wiedzy po prostu nie zawiera odpowiedzi, system nie ma żadnej alternatywnej ścieżki.
Korzystną zmianą perspektywy jest przestanie zadawania pytań tylko o to, jak poprawić proces wydobywania informacji, a zamiast tego pytanie o to, co system powinien robić, gdy wydobywane dane nie są wystarczająco dobre. Każdy z poniższych wzorców stanowi odpowiedź na jakąś wersję tego drugiego pytania. Jeśli chcesz szerszego porównania architektur wydobywania informacji przed przejściem do poszczególnych wzorców, zapoznaj się z RAG vs agentic RAG vs graph RAG.
Ocena jakości wydobywanych informacji i przepisanie zapytania
Weźmy na przykład pytanie „Jak LangGraph radzi sobie z utrzymywaniem danych?”. Załóżmy, że narzędzie do wydobywania informacji zwraca pięć fragmentów, a tylko jeden z nich jest istotny. Liniowa ścieżka przekazuje wszystkie pięć fragmentów i pozostawia modelowi zadanie ich uporządkowania, co osłabia wartość użytecznych dowodów i prowadzi do zamieszania.
W przepływie pracy opartym na agentach najpierw wprowadzana jest etap oceny. Osoba oceniająca, często to małe wezwanie modelu LLM z kryteriami typu tak/nie, decyduje, czy uzyskane dokumenty są wystarczająco istotne, aby odpowiedzieć na pytanie. Jeśli nie są, przepływ pracy nie polega jedynie na ponownym wyszukiwaniu z tym samym tekstem. Generuje się ulepszona zapytanie, oparta na wynikach pierwszej próby, a następnie dokonuje się ponownego wyszukiwania. Powstały cykl wygląda następująco:
- wyszukiwanie
- ocena wyników
- przepisanie zapytania, jeśli wyniki są niewystarczające
- ponowne wyszukiwanie
Sam cykl nie jest najważniejszą częścią. Kluczowe jest to, aby system potrafił rozpoznać, że jego pierwsza próba była niewystarczająca. W praktyce potrzebna jest również warunek zatrzymania, np. maksymalna liczba przepisania zapytania, aby pytanie, na które indeks nie może odpowiedzieć, nie krążyło w nieskończoność.
Przechodzenie na alternatywę, gdy indeks nie ma odpowiedzi
Ponowne sformułowanie pomaga tylko wtedy, gdy informacja istnieje gdzieś w twoim korpusie. Często tak nie jest. Wyobraź sobie asystenta opartego na dokumentacji zebranej miesiąc temu, a użytkownik pyta o funkcję ogłoszoną wczoraj. Żadne przerabianie zdań nie pomoże znaleźć dokumentu, który nigdy nie został skatalogowany.
RAG korygujące rozwiązuje ten problem. Po ocenie pobranych dokumentów proces przetwarzania traktuje niewystarczający wynik jako sygnał do skorygowania kursu, na przykład poprzez zapytanie w innej bazie danych, takiej jak wyszukiwarka internetowa. Liniowy proces pobierania, a następnie generowania zmienia się na:
- pobieranie
- ocena dokumentów
- korekta, jeśli ocena jest niska
- generowanie
"Poprawny" jest celowo szeroko zdefiniowany. W zależności od zastosowania może oznaczać przepisanie zapytania, skonsultowanie się z innym źródłem lub podjęcie innej akcji. Kluczową cechą jest to, że nieudana próba pobrania informacji powoduje przejście na inną ścieżkę zamiast dostarczenia słabej odpowiedzi. Pamiętaj, że dodanie alternatywy internetowej zmienia model zaufania: publiczne treści internetowe są mniej starannie przygotowywane niż twoja własna dokumentacja, więc warto oznaczać lub filtrować odpowiedzi oparte na nich.
Kierowanie każdego pytania do odpowiedniego źródła
Kolejnym domyślnym założeniem w podstawowym RAG jest to, że każde pytanie powinno trafić do tego samego narzędzia do wyszukiwania informacji. Wiele rzeczywistych systemów posiada jednocześnie kilka źródeł wiedzy: wewnętrzną dokumentację firmy, publiczne dokumentacje produktów, jeden lub więcej magazynów wektorowych oraz bezpośrednie wyszukiwanie w internecie.
Tego rodzaju źródła nie są wzajemnie zamienne. Na pytanie dotyczące wewnętrznej polityki HR nie powinno się odpowiadać na podstawie danych dostępnych publicznie w Internecie. Pytanie o wersję biblioteki wydanej w zeszłym tygodniu nie powinno polegać wyłącznie na bazie danych wektorowych utworzonej przed tym wydaniem.
Adaptive RAG wprowadza decyzję o kierunku działania na początku procesu. Zanim system pobierze jakiekolwiek dane, klasyfikuje pytanie i określa, które źródło najlepiej nadaje się do jego odpowiedzi, a następnie ocenia kontekst pochodzący z tego źródła. Ścieżka pobierania danych jest dobierana indywidualnie dla każdego pytania, a nie jest stała dla wszystkich. System kierowania może być tak prosty jak prośba o klasyfikację lub zestaw reguł; nie musi być skomplikowany, aby wykluczyć całą kategorię błędnych odpowiedzi pochodzących z niewłaściwych źródeł.
Kontrola odpowiedzi, a nie tylko dokumentów
Lekki błąd jest łatwy do przeoczenia: doskonałe odnalezienie informacji nie gwarantuje dobrego odpowiedzi. Model może otrzymać dokładnie te właściwe fragmenty, a mimo to wygenerować odpowiedź, która wykracza poza nie lub odbiega od pytania.
Rozwiązaniem jest ocenianie również wyniku generowania. Po stworzeniu odpowiedzi proces pracy agenta może zadać następujące pytania:
- Czy każde twierdzenie w odpowiedzi ma podstawy w odnalezionym kontekście?
- Czy odpowiedź dotyczy tego, o co faktycznie pytał użytkownik?
- Czy model dodał informacje, których kontekst nie potwierdza?
Jeśli odpowiedź zawiedzie, proces może ją poprawić lub wygenerować na nowo. Dzięki temu mamy dwa odrębne sprawdzenia, które warto traktować oddzielnie: czy udało się pobrać właściwe informacje oraz czy te informacje zostały prawidłowo wykorzystane. Ich rozdzielenie ułatwia również debugowanie, ponieważ niepowodzenie można przypisać etapowi pobierania danych lub etapowi generowania, zamiast mówić po prostu „bot się pomylił”. Artykuł na temat oceny RAG według etapu niepowodzenia rozwija tę koncepcję.
Pauza w oczekiwaniu na decyzję człowieka
Niektóre decyzje nie powinny być podejmowane automatycznie. Typowe sytuacje wymagające ludzkiej oceny to:
- dowody, które są niejednoznaczne lub sprzeczne
- odpowiedzi, które wymagają formalnej aprobaty przed użyciem
- niska pewność ze strony własnych oceniających systemu
RAG z udziałem człowieka umieszcza punkt kontrolny w procesie pracy, gdzie ktoś może zatwierdzić wynik, go odrzucić lub go edytować przed kontynuacją wykonywania zadań. Nie jest to odstąpienie od automatyzacji – system nadal sam zajmuje się rutynowymi przypadkami i przenosi do dalszej obrady tylko te, które rzeczywiście wymagają oceny, co zazwyczaj stanowi o wiele lepsze wykorzystanie czasu recenzentów niż sprawdzanie wszystkiego lub niczego. Ramy orkiestracji oparte na grafach, takie jak LangGraph, doskonale nadają się do tego, ponieważ mogą przechowywać stan procesu pracy w punkcie kontrolnym i wznowić jego działanie po otrzymaniu odpowiedzi.
Rozdzielenie pracy między specjalistycznymi agentami
Gdy procesy pracy stają się coraz bardziej złożone, trudno jest zarządzać jednym agentem, który przejmuje wszystkie obowiązki, oraz skutecznie mu dawać instrukcje. Niektóre problemy naturalnie dzielą się na konkretne role: pozyskiwanie informacji, badania, ocena itp.
W architekturze z kilkoma agentami istnieje specjalny nadzorca, którego zadaniem jest koordynacja. Nadzorca decyduje, który specjalista powinien wykonać następny krok, a każdy specjalista zajmuje się wąskim zakresem zadań. Celem nie jest dodawanie agentów bez powodu; każdy dodatkowy agent powoduje opóźnienia, wzrost kosztów oraz konieczność utrzymywania dodatkowych instrukcji. Taka metoda okazuje się korzystna, gdy problem faktycznie wymaga kilku kroków lub specjalistycznych umiejętności, a instrukcje dla jednego agenta stają się zbyt długim i trudnym do zarządzania wykazem szczególnych przypadków.
Równoległe uruchamianie niezależnego pozyskiwania informacji
Nie każdy krok musi czekać na poprzedni. Jeśli odpowiedź wymaga informacji z kilku niezależnych źródeł, przeprowadzanie zapytań do nich jeden po drugim – najpierw do źródła A, potem B, następnie C – i dopiero później udzielanie odpowiedzi marnuje czas.
W modelu równoległym te zapytania są wysyłane jednocześnie: pytanie jest kierowane równocześnie do A, B i C, a ich wyniki są łączone przed sformułowaniem odpowiedzi. Niezależne zadania pobierania lub przetwarzania danych przebiegają równolegle i są łączone na końcu. Dzięki temu złożone procesy mogą być zarówno szybsze, jak i łatwiejsze do zorganizowania, ponieważ każda gałąź jest samodzielna. Wadą jest to, że etap łączenia musi radzić sobie z nakładającymi się lub sprzecznymi wynikami oraz musi podjąć decyzję w przypadku awarii lub wygaśnięcia czasu oczekiwania jednej z gałęzi.
Planowanie przed wykonaniem
Część pytań w ogóle nie może zostać odpowiedziana przy jednej tylko wyszukiwaniu. Wymagają one kilku poszukiwań, pośrednich transformacji lub etapów rozumowania, których kolejność ma znaczenie.
Metoda planowania i wykonywania w RAG radzi sobie z tym, oddzielając proces myślenia od samego wykonywania zadania. Przepływ operacji wygląda następująco:
- otrzymanie pytania
- stworzenie planu
- wykonanie zaplanowanych kroków
- ocena wyników
- danie odpowiedzi
Planista określa, co musi zostać zrobione; sam proces wykonywania zajmuje się poszczególnymi krokami. Jest to szczególnie przydatne w przypadku pytań wieloetapowych, takich jak porównania między kilkoma dokumentami, gdy bezpośrednie korzystanie z narzędzi często skutkuje powierzchownymi lub niekompletnymi odpowiedziami. Plan umożliwia również sprawdzenie, co poszło nie tak w przypadku błędu, co jest trudniejsze przy agencie, który improwizuje na każdym kroku.
Co tak naprawdę sprawia, że system RAG ma charakter agencji
Zawołanie modelu LLM lub określenie czegoś jako agenta samo w sobie nie czyni systemu agentem. Kluczową cechą jest to, że system potrafi ocenić swoją sytuację i wybrać następny krok. Stała ścieżka przetwarzania zakłada najpierw pozyskanie informacji, a następnie udzielenie odpowiedzi. System agentowy może zadać sobie serię pytań:
- Czy w ogóle potrzebne jest pozyskiwanie informacji do tego pytania?
- Czy to, co otrzymał, było rzeczywiście przydatne?
- Czy powinien ponownie wyszukać informacje przy użyciu innej zapytania?
- Czy inny źródło byłoby lepszym wyborem?
- Czy odpowiedź jest poparta dowodami?
- Czy potrzebna jest interwencja człowieka?
- Czy powinien przejąć kontrolę inny, specjalistyczny agent?
- Czy zaplanowanie zadań wcześniej przyniosłoby lepszy rezultat?
Każde pytanie odpowiada jednemu z powyższych wzorców, dlatego pomocne jest postrzeganie agentic RAG jako zestawu narzędzi do podejmowania decyzji, a nie jako jednolitego rozwiązania. Te wzorce naturalnie odpowiadają orkiestracji grafów: ocena i kierowanie zapytaniami stają się brzegami warunkowymi, pętle przekształcają się w cykle z licznikiem stanu, ludzka weryfikacja staje się przerwą, a rozgałęzienia – równoległymi gałęziami, które się łączą.
Połącz wzorzec z awarią
Żadna aplikacja nie potrzebuje wszystkich tych wzorców, a każdy z nich zwiększa opóźnienie, koszty oraz liczbę elementów ruchomych. Wybierz rozwiązanie w zależności od rzeczywistej awarii, którą zaobserwowano:
- Jeśli głównym problemem jest jakość pozyskiwania informacji, wystarczy przepisanie zapytania przy użyciu narzędzia do oceny trafności.
- Jeśli baza wiedzy ma luki, dodaj alternatywny źródło informacji.
- Jeśli używasz kilku źródeł wiedzy, dodaj mechanizm kierowania zapytaniami.
- Jeśli niektóre decyzje wymagają nadzoru, dodaj punkt kontroli realizowany przez człowieka.
Podsumowanie
Pytanie, które prowadzi do użytecznych ulepszeń, nie brzmi jak zrobić system RAG bardziej autonomicznym. Chodzi o to, gdzie system obecnie działa ślepo: przekazuje dokumenty, których nikt nie sprawdził, wyszukuje w niewłaściwym źródle, ufa nieuzasadnionej odpowiedzi lub podejmuje decyzję, którą powinien podjąć człowiek. Wyposaż proces w narzędzia, aby móc zobaczyć, które z tych błędów występują najczęściej, dodaj najprostszy punkt decyzyjny, który pozwoli je wykryć, a następnie ponownie sprawdź efekty przed dodaniem kolejnego elementu.