Retrywalizacja oparta na agentach i wystarczający kontekst: gdy RAG nie wie wystarczająco dużo

Poszukiwanie wektorowe nie jest główną przyczyną awarii większości systemów RAG. Prawdziwym problemem w produkcji jest model, który odpowiada, mimo że brakuje mu wystarczających dowodów. Nie chodzi o sytuację, gdy nie znajduje się nic – system zazwyczaj dostarcza jakieś informacje, fragmenty wydają się istotne dla tematu, a odpowiedź jest płynna i pewna siebie. Mimo to jest ona niekompletna, ponieważ potrzebne fakty znajdują się w kilku dokumentach, systemach, tabelach, zgłoszeniach, instrukcjach, dziennikach lub relacjach grafowych.

Klasyczny schemat polega na jednej rundzie przetwarzania:

User question → embed query → retrieve top-k chunks → send to LLM → generate answer

To w porządku w przypadku prostych pytań, ale pytania typu enterprise rzadko takie są. Zasada znajduje się w jednym dokumencie, a jej wyjątek w innym. Ticket opisuje incydent, notatka wydawnicza wyjaśnia zmienione zachowanie, wiersz w bazie danych przechowuje aktualny stan, krawędź w grafie pokazuje zależność, tabela w PDF zawiera rzeczywiste dane, a wcześniejsza rozmowa rejestruje to, co użytkownik już próbował. Jeśli pobrać tylko kilka pierwszych podobnych fragmentów, model odpowiada zbyt szybko. RAG nie umarło – musi potrafić rozpoznać, gdy brakuje mu wystarczających danych.

Przedwczesne odpowiedzi

Wiele systemów RAG zawodzi w sposób niewidoczny. Nigdy nie mówią, że brakuje wystarczających dowodów. Przekazują odpowiedź – płynną, ustrukturyzowaną i w większości wiarygodną – ale błędną.

Załóżmy, że pracownik działu wsparcia zostaje zapytany, dlaczego eksport w Acme przestał działać po migracji przestrzeni roboczej. Prosty mechanizm wyszukiwania znajduje jedną stronę z instrukcjami naprawczymi i stwierdza, że brakuje uprawnień. Być może to częściowo prawda. Pełna odpowiedź wymaga odniesienia się do zapisów migracji w Acme, notatki o zmianach w uprawnieniach do eksportu, zgłoszenia z zeszłego tygodnia, raportu o incydencie wewnętrznym, flag funkcjonalnych konta oraz diagramu zależności wskazującego na usługę eksportu. Jeden dokument nigdy nie mógłby pomieścić tego wszystkiego, dlatego proces wyszukiwania musi funkcjonować bardziej jak działanie agenta.

Co oznacza wystarczający kontekst

Wystarczający kontekst oznacza, że dostępne dowody umożliwiają udzielenie pewnej odpowiedzi. Nieskojarzone ze sobą fragmenty, wysoki wynik podobieństwa lub pięć zwróconych dokumentów nie mają znaczenia. Przed generowaniem system powinien sprawdzić, czy posiada politykę, wyjątki, aktualny stan, autorytatywne dane, powiązania między entytetami, informacje wystarczające do wyjaśnienia przyczyny, a nie tylko objawu, oraz sposób cytowania wyniku. Jeśli czegoś brakuje, powinien wrócić i przeszukać ponownie. To właśnie stanowi przejście od klasycznego RAG do agentic retrieval.

Od top-k do poszukiwania dowodów

Klasyczny RAG traktuje proces pozyskiwania informacji jako pojedynczy krok – pozyskuje dane raz i udziela odpowiedzi. Agentic retrieval traktuje go jako proces pracy:

Retrieve once → answer

Plan → retrieve → inspect → judge evidence → retrieve again → answer

Nic nie zobowiązuje modelu do odpowiadania na podstawie tego, co wróciło pierwsze. Działa raczej jak analityk badawczy, który szuka informacji, otwiera dokumenty, porównuje je, analizuje powiązania, weryfikuje dane i odpowiada dopiero wtedy, gdy kontekst jest wystarczający.

Dlaczego agenci zwiększają stopień ryzyka

