recursive-char (výchozí). Pokusí se rozdělit nejprve na odstavcích, pak nových řádcích, pak hranicích vět ( . ), pak mezerách. Každý kousek se hltavě zabalí do rozpočtu velikosti. Spadne na tvrdé dělení po znacích jen pokud nic jiného nesedí. Výchozí v LangChain, LlamaIndex a většině produkčních RAG stacků; rozumný výchozí bod pro téměř každý prózový korpus. sentence . Dělí na hranicích vět a nikdy uvnitř věty — i když je věta kratší než rozpočet, zůstane celá. Lepší než recursive-char když budou chunky citovány jako důkaz (QA, citace), protože žádný chunk nekončí uprostřed myšlenky. Velikosti chunků jsou proměnlivější, protože délky vět jsou. paragraph . Zpracovává každý odstavec jako jednotku. Dva sousední krátké odstavce mohou být zabaleny spolu, ale dlouhý odstavec není nikdy rozdělen. Užitečné pro dokumentaci, KB články a dobře formátované long-form, kde každý odstavec je soudržná myšlenka. semantic . Přidává detekci nadpisů nad paragraph: řádky začínající # , ## atd., nebo krátké velkoupísmenné řádky, jsou zpracovány jako začátek nové sekce. Dobré pro technickou dokumentaci, kde hranice sekcí zabírají víc než vizuální odsazení.

Je to heuristika. znaky / 3.8 pro angličtina-podobný text a 1 token na znak CJK. ±5–10% pro prózu, horší pro code-heavy nebo strukturovaný text. Proč ne skutečný tokenizer? tiktoken je ~1 MB WASM — příliš těžký jen pro sizing. Pokud má tvůj downstream model tvrdý limit tokenů na chunky (některé mají, např. cohere/embed-v3 je capnutý na 512), stavj s bezpečnostní rezervou nebo spusť skutečný tokenizer v pipeline. Pro sizing je to fajn. Přesný počet tokenů na chunk moc neznamená pro kvalitu RAG — embedding model příliš velké vstupy stejně zkrátí. Co se počítá je konzistence: stejná heuristika pro chunking i pro budgetování downstream promptů.

Strukturovaná data (JSON, CSV) nechunkuj textovým chunkerem. Hranice padnou doprostřed záznamů a embeddings ztratí smysl. Nejprve rozděl na hranicích záznamů, nebo použij tool-specifický RAG přístup. Kód nechunkuj prózovým chunkerem. Pro retrieval kódu jsou důležité hranice funkcí, ne počty znaků. Existují chunkery založené na tree-sitter. Whitespace a BOM. Vložený text může nést skrytý whitespace, který zkresluje odhad tokenů. Trimni a normalizuj před vložením, pokud na tom záleží. Soukromí. Vše běží v prohlížeči. Dokumenty vložené sem nikdy neopustí stránku; můžeš to používat na důvěrný nebo PII obsahující materiál stejně jako bys použil lokální skript.

RAG Text Chunker

Rozděl text na token-velké chunky pro přípravu RAG / embeddingů. Více strategií: recursive char, sentence-aware, semantic boundaries. Konfigurovatelný overlap. Vše v prohlížeči.

Paste your document

RAG (Retrieval-Augmented Generation) is a technique that pairs an LLM with an external knowledge base. Instead of relying only on the model's parametric memory, the system retrieves relevant passages at query time and concatenates them into the prompt.

The retrieval step depends on a vector store. Documents are split into chunks, each chunk gets an embedding vector, and those vectors are stored in a database that supports approximate nearest-neighbour search.

# Chunk size matters

Chunks that are too small lose context — a single sentence might not contain enough information to answer the question. Chunks that are too large dilute relevance — the embedding becomes an average of many unrelated topics, and retrieval gets noisy.

A common starting point is 500 tokens per chunk with 50 tokens of overlap. Overlap lets a chunk see a bit of context from its neighbours, which helps when a relevant span happens to fall across a chunk boundary.

# Strategy choice

Recursive character splitting is the most general: it tries paragraph breaks first, then line breaks, then sentence boundaries, then spaces. This is the default in most frameworks and works well for prose.

Sentence-aware splitting respects sentence boundaries and never breaks mid-sentence. It produces cleaner chunks for QA over articles and books, at the cost of more variable chunk sizes.

Paragraph chunking treats each paragraph as its own chunk (subject to the size limit). This is useful for structured documents like documentation or knowledge-base articles where each section is already a coherent unit.

Semantic chunking goes one step further: it tries to keep semantically related content together by respecting headings and topic boundaries, even when those don't align with paragraph breaks.

