AWSAWS Certified Generative AI Developer - Professional2026-101.5 Design retrieval mechanisms for FM augmentation
Match chunk boundaries to answer evidence
Completed by the knowledge check
Learning objective
Choose fixed-size, semantic, hierarchical, or no chunking by document structure and retrieval needs.
Core idea
A chunk is both a unit of search and a potential unit of evidence. If a chunk separates a rule from its exception, a relevant retrieval result can still produce an incomplete answer. If it combines unrelated topics, its embedding can dilute the passage that the question needs. Choose boundaries from the documents and questions you expect, rather than from a universal token count.
Amazon Bedrock Knowledge Bases splits ingested text, generates embeddings, and writes them to a vector index with a mapping to the source document. Its chunking strategy controls that text boundary. It does not repair extraction errors, choose the embedding model, or guarantee that retrieved text supports a generated claim. Parsing belongs to 1.5.2; embedding selection belongs to 1.5.3.
How it works
Use fixed-size chunks for a predictable baseline
In CreateDataSource, configure vectorIngestionConfiguration.chunkingConfiguration with chunkingStrategy: FIXED_SIZE. The fixedSizeChunkingConfiguration.maxTokens setting bounds chunk size, while overlapPercentage controls overlap between consecutive chunks. Default chunking is a separate option that produces approximately 300-token chunks and honors sentence boundaries; FIXED_SIZE instead uses the maxTokens and overlapPercentage you set.
Fixed-size chunking is a useful baseline for prose with reasonably uniform structure. Overlap can preserve a sentence or definition near a boundary, but it also repeats content across embeddings and retrieval results. More overlap is not free additional evidence: it adds redundant text to ingestion and can crowd the eventual context.
Do not assume that increasing maxTokens merges every neighboring passage. AWS documents that parsed content, including content from advanced parsers or converted HTML, can retain logical page or section boundaries. The chunker does not merge across those boundaries merely because the configured maximum permits a larger chunk.
Use semantic chunks for topic boundaries
Set chunkingStrategy: SEMANTIC and provide semanticChunkingConfiguration.maxTokens, bufferSize, and breakpointPercentileThreshold. Semantic chunking uses content similarity to find divisions rather than relying only on text length.
The buffer controls the surrounding sentences considered when producing sentence embeddings. A buffer size of 1 considers the current sentence together with its previous and next sentences. A larger buffer can provide context for boundary detection, but it can also smooth over a narrow topic change. The percentile threshold determines which sentence-distance differences produce breakpoints. A higher threshold requires greater dissimilarity, so it tends to produce fewer, larger chunks.
Use this strategy when topic transitions matter more than uniform length, such as a narrative that moves between incident causes and corrective actions. Check actual boundaries: semantically related text is not automatically a complete contractual rule. AWS documents additional foundation-model costs for semantic chunking. Include those ingestion costs in the comparison instead of measuring query quality alone.
Use hierarchical chunks for precise search and broader context
Set chunkingStrategy: HIERARCHICAL. In hierarchicalChunkingConfiguration.levelConfigurations, configure the parent and child maxTokens values, and set overlapTokens. This overlap is an absolute token count, unlike the percentage used for fixed-size chunks. Knowledge Bases supports two levels: parents and children.
Retrieval initially finds child chunks and replaces them with broader parent chunks. This separates the small unit used to locate evidence from the larger unit delivered as context. It is useful when a precise clause needs its surrounding procedure, definitions, or exceptions to be interpreted correctly.
The result-count behavior matters. numberOfResults maps to retrieved children; children with the same parent collapse into a parent result. Receiving fewer final results than requested is therefore not necessarily a retrieval failure. Broader parents also consume more generation context, so assess the returned text size as well as the number of matches.
Children that share a parent collapse into one parent result, so fewer results can return than the requested child count.
AWS does not recommend hierarchical chunking with an S3 vector bucket because high combined chunk token counts, above 8,000, can encounter metadata-size limitations. Scope this constraint to that store; it is not a universal maximum for every hierarchical configuration.
Use no chunking when files already represent evidence units
Set chunkingStrategy: NONE to treat each document as one text chunk. This is useful for short, independently meaningful records or files you split before ingestion. It is also the starting point for custom Lambda chunking; see 1.5.2.
No chunking does not remove the embedding model’s input limits. A whole manual can still exceed the selected model’s supported input, or provide an embedding that mixes too many topics. AWS also documents that no chunking prevents page-number citations and filtering through x-amz-bedrock-kb-document-page-number. Decide whether that loss is acceptable before adopting file-level evidence units.
Key distinctions and trade-offs
Compare the strategies against the same answer-evidence set:
| Strategy | Useful document property | Main trade-off |
|---|---|---|
| Fixed-size | Relatively uniform prose | Predictable configuration can split dependent statements |
| Semantic | Meaningful topic shifts | Content-aware boundaries add model cost and tuning choices |
| Hierarchical | Specific clauses need surrounding context | Precise child matches return larger parent context |
| None | Each file is already a bounded evidence unit | File boundaries must fit retrieval needs and model limits |
These text strategies do not apply universally to every modality. AWS states that native multimodal embeddings chunk audio, video, and images at the embedding-model level. Bedrock Data Automation can instead convert content to text, after which text chunking applies. Identify the ingestion path before interpreting a text chunk setting.
For evaluation, label the passages required to answer each question and inspect Knowledge Bases retrieval outputs. An Amazon Bedrock retrieve-only RAG evaluation job evaluates retrieved data and can compare knowledge bases configured with different chunking strategies; see 5.1.8 for retrieval evaluation and metrics. Record whether the returned chunk includes the required exception, whether overlap creates duplicates, and whether parent replacement expands context excessively. These are application acceptance criteria, not AWS-provided guarantees of correctness.
Architecture / decision scenario
An engineering assistant searches maintenance instructions, incident narratives, short equipment records, and long safety procedures. One global strategy fails because these documents define different evidence units.
The team starts maintenance instructions with FIXED_SIZE and tunes overlap against steps that cross a boundary. It tests SEMANTIC on incident narratives, inspecting whether cause and remediation remain together. It uses HIERARCHICAL for safety procedures where a matched requirement needs surrounding exceptions. Equipment records use NONE because each file is short and self-contained.
Evaluation shows that several child hits collapse into one safety-procedure parent. The team treats that as documented behavior and measures whether the parent contains the full rule. It also finds that equipment questions need page-number citations, so those records cannot remain on the no-chunking path without changing that requirement. The decision follows observed evidence needs, not a preference for the most elaborate strategy.
Common exam traps
- Treating
maxTokensas a promise to merge across parsed page boundaries. - Confusing
overlapPercentagewith hierarchicaloverlapTokens. - Assuming a higher semantic breakpoint threshold creates more chunks.
- Expecting hierarchical retrieval to return exactly the requested child count.
- Choosing
NONEfor arbitrary large files without checking embedding limits. - Applying text chunk settings to native audio or video embeddings.
What to remember
- Choose boundaries that preserve the evidence needed for an answer.
- Fixed-size, semantic, hierarchical, and no chunking solve different boundary problems.
- Hierarchical search locates children but returns parent context.
- No chunking trades automatic splitting and page metadata for file-level control.
- Validate returned content, context size, and ingestion cost together.
Knowledge check
A data source uses an advanced parser and FIXED_SIZE chunking. The team doubles maxTokens so that a requirement and its exception on the next page land in one chunk, but the chunk still ends at the page break. What explains the result?
overlapPercentage value caps each chunk below the new maxTokensmaxTokens would allow it. Raising the maximum therefore cannot join evidence that a page break separates.Incident narratives move between causes and corrective actions at irregular points, and fixed-size chunks often separate a cause from its remediation. Which strategy should the team evaluate next, budgeting for its additional foundation-model cost at ingestion?
HIERARCHICALNONESEMANTICFIXED_SIZE with higher overlapA knowledge base with HIERARCHICAL chunking is queried with numberOfResults set to 10 and returns 6 results. Which diagnosis fits documented behavior?
numberOfResults maps to retrieved child chunks, and children that share a parent collapse into that one parent result. Fewer final results is expected behavior, not a failure; what to check is whether each parent carries the full rule and how much context it consumes.Each source file is a short, complete evidence unit, but the application requires page-number citations. Which consequence of choosing NONE must be resolved first?
NONE adds the foundation-model cost of semantic boundariesNONE turns every file into parent and child chunksNONE removes page numbers from citations and filteringNONE lifts the embedding model’s input-size limit