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. Szczegóły opisujemy w Treści pod LLM — framework.

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 ciąg procesów 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). Więcej o tym zagadnieniu znajdziesz w Struktura artykułu AI.

• 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%). Szczegóły opisujemy w Jak działa wyszukiwanie AI.

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. Szczegóły opisujemy w AIO 2026 – przewodnik.

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).

Case studies – chunking w praktyce

Case 1: blog fintech – 31% wzrost cytowań w Perplexity

Polski blog z tematyki pożyczek i finansów osobistych (120 artykułów, średnio 1800 słów) miał problem: w Perplexity pojawiał się jako źródło tylko w 8% zapytań branżowych. Audyt wykazał typowe błędy struktury — akapity 8–12 zdań, sekcje H2 po 1000–1500 słów, brak FAQ.

• Refactor strukturalny (6 tygodni): akapity do 2–4 zdań, H2 co 400 słów, dodanie FAQ 5–7 w każdym artykule.
• Konsekwencja: średnia długość chunka spadła z 920 do 380 tokenów, liczba chunków per artykuł wzrosła z 4 do 11.
• Rezultat po 90 dniach: cytowania w Perplexity 8% → 39% (+387%), w ChatGPT Search z 3% → 22%, w Gemini z 5% → 28%.
• Organic traffic z AI referrerów wzrósł o 240%, mierzone przez user-agent w Matomo.

Case 2: help center SaaS — RAG chatbot z semantic chunking

Dostawca narzędzia do księgowości zbudował własny AI support chatbot na bazie 840 artykułów help center. Pierwsza iteracja (LangChain RecursiveCharacterTextSplitter, fixed 1000 tokenów, 10% overlap): retrieval recall 62%, chatbot dawał niedokładne odpowiedzi w 38% zapytań.

• Druga iteracja (SemanticChunker z threshold 0,7, chunk 300–700 tokenów): retrieval recall 84% (+22 pkt).
• Trzecia iteracja (hierarchiczny chunking small/medium/large): retrieval recall 91%.
• Koszt: semantic chunking 3,2x droższy niż fixed (embedding calls), ale jakość odpowiedzi wzrosła – tier 1 support tickets spadły o 34%.
• ROI: savings z support tickets (350 000 PLN/rok) przewyższają koszt infrastruktury (60 000 PLN/rok) 5,8×.

Tutorial: chunking dla własnej bazy wiedzy z LangChain

Przykład ciąg procesów dla marketera, który buduje RAG na bazie 200 artykułów firmowych. Setup Python + LangChain + Pinecone.

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_pinecone import PineconeVectorStore

# Ustaw chunking pod content marketing
splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,       # tokens
    chunk_overlap=100,    # ~20%
    separators=["

", "
", ". ", " ", ""],
    length_function=lambda x: len(tiktoken.get_encoding("cl100k_base").encode(x)),
)

# Wczytaj dokumenty (HTML z blogu)
docs = load_wordpress_articles(site="semtools.pl")

# Chunkuj
chunks = splitter.split_documents(docs)
print(f"Zindeksowano {len(chunks)} chunków z {len(docs)} dokumentów")

# Embed i zapisz do vector store
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vs = PineconeVectorStore.from_documents(
    chunks, embeddings, index_name="blog-kb"
)

Dla dokumentów HTML z WordPressa zamiast RecursiveCharacterTextSplitter użyj HTMLHeaderTextSplitter, który respektuje H2/H3 struktury:

from langchain_text_splitters import HTMLHeaderTextSplitter

headers_to_split_on = [
    ("h1", "h1"),
    ("h2", "h2"),
    ("h3", "h3"),
]
html_splitter = HTMLHeaderTextSplitter(headers_to_split_on)
chunks = html_splitter.split_text_from_url("https://semtools.pl/artykul")

Integracja chunkingu z content stackiem

Chunking + WordPress

Plugin Blogers Connector (lub własny) eksportuje artykuły jako strukturyzowane JSON z H2/H3/paragraphs jako dyskretnymi polami. To eliminuje parsing HTML w chunking ciąg procesów. Alternatywnie: WP REST API /wp-json/wp/v2/posts + Python BeautifulSoup do pre-processing.

Chunking + Algolia / Meilisearch

Standardowe wyszukiwarki full-text również korzystają z chunkingu, choć inaczej niż LLM. Algolia indeksuje „attributes” (title, body, headers) — split po H2 daje osobne rekordy dla każdej sekcji. Dla witryny 500+ artykułów: 5–10x więcej rekordów, ale znacznie lepsze search relevance.

Chunking + GA4

Aby zmierzyć jak chunking wpływa na zaangażowanie: custom events w GTM per H2 section (scroll past H2). GA4 raport: „zaangażowanie per section” pokazuje, które chunki użytkownicy rzeczywiście czytają. Pomaga odkryć H2, które są pomijane (zbyt długie, niejasne) — kandydaci do rewrite.

Embedding models – jak wybrać

