Chunking
Chunking is how a document becomes searchable passages. It's the single setting that most affects whether retrieval works well, and it's the one people skip.
Why documents are split
Two reasons:
- Search precision. A 40-page manual is about forty things. As one unit it matches every question weakly and no question strongly. Split into passages, the paragraph about refunds matches a refund question exactly.
- Context limits. The retrieved passages are pasted into the model's prompt. Whole documents don't fit — and even where they do, you pay for every token of them on every message.
A good chunk is one self-contained idea: enough context to make sense on its own, not so much that it's about several things at once.
Choosing a splitter
Flowera offers six text splitters. Pick by what the content is:
| Splitter | Splits on | Use for |
|---|---|---|
| Recursive Character Text Splitter | Paragraphs, then sentences, then words | Almost everything. The right default |
| Character Text Splitter | One separator you choose | Content with a reliable delimiter |
| Markdown Text Splitter | Markdown headings and structure | Docs, READMEs, knowledge bases in Markdown |
| HtmlToMarkdown Text Splitter | HTML structure, converting to Markdown first | Scraped web pages |
| Token Text Splitter | Model tokens | When you need exact token-count control |
| Code Text Splitter | Language syntax — functions, classes | Source code |
The recursive splitter earns its default status: it tries to break at a paragraph, falls back to a sentence, and only splits mid-sentence when it has no choice. That's usually what you want.
Chunk size and overlap
Two numbers, both worth understanding:
Chunk size is the maximum characters per chunk.
| Size | Effect |
|---|---|
| Small (~300–500) | Precise matches, but passages may lack the context to be useful |
| Medium (~800–1500) | The usual sweet spot for prose |
| Large (~2000+) | Rich context, vaguer matching, more tokens per message |
Chunk overlap is how much text repeats between neighbours. Overlap exists because a sentence split across two chunks is understandable in neither. A common rule is 10–20% of the chunk size — 200 characters of overlap on 1000-character chunks.
Start at 1000 / 200 — the shipped default for every splitter — and adjust based on what the query playground returns. This is an empirical setting, not one to reason your way to.
Viewing stored chunks
From a loader's Options, choose View & Edit Chunks to see everything it produced, with the count and the character totals.
Reading the chunks is the fastest way to explain bad answers. If the retrieved passage doesn't contain the fact the customer asked about, the problem is here — not in the prompt.
Editing and removing chunks
Individual chunks can be edited or deleted. This is genuinely useful for:
- Deleting noise — nav bars, cookie banners, page footers that came in with a scrape.
- Fixing extraction damage — a table that came out as a wall of numbers.
- Removing content that's simply wrong — an outdated price that keeps surfacing.
Two caveats. Edits are lost if you reload the loader from its source, so fix the source when you can. And an edit does not change the store's badge — it still reads Upserted while the index serves the old text. Upsert again after editing; nothing will remind you.
Related
- Document loaders — where chunks come from, and previewing them
- Vector store — making chunks searchable
- Query playground — checking whether your chunking works