Chunkowanie treści: jak dzielić tekst pod retrieval

Chunkowanie (chunking) to proces dzielenia tekstu na mniejsze fragmenty — chunki — które są potem indeksowane i retrievowane przez LLM. W 2026 roku każda wyszukiwarka AI (ChatGPT Search, Perplexity, Claude, Gemini, You.com) chunkuje treści z internetu. Jak je chunkuje, decyduje o tym, co zostanie zacytowane.

Ten tekst opisuje teorię i praktykę chunkingu dla marketerów, którzy chcą, żeby ich treści były cytowane przez LLM. Pełny kontekst w przewodniku AIO 2026.

Czym jest chunk

Chunk to fragment treści wyodrębniony z dokumentu, zwykle 200–1000 tokenów. Każdy chunk indeksowany jest osobno, embedowany do vector space, i może być retrievowany niezależnie od reszty dokumentu.

Dlaczego chunking, nie cały dokument

1. LLM context window ograniczony — nie każdy dokument się mieści (choć 1M+ tokenów w 2026).
2. Relevance — query dotyczy części dokumentu, nie całości.
3. Cost — retrievowanie tylko relevantnych chunków obniża koszty inference.
4. Accuracy — skupienie na konkretnych chunkach daje dokładniejsze odpowiedzi.
5. Citation — LLM cytuje chunk, nie cały dokument — granice matter.

Życie chunka w pipeline RAG

1. Dokument crawlowany przez LLM system.
2. Chunking — tekst dzielony na fragmenty.
3. Embedding — każdy chunk przez embedding model (text-embedding-3-large, Voyage, Cohere).
4. Storage — chunki + embeddings w vector database (Pinecone, Weaviate, Qdrant).
5. Retrieval — na query, top-k chunków po similarity.
6. Generation — LLM używa chunków jako kontekstu, cytuje je w odpowiedzi.

Cztery strategie chunkingu

1. Fixed-size chunking

Najprostsza strategia — dziel tekst na fragmenty stałej długości (np. 500 tokenów).

• Plusy: proste, szybkie, deterministyczne.
• Minusy: tnie zdania, niszczy kontekst.
• Kiedy: bulk indeksing, gdy szybkość > jakość.
• Wariant: fixed-size z overlap (chunk 500, przesunięcie 400) — zachowuje granice.

2. Sentence-based chunking

Dziel na zdania, potem grupuj w chunki do docelowej długości.

• Plusy: zachowuje syntactic integrity zdań.
• Minusy: zdania o bardzo różnych długościach.
• Implementacja: NLTK sent_tokenize, spaCy.
• Kiedy: teksty naturalne z różnymi długościami zdań.

3. Paragraph-based chunking

Dziel na akapity, grupuj w chunki.

• Plusy: zachowuje semantic coherence (akapit = jedna myśl).
• Minusy: akapity mogą być za długie lub za krótkie.
• Implementacja: split po <p> lub dwóch newlinach.
• Kiedy: strukturyzowane dokumenty z dobrymi akapitami.

4. Semantic chunking

Dziel na podstawie semantic similarity — chunk kończy się, gdy zmienia się temat.

• Plusy: najbardziej „inteligentny” podział, każdy chunk self-contained.
• Minusy: wolny, droższy (embedding-based).
• Implementacja: LlamaIndex SemanticSplitter, LangChain SemanticChunker.
• Kiedy: high-value treści, gdzie jakość cytowania ma znaczenie.

Rozmiary chunków — benchmarki

Tokeny vs. słowa

Tokeny	Słowa PL (średnio)	Długość chunk
128	85	Bardzo krótki — 1 akapit
256	170	Krótki — 2–3 akapity
512	340	Średni — sekcja H3
1024	680	Długi — sekcja H2
2048	1360	Bardzo długi — 2–3 sekcje

Rekomendacja dla content marketing

• Optymalny chunk: 300–600 tokenów (200–400 słów PL).
• Za krótki (< 128 tokenów) — brak kontekstu.
• Za długi (> 1500 tokenów) — LLM gubi fokus, ważna informacja zniknie w noise.
• Dla technical docs: 500–1000 tokenów (więcej kontekstu).
• Dla FAQ: 128–256 tokenów per pytanie (discrete units).

Overlap — dlaczego chunki się nakładają

Overlap to procentowa nakładka między kolejnymi chunkami. Chunk 1 = tokens 0–500, Chunk 2 = tokens 400–900 (overlap 100 tokenów = 20%).

Dlaczego overlap pomaga

• Zdania przecięte na granicy są w dwóch chunkach — retrieval nie straci kontekstu.
• Koncepcja wspomniana w ostatnim zdaniu chunk 1 i pierwszym chunk 2 — oba indeksowane.
• Redundancy zwiększa recall (więcej chunków dla tego samego concept = wyższa chance retrievalu).

