Język polski w przepływach AI n8n: jak optymalizować chunking, prompty i RAG pod polską morfologię

Polska morfologia wpływa na jakość AI – odpowiedź w skrócie

Polski jest językiem fleksyjnym z rozbudowaną odmianą przez przypadki, rodzaje i liczby. W praktyce oznacza to, że standardowe dzielenie tekstu po limicie tokenów często rozrywa zdania w środku wyrazu lub odcina końcówki fleksyjne, które niosą znaczenie gramatyczne. W n8n muszę dlatego konfigurować chunking nie tylko po liczbie znaków, ale z zachowaniem granic zdań i akapitów. Dodatkowo w promptach precyzyjnie określam formę wymaganego wyjścia, bo model nie zawsze domyślnie zachowuje polską składnię, szczególnie gdy w treści pojawiają się angielskie fragmenty dokumentacji lub danych technicznych.

Chunking z myślą o polskich końcówkach fleksyjnych

W anglojęzycznych materiałach często pokazuje się podział co N słów lub stałą liczbę tokenów. W polskich dokumentach stosuję inne zasady:

• Dzielę po granicach zdań, nawet jeśli fragment będzie krótszy niż limit tokenów. Lepszy mniejszy chunk z pełnym kontekstem syntaktycznym niż przerwane zdanie, w którym odmienione przez przypadki rzeczowniki tracą związek z orzeczeniem.
• Akapit jako niepodzielna jednostka semantyczna. Jeśli akapit opisuje jeden temat – na przykład warunki gwarancji lub procedurę reklamacji – nie rozdzielam go między dwa wektory. Polskie zaimki i formy czasowników często odwołują się do podmiotu z pierwszego zdania akapitu.
• Weryfikacja końca chunka. W węźle Function lub Code w n8n sprawdzam, czy ostatni znak fragmentu to znak końca zdania (., ! lub ?). Jeśli nie – cofam podział do poprzedniego separatora. Używam prostego warunku: chunk.endsWith('.') || chunk.endsWith('?') || chunk.endsWith('!').
• Overlap na poziomie 2-3 zdań. Dla dokumentów prawnych i ofertowych ustawiam nachodzenie chunków na 2-3 zdania, ponieważ polskie zaimki osobowe i spójniki mogą odnosić się do treści z poprzedniego zdania, a zerwanie tego związku obniża trafność odpowiedzi RAG.

Prompt engineering – jak formułować instrukcje po polsku

Pracując z polskimi klientami, zauważyłem, że jakość odpowiedzi drastycznie rośnie, gdy prompt zawiera konkretne reguły językowe:

• Wymuszenie formy wyjściowej. Zamiast ogólnego "Napisz podsumowanie", używam: "Napisz podsumowanie w języku polskim, w formie bezosobowej, w czasie teraźniejszym. Używaj pełnych zdań, nie punktów."
• Kontekst stylistyczny. Określam docelowy rejestr: "Odpowiedź ma być napisana językiem formalnym, zgodnym z polską normą korespondencji biznesowej" lub "Używaj prostego języka, zrozumiałego dla klienta bez przygotowania technicznego".
• Zabezpieczenie przed code-switchingiem. Dodaję regułę: "Odpowiedź musi być w całości po polsku. Nie używaj angielskich terminów, chyba że są to ustalone nazwy własne produktów lub firm." Zapobiega to sytuacjom, w których model miesza polską składnię z angielskimi słowami kluczowymi.
• Przykłady few-shot po polsku. Jeśli stosuję technikę few-shot, podaję 2-3 przykłady w języku polskim. Przełączanie na angielskie wzorce zakłóca odmianę i składnię wyjściową, szczególnie w przypadku polskich końcówek fleksyjnych.

RAG i wyszukiwanie wektorowe dla polskich zapytań

W polskich automatyzacjach RAG w n8n wdrażam dodatkowe kroki związane z specyfiką języka:

• Zachowanie diakrytyków. Użytkownik może wpisać "faktura" lub "fakturę". Przed wyszukaniem wektorowym nie zmieniam formy fleksyjnej – embeddingi radzą sobie z odmianą – ale trzymam polskie znaki diakrytyczne (ą, ę, ś, ć, ń, ó, ż, ź, ł) w całym pipeline. Usuwam je tylko wtedy, gdy mam pewność, że baza danych jest zdenormalizowana w sposób kontrolowany.
• Rozszerzenie zapytania o synonimy domenowe. W węźle Set lub Function dodaję prosty słownik synonimów dla branży klienta, na przykład: "umowa" → "kontrakt", "regulamin" → "warunki". Nie wywołuję zewnętrznego API – po prostu buduję alternatywne warianty zapytania i wysyłam je równolegle lub łączę w jeden string przed embeddingiem.
• Filtracja wyników po retrieval. Po pobraniu chunków z bazy wektorowej w n8n sprawdzam w węźle IF, czy zwrócone fragmenty faktycznie zawierają polskie słowa kluczowe z zapytania. Jeśli similarity search zwraca fragment w języku angielskim (np. z dokumentacji technicznej), odrzucam go, aby nie zakłócać generowania odpowiedzi po polsku.

Sanityzacja i kodowanie polskich znaków w HTTP Request

Gdy n8n komunikuje się z lokalnymi modelami LLM przez węzeł HTTP Request lub zewnętrznymi API, spotykam się z problemami kodowania:

• Wymuszam UTF-8 w nagłówkach. Zawsze ustawiam Content-Type: application/json; charset=utf-8. Brak tego parametru w połączeniu z lokalnym serwerem może spowodować zamianę polskich znaków na krzaki lub encje HTML.
• Weryfikacja payloadu. W węźle Function sprawdzam, czy polskie znaki nie zostały zamienione na encje Unicode (\u0105 zamiast ą) lub HTML (ą). Jeśli widzę takie zamiany, używam JSON.parse i JSON.stringify z odpowiednim kodowaniem lub wymuszam UTF-8 w konfiguracji webhooka.
• Webhooki zwrotne. Jeśli n8n udostępnia endpoint przyjmujący polskie zapytania, ustawiam w węźle Webhook nagłówek odpowiedzi Content-Type: application/json; charset=utf-8, aby przeglądarka lub klient API poprawnie wyświetlił polskie znaki.

Checklista weryfikacji polskich automatyzacji AI

Przed wdrożeniem każdego przepływu n8n obsługującego język polski sprawdzam:

1. Czy chunki kończą się granicą zdania, a nie w środku wyrazu lub odmiany?
2. Czy prompt zawiera explicit wymaganie języka polskiego i preferowaną formę stylistyczną?
3. Czy zapytania do RAG zachowują polskie znaki diakrytyczne w całym pipeline?
4. Czy odpowiedź modelu nie zawiera nieuzasadnionych anglicyzmów lub code-switchingu?
5. Czy webhooki i endpointy zwracają odpowiedź z nagłówkiem UTF-8 bez błędów kodowania?
6. Czy w przypadku few-shot przykłady są w języku polskim i odpowiadają docelowemu rejestrowi?

Jeśli planujesz wdrożyć w firmie automatyzację AI obsługującą polskie dokumenty, klientów lub wewnętrzne bazy wiedzy, pomagam zaprojektować przepływy n8n, które respektują specyfikę języka polskiego – od przygotowania danych po walidację odpowiedzi modeli.