Chatbot odpowiada na pytanie. Agent podejmuje decyzje: wybiera narzędzia, wywołuje API, aktualizuje dane, składa zgłoszenia, poleca działania, prosi o zatwierdzenie lub kontynuuje proces przez wiele kroków. Niedoskonały kontekst wtedy rozprzestrzenia się dalej:

Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action

Agent produkcji nie powinien jedynie przedstawiać podobnego dokumentu. Powinien być w stanie stwierdzić, że odnalazł polisę, wyjątek, stan konta w czasie rzeczywistym oraz powiązany incydent, i że te dowody rozstrzygają kwestię. To zupełnie inna architektura.

Kierunek rozwoju agentowego wyszukiwania

Nowsze badania nad RAG i grafami wiedzy wskazują na wyszukiwanie kontrolowane przez agenta, świadome grafu, oceniane na podstawie dowodów i wspierane pamięcią. Nie każdy system potrzebuje ogromnego grafu wiedzy, ale warstwa wyszukiwania wymaga większej inteligencji niż proste umieszczenie zapytania i zwrócenie najlepszych wyników. Istotne są kilka kierunków rozwoju.

Wyszukiwanie międzykorporum

Wiedza przedsiębiorstwa nie znajduje się w jednej uporządkowanej bazie danych wektorowych. Jest rozproszona w Google Drive, Confluence, Notion, Slack, Jira, GitHub, magazynach, ticketach obsługi klienta, panelach kontrolnych, wewnętrznych API, dokumentacji produktu oraz instrukcjach w formacie PDF. Dobry system musi decydować, gdzie najpierw szukać. Planer wyszukiwania może sklasyfikować pytanie jako dotyczące polityki, zachowania produktu, specyfiki klienta, incydentu, wskaźnika finansowego lub zależności technicznej i skierować je odpowiednio. Szukanie we wszystkim jest kosztowne, a szukanie w niewłaściwym miejscu jest jeszcze gorsze.

Wyszukiwanie jako narzędzia

Jeden przydatny model przedstawia wyszukiwanie jako kontrolowany zestaw narzędzi zamiast stałego wyniku:

search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)

To odzwierciedla ludzkie dochodzenie: wyszukiwanie, otwieranie obiecujących wyników, analiza poszczególnych części, udoskonalanie zapytania oraz porównywanie dowodów. Model rozumowania kieruje tym procesem, ale tylko w ramach ograniczonego zestawu narzędzi, co zapewnia elastyczność bez nieograniczonego dostępu.

Przechodzenie po grafie wiedzy

Wyszukiwanie wektorowe znajduje teksty semantycznie podobne, natomiast wiele zadań praktycznych opiera się na relacjach między elementami. Którzy klienci są dotknięci tą usługą? Które produkty zależą od tej API? Która polityka obowiązuje w tym regionie? Która implementacja spowodowała ten incydent? To są pytania dotyczące kontekstu powiązań, a nie podobieństwa. Graf może łączyć entity bezpośrednio:

Customer → Workspace → Feature Flag → Service → Incident → Release Note

Agent może klikać te linki zamiast liczyć na to, że odpowiedni fragment pojawi się w górnych wynikach. To dowód na to, że chodzi tu bardziej o nawigację niż o wyszukiwanie. Wykorzystaj to tam, gdzie istotne są relacje pomiędzy informacjami, a pomijaj to, gdy brzmi to jedynie jak coś zaawansowanego.

Ocena wystarczalności dowodów

Po znalezieniu informacji system powinien ocenić, czy dowody są wystarczające. Czy bezpośrednio odpowiadają na pytanie? Czy brakuje jakichś entytetów, dat lub źródeł? Czy źródła są sprzeczne? Czy źródło ma rzeczywistą autorytet? Czy odpowiedź można zacytować? Gdy dowody są słabe, system kontynuuje poszukiwania:

Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source

Pętla zapobiega przedwczesnym odpowiedziom i ułatwia debugowanie, ponieważ można zobaczyć, dlaczego agent ponownie przeprowadził wyszukiwanie.

Grafy kontekstowe i pamięć agenta