Standard overlap

1. Minimum: 10% (50 tokenów dla chunk 500).
2. Standard: 15–20% (75–100 tokenów dla chunk 500).
3. Maximum: 25% (powyżej = marnotrawstwo storage i compute).
4. Zero overlap: tylko dla perfekcyjnie strukturyzowanych dokumentów z clear boundaries (FAQ, structured data).

Strukturalne markery jako sygnały chunkingu

LLM crawlery używają HTML struktury jako sygnałów chunkingu. Dobrze zstrukturyzowany dokument generuje lepsze chunki automatycznie.

Hierarchia markerów

• H1 — dokument boundary (rzadko).
• H2 — section boundary (najczęstszy chunk split).
• H3 — sub-section boundary (opcjonalny split).
• <p> (double newline) — paragraph boundary.
• Lists (ul/ol) — coherent unit, zwykle jeden chunk.
• Tabele — coherent unit, zwykle jeden chunk.
• <details> — FAQ item, jeden chunk per Q&A.

Jak LLM crawlery parsują HTML

1. Strip scripts, styles, navigations.
2. Extract main content (article, main, content div).
3. Respect semantic tags (h2, h3, p, ul, ol, table).
4. Chunk boundaries — preferują h2/h3 jako naturalne podziały.
5. Preservuj relacje parent-child (section parent, sub-sections children).

Jak optymalizować treść pod chunking

Struktura dokumentu

• H2 co 400–500 słów (naturalna granica chunka).
• H3 co 150–200 słów (sub-granica).
• Akapity 2–4 zdania (nie więcej niż 80 słów).
• Każda sekcja H2 self-contained — czytelna bez reszty.
• Key facts w pierwszym zdaniu każdego akapitu.

Semantic coherence per chunk

• Każda sekcja H2 o jednym temacie.
• Factoidy grupowane tematycznie, nie rozrzucone.
• Listy zachowują jedną kategorię (wszystkie itemy to „benefits” albo „challenges”, nie mieszane).
• Tabele z spójnymi nagłówkami kolumn.

Anchor + self-contained content

• Jeśli chunk jest retrievowany bez reszty dokumentu, czy ma sens?
• Pronouny („to”, „ona”) niszczą self-containment — unikaj lub rekontekstualizuj.
• Przykład: „To się sprawdza w praktyce” — bad. „CAPI sprawdza się w praktyce” — good.
• Każdy akapit powinien być czytelny standalone w 80% przypadków.

Chunking FAQ sekcji

FAQ jest szczególnie przyjazne pod chunking. Każda para Q&A to naturalny, self-contained chunk.

Format dla optymalnego FAQ chunking

• <details><summary><strong>Question?</strong></summary><p>Answer.</p></details>
• Każdy details chunkowany osobno.
• Question jako kluczowy sygnał embedding.
• Answer 100–300 słów (pasuje do 150–450 tokenów).
• 5–7 FAQ = 5–7 dyskretnych chunków.

Dlaczego FAQ są cytowane 2–3× częściej

1. Pytanie jako embedding z high signal — perfect match dla user queries.
2. Self-contained answer — retrievable standalone.
3. Dyskretny chunk — LLM łatwo cytuje całą odpowiedź.
4. Q&A format to jeden z trenowanych patterns LLM — naturalnie preferowane.

Narzędzia do chunkingu

LangChain TextSplitters

• RecursiveCharacterTextSplitter — split po różnych separatorach, fallback do mniejszych.
• MarkdownTextSplitter — respektuje markdown headers.
• HTMLHeaderTextSplitter — respektuje HTML headers.
• TokenTextSplitter — split po liczbie tokenów.

LlamaIndex Node Parsers

• SentenceSplitter — sentence-based z target size.
• SemanticSplitterNodeParser — semantic chunking (embedding-based).
• HierarchicalNodeParser — multi-level chunking (small + medium + large).

Własne implementacje

• Python spaCy dla sentence detection.
• tiktoken dla counting tokenów (OpenAI models).
• anthropic-tokenizer dla Claude.
• Custom logic dla domain-specific content (legal, medical).

Typowe błędy w chunking

• Za duży chunk size (> 1500 tokenów) — LLM gubi fokus.
• Za mały chunk size (< 128 tokenów) — brak kontekstu.
• Zero overlap — zdania przecięte giną.
• Fixed-size bez respect struktury — chunki kończą się w środku zdania.
• Brak metadanych per chunk — chunk bez contextu nie ma sensu przy retrievalu.
• Inkonsekwentny chunking między dokumentami — nieporównywalne indexes.
• Ignorowanie struktury HTML — H2/H3 markerów nie respektuje.
• Re-chunking bez reembedding — stare embeddings nie matchują nowych chunków.

