Strategie chunkingu w RAG: porównanie metod fixed-size, semantic, hierarchical i late chunking

Strategie chunkingu w RAG określają, jak dokument jest dzielony przed embeddingiem na przeszukiwalne fragmenty tekstu, tzw. chunki. Wybór strategii i rozmiaru chunków w dużej mierze decyduje o jakości wyszukiwania: od niego zależy, czy model językowy znajdzie właściwy fragment i czy będzie on zawierał wystarczająco dużo kontekstu, by udzielić poprawnej odpowiedzi popartej źródłami. Chunking jest więc najmniej efektowną, ale najskuteczniejszą dźwignią w całym stacku RAG.

• Rekomendacja domyślna: 200-800 tokenów na chunk, nakładanie 10-20%, a wcześniej zawsze parsowanie z uwzględnieniem układu (layout-aware).
• Najczęstszy błąd: naiwny chunking o stałym rozmiarze tnie zdania, tabele i listy, przez co należy do głównych przyczyn halucynacji.
• Najlepsze uniwersalne rozwiązanie w 2026 r.: hierarchiczny chunking parent-child, opcjonalnie w połączeniu z Contextual Retrieval (Anthropic: do -67% błędów wyszukiwania przy wyszukiwaniu hybrydowym i re-rankingu).

Dlaczego chunking decyduje o sukcesie lub porażce

W pipelinie RAG każdy dokument źródłowy jest dzielony, a każdy chunk zamieniany na wektor (embedding) i zapisywany w wektorowej bazie danych. W czasie działania system wyszukuje chunki najbardziej podobne do pytania użytkownika i przekazuje je modelowi językowemu w prompcie. Oznacza to, że czego nie podzielono porządnie, tego w ogóle nie da się znaleźć. A to, co zostało znalezione, ale pocięte bez kontekstu, wprowadza model w błąd.

W praktyce dominują dwie klasy błędów. Po pierwsze naiwny chunking o stałym rozmiarze ignoruje granice zdań, tabel i list; skutkiem są halucynacje i brakujące treści tabel. Po drugie problem „lost-in-the-chunks”: chunk zawiera zdanie „Wzrósł o 12%”. Bez otaczającego kontekstu nie wiadomo, co wzrosło. Oba problemy powstają przed embeddingiem i żaden, nawet najlepszy re-ranking nie naprawi ich później.

Sześć strategii chunkingu w skrócie

Fixed-size Chunking tnie tekst na stałe okna, np. 512 tokenów z nakładaniem 50 tokenów. Jest szybki, deterministyczny i tani, ale ślepy na treść. Nadaje się do jednorodnych tekstów, takich jak logi czy transkrypcje.

Recursive Character / Sentence Splitting dzieli tekst hierarchicznie według separatorów (akapity, potem zdania, potem słowa) i przy tym respektuje naturalne granice. To generyczne ustawienie domyślne wielu frameworków (LangChain) i dobry punkt wyjścia dla mieszanych korpusów.

Sentence-window to jego wariant: embeddingi tworzy się i przeszukuje na poziomie zdań, ale do LLM trafia okno złożone z sąsiednich zdań. To lekki poprzednik zasady parent-child.

Semantic Chunking mierzy odległość kosinusową między kolejnymi zdaniami i stawia cięcie tam, gdzie urywa się spójność treści (cosine drift). W dokumentach o zróżnicowanej treści daje to spójne chunki, ale indeksowanie wymaga więcej obliczeń, bo dla każdego zdania trzeba najpierw wygenerować embedding.

Hierarchical / Parent-Child Chunking oddziela wyszukiwanie od generowania: małe chunki podrzędne służą jako precyzyjny cel wyszukiwania, a powiązany duży chunk nadrzędny trafia do generatora jako kontekst. Przy długich raportach i instrukcjach technicznych ta strategia często jest najlepszym wyborem.

Late Chunking to nowsze podejście, które odwraca kolejność: zamiast ciąć tekst przed embeddingiem, najpierw przetwarza się cały (długi) dokument za pomocą modelu embeddingowego z długim kontekstem, a dopiero potem uzyskane embeddingi tokenów są łączone (pooling) w wektory chunków. Dzięki temu każdy wektor chunka niesie w sobie kontekst całego dokumentu. Podejście ma ten sam cel co Contextual Retrieval, czyli rozwiązanie problemu lost-in-the-chunks, ale nie wymaga dodatkowego wywołania LLM dla każdego chunka. Jest jednak stosunkowo młode, słabiej sprawdzone w praktyce i wymaga modelu embeddingowego obsługującego długi kontekst. Przed wdrożeniem produkcyjnym sprawdź obsługiwaną długość kontekstu i sposób poolingu w aktualnej dokumentacji dostawcy wybranego modelu.

Warto znać jeszcze dwie metody: Propositional Chunking, który rozkłada tekst na atomowe, pojedyncze stwierdzenia i sprawdza się przy bardzo precyzyjnej ekstrakcji faktów, oraz Contextual Chunking (zob. niżej), który umieszcza na początku każdego chunka objaśniający nagłówek kontekstowy.

Tabela porównawcza: kiedy którą strategię?

Kompromisy: rozmiar chunka i nakładanie

Rozmiar chunka to klasyczny konflikt celów. Małe chunki (np. 256 tokenów) dają ostrzejsze embeddingi i precyzyjniejsze trafienia przy punktowych pytaniach o fakty, ale grozi im utrata kontekstu. Duże chunki (np. 800 tokenów i więcej) przenoszą więcej powiązań, ale rozmywają embedding i zwiększają ryzyko, że istotna informacja zginie przez efekt „lost-in-the-middle” w LLM. Przekazywanie modelowi zbyt dużych zbiorów top-k dodatkowo to pogłębia. Dlatego zaleca się, by po wyszukiwaniu zawęzić wyniki re-rankerem do top_k = 5-10.

