Context engineering: co (nie) wkładać do okna kontekstu LLM

Zespół prawny pewnej kancelarii wdrożył asystenta RAG do przeszukiwania 2000 umów. Po kilku tygodniach zauważył, że asystent trafnie odpowiada na pytania o klauzule z pierwszej i ostatniej strony dokumentu, ale konsekwentnie pomija postanowienia ze środkowych sekcji. Model nie był zepsuty. Problem leżał w tym, że do każdego zapytania trafiało 20-30 fragmentów tekstu bez żadnego sortowania, a te z środka okna były traktowane przez model z niższym priorytetem.

To klasyczny przykład złego context engineering. Nie chodzi o to, ile tekstu podasz modelowi. Chodzi o to, co podasz, w jakiej kolejności i czy model ma realną szansę z tego skorzystać.

Najczęstszy błąd to przekazywanie do LLM całego dokumentu zamiast trafnie wybranych fragmentów. Przy dokumentach liczących 50 lub więcej stron okno kontekstu szybko się zapycha, koszty rosną, a i tak nie masz gwarancji, że model skupi uwagę na właściwej sekcji.

Podejście oparte na RAG działa inaczej: zamiast całego dokumentu do modelu trafia 5-10 fragmentów wybranych przez wyszukiwanie semantyczne i opcjonalnie reranker. Jakość tych fragmentów zależy od chunkingu, który opisujemy w artykule o chunkingu dokumentów do RAG. W praktyce wdrożeń widać wyraźnie, że jakość pobranych fragmentów ma większy wpływ na trafność odpowiedzi niż parametry samego modelu.

Decyzja po stronie człowieka: liczba pobieranych fragmentów (top-k) oraz próg odrzucenia słabych wyników (score threshold) wymagają kalibracji na zestawie testowym specyficznym dla Twojego dokumentu i domeny. Ustawienie tych parametrów to czynność inżynierska, nie algorytmiczna.

W 2023 roku badacze z Uniwersytetu Stanforda opublikowali obserwację, którą praktycy wdrożeń AI znają z własnych projektów: modele językowe wyraźnie lepiej zapamiętują informacje z początku i końca okna kontekstu niż z jego środka. Efekt narasta wraz z długością okna. Przy oknie 16 000 tokenów informacja umieszczona na pozycji od 6000 do 10 000 tokenów może być praktycznie ignorowana przez model.

Praktyczne konsekwencje dla kolejności wstawiania kontekstu:

• Instrukcja systemowa: zawsze na początku, przed fragmentami dokumentu.
• Najbardziej trafne fragmenty RAG: na początku listy, nie na końcu.
• Historia rozmowy: za instrukcją systemową, ale przed fragmentami dokumentów.
• Fragmenty o niskiej trafności: jeśli musisz je dołączyć, umieść je w środku. Lepiej je odfiltrować.

Wynik rerankowania można wykorzystać do sortowania: fragment z najwyższym score trafia jako pierwszy, najniższy jako ostatni (jeśli w ogóle). My w Cashcrown rekomendujemy utrzymanie poniżej 8 fragmentów w pojedynczym oknie kontekstu dla zapytań faktograficznych. Więcej rzadko poprawia jakość, a zawsze podnosi koszty.

W asystentach konwersacyjnych historia rozmowy rośnie z każdą wymianą. Po 10-15 turach dialog może zająć 3000-6000 tokenów, zanim jeszcze dodasz fragmenty z bazy wiedzy. Dwie strategie kompresji, które stosujemy w praktyce:

Summaryzacja krocząca: po każdej n-tej turze (np. co 5 wymian) agent generuje podsumowanie poprzedniej części rozmowy i zastępuje nim pełne transkrypty tych tur. Podsumowanie zajmuje 200-400 tokenów zamiast 1500-2500. Wada: precyzyjne fakty padające w środku rozmowy mogą być uproszczone w streszczeniu. Wymagaj cytowania źródłowego w podsumowaniu lub zatrzymuj się przy decyzjach wymagających precyzji.

Pamięć wektorowa z selekcją: zamiast przepisywać historię, zapisujesz ją do bazy wektorowej (wzorzec opisany w artykule o pamięci agenta AI) i pobierasz tylko te fragmenty, które są istotne dla bieżącego zapytania. Historia z sesji sprzed tygodnia nie zapycha okna, chyba że jest potrzebna.

Wybór między tymi podejściami zależy od natury dialogu. Przy rozmowach wieloturowych o jednym dokumencie summaryzacja krocząca działa lepiej. Przy asystentach obsługujących klientów przez wiele tygodni pamięć wektorowa jest koniecznością. Decyzję o sposobie kompresji powinien podjąć człowiek, który rozumie, jakie informacje z historii są krytyczne dla danego zastosowania.

