recursive-char (domyślne). Najpierw próbuje dzielić po akapitach, potem nowych liniach, potem granicach zdań ( . ), potem spacjach. Każdy kawałek jest greedy pakowany do budżetu. Wpada w hard split po znakach tylko jak nic innego nie pasuje. Default w LangChain, LlamaIndex i większości produkcyjnych stacków RAG; rozsądny punkt startowy dla niemal każdego korpusu prozy. sentence . Dzieli na granicach zdań i nigdy wewnątrz zdania — nawet jak jest krótsze niż budżet, zostaje całe. Lepsze od recursive-char gdy chunki będą cytowane jako dowód (QA, cytaty), bo żaden nie kończy się w środku myśli. Rozmiary bardziej zmienne, bo zdania są. paragraph . Traktuje każdy akapit jako jednostkę. Dwa sąsiadujące krótkie mogą być zapakowane razem, ale długi nigdy nie jest dzielony. Przydatne dla dokumentacji, artykułów KB i dobrze sformatowanych long-formów gdzie każdy akapit to spójna myśl. semantic . Dodaje detekcję nagłówków ponad paragraph: linie z # , ## itd., albo krótkie linie all-caps, traktowane jako początek nowej sekcji. Dobre dla dokumentacji technicznej gdzie granice sekcji liczą się bardziej niż wizualne odstępy.

To heurystyka. znaki / 3.8 dla tekstu angielsko-podobnego i 1 token na znak CJK. ±5–10% dla prozy, gorzej dla code-heavy lub strukturyzowanego. Czemu nie prawdziwy tokenizer? tiktoken to ~1 MB WASM — za ciężko tylko do sizingu. Jeśli twój downstream model ma twardy limit (np. cohere/embed-v3 na 512), buduj z marginesem albo odpal prawdziwy tokenizer w pipelinie. Do sizingu jest ok. Dokładna liczba tokenów per chunk mało znaczy dla jakości RAG — model embeddingowy i tak trunkuje. Co się liczy to spójność: ta sama heurystyka do chunkingu i do budżetowania downstream promptów.

Nie chunkuj danych strukturyzowanych (JSON, CSV) chunkerem tekstu. Granice wpadają w środek rekordów i embeddingi tracą sens. Najpierw podziel po rekordach albo użyj specyficznego podejścia RAG. Nie chunkuj kodu chunkerem prozy. Dla retrievalu kodu liczą się granice funkcji, nie liczby znaków. Istnieją chunkery oparte na tree-sitter. Whitespace i BOM. Wklejony tekst może nieść ukryty whitespace zaburzający estymację. Trimuj i normalizuj przed wklejeniem jeśli ważne. Prywatność. Wszystko leci w przeglądarce. Wklejone dokumenty nigdy nie opuszczają strony; możesz tego używać do poufnego materiału lub z PII jak lokalnego skryptu.

RAG Text Chunker

Dziel tekst na chunki o rozmiarze w tokenach do RAG / przygotowania embeddingów. Wiele strategii: recursive char, sentence-aware, semantic boundaries. Konfigurowalny overlap. Całość w przeglądarce.

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

Do czego to służy?

RAG (Retrieval-Augmented Generation) i wyszukiwanie po embeddingach zależą oba od dzielenia korpusu na chunki: małe kawałki, które są pojedynczo embedowane i przechowywane w vector DB. Podział dzieje się przed jakąkolwiek maszynerią AI, ale jakość twojego retrievalu zależy od niego po cichu bardziej niż większość ludzi sądzi. Za małe chunki tracą kontekst; za duże rozcieńczają relewancję; chunki ucięte w środku zdania retrievują źle, bo embedding ląduje w dziwnym semantycznym miejscu. To narzędzie to szybki playground w przeglądarce do eksperymentowania z rozmiarem, overlapem i strategią przed zafiksowaniem pipeline'u.

Cztery strategie

recursive-char (domyślne). Najpierw próbuje dzielić po akapitach, potem nowych liniach, potem granicach zdań (. ), potem spacjach. Każdy kawałek jest greedy pakowany do budżetu. Wpada w hard split po znakach tylko jak nic innego nie pasuje. Default w LangChain, LlamaIndex i większości produkcyjnych stacków RAG; rozsądny punkt startowy dla niemal każdego korpusu prozy.
sentence. Dzieli na granicach zdań i nigdy wewnątrz zdania — nawet jak jest krótsze niż budżet, zostaje całe. Lepsze od recursive-char gdy chunki będą cytowane jako dowód (QA, cytaty), bo żaden nie kończy się w środku myśli. Rozmiary bardziej zmienne, bo zdania są.
paragraph. Traktuje każdy akapit jako jednostkę. Dwa sąsiadujące krótkie mogą być zapakowane razem, ale długi nigdy nie jest dzielony. Przydatne dla dokumentacji, artykułów KB i dobrze sformatowanych long-formów gdzie każdy akapit to spójna myśl.
semantic. Dodaje detekcję nagłówków ponad paragraph: linie z #, ## itd., albo krótkie linie all-caps, traktowane jako początek nowej sekcji. Dobre dla dokumentacji technicznej gdzie granice sekcji liczą się bardziej niż wizualne odstępy.

Overlap — dlaczego i ile

Dlaczego. Jeśli relewantny fragment wypada dokładnie między dwoma chunkami, oba retrievują źle bo każdy ma tylko połowę. Overlap kopiuje ostatnie N tokenów z poprzedniego chunka na początek następnego, dając obu szansę przechwycenia.
Ile. 10–20% rozmiaru chunka jako reguła. Dla chunków 500-tokenowych, 50–100 overlap. Default tu to 50, działa dobrze w praktyce.
Trade-off. Więcej overlapu = więcej embeddingów łącznie (więcej storage, więcej kosztów, wolniejszy build indeksu, więcej kandydatów retrievalu). Nie przekraczaj 30% bez konkretnego powodu; tracisz kasę bez większego zysku.

Estymacja tokenów

To heurystyka. znaki / 3.8 dla tekstu angielsko-podobnego i 1 token na znak CJK. ±5–10% dla prozy, gorzej dla code-heavy lub strukturyzowanego.
Czemu nie prawdziwy tokenizer? tiktoken to ~1 MB WASM — za ciężko tylko do sizingu. Jeśli twój downstream model ma twardy limit (np. cohere/embed-v3 na 512), buduj z marginesem albo odpal prawdziwy tokenizer w pipelinie.
Do sizingu jest ok. Dokładna liczba tokenów per chunk mało znaczy dla jakości RAG — model embeddingowy i tak trunkuje. Co się liczy to spójność: ta sama heurystyka do chunkingu i do budżetowania downstream promptów.

Częste pułapki

Nie chunkuj danych strukturyzowanych (JSON, CSV) chunkerem tekstu. Granice wpadają w środek rekordów i embeddingi tracą sens. Najpierw podziel po rekordach albo użyj specyficznego podejścia RAG.
Nie chunkuj kodu chunkerem prozy. Dla retrievalu kodu liczą się granice funkcji, nie liczby znaków. Istnieją chunkery oparte na tree-sitter.
Whitespace i BOM. Wklejony tekst może nieść ukryty whitespace zaburzający estymację. Trimuj i normalizuj przed wklejeniem jeśli ważne.
Prywatność. Wszystko leci w przeglądarce. Wklejone dokumenty nigdy nie opuszczają strony; możesz tego używać do poufnego materiału lub z PII jak lokalnego skryptu.