Nakładanie (overlap, czyli wspólne tokeny sąsiednich chunków) zapobiega temu, by myśl została rozerwana dokładnie na krawędzi cięcia. Sprawdzoną wartością orientacyjną jest 10-20% rozmiaru chunka. Większe nakładanie zwiększa redundancję, zapotrzebowanie na pamięć i koszty indeksowania, nie podnosząc proporcjonalnie jakości.

Czynnik często niedoceniany w korpusach z regionu DACH (Niemcy, Austria, Szwajcaria): niemieckie wyrazy złożone, takie jak „Datenschutz-Folgenabschätzung”, generują, zależnie od tokenizera (BPE/SentencePiece), wyraźnie więcej tokenów niż ich angielskie odpowiedniki. Jako regułę orientacyjną przyjmuje się, że niemiecki, zależnie od modelu, zużywa ok. 1,3-1,7x więcej tokenów. Obniża to efektywną pojemność treściową chunka o rozmiarze 512 tokenów: rozmiar zdefiniowany w tokenach przenosi po niemiecku mniej merytorycznej treści niż po angielsku.

Konkretny przykład z liczbami

Załóżmy, że indeksujesz 10 000 technicznych stron PDF (umowy i instrukcje produktów).

1. Parsowanie: z uwzględnieniem układu (layout-aware), za pomocą parsera takiego jak Docling lub Unstructured, aby zachować tabele, listy i nagłówki.
2. Chunking: parent-child. Chunki nadrzędne po ok. 1500 tokenów (całe sekcje), chunki podrzędne po ok. 300 tokenów z nakładaniem 15%.
3. Cel embeddingu: chunki podrzędne; do LLM trafia odpowiedni chunk nadrzędny.
4. Opcjonalny Contextual Header: dla każdego chunka krótkie zdanie kontekstowe wygenerowane przez LLM przed embeddingiem. Według Anthropic (wrzesień 2024 r.) odsetek błędów wyszukiwania top-20 spada przy samych Contextual Embeddings z 5,7% do 3,7% (-35%). W połączeniu z Contextual BM25 (wyszukiwanie hybrydowe) spada do 2,9% (-49%), a z dodatkowym re-rankingiem do 1,9% (-67%). Jednorazowy koszt zdań kontekstowych Anthropic szacuje na ok. 1,02 USD za 1 mln tokenów dokumentu (Claude 3 Haiku z prompt cachingiem, chunki po 800 tokenów, dokumenty po 8000 tokenów, ceny z września 2024 r.). Przy chunkach po 300 tokenów, jak tutaj, wartość jest wyższa, bo na milion tokenów przypada więcej chunków, które potrzebują zdania kontekstowego.

Pseudokod hierarchicznego podziału:

```
parents = split(document, size=1500, separators=["\n## ", "\n\n"])
for p in parents:
children = split(p, size=300, overlap=45) # 15% z 300
for c in children:
c.context = llm("Krótko osadź ten chunk w kontekście całego dokumentu.", document=document, chunk=c.text) # opcjonalnie
index.upsert(embed(c.context + c.text), parent_ref=p.id)
```

Jak przetestować właściwą strategię

Decyzji dotyczących chunkingu się nie zgaduje, tylko się je mierzy. Procedura wygląda tak:

• Zbuduj zbiór referencyjny: 50-200 prawdziwych pytań użytkowników, każde z adnotacją poprawnego fragmentu źródłowego. Bez zbioru referencyjnego pomoże LLM-as-Judge (RAGAS reference-free) albo syntetycznie wygenerowany zestaw testowy.
• Zindeksuj warianty: podziel ten sam korpus kilka razy, np. jako Fixed-512, Recursive-300, Semantic i Parent-Child, przy poza tym identycznym pipelinie.
• Zmierz za pomocą RAGAS: kluczowe metryki ewaluacji RAG za pomocą RAGAS to Context Precision i Context Recall (czy wyszukiwanie trafia we właściwe fragmenty?) oraz Faithfulness i Answer Relevancy (czy odpowiedź naprawdę opiera się na kontekście?).
• A/B na produkcji: zestaw wariant prowadzący w teście offline z obecnym i obserwuj realne sygnały (kliknięcia, opinie użytkowników).

Ważne: jeśli zmienia się model embeddingowy, konieczna jest pełna ponowna indeksacja, ponieważ embeddingi z różnych modeli nie są porównywalne. Dlatego oznaczaj indeksy ciągiem wersji.

Dla agencji i decydentów B2B

Chunking nie jest szczegółem konfiguracji, który ustawia się raz i o nim zapomina, lecz pokrętłem o największym wpływie na jakość odpowiedzi Twojego systemu RAG, a tym samym na zaufanie, jakim darzą go klienci i pracownicy. Kto zaczyna tu od naiwnego chunkingu o stałym rozmiarze, płaci później halucynacjami, eskalacjami do supportu i kosztownymi poprawkami. Jako agencja Blck Alpaca (Wiedeń) projektujemy i oceniamy pipeline'y RAG dla firm w całej Europie w mierzalny sposób, na podstawie metryk RAGAS, z uwzględnieniem tokenizacji języka niemieckiego, hostingu w UE zgodnie z wymogami RODO oraz strategii chunkingu dopasowanej do Twoich dokumentów i pytań. Odezwij się do nas, zanim wejdziesz na produkcję, zamiast naprawiać wszystko potem.