recursive-char (Standard). Versucht zuerst auf Absätzen zu splitten, dann auf Zeilen, dann auf Satzgrenzen ( . ), dann auf Leerzeichen. Jedes Stück wird greedy bis zur Chunk-Größe gepackt. Fällt nur dann auf harten Zeichensplit zurück, wenn nichts anderes passt. Standard in LangChain, LlamaIndex und den meisten Produktions-RAG-Stacks; vernünftiger Startpunkt für fast jedes Prosa-Korpus. sentence . Splittet an Satzgrenzen und nie innerhalb eines Satzes — auch wenn ein Satz kürzer als das Budget ist, bleibt er ganz. Besser als recursive-char, wenn Chunks als Beweis zitiert werden (QA, Zitationen), weil kein Chunk mitten im Gedanken endet. Chunk-Größen variieren stärker, weil Sätze es tun. paragraph . Behandelt jeden Absatz als Einheit. Zwei kurze benachbarte Absätze können zusammengepackt werden, aber ein langer Absatz wird nie geteilt. Nützlich für Doku, Knowledge-Base-Artikel und gut formatierte Langtexte, wo jeder Absatz ein kohärenter Gedanke ist. semantic . Erweitert Paragraph um Heading-Erkennung: Zeilen mit # , ## usw., oder kurze All-Caps-Zeilen werden als neue Sektion behandelt. Gut für technische Doku, wo Sektionsgrenzen wichtiger sind als visuelle Absatzabstände.

Ist eine Heuristik. Zeichen / 3.8 für englisch-ähnlichen Text und 1 Token pro CJK-Zeichen. ±5–10% für Prosa, schlechter für Code-lastige oder strukturierte Texte. Warum nicht der echte Tokenizer? tiktoken ist ~1 MB WASM — zu schwer nur fürs Chunk-Sizing. Wenn dein Downstream-Modell ein hartes Tokenlimit auf Chunks hat (z. B. cohere/embed-v3 mit 512), baue mit Sicherheitsmarge oder fahre den echten Tokenizer in deiner Pipeline. Für Sizing ist das fein. Die exakte Token-Zahl pro Chunk ist für RAG-Qualität egal — das Embedding-Modell trunkiert sowieso. Was zählt ist Konsistenz: gleiche Heuristik fürs Chunking und fürs Budgetieren der Downstream-Prompts.

RAG-Text-Chunker

Zerlege Text in token-große Chunks für RAG- / Embeddings-Vorbereitung. Mehrere Strategien: recursive char, satz-aware, semantische Grenzen. Konfigurierbarer Overlap. Alles im Browser.

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

Wozu ist das gut?

Retrieval-Augmented Generation (RAG) und Embedding-basierte Suche hängen beide davon ab, ein Korpus in Chunks zu zerlegen: kleine Stücke, die einzeln eingebettet und in einer Vektor-Datenbank gespeichert werden. Der Split passiert vor jeder KI-Mechanik, aber die Qualität deines Retrievals hängt heimlich mehr davon ab, als die meisten denken. Zu kleine Chunks verlieren Kontext; zu große verwässern Relevanz; mitten im Satz geteilte Chunks retrieven schlecht, weil das Embedding an einer seltsamen semantischen Stelle landet. Dieses Tool ist ein schneller Browser-Spielplatz, um Chunk-Größe, Overlap und Strategie auszuprobieren, bevor du eine Pipeline darauf festlegst.

Die vier Strategien

recursive-char (Standard). Versucht zuerst auf Absätzen zu splitten, dann auf Zeilen, dann auf Satzgrenzen (. ), dann auf Leerzeichen. Jedes Stück wird greedy bis zur Chunk-Größe gepackt. Fällt nur dann auf harten Zeichensplit zurück, wenn nichts anderes passt. Standard in LangChain, LlamaIndex und den meisten Produktions-RAG-Stacks; vernünftiger Startpunkt für fast jedes Prosa-Korpus.
sentence. Splittet an Satzgrenzen und nie innerhalb eines Satzes — auch wenn ein Satz kürzer als das Budget ist, bleibt er ganz. Besser als recursive-char, wenn Chunks als Beweis zitiert werden (QA, Zitationen), weil kein Chunk mitten im Gedanken endet. Chunk-Größen variieren stärker, weil Sätze es tun.
paragraph. Behandelt jeden Absatz als Einheit. Zwei kurze benachbarte Absätze können zusammengepackt werden, aber ein langer Absatz wird nie geteilt. Nützlich für Doku, Knowledge-Base-Artikel und gut formatierte Langtexte, wo jeder Absatz ein kohärenter Gedanke ist.
semantic. Erweitert Paragraph um Heading-Erkennung: Zeilen mit #, ## usw., oder kurze All-Caps-Zeilen werden als neue Sektion behandelt. Gut für technische Doku, wo Sektionsgrenzen wichtiger sind als visuelle Absatzabstände.

Overlap — warum und wie viel

Warum. Fällt ein relevanter Abschnitt genau zwischen zwei Chunks, retrieven beide schlecht, weil jeder nur die Hälfte hat. Overlap kopiert die letzten N Tokens des vorherigen Chunks an den Anfang des nächsten, damit beide den Abschnitt einfangen können.
Wie viel. 10–20% der Chunk-Größe ist die Faustregel. Bei 500 Tokens also 50–100 Tokens Overlap. Standard hier 50, funktioniert gut in der Praxis.
Trade-off. Mehr Overlap = mehr Embeddings (mehr Storage, mehr Kosten, langsamerer Indexaufbau, mehr Retrieval-Kandidaten). Geh nicht über 30% ohne spezifischen Grund; verbrennt Geld ohne deutlich besseres Retrieval.

Token-Schätzung

Ist eine Heuristik. Zeichen / 3.8 für englisch-ähnlichen Text und 1 Token pro CJK-Zeichen. ±5–10% für Prosa, schlechter für Code-lastige oder strukturierte Texte.
Warum nicht der echte Tokenizer? tiktoken ist ~1 MB WASM — zu schwer nur fürs Chunk-Sizing. Wenn dein Downstream-Modell ein hartes Tokenlimit auf Chunks hat (z. B. cohere/embed-v3 mit 512), baue mit Sicherheitsmarge oder fahre den echten Tokenizer in deiner Pipeline.
Für Sizing ist das fein. Die exakte Token-Zahl pro Chunk ist für RAG-Qualität egal — das Embedding-Modell trunkiert sowieso. Was zählt ist Konsistenz: gleiche Heuristik fürs Chunking und fürs Budgetieren der Downstream-Prompts.

Typische Stolperfallen

JSON oder CSV nicht mit einem Text-Chunker chunken. Chunk-Grenzen fallen mitten in Records, Embeddings werden bedeutungslos. Erst auf Record-Grenzen splitten oder einen tool-spezifischen RAG-Ansatz nutzen.
Code nicht mit einem Prosa-Chunker chunken. Für Code-Retrieval zählen Funktionsgrenzen, nicht Zeichenzahlen. Tree-sitter-basierte Chunker gibt's dafür.
Whitespace und BOM. Eingefügter Text kann unsichtbares Whitespace tragen, das Token-Schätzungen verzerrt. Vor dem Einfügen trimmen und normalisieren, wenn's drauf ankommt.
Privacy. Alles läuft im Browser. Hier eingefügte Dokumente verlassen die Seite nie; nutzbar für vertrauliches oder PII-haltiges Material, genau wie ein lokales Skript.