Before a knowledge base can search your documents, it has to split them into chunks — the units that get embedded, indexed, and retrieved. Chunk too small and each result lacks context; chunk too large and retrieval gets blurry while token costs climb. Amazon Bedrock Knowledge Bases documents five chunking strategies, chosen per data source at ingestion time. Because chunking happens at ingestion, changing your mind later means re-ingesting — which is why this decision deserves ten minutes of thought up front.
The five strategies
| Strategy | How it splits | You configure |
|---|---|---|
| Default | ~300-token chunks, honoring sentence boundaries | Nothing |
| Fixed-size | Uniform chunks of your chosen size | Max tokens per chunk + overlap percentage |
| Hierarchical | Small child chunks nested under larger parent chunks | Parent/child max token sizes + absolute overlap tokens |
| Semantic | Splits where meaning shifts | Max tokens, buffer size (surrounding sentences), breakpoint percentile threshold |
| No chunking | One chunk per document | Nothing (you pre-split documents yourself) |
Default is the sensible starting point: roughly 300-token chunks that respect sentence boundaries. Fixed-size is default with the dials exposed — you set the maximum tokens per chunk and an overlap percentage, so consecutive chunks share some text and a sentence straddling a boundary isn't lost to retrieval.
Hierarchical is the clever one. It builds two layers: small child chunks (precise to search) nested under larger parent chunks (rich in context). At query time, child chunks are what get retrieved — then each is replaced by its parent chunk, so Claude receives the surrounding context rather than an isolated fragment. You configure maximum token sizes for both layers plus an absolute overlap in tokens. This is Bedrock's managed version of the small-to-big retrieval idea covered in the general chunking pattern.
Semantic chunking uses a model to find natural topical boundaries instead of counting tokens. You set a maximum chunk size, a buffer size (how many surrounding sentences are considered together), and a breakpoint percentile threshold (how big a shift in meaning triggers a split). The documented catch: it incurs additional foundation-model cost at ingestion, because a model is doing the boundary detection. For a large corpus, price that before choosing it.
No chunking treats each document as a single chunk — the right choice when you've already split documents yourself upstream. The documented trade-off: you lose page-number citations and filtering that chunk-level processing provides.
The two constraints that bite in production
A note on multimodal content
Chunking extends beyond text. With Nova multimodal embeddings, audio and video chunk duration is configurable from 1 to 30 seconds (default 5 seconds). Alternatively, the Bedrock Data Automation parser converts media into text — transcripts and scene summaries — which then flows through the standard text chunking strategies above. Details in multimodal chunking.
Choosing, quickly
Start with default. Move to fixed-size when evaluation shows your content wants bigger or smaller units. Reach for hierarchical when answers need surrounding context (contracts, policies, technical manuals) — minding both constraints above. Try semantic when documents mix many topics and fixed boundaries keep cutting mid-thought, and accept the ingestion cost. Use no-chunking only when you control splitting upstream. Whatever you pick, verify with retrieval evaluations, not vibes — Bedrock's RAG evaluation tooling exists for exactly this.
Where to go next
Continue the Knowledge Bases series with embedding model choice and RetrieveAndGenerate with Claude, or zoom out to RAG basics.