RAG zazwyczaj obsługuje wiedzę z zewnątrz, ale agenci potrzebują również pamięci: tego, o co pytał wcześniej użytkownik, czego szukano, jakie dowody zostały przyjęte, co zostało zdecydowane oraz jakie założenia pozostają otwarte. Prosty bufor rozmowy nie wystarczy. Lepszy projekt łączy pamięć z entytetami i decyzjami, dzięki czemu sam ślad rozumowania staje się pamięcią:

User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch

Kiedy następnym razem pojawi się podobny problem, agent nie musi zaczynać od zera, co ma znaczenie dla agentów działających przez długi czas.

RAG wielomodalne i rozumiejące dokumenty

Wielka część wiedzy korporacyjnej nie ma postaci zwykłego tekstu. Znajduje się ona w plikach PDF, tabelach, zrzutach ekranu, diagramach, wzorach, skanach, wykresach, prezentacjach i formularzach. Zwykłe dzielenie na fragmenty niszczy strukturę: tabele zamieniają się w chaotyczny tekst, wzory tracą swój kontekst, diagramy stają się domysłami OCR, a sekcje są oddzielane od opisów je objaśniających. System rozumiejący dokumenty potrafi analizować tekst, tabele, rysunki, układ, hierarchię nagłówków, opisy, pola formularza oraz sposób, w jaki elementy wizualne są powiązane z tekstem. Najbardziej od niego zależą dziedziny takie jak finanse, opieka zdrowotna, przemysł, prawo, ubezpieczenia oraz dokumentacja techniczna.

Budżety narzędzi i kontekstu

Narzędzia również zużywają zasoby kontekstowe. Gdy załadujesz dziesiątki narzędzi do wyszukiwania, analizy grafów, pracy z bazami danych oraz wyszukiwania, ich schematy konkurują z dowodami:

Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window

Agentic RAG wymaga zatem środowiska działania świadomego budżetu, które decyduje, jakie narzędzia pokazać, ile fragmentów włączyć, czy podsumować wyniki narzędzi oraz, co najważniejsze, kiedy przestać. Celem jest uzyskanie wystarczającej ilości informacji, a nie ich nieskończone gromadzenie.

Architektura produkcyjna

W całości system produkcyjny do agentic retrieval przypomina bardziej płaszczyznę sterowania niż łańcuch przetwarzania:

User Question
   ↓
Intent + Risk Classifier
   ↓
Retrieval Planner
   ↓
Source Router
   ├── Enterprise Search
   ├── Vector Search
   ├── Keyword Search
   ├── Knowledge Graph
   ├── Structured Data
   ├── Document Parser
   └── Agent Memory
   ↓
Evidence Inspector
   ↓
Sufficiency Gate
   ├── If insufficient → refine query / follow graph / open document
   └── If sufficient → generate answer
   ↓
Answer with Evidence Trace

Praktyczna zasada jest prostsza: nie pozwól systemowi RAG udzielać odpowiedzi, dopóki nie ma wystarczających dowodów.

Przypadek Acme, od początku do końca

Gdy zostanie zadaane pytanie, dlaczego eksport nie powiódł się po migracji przestrzeni roboczej, standardowy system RAG pobiera przewodnik rozwiązywania problemów z eksportem oraz FAQ dotyczące migracji i odpowiada, że eksport prawdopodobnie nie powiódł się z powodu braku uprawnień. System agencyjny przeprowadza dochodzenie:

1. Szuka w dokumentacji wsparcia informacji o nieudanych eksportach.
2. Szuka w notatkach wydawniczych zmian związanych z migracją przestrzeni roboczej.
3. Otwiera konfigurację konta klienta.
4. Sprawdza stan flag funkcjonalnych.
5. Szuka w historii incydentów.
6. Śledzi graf zależności od usługi eksportu do usługi uprawnień.
7. Decyduje, czy dowody są teraz wystarczające.
8. Pisze odpowiedź z odniesieniami do źródeł.

Otrzymana odpowiedź brzmi: Acme zostało przeniesione do nowego modelu przestrzeni roboczej, podczas gdy usługa eksportu nadal sprawdzała starszą ścieżkę uprawnień. Flaga przestrzeni roboczej jest włączona, ale polityka eksportu nigdy nie została zaktualizowana, więc rozwiązaniem jest aktualizacja tej polityki dla modelu przestrzeni roboczej. To nie silniejszy model zmienił wynik – lepsze gromadzenie dowodów tak.