Każdy token w oknie kontekstu kosztuje i wpływa na czas odpowiedzi. Przy modelach chmurowych koszt wejściowych tokenów to 0,5-15 USD za milion tokenów w zależności od modelu. Przy self-hostingu to czas GPU i latencja. Pełne koszty i wzorce optymalizacji opisujemy w artykule o koszcie tokenów LLM.

Tabela poniżej pokazuje, jak różne strategie wypełniania kontekstu wpływają na budżet tokenów, koszt i ryzyko pogorszenia jakości:

Dobra reguła projektowa: każdy element kontekstu powinien dawać się uzasadnić konkretną korzyścią dla jakości odpowiedzi. Jeśli nie potrafisz powiedzieć, dlaczego dany fragment tam jest, usuń go.

Forma kontekstu ma znaczenie obok jego zawartości. Surowy PDF po OCR z artefaktami, powtarzającymi się nagłówkami i przypisami to gorszy kontekst niż ten sam tekst po wyczyszczeniu i ustrukturyzowaniu.

Kilka konkretnych wzorców, które poprawiają jakość odpowiedzi:

Oznaczanie źródeł: każdy fragment z RAG poprzedzony etykietą [Źródło: Umowa XYZ, §3.2] pozwala modelowi cytować i pozwala systemowi guardrails weryfikować, czy odpowiedź nie wychodzi poza dostarczone fakty. Cytowanie źródeł w odpowiedzi to podstawowy mechanizm ograniczający halucynacje. Więcej o tym wzorcu w artykule o ograniczaniu halucynacji AI.

Dekontekstualizacja fragmentów: fragment „W tej sprawie termin wynosi 14 dni" bez informacji, o jakiej sprawie mowa, jest bezużyteczny. Przy chunkingu warto dodać nagłówek sekcji jako prefiks każdego fragmentu, by model miał kontekst pozycji w dokumencie.

Instrukcja negatywna w prompcie: jawne poinstruowanie modelu, żeby odpowiedział „nie wiem" zamiast spekulować, gdy fragmenty nie zawierają odpowiedzi, redukuje liczbę zmyślonych odpowiedzi. To część inżynierii promptów opisanej szerzej w artykule o prompt engineeringu dla firm.

Decyzja po stronie człowieka: przy wyjściach wysokiego ryzyka (decyzje prawne, medyczne, finansowe) system powinien zawsze wskazać źródłowy fragment, z którego pochodzi odpowiedź. Weryfikacja tego cytatu przez człowieka to obowiązkowa bramka przed działaniem na podstawie odpowiedzi modelu.

Optymalna liczba zależy od długości fragmentów i modelu, ale w praktyce 5-8 dobrze zrerankowanych fragmentów daje lepsze wyniki niż 15-20 fragmentów bez selekcji. Powyżej 10 fragmentów ryzyko efektu lost-in-the-middle rośnie, a koszt inferencji rośnie liniowo. Zacznij od top-5, zmierz jakość na zestawie testowym i zwiększaj ostrożnie.

Nie. Modele z oknami 128 000 lub więcej tokenów kuszą do wstawienia całego dokumentu bez filtrowania, ale precyzja odpowiedzi na pytania o szczegóły z środka dokumentu jest wtedy niższa niż przy starannym retrieval. Duże okno kontekstu to przydatne narzędzie awaryjne lub do analizy jednorazowej, nie substytut architektury RAG w systemach produkcyjnych.

Instrukcja systemowa powinna jawnie nakazywać modelowi zwrócić odpowiedź „nie mam wystarczających informacji w dostępnych dokumentach" zamiast spekulować. Warto zmierzyć wskaźnik takich odpowiedzi (tzw. „nie wiem" rate) na zestawie testowym: wartość poniżej 5-10 procent dla dobrze zaindeksowanej bazy wiedzy to dobry punkt odniesienia. Wyższy wskaźnik może wskazywać na problemy z chunkingiem lub retrieval.

Summaryzacja krocząca może gubić precyzyjne fakty padające w skompresowanej części rozmowy. Zabezpieczenie: przechowuj kluczowe fakty (liczby, daty, nazwy stron) jako oddzielny ustrukturyzowany rekord obok podsumowania. Agent może aktualizować ten rekord po każdej turze. Przy danych wrażliwych decyzję o tym, co wchodzi do trwałej pamięci, powinna zatwierdzać polityka retencji zatwierdzona przez człowieka.

Ciągły. Dystrybucja pytań użytkowników zmienia się w czasie, a za nią zmienia się optymalna konfiguracja retrieval i kolejności kontekstu. Rekomendujemy miesięczny przegląd złotego zestawu testowego: jeśli wskaźnik faithfulness lub trafności odpowiedzi spada o więcej niż 5 punktów procentowych, zbadaj, czy zmieniła się dystrybucja zapytań lub struktura dokumentów. Takie audyty jakości to ciągły proces, nie jednorazowe ustawienie systemu.