Zarządzanie oknem kontekstu LLM w n8n: jak przetwarzać długie dokumenty bez przekraczania limitu tokenów

Gdy wdrażam automatyzacje AI dla firm, najczęstszym problemem przy analizie umów, raportów czy specyfikacji jest przepełnienie okna kontekstu modelu. Przekroczenie limitu tokenów powoduje błędy API i przerywa działanie przepływu. Aby bezpiecznie przetwarzać długie dokumenty w n8n, musisz podzielić je na fragmenty, przetworzyć iteracyjnie i scalić wyniki, zachowując spójność informacji.

Czym jest okno kontekstu i dlaczego ogranicza automatyzacje

Okno kontekstu to maksymalna liczba tokenów, jaką model LLM może przyjąć w jednym zapytaniu. Obejmuje ona zarówno tekst wejściowy (prompt systemowy, dokument, historia rozmowy), jak i generowaną odpowiedź. Nawet modele z dużym oknem kontekstu mają swoje limity, a wysyłanie całych wielostronicowych PDF-ów często prowadzi do błędów typu context_length_exceeded lub nieuzasadnionego pomijania fragmentów tekstu przez model (tzw. "lost in the middle").

Dodatkowo, pełne okno kontekstu znacząco podnosi koszty pojedynczego zapytania. Zamiast bezrefleksyjnie zwiększać rozmiar pojedynczego zapytania, projektuję przepływy, które dzielą tekst na mniejsze, kontrolowane fragmenty.

Strategie podziału tekstu (chunking) w n8n

Sposób podziału dokumentu bezpośrednio wpływa na jakość odpowiedzi LLM. Dzielenie na sztywno co 1000 znaków może uciąć ważne zdanie w połowie, przez co model straci kluczowy kontekst. W n8n stosuję dwa podejścia do fragmentacji.

Podział semantyczny zamiast cięcia na sztywno

Zamiast ucinania tekstu w arbitralnych miejscach, dzielę dokument na akapity lub sekcje. W n8n używam węzła Code, aby rozbić tekst za pomocą wyrażeń regularnych (np. po podwójnych znakach nowej linii \n\n) lub dedykowanych bibliotek JavaScript w środowisku self-hosted. Taki podział gwarantuje, że pojedynczy fragment zawiera pełną myśl, co ułatwia modelowi poprawne zrozumienie kontekstu.

Przykładowy skrypt w węźle Code dzielący tekst po akapitach:

const text = items[0].json.text;
const chunks = text.split(/\n\n+/).filter(chunk => chunk.trim().length > 0);
return chunks.map((chunk, index) => ({ json: { chunkIndex: index, text: chunk } }));

Nakładanie się fragmentów (overlap)

Gdy przetwarzam dokumenty, w których kontekst płynnie przechodzi między akapitami, nakładam na siebie sąsiednie fragmenty. Jeśli pierwszy chunk kończy się w połowie zdania, drugi chunk zaczyna się kilka zdań wcześniej. W n8n realizuję to w węźle Code, modyfikując logikę dzielenia tak, aby każdy kolejny fragment zawierał końcówkę poprzedniego. Zapobiega to utracie sensu na granicach cięcia.

Mapowanie fragmentów przez LLM w n8n

Gdy dokument jest już podzielony na tablicę fragmentów, musisz wysłać każdy z nich do modelu. W n8n służy do tego wzorzec iteracji.

Split In Batches vs. Loop

Do przetwarzania tablicy fragmentów używam węzła Split In Batches. Pozwala on na przesyłanie fragmentów do węzła LLM w kontrolowanych paczkach, co zapobiega przeciążeniu API i pozwala na wstrzymanie w przypadku błędu. W przeciwieństwie do prostego węzła Loop, Split In Batches łatwiej zintegrować z logiką ponawiania prób (retry logic) i fallbackami. Dodatkowo, węzeł ten automatycznie czeka na zakończenie przetwarzania paczki przed załadowaniem kolejnej, co jest kluczowe przy limitach zapytań (rate limiting).

Utrzymanie kontekstu między fragmentami

Często model musi wiedzieć, że analizuje fragment większej całości. W n8n dodaję do promptu systemowego informację o numerze fragmentu, np.: "Analizujesz fragment {{ $json.chunkIndex }} z {{ $json.totalChunks }} dokumentu". Jeśli to konieczne, przekazuję w prompcie krótkie podsumowanie poprzedniego fragmentu, wygenerowane w poprzedniej iteracji pętli. Wymaga to zapisywania stanu w zmiennych przepływu lub bazie danych, aby kolejny krok miał dostęp do wyników poprzednika.

Wzorzec Map-Reduce dla ostatecznej odpowiedzi

Samo przetworzenie fragmentów to połowa sukcesu. Ostatnim krokiem jest złączenie odpowiedzi z poszczególnych fragmentów w sensowną całość. Stosuję tu wzorzec map-reduce.

Jak scalić wyniki w n8n

W n8n, po wyjściu z pętli Split In Batches, zbieram wyniki do jednej tablicy. Następnie używam węzła Code, aby połączyć je w spójny tekst. Jeśli przepływ ma na celu wyciągnięcie konkretnych danych z całego dokumentu (np. sumy z faktur czy dat z umów), proste złączenie tekstów może wystarczyć.

Kiedy jednak potrzebuję spójnego podsumowania lub syntezy całego dokumentu, wysyłam złączone wyniki z fazy "map" do kolejnego zapytania LLM. Ten model redukujący bierze pod uwagę tylko kluczowe informacje z poszczególnych fragmentów i generuje ostateczną, globalną odpowiedź, omijając problem przepełnienia okna kontekstu.

Checklist: Weryfikacja przepływu dla długich dokumentów

Przed wdrożeniem automatyzacji do produkcji sprawdzam następujące warunki:

• Czy węzeł Code poprawnie dzieli tekst na fragmenty nieprzekraczające bezpiecznego limitu tokenów dla docelowego modelu (zostawiając miejsce na prompt i odpowiedź)?
• Czy podział zachowuje spójność logiczną (cięcie po akapitach/zdaniach) lub posiada odpowiedni overlap?
• Czy węzeł Split In Batches ma ustawiony odpowiedni rozmiar paczki (batch size), aby nie naruszyć limitów API?
• Czy przepływ posiada logikę obsługi błędów na węźle LLM (np. fallback na mniejszy model lub retry w przypadku błędu limitu)?
• Czy wyniki z pętli są poprawnie agregowane po zakończeniu iteracji i nie tracą powiązań z oryginalnym dokumentem?

Projektowanie przepływów AI w n8n wymaga precyzyjnego zarządzania danymi wejściowymi. Pomagam firmom budować odporne automatyzacje, które radzą sobie z długimi dokumentami i ograniczeniami modeli językowych.