Możesz dać agentowi całą wiedzę z góry.
Albo dać mu ją dokładnie wtedy, kiedy jej potrzebuje.
W poprzednim wpisie jedna z pięciu warstw okna dostała werdykt „prawie zawsze pobierać na żądanie, nie trzymać". To warstwa retrievalu — wiedzy, której agent nie ma w sobie ani w pamięci: dokumentacji, bazy wiedzy, danych produktowych, polityk. Ten wpis jest o tym werdykcie: dlaczego pobieranie na żądanie prawie zawsze wygrywa z ładowaniem wszystkiego z góry, i kiedy to „prawie" ma znaczenie.
Mechanikę samego pobierania — czym jest RAG, dlaczego powstało i kiedy ma sens — rozkłada artykuł serii o RAG. Tu patrzymy na retrieval z jednej, konkretnej strony: co i kiedy ląduje w oknie kontekstu.
Dwa podejścia do tej samej wiedzy
Masz bazę wiedzy — powiedzmy sto stron dokumentacji produktu. Agent ma odpowiadać na jej podstawie. Są dwa sposoby, żeby ta wiedza trafiła do modelu.
Preload — wszystko z góry. Wrzucasz całą dokumentację do okna na starcie i zostawiasz ją tam. Agent „ma wszystko". Proste do zbudowania, kuszące w swojej oczywistości.
Just-in-time — na żądanie. Trzymasz dokumentację poza oknem. Gdy konkretny krok wymaga konkretnej wiedzy, agent pobiera tylko ten fragment, który jest istotny, i tylko na ten krok. Okno zostaje chude.
Na pierwszy rzut oka preload wygląda bezpieczniej — „przecież lepiej, żeby miał komplet". Praktyka mówi odwrotnie. I to z powodów, które znasz już z dwóch poprzednich wpisów.
Dlaczego preload przegrywa
Trzy ceny ładowania wszystkiego z góry — i wszystkie trzy widzieliśmy już wcześniej, tylko z innej strony.
Zabija budżet okna. Sto stron dokumentacji w oknie to dziesiątki tysięcy tokenów, które siedzą tam przy każdym obrocie pętli — niezależnie od tego, czy bieżący krok ich potrzebuje. To dokładnie okno traktowane jak worek, tylko na sterydach.
Wywołuje context rot. Im więcej nieistotnej dokumentacji w oknie, tym trudniej modelowi znaleźć ten jeden akapit, który dotyczy bieżącego pytania. Sygnał tonie w komplecie. Agent „ma wszystko" i właśnie dlatego trafia gorzej.
Starzeje się. Wiedza wrzucona na starcie jest zamrożona w stanie z momentu startu. Jeśli w trakcie długiego zadania coś się zmieni — stan zamówienia, dostępność, cena — preload tego nie wie. Pobieranie na żądanie sięga po aktualny stan w momencie, w którym jest potrzebny.
Pętla agenta sprawia, że just-in-time jest wręcz naturalne. Agent i tak przy każdym kroku decyduje, co zrobić dalej — więc „pobierz to, czego ten krok wymaga" to po prostu jedna z jego akcji, a nie osobna mechanika doklejona z boku.
Retrieval jest tak dobry, jak to, co zwróci
Jest jedno „ale", którego nie wolno przemilczeć. Preload jest głupi, ale przewidywalny — agent dostaje całość, więc istotny fragment na pewno tam jest, choćby utopiony. Just-in-time jest mądrzejszy, ale zależy od trafności pobierania.Jeśli zapytanie do bazy wiedzy zwróci nie ten fragment, agent dostanie do okna kontekst, który wygląda sensownie, a prowadzi go na manowce.
To przesuwa ciężar: jakość kontekstu staje się jakością retrievalu. Garbage in, garbage context. Dlatego przy podejściu just-in-time inwestycja idzie w to, jak agent pyta i jak baza odpowiada — żeby zwracała trafnie, zwięźle i to, co istotne. To znów odsyła do mechaniki RAG: dobór tego, co wraca, jest osobnym rzemiosłem.
Praktyczna konsekwencja: pobieraj fragmenty, nie całe dokumenty. Zwrócenie całej strony dokumentacji „bo gdzieś tam jest odpowiedź" to preload tylnymi drzwiami — przenosisz problem zapchanego okna z etapu startu na etap pobierania. Dobry retrieval oddaje akapit, nie rozdział.
Podejście hybrydowe — bo „prawie zawsze" to nie „zawsze"
Werdykt z C2 brzmiał „prawie zawsze pobierać". To „prawie" ma sens. Nie wszystko opłaca się pobierać za każdym razem.
Sensowny układ dla większości agentów jest hybrydowy: mały, stabilny rdzeń w oknie na stałe + reszta just-in-time.Do rdzenia trafia to, czego agent potrzebuje praktycznie zawsze i co się nie zmienia — kluczowe reguły, podstawowy kontekst zadania. Wszystko, co jest potrzebne czasem albo co się zmienia, zostaje poza oknem i jest pobierane na żądanie.
Pytanie, które rozstrzyga, co idzie do rdzenia, to dokładnie heurystyka z C2: czy model potrzebuje tego przy każdym kroku? Jeśli tak — rdzeń. Jeśli „czasem" — retrieval. Hybryda to nie kompromis z lenistwa, tylko świadome rozłożenie: stałe na stałe, zmienne na żądanie.
Jak to wygląda w n8n
W n8n różnica jest namacalna. Wersja preload: węzeł, który na starcie wczytuje cały dokument / cały arkusz / całą tabelę i podpina to pod wejście modelu przy każdym kroku przepływu. Działa na małych danych, puchnie i gnije na większych.
Wersja just-in-time: model (albo logika przepływu) najpierw ustala, czego potrzebuje, a potem osobny węzeł pobiera tylko to — konkretny rekord, konkretny fragment, wynik konkretnego zapytania — i dopiero ten wynik wraca do okna. Więcej węzłów, więcej myślenia o tym, „kto pyta o co i kiedy" — ale chude okno, świeże dane i niższy rachunek przy każdym obrocie.
Moment, w którym przestajesz wczytywać wszystko pod wejście „bo może się przyda", a zaczynasz projektować kiedy i co przepływ pobiera — to jest moment, w którym retrieval przestaje być wczytywaniem pliku, a staje się składaniem kontekstu.
Co z tego wynika
Retrieval to nie „danie agentowi dostępu do wiedzy". To decyzja, która wiedza trafia do okna i w którym momencie.Preload odpowiada na to pytanie raz, na starcie, dla wszystkiego naraz — i płaci budżetem, trafnością i świeżością. Just-in-time odpowiada na nie krok po kroku, dla tego, co akurat potrzebne — i wygrywa wszędzie tam, gdzie wiedzy jest dużo albo gdzie się zmienia.
Zasada do zabrania: nie ładuj wiedzy do agenta — daj mu sposób, żeby sięgał po nią wtedy, gdy jej potrzebuje. A skoro już przy tym jesteśmy: część kontekstu, której nie da się po prostu „pobrać na nowo", bo to historia własnych kroków agenta — wymaga osobnego podejścia. O tym, jak nie gubić wątku, gdy ta historia rośnie, jest następny wpis tej kategorii: kompakcja kontekstu.
Pojęcia ze słownika: Just-in-time retrieval · Grounding · Okno kontekstu · Context rot · Budżet tokenów
