Skip to lesson

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.

Children that share a parent collapse into one parent result, so fewer results can return than the requested child countThe results requested map to retrieved child chunks. Two of the three children share a parent and collapse into one parent result; the third is replaced by its own parent. Two broader parent results reach the generation context, fewer than the children requested.same parentResults requestedChild chunkChild chunkChild chunkParent resultParent resultGeneration context

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:

StrategyUseful document propertyMain trade-off
Fixed-sizeRelatively uniform prosePredictable configuration can split dependent statements
SemanticMeaningful topic shiftsContent-aware boundaries add model cost and tuning choices
HierarchicalSpecific clauses need surrounding contextPrecise child matches return larger parent context
NoneEach file is already a bounded evidence unitFile 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 maxTokens as a promise to merge across parsed page boundaries.
  • Confusing overlapPercentage with hierarchical overlapTokens.
  • Assuming a higher semantic breakpoint threshold creates more chunks.
  • Expecting hierarchical retrieval to return exactly the requested child count.
  • Choosing NONE for 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

References