Surowy dump z API to nie kontekst.
To materiał, z którego dopiero trzeba kontekst zrobić.
Cztery poprzednie wpisy odpowiadały na pytanie „co i ile” wrzucić do okna. Został ostatni wymiar: w jakiej formie. Bo nawet trafnie dobrany fragment, podany w złym kształcie, model wykorzysta gorzej — albo wcale.
To pytanie pojawia się na dwóch brzegach pętli agenta. Agent woła narzędzie i coś z niego wraca do okna — to brzeg wejścia. Agent produkuje odpowiedź, którą przejmuje kolejny krok albo kolejne narzędzie — to brzeg wyjścia. Oba brzegi rządzą się tą samą zasadą: forma jest częścią kontekstu. Ten wpis jest o obu.
Mechanikę wywoływania narzędzi w pętli rozkłada artykuł serii o tym, jak agent myśli i działa. Tu zajmujemy się tym, co przepływa przez te brzegi — i jak to ukształtować.
Brzeg wejścia: co wraca z narzędzia
Gdy agent odpyta bazę albo uderzy w API, wynik wraca do okna, żeby model oparł na nim następny krok. I tu pojawia się błąd, który widać u każdego początkującego: surowy wynik trafia do okna w całości. Pełny JSON z pięćdziesięcioma polami, gdzie istotne są trzy. Cała odpowiedź API z metadanymi, nagłówkami, paginacją.
To dokładnie to, przed czym ostrzegał wpis o warstwach okna: surowy wynik narzędzia to nie kontekst, to materiał na kontekst. Zanim wróci do modelu, warto go obrobić.
Trzy ruchy, które zamieniają dump w kontekst.
Wytnij nieistotne. Z pięćdziesięciu pól zostaw te, których krok faktycznie potrzebuje. Reszta to budżet okna spalony na metadane i context rot dosypany za darmo.
Opisz, co to jest. Goły ciąg wartości mówi modelowi mniej niż ten sam ciąg z czytelnymi etykietami. Wynik ma być samoopisujący się — żeby model nie musiał zgadywać, czym jest 0.92 ani co znaczy trzecia kolumna.
Streszczaj długie wyniki. Jeśli narzędzie zwraca listę stu rekordów, a krok potrzebuje wniosku z nich — daj wniosek, nie sto rekordów. To ten sam ruch co kompakcja, tylko zastosowany do wyniku narzędzia, nie do historii.
Zasada brzegu wejścia: do okna wraca wynik gotowy do użycia, nie surowiec do przekopania.
Brzeg wyjścia: co model oddaje
Druga strona jest równie ważna, a często pomijana. To, co model produkuje, bardzo często staje się wejściem następnego kroku — innego węzła, innego narzędzia, kolejnej iteracji pętli. Jeśli model oddaje to jako swobodny tekst, następny krok musi ten tekst rozumieć, parsować, zgadywać. A swobodny tekst jest nieprzewidywalny.
Tu wchodzi structured output: zmuszenie modelu, żeby oddawał wynik w ustalonej, sztywnej formie — najczęściej jako JSON o zdefiniowanej strukturze — zamiast jako prozę. Zamiast „Znalazłem trzy hotele, najtańszy to…” model oddaje strukturę z polami nazwa, cena, odległość, którą następny krok przejmuje bez zgadywania.
To rozwiązuje problem, który inaczej rozwiązuje się brzydko: parsowanie prozy regexami. Każdy, kto próbował wyłuskać liczbę ze swobodnej odpowiedzi modelu i trafił raz na „380 zł”, raz na „trzysta osiemdziesiąt złotych”, a raz na „około 380″ — wie, dlaczego struktura wygrywa.
Structured output a namiastka determinizmu
Jest w tym głębszy wątek. LLM jest z natury niedeterministyczny — to samo wejście potrafi dać różne wyjścia. W przepływie, który ma działać powtarzalnie, to problem. Structured output nie usuwa tej niedeterministyczności, ale ją okiełznuje: treść może się wahać, ale kształt jest stały. Pole cena zawsze jest liczbą, zawsze w tym samym miejscu. To jedna z głównych dźwigni budowania powtarzalnych przepływów na nieprzewidywalnym modelu — namiastka determinizmu, o której więcej w eksperymentach na promptujemy.pl.
I jest tu drugi zysk, który spina się z wpisem serii o ewaluacji: strukturę da się sprawdzić. Walidacja, czy cena jest liczbą dodatnią, jest trywialna. Walidacja, czy proza „zawiera sensowną cenę”, jest sama w sobie zadaniem dla modelu. Structured output zamienia kontrolę jakości z domysłu w prosty test.
Kiedy nie przesadzić ze strukturą
Structured output nie jest darmowy i nie jest zawsze właściwy. Dwie sytuacje, w których warto się powstrzymać.
Gdy reasoning ma wartość. Jeśli krok wymaga, żeby model „pomyślał na głos” — przeszedł rozumowanie zanim da wynik — wymuszenie samego JSON-a obcina to myślenie i pogarsza decyzję. Częste rozwiązanie: pozwól na reasoning ipoproś o strukturę na końcu, zamiast zabijać jedno dla drugiego.
Gdy schemat jest zbyt sztywny. Schemat, który nie przewiduje przypadku „nie znaleziono” albo „niepewne”, zmusza model do wciskania rzeczywistości w pola, które do niej nie pasują. Dobry schemat ma miejsce na brak wyniku i na niepewność — inaczej kupujesz przewidywalny kształt za cenę zmyślonej treści.
Struktura jest narzędziem, nie religią. Stosuj ją tam, gdzie wyjście modelu ma być przejęte maszynowo. Odpuść tam, gdzie liczy się rozumowanie albo gdzie wynik czyta człowiek.
Jak to wygląda w n8n
Oba brzegi widać w przepływie wprost. Brzeg wejścia: węzeł narzędzia zwraca surową odpowiedź API, a Ty — zamiast podpinać ją do modelu w całości — wstawiasz krok, który wyciąga i opisuje istotne pola, zanim trafią do węzła z modelem. Brzeg wyjścia: zamiast brać swobodną odpowiedź modelu i parsować ją w kolejnych węzłach, wymuszasz structured output, dzięki czemu następne węzły dostają przewidywalne pola i przepływ przestaje się wykrzaczać na nietypowym sformułowaniu.
Moment, w którym zaczynasz formatować to, co wchodzi, i wymuszać kształt tego, co wychodzi — to moment, w którym przepływ przestaje być „połączonymi węzłami z modelem w środku”, a staje się układem, który działa powtarzalnie.
Co z tego wynika — i co domyka klaster
Forma jest częścią kontekstu. Najtrafniej dobrany fragment, podany jako surowy dump, model wykorzysta gorzej niż mniejszy fragment podany czytelnie. A wyjście modelu bez nałożonej struktury staje się chaotycznym wejściem dla następnego kroku. Oba brzegi okna chcą tego samego: przewidywalnego kształtu.
Tym domykamy bazę context engineeringu. Mamy już komplet: dlaczego prompt to za mało (pillar), okno jako budżet (C1), pięć warstw i decyzja co wpuścić (C2), retrieval just-in-time (C3), kompakcja przy długich przebiegach (C4), dobór przykładów (C5) i — tu — forma na obu brzegach. Razem to jeden zestaw umiejętności: agent jest tak dobry, jak kontekst, który mu składasz — co do treści, ilości i formy.
Zostaje jeszcze jeden wątek, którego dotąd nie ruszaliśmy: co, jeśli to, co wpada do okna, jest atakiem. Gdy kontekst staje się wektorem — zatruty dokument, spreparowany wynik narzędzia, instrukcja ukryta w pobranych danych. To bonusowy wpis tej kategorii i most do bezpieczeństwa agentów.
Pojęcia ze słownika: Structured output · Okno kontekstu · Context rot · Grounding · Budżet tokenów
