recursive-char (predvolené). Pokúsi sa rozdeliť najprv na odsekoch, potom nových riadkoch, potom hraniciach viet ( . ), potom medzerách. Každý kúsok sa hltavo zabalí do rozpočtu veľkosti. Spadne na tvrdé delenie po znakoch len ak nič iné nesedí. Predvolené v LangChain, LlamaIndex a väčšine produkčných RAG stackov; rozumné východisko pre takmer každý prózový korpus. sentence . Delí na hraniciach viet a nikdy vnútri vety — aj keď je veta kratšia než rozpočet, ostane celá. Lepšie ako recursive-char keď budú chunky citované ako dôkaz (QA, citácie), lebo žiadny chunk nekončí uprostred myšlienky. Veľkosti chunkov variabilnejšie, lebo dĺžky viet sú. paragraph . Spracúva každý odsek ako jednotku. Dva susedné krátke odseky môžu byť zabalené spolu, ale dlhý odsek nikdy nie je rozdelený. Užitočné pre dokumentáciu, KB články a dobre formátované long-form, kde každý odsek je súdržná myšlienka. semantic . Pridáva detekciu nadpisov nad paragraph: riadky začínajúce # , ## atď., alebo krátke veľkomi-písmenkové riadky, sú spracované ako začiatok novej sekcie. Dobré pre technickú dokumentáciu, kde hranice sekcií zaberajú viac než vizuálny odsadenie.

Je to heuristika. znaky / 3.8 pre angličtinu-podobný text a 1 token na znak CJK. ±5–10% pre prózu, horšie pre code-heavy alebo štruktúrovaný text. Prečo nie skutočný tokenizer? tiktoken je ~1 MB WASM — príliš ťažký len pre sizing. Ak má tvoj downstream model tvrdý limit tokenov na chunky (niektoré majú, napr. cohere/embed-v3 je capnutý na 512), stavaj s bezpečnostnou rezervou alebo spusti skutočný tokenizer v pipeline. Pre sizing je to fajn. Presný počet tokenov na chunk veľa neznamená pre kvalitu RAG — embedding model príliš veľké vstupy aj tak skráti. Čo sa počíta je konzistencia: rovnaká heuristika pre chunking aj pre budgetovanie downstream promptov.

Štruktúrované dáta (JSON, CSV) nechunkuj textovým chunkerom. Hranice padnú doprostred záznamov a embeddingy stratia zmysel. Najprv rozdeľ na hraniciach záznamov, alebo použi tool-špecifický RAG prístup. Kód nechunkuj prózovým chunkerom. Pre retrieval kódu sú dôležité hranice funkcií, nie počty znakov. Existujú chunkery založené na tree-sitter. Whitespace a BOM. Vložený text môže niesť skryté whitespace, ktoré skresľuje odhad tokenov. Trimni a normalizuj pred vložením, ak na tom záleží. Súkromie. Všetko beží v prehliadači. Dokumenty vložené sem nikdy neopustia stránku; môžeš to používať na dôverný alebo PII obsahujúci materiál tak isto, ako by si použil lokálny skript.

RAG Text Chunker

Rozdeľ text na token-veľké chunky pre prípravu RAG / embeddingov. Viac stratégií: recursive char, sentence-aware, semantic boundaries. Konfigurovateľný overlap. Všetko v prehliadač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

Načo to slúži?

RAG (Retrieval-Augmented Generation) a vyhľadávanie založené na embeddingoch oba závisia od rozdelenia korpusu na chunky: malé kúsky, ktoré sú jednotlivo embednuté a uložené vo vector DB. Rozdelenie sa deje pred akoukoľvek AI mašinériou, ale kvalita tvojho retrievalu na tom potichu závisí viac, než si väčšina uvedomuje. Príliš malé chunky strácajú kontext; príliš veľké rozriedia relevanciu; chunky rozdelené uprostred vety zle retrievujú, lebo embedding pristane v zvláštnom sémantickom bode. Tento nástroj je rýchle ihrisko v prehliadači na experimentovanie s veľkosťou chunku, overlapom a stratégiou pred tým, než pipeline zafixuješ.