Chunk size (tokens): 500

Overlap (tokens): 50

Strategy

K čemu to slouží?

RAG (Retrieval-Augmented Generation) a vyhledávání založené na embeddings oba závisí na rozdělení korpusu na chunky: malé kousky, které jsou jednotlivě embednuté a uloženy ve vector DB. Rozdělení se děje před jakoukoliv AI mašinerií, ale kvalita tvého retrievalu na tom potichu závisí víc, než si většina uvědomuje. Příliš malé chunky ztrácí kontext; příliš velké zředí relevanci; chunky rozdělené uprostřed věty špatně retrievují, protože embedding přistane v podivném sémantickém bodě. Tenhle nástroj je rychlé hřiště v prohlížeči na experimentování s velikostí chunku, overlapem a strategií předtím, než pipeline zafixuješ.

Čtyři strategie

recursive-char (výchozí). Pokusí se rozdělit nejprve na odstavcích, pak nových řádcích, pak hranicích vět (. ), pak mezerách. Každý kousek se hltavě zabalí do rozpočtu velikosti. Spadne na tvrdé dělení po znacích jen pokud nic jiného nesedí. Výchozí v LangChain, LlamaIndex a většině produkčních RAG stacků; rozumný výchozí bod pro téměř každý prózový korpus.
sentence. Dělí na hranicích vět a nikdy uvnitř věty — i když je věta kratší než rozpočet, zůstane celá. Lepší než recursive-char když budou chunky citovány jako důkaz (QA, citace), protože žádný chunk nekončí uprostřed myšlenky. Velikosti chunků jsou proměnlivější, protože délky vět jsou.
paragraph. Zpracovává každý odstavec jako jednotku. Dva sousední krátké odstavce mohou být zabaleny spolu, ale dlouhý odstavec není nikdy rozdělen. Užitečné pro dokumentaci, KB články a dobře formátované long-form, kde každý odstavec je soudržná myšlenka.
semantic. Přidává detekci nadpisů nad paragraph: řádky začínající #, ## atd., nebo krátké velkoupísmenné řádky, jsou zpracovány jako začátek nové sekce. Dobré pro technickou dokumentaci, kde hranice sekcí zabírají víc než vizuální odsazení.

Overlap — proč a kolik

Proč. Pokud relevantní úsek padne přesně na hranici mezi dvěma chunky, oba retrievují špatně, protože každý má jen polovinu. Overlap zkopíruje posledních N tokenů předchozího chunku na začátek dalšího, dává oběma šanci úsek zachytit.
Kolik. 10–20% velikosti chunku jako pravidlo. Pro 500-tokenové chunky 50–100 tokenů overlapu. Výchozí zde je 50, v praxi funguje dobře.
Trade-off. Více overlapu = víc celkových embeddingů (víc storage, víc nákladů, pomalejší build indexu, víc kandidátů retrievalu). Nepřekračuj 30% bez konkrétního důvodu; zbytečně utrácíš peníze bez většího zlepšení retrievalu.

Odhad tokenů

Je to heuristika. znaky / 3.8 pro angličtina-podobný text a 1 token na znak CJK. ±5–10% pro prózu, horší pro code-heavy nebo strukturovaný text.
Proč ne skutečný tokenizer? tiktoken je ~1 MB WASM — příliš těžký jen pro sizing. Pokud má tvůj downstream model tvrdý limit tokenů na chunky (některé mají, např. cohere/embed-v3 je capnutý na 512), stavj s bezpečnostní rezervou nebo spusť skutečný tokenizer v pipeline.
Pro sizing je to fajn. Přesný počet tokenů na chunk moc neznamená pro kvalitu RAG — embedding model příliš velké vstupy stejně zkrátí. Co se počítá je konzistence: stejná heuristika pro chunking i pro budgetování downstream promptů.

Časté pasti

Strukturovaná data (JSON, CSV) nechunkuj textovým chunkerem. Hranice padnou doprostřed záznamů a embeddings ztratí smysl. Nejprve rozděl na hranicích záznamů, nebo použij tool-specifický RAG přístup.
Kód nechunkuj prózovým chunkerem. Pro retrieval kódu jsou důležité hranice funkcí, ne počty znaků. Existují chunkery založené na tree-sitter.
Whitespace a BOM. Vložený text může nést skrytý whitespace, který zkresluje odhad tokenů. Trimni a normalizuj před vložením, pokud na tom záleží.
Soukromí. Vše běží v prohlížeči. Dokumenty vložené sem nikdy neopustí stránku; můžeš to používat na důvěrný nebo PII obsahující materiál stejně jako bys použil lokální skript.