---
title: "Strategie chunkingu w RAG: porównanie metod fixed-size, semantic, hierarchical i late chunking"
description: "Strategie chunkingu w RAG określają, jak dokument jest dzielony przed embeddingiem na przeszukiwalne fragmenty tekstu (chunki)."
locale: "pl"
canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/strategie-chunkingu-w-rag-porownanie-metod-fixed-size-semantic-hierarchical-i-la"
category: "Agenci AI"
topic: "Jak działają systemy RAG w AI"
updated: "2026-10-28T13:35:50.084Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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 (chunki). Wybór strategii i rozmiaru chunków w dużej mierze decyduje o jakości wyszukiwania (retrieval): 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.

## W skrócie

- Chunking to nie szczegół, lecz dźwignia o największym wpływie na jakość wyszukiwania: naiwny chunking o stałym rozmiarze, który ignoruje granice zdań, tabel i list, jest jedną z najczęstszych przyczyn halucynacji i brakujących treści.
- Nie ma uniwersalnego optimum. Domyślnym punktem wyjścia jest 200-800 tokenów z nakładaniem (overlap) 10-20%; właściwa strategia zależy od typu dokumentu, modelu embeddingowego i wzorców zapytań.
- Hierarchiczny chunking parent-child oddziela wyszukiwanie (małe, precyzyjne chunki podrzędne) od generowania (duże chunki nadrzędne z kontekstem) i przy długich raportach oraz instrukcjach technicznych często jest najlepszym wyborem.
- Contextual Retrieval od Anthropic (stan na 2024 r.) dodaje na początku każdego chunka nagłówek kontekstowy wygenerowany przez LLM. Już samo to obniża odsetek błędów wyszukiwania o 35%, w połączeniu z Contextual BM25 (wyszukiwanie hybrydowe) o 49%, a z dodatkowym re-rankingiem o 67%.
- Niemieckie wyrazy złożone zużywają, zależnie od tokenizera, ~1,3-1,7x więcej tokenów niż tekst angielski. Zmniejsza to efektywną pojemność chunka i trzeba to uwzględnić przy wyborze rozmiaru.
- Właściwej strategii się nie zgaduje, tylko się ją mierzy: dzięki zbiorowi referencyjnemu (gold set) i metrykom RAGAS (Context Precision, Context Recall, Faithfulness) możesz obiektywnie porównać warianty w teście A/B.

Strategie chunkingu w [RAG](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/halucynacja-ai-ai-hallucination) 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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/porownanie-modeli-embeddingowych-2026-text-embedding-3-cohere-bge-m3-voyage-jina), 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ę?

| Strategia | Kiedy stosować | Zalety | Wady |
| --- | --- | --- | --- |
| Fixed-size (np. 512 tokenów, nakładanie 50) | Logi, transkrypcje, jednorodne teksty | Szybki, deterministyczny, tani | Ślepy na treść, tnie zdania/tabele |
| Recursive / Sentence Splitter | Generyczne ustawienie domyślne, mieszane korpusy | Respektuje naturalne granice, odporny | Nie wykrywa semantycznych zmian tematu |
| Sentence-window | Q&A na tekście ciągłym, krótkie pytania o fakty | Precyzyjne wyszukiwanie, trochę kontekstu dzięki oknu | Ograniczony kontekst przy długich zależnościach |
| Semantic Chunking | Dokumenty o zróżnicowanej treści | Spójne, jednotematyczne chunki | Kosztowne obliczeniowo indeksowanie |
| Hierarchical / Parent-Child | Długie raporty, instrukcje, umowy | Precyzyjne wyszukiwanie + pełny kontekst dla LLM | Większa złożoność pipeline'u, podwójne przechowywanie |
| Late Chunking | Długie dokumenty, embeddingi z długim kontekstem (stan na 2026 r., zależnie od dostawcy) | Globalny kontekst na chunk bez nagłówka LLM | Wymaga modelu embeddingowego z długim kontekstem; słabiej sprawdzony |
| Contextual Chunking (Anthropic, stan na 2024 r.) | Szerokie zastosowanie | -35% błędów wyszukiwania (z Contextual BM25 -49%), rozwiązuje problem lost-in-the-chunks | Jedno wywołanie LLM na chunk przy indeksowaniu |