Štyri stratégie

recursive-char (predvolené). Pokúsi sa rozdeliť najprv na odsekoch, potom nových riadkoch, potom hraniciach viet (. ), potom medzerách. Každý kúsok sa hltavo zabalí do rozpočtu veľkosti. Spadne na tvrdé delenie po znakoch len ak nič iné nesedí. Predvolené v LangChain, LlamaIndex a väčšine produkčných RAG stackov; rozumné východisko pre takmer každý prózový korpus.
sentence. Delí na hraniciach viet a nikdy vnútri vety — aj keď je veta kratšia než rozpočet, ostane celá. Lepšie ako recursive-char keď budú chunky citované ako dôkaz (QA, citácie), lebo žiadny chunk nekončí uprostred myšlienky. Veľkosti chunkov variabilnejšie, lebo dĺžky viet sú.
paragraph. Spracúva každý odsek ako jednotku. Dva susedné krátke odseky môžu byť zabalené spolu, ale dlhý odsek nikdy nie je rozdelený. Užitočné pre dokumentáciu, KB články a dobre formátované long-form, kde každý odsek je súdržná myšlienka.
semantic. Pridáva detekciu nadpisov nad paragraph: riadky začínajúce #, ## atď., alebo krátke veľkomi-písmenkové riadky, sú spracované ako začiatok novej sekcie. Dobré pre technickú dokumentáciu, kde hranice sekcií zaberajú viac než vizuálny odsadenie.

Overlap — prečo a koľko

Prečo. Ak relevantný úsek padne presne na hranicu medzi dvoma chunkmi, oba retrievujú zle, lebo každý má len polovicu. Overlap skopíruje posledných N tokenov predchádzajúceho chunku na začiatok ďalšieho, dáva obom šancu zachytiť úsek.
Koľko. 10–20% veľkosti chunku ako pravidlo. Pre 500-tokenové chunky 50–100 tokenov overlapu. Predvolené tu je 50, v praxi funguje dobre.
Trade-off. Viac overlapu = viac celkových embeddingov (viac storage, viac nákladov, pomalší build indexu, viac kandidátov retrievalu). Nechoď nad 30% bez konkrétneho dôvodu; zbytočne míňaš peniaze bez veľkého zlepšenia retrievalu.

Odhad tokenov

Je to heuristika. znaky / 3.8 pre angličtinu-podobný text a 1 token na znak CJK. ±5–10% pre prózu, horšie pre code-heavy alebo štruktúrovaný text.
Prečo nie skutočný tokenizer? tiktoken je ~1 MB WASM — príliš ťažký len pre sizing. Ak má tvoj downstream model tvrdý limit tokenov na chunky (niektoré majú, napr. cohere/embed-v3 je capnutý na 512), stavaj s bezpečnostnou rezervou alebo spusti skutočný tokenizer v pipeline.
Pre sizing je to fajn. Presný počet tokenov na chunk veľa neznamená pre kvalitu RAG — embedding model príliš veľké vstupy aj tak skráti. Čo sa počíta je konzistencia: rovnaká heuristika pre chunking aj pre budgetovanie downstream promptov.

Časté pasce

Štruktúrované dáta (JSON, CSV) nechunkuj textovým chunkerom. Hranice padnú doprostred záznamov a embeddingy stratia zmysel. Najprv rozdeľ na hraniciach záznamov, alebo použi tool-špecifický RAG prístup.
Kód nechunkuj prózovým chunkerom. Pre retrieval kódu sú dôležité hranice funkcií, nie počty znakov. Existujú chunkery založené na tree-sitter.
Whitespace a BOM. Vložený text môže niesť skryté whitespace, ktoré skresľuje odhad tokenov. Trimni a normalizuj pred vložením, ak na tom záleží.
Súkromie. Všetko beží v prehliadači. Dokumenty vložené sem nikdy neopustia stránku; môžeš to používať na dôverný alebo PII obsahujúci materiál tak isto, ako by si použil lokálny skript.