Co zbudować najpierw

Jeśli masz już istniejący system RAG, nie buduj wszystkiego od nowa. Postępuj zgodnie z tymi krokami:

1. Dodaj sprawdzenie wystarczalności. Przed generowaniem zapytaj, czy zebrane dowody są wystarczające na to konkretne pytanie, a jeśli nie, przeprowadź kolejne wyszukiwanie lub zadaj użytkownikowi pytanie uzupełniające.
2. Dodaj routowanie źródłowe. Szukanie w każdym źródle za każdym razem jest marnotrawstwem zasobów. Najpierw sklasyfikuj zapytanie: pytania dotyczące polityk trafiają do dokumentów z politykami, problemy klientów do ticketów wraz ze stanem konta, usterki techniczne do dokumentów, logów i grafu usług, a pytania dotyczące metryk do warstwy semantycznej.
3. Dodaj narzędzia do wyszukiwania, takie jak search, open, find, summarize, follow_entity_relation i query_structured_record, aby proces wyszukiwania był iteracyjny.
4. Dodaj przemierzanie grafu, w którym odpowiedzi zależą od właściciela, zależności, linii przekazu, przyczynowości, hierarchii, łączy wieloetapowych lub wyjątków w politykach.
5. Zachowaj strukturę dokumentu. W przypadku plików PDF, raportów, slajdów, tabel i diagramów użyj parsowania uwzględniającego strukturę dokumentu i przechowuj ją zamiast prostego dzielenia na fragmenty.
6. Niech istnieje ślad dowodowy, który rejestruje wyszukiwane źródła, otwierane dokumenty, przyjęte fakty, stwierdzone luki oraz powód, dla którego system uznał, że ma już wystarczająco danych. To właśnie taki zapis buduje zaufanie do systemów agencyjnych typu RAG.

Czego nie należy nadmiernie rozwijać

To może stać się zbyt skomplikowane, a nie każda technika nadaje się do każdego przypadku użycia. Proste wyszukiwanie w FAQ prawdopodobnie nie wymaga grafu wiedzy, dokumenty w formacie prostego tekstu nie potrzebują analizy multimodalnej, interakcje typu „jedno pytanie – jedna odpowiedź” nie wymagają długoterminowej pamięci grafowej, a w pełni wewnętrzne domeny nie potrzebują zewnętrznego wyszukiwania. Należy zadać pytanie, jakiego rodzaju dowody potrzebuje dana sytuacja. W przypadku jednego, uporządkowanego dokumentu wystarczy zwykły system RAG. Gdy odpowiedź wymaga uwzględnienia różnych źródeł, relacji, pamięci oraz aktualnego stanu, to właśnie systemy agencyjne typu RAG uzasadniają swoją złożoność.

Zmiana

Obecny rozwój w obszarze RAG nie polega na zastępowaniu wyszukiwania wektorowego. Działa ono jako narzędzie umożliwiające lepszą kontrolę nad procesem wydobywania informacji. Wyszukiwanie wektorowe nadal ma znaczenie, podobnie jak wyszukiwanie według słów kluczowych. Grafy wiedzy są istotne tam, gdzie istnieją relacje, analiza dokumentów tam, gdzie ma znaczenie ich struktura, a pamięć tam, gdzie agent działa w czasie. Zadaniem w praktyce jest łączenie tych elementów. Następne pokolenie rozwiązań będzie wyglądać inaczej:

Vector DB → top-k chunks → LLM

i tak dalej:

Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer

RAG nie zawodzi tylko wtedy, gdy ładuje złe fragmenty. Zawodzi również, gdy ładuje częściowo przydatne fragmenty i odpowiada zbyt wcześnie. W przypadku prostych pytań metoda top-k może nadal być skuteczna. Natomiast dla zastosowań korporacyjnych, badawczych, obsługi klienta, operacyjnych oraz agentów pracujących z dużą ilością dokumentów konieczny jest silniejszy mechanizm iteracyjny:

plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded

To jest przejście od standardowego RAG do agentic retrieval. Nie dzieje się tak dlatego, że RAG przestało istnieć. Agenci produkcyjne muszą rozpoznawać, gdy nie wiedzą wystarczająco dużo.