Chunking bez dobrego embedding modelu daje słabe retrieval. W 2026 dominują trzy rodziny modeli:

Model	Wymiary	Koszt / 1M tok.	Mocne strony
OpenAI text-embedding-3-large	3072	0,13 USD	General purpose, multilingual
Voyage-3	1024	0,12 USD	State-of-the-art retrieval
Cohere embed-v3	1024	0,10 USD	Compression, multilingual
Jina embeddings v3	1024	0,02 USD	Open source, cheap
BGE-large (self-hosted)	1024	0 USD (infra)	Open source, on-prem

Dla polskiego contentu: Voyage-3 i OpenAI text-embedding-3-large dają najlepsze wyniki (retrieval recall ≥ 85% w wewnętrznych testach). Cohere embed-v3 Matryoshka pozwala redukować wymiar do 256/512 z marginalną utratą jakości — oszczędność storage 2–4x.

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. Pełen obraz tematu znajdziesz w kompletnym przewodniku aio 2026.

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% przypadki użycia.

Jak reindeksować dokumenty po zmianie chunk strategy?

Musisz re-chunkować i re-embedować całą bazę. Stare embeddings nie matchują nowych chunków — nie możesz ich zostawić. Procedura: (1) wersjonuj chunk strategy w config (chunk_strategy_v1.2); (2) zaindeksuj nowe chunki w parallel namespace w vector DB (Pinecone: nowy namespace, Weaviate: nowy class); (3) testuj quality na 50 queries; (4) jeśli lepsze – switch production endpoint, delete stare. Koszt reembedding 10 000 artykułów: 30–80 USD, czas 2–6 godz.

Czy contextual retrieval (Anthropic) zmienia chunking?

Tak – zmienia podejście. Contextual retrieval (Anthropic, Sep 2024) preprocess chunków: dla każdego chunka, Claude generuje krótki kontekstowy opis (50–100 słów) łączący chunk z parent document. Ten opis konkatenuje się z chunkiem przed embedding. Rezultat: retrieval accuracy +35% vs. standard chunking. Koszt: dodatkowe 0,02 USD per chunk (Claude Haiku). Dla bazy 10k chunków: +200 USD one-time. Wart dla production RAG; overkill dla marketing content indeksowanego przez publiczne LLM.

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.

Reranking — druga warstwa po chunking retrievalu

Samo chunking + embedding retrieval (bi-encoder search) ma limit jakości. Dla production RAG warstwa reranker (cross-encoder) podnosi precyzję o 15–30 pkt.

Jak działa reranker

1. Bi-encoder retrieval zwraca top-k (np. 20) chunków z vector DB.
2. Cross-encoder (np. Cohere Rerank, Voyage Rerank) ocenia każdą parę query–chunk score 0–1.
3. Top-n (np. 5) po reranku idzie do LLM jako kontekst.
4. Koszt dodatkowy: 0,001 USD per query (Cohere), latencja +80 ms.

Kiedy warto

• Production chatbot z > 1000 queries/dzień – każdy point precyzji się opłaca.
• Domain-specific (legal, medical) — wysokie koszty błędnych odpowiedzi.
• Long document retrieval – gdy podobieństwo bazowe embedding nie wystarcza.

Kiedy pominąć

• Public content marketing – LLM i tak nie używa Twojego rerankera.
• Mały RAG (< 100 queries/dzień) – ROI nie uzasadnia dodatkowej warstwy.
• Latency-critical aplikacje (voice assistants) — 80 ms może przesunąć SLA.

Monitoring i metryki chunkingu w czasie

Chunking to nie one-off setup – bazy wiedzy rosną, publikujesz nowe artykuły, modele się zmieniają. Bez monitoringu jakość retrievalu degraduje się niewidocznie.

Metryki do trackingu w dashboardzie

• Retrieval recall@k — dla k=3, k=5, k=10. Target recall@5 > 85%.
• Chunk hit rate – % chunków retrievowanych przynajmniej raz/miesiąc. Niski hit rate = duplikaty albo dead content.
• Average chunk size – trend w czasie. Duże wahania = inkonsystencja struktury.
• Embedding cost per month – monitoring budżetu, szczególnie przy częstym reembedding.
• P95 retrieval latency – dla production RAG. Target < 300 ms.

Regresje do wyłapywania

1. Nowy artykuł bez FAQ — chunk coverage dla tego dokumentu spada.
2. Edycja existing content bez reembedding — chunki stale.
3. Zmiana modelu LLM (GPT-4 → GPT-4.5) — różne tokenization, różne chunk boundaries.
4. Rozrost bazy > 50% – może wymagać hierarchical chunking albo reranker warstwy.

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.

Dla content marketera priorytet to trzy rzeczy: krótkie akapity (2–4 zdania), H2 co 400–500 słów, FAQ w formacie details/summary. Reszta to inżynieria retrieval system – warto znać koncepcje, ale nie musisz implementować chunkingu samodzielnie, żeby być cytowanym w Perplexity i ChatGPT.