FAQ — chunkowanie treści AI

Jak sprawdzić, jak LLM chunkuje moją treść?

Trzy sposoby: (1) narzędzia devtools: GPT Tokenizer, Anthropic Tokenizer — sprawdź liczbę tokenów sekcji; (2) API inspection — skorzystaj z LlamaIndex / LangChain z tym samym strategią chunkingu jaką LLM używa, zobacz wyniki; (3) black-box testing — zadaj LLM konkretne pytanie i zobacz, który fragment Twojej strony został zacytowany. Dla content marketing: skupiaj się na zapewnieniu, że sekcje H2/H3 są self-contained, a akapity krótkie — to wystarczy, żeby każda strategia chunkingu dała dobre wyniki.

Czy mogę wymusić konkretne chunki dla mojej treści?

Dla LLM z API (Claude, GPT) — tak, przez proprietary chunking w RAG system, który sam kontrolujesz. Dla publicznych wyszukiwarek AI (Perplexity, ChatGPT Search, Gemini) — nie, używają własnych strategii chunkingu. Najlepsze, co możesz zrobić: optymalizować strukturę HTML (H2, H3, akapity, listy), żeby każda strategia chunkingu (fixed, sentence, paragraph, semantic) dała dobre wyniki. Dobrze zstrukturyzowany dokument jest robust na różne chunking strategies.

Czy chunkowanie wpływa na SEO w Google?

Pośrednio. Google używa passage indexing (od 2021), który jest formą chunkingu. Pojedynczy akapit Twojej strony może rankować dla konkretnego zapytania niezależnie od reszty. Struktura, która jest dobra dla LLM (H2/H3, krótkie akapity, listy, tabele) jest również dobra dla passage indexing Google. Overlap między dobrym AIO a dobrym SEO przekracza 80%. Jeden artykuł dobrze zstrukturyzowany wygrywa w obu kanałach.

Czy mogę chunkować artykuł ręcznie przed publikacją?

Nie ma sensu dla publicznych LLM — używają własnych chunkingu. Ma sens dla Twojego własnego RAG system (knowledge base, help center, chatbot). Dla własnego RAG: LlamaIndex / LangChain z semantic splitter da najlepsze wyniki. Dla marketing content publicznego: inwestycja w strukturę (nie w custom chunking) wystarczy. Sweet spot: dobrze napisać, dobrze ustrukturyzować, zaufać LLM crawlerom, że zchunkują prawidłowo.

Jakie są benchmarki chunk size per branża?

Content marketing (blog, docs): 300–600 tokenów. Technical documentation (programming, APIs): 500–1000 tokenów (więcej kontekstu). Legal / medical: 800–1200 tokenów (precyzja > szybkość). E-commerce (product descriptions): 128–300 tokenów (dyskretne produkty). FAQ / help center: 150–400 tokenów per Q&A. News / reporting: 200–400 tokenów (krótkie jednostki informacji). Rekomendacja: start od standardowych (300–600), iteruj na podstawie accuracy testów retrievalu.

Czy hierarchiczny chunking ma przewagę?

Tak, dla enterprise knowledge bases. Hierarchiczny chunking przechowuje wiele poziomów: small (128 t), medium (512 t), large (1500 t). Retrieval zwraca small dla precision, medium dla kontekstu, large dla całych sekcji. LlamaIndex AutoMergingRetriever robi to natywnie. Dla typowego content marketing overhead overweights benefit — standardowy single-level chunking (512 tokenów + 20% overlap) wystarczy dla 90% use cases.

Jak ewaluować jakość chunkingu?

Trzy metryki: (1) Retrieval recall — czy dla danego query retrievujemy chunk zawierający odpowiedź? Cel: ≥ 85%. (2) Chunk coherence — czy chunk ma spójny semantic sens (sprawdzane human eval lub LLM-as-judge)? Cel: ≥ 4/5. (3) Chunk boundaries — czy chunki nie tną zdań / sekcji? Sprawdź ręcznie 20 próbek. Dla content marketing kluczowa jest metryka 1 — upewnij się, że odpowiedzi w Twoich treściach są „findable” przez LLM retrieval.

Co dalej

Chunkowanie to techniczny lower-level proces, ale rozumienie go pozwala pisać treści, które LLM łatwo interpretują. Inwestycja w strukturę dokumentu jest długoterminowa — niezależnie od zmian w strategiach chunkingu, dobrze zstrukturyzowany tekst wygrywa.

• Treści pod LLM — framework — pełny kontekst AIO writing.
• Struktura artykułu AI — praktyczne zasady struktury.
• Jak działa wyszukiwanie AI — co robi LLM między chunkingiem a odpowiedzią.
• AIO 2026 — przewodnik — pełny kontekst.