## 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](https://www.anthropic.com/engineering/contextual-retrieval) (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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/ewaluacja-rag-porownanie-ragas-trulens-i-deepeval) 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](https://gdpr-info.eu/) oraz strategii chunkingu dopasowanej do Twoich dokumentów i pytań. Odezwij się do nas, zanim wejdziesz na produkcję, zamiast naprawiać wszystko potem.

## Najczęściej zadawane pytania

### Jakiego rozmiaru chunków używać w RAG?

Jako domyślny punkt wyjścia sprawdza się 200-800 tokenów z nakładaniem 10-20%. Mniejsze chunki (np. 256 tokenów) dają precyzyjniejsze trafienia przy pytaniach o fakty, większe (np. 800 tokenów) zachowują więcej kontekstu dla spójnych, dłuższych wyjaśnień. Ponieważ teksty niemieckie, zależnie od tokenizera, zużywają ok. 1,3-1,7x więcej tokenów niż angielskie, przetestuj efektywny rozmiar na swoim korpusie, zamiast przyjmować stałą wartość.
### Czym różni się chunking o stałym rozmiarze od chunkingu semantycznego?

Chunking o stałym rozmiarze tnie tekst mechanicznie według stałej liczby tokenów, niezależnie od treści i często w środku zdania lub tabeli. Chunking semantyczny mierzy odległość kosinusową między kolejnymi zdaniami i stawia cięcie tam, gdzie urywa się spójność treści. Stały rozmiar jest szybki i przewidywalny, a chunking semantyczny daje bardziej spójne chunki w dokumentach o zróżnicowanej treści, ale indeksowanie wymaga w nim więcej mocy obliczeniowej.
### Czym jest chunking parent-child, czyli hierarchiczny?

Chunking hierarchiczny oddziela wyszukiwanie od generowania. Embeddingi tworzy się i przeszukuje dla małych, precyzyjnych chunków podrzędnych, ale do modelu językowego trafia powiązany z nimi duży chunk nadrzędny. Dzięki temu system znajduje dokładne miejsce, a LLM dostaje wystarczająco dużo otaczającego kontekstu, by odpowiedzieć w pełni. Sprawdza się szczególnie przy długich raportach, instrukcjach technicznych i umowach.
### Czym jest Contextual Retrieval i ile daje?

W Contextual Retrieval (Anthropic, stan na 2024 r.) przed embeddingiem na początku każdego chunka umieszcza się krótki, wygenerowany przez LLM nagłówek kontekstowy, który wyjaśnia, skąd pochodzi dany fragment. Rozwiązuje to problem lost-in-the-chunks, np. gdy chunk zawiera tylko zdanie „Wzrósł o 12%”. Według Anthropic odsetek błędów wyszukiwania top-20 spada dzięki samemu nagłówkowi kontekstowemu o 35%, w połączeniu z Contextual BM25 (wyszukiwanie hybrydowe) o 49%, a z dodatkowym re-rankingiem o 67%.
### Jak znaleźć właściwą strategię chunkingu dla mojego projektu?

Nie zgadując, tylko mierząc. Stwórz zbiór referencyjny z prawdziwych pytań użytkowników wraz z poprawnymi fragmentami źródłowymi, zindeksuj ten sam korpus kilkoma wariantami chunkingu i porównaj je za pomocą metryk RAGAS, takich jak Context Precision, Context Recall i Faithfulness. Dopiero takie kontrolowane porównanie A/B pokazuje, która strategia faktycznie działa najlepiej dla Twoich dokumentów i wzorców zapytań.

---

Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/jak-dzialaja-systemy-rag-w-ai/strategie-chunkingu-w-rag-porownanie-metod-fixed-size-semantic-hierarchical-i-la). Systemy AI mogą wykorzystywać te treści z podaniem źródła.