AWSAWS Certified Generative AI Developer - Professional2026-101.5 Design retrieval mechanisms for FM augmentation

Transform queries without changing their intent

Completed by the knowledge check

Learning objective

Implement query rewriting, expansion, and decomposition using Bedrock, Lambda, or Step Functions.

Core idea

A query transformation changes how you search, not what the user asked or what the user may access. Rewriting makes one search clearer. Expansion adds alternative expressions for the same information need. Decomposition separates a question into independently searchable parts. Choose the smallest transformation that repairs a measured retrieval failure.

For an architect, the main risk is silent intent drift. A fluent rewritten query can change a date, omit a negation, or invent a product version. A decomposed comparison can retrieve excellent evidence for only one side. Treat transformed queries as proposed search instructions that your application validates, not authoritative facts or access-policy inputs.

How it works

Choose the transformation deliberately

A rewrite produces one revised query. Use it when conversation shorthand hides the subject: “Does it support that mode?” can become a search about a named product and mode already established in the conversation. Preserve the original request and the conversation evidence that supplied those names. If the information is absent, ask for clarification instead of guessing.

Expansion produces bounded alternatives, such as an approved abbreviation and its full name. Keep the original query in the experiment so that expansion does not lose exact identifiers. Deduplicate retrieved passages across alternatives; otherwise, repeated evidence can occupy the whole final context without improving coverage.

Decomposition produces subqueries for distinct information needs, such as the retention policy for two products before comparing them. Each subquery needs a traceable relationship to a clause of the original question. The final answer must account for missing evidence in any required clause rather than merging partial findings into a confident complete answer.

Amazon Bedrock Knowledge Bases provides a managed decomposition mechanism in RetrieveAndGenerate. Set retrieveAndGenerateConfiguration.knowledgeBaseConfiguration.orchestrationConfiguration.queryTransformationConfiguration.type to QUERY_DECOMPOSITION. AWS describes this as breaking a complex query into smaller subqueries and notes that it can execute multiple queries against the knowledge base.

Do not present QUERY_DECOMPOSITION as a general rewrite or expansion switch, or place it in a plain Retrieve request. For application-controlled rewriting or expansion, invoke a supported Bedrock model and validate its output before calling Retrieve. This is a custom pipeline design using model inference, not a separately named Knowledge Bases rewriting API.

Divide responsibilities between services

Use Bedrock inference to propose language transformations. Converse offers messages, system, and inferenceConfig for a supported model; InvokeModel uses a model-specific request body. The interface contracts are covered in 1.3.6 and 1.3.7. Here, the important instruction is to request search queries rather than answers and prohibit adding unsupported entities or constraints.

Use Lambda for application validation and compact orchestration. It can compare proposed terms with trusted conversation fields, reject malformed output, cap the query count, and attach the same authorization filter to every retrieval request. The model must not supply the caller identity or weaken the permission predicate described in 1.4.6. These checks are application logic executed by Lambda, not automatic guarantees of choosing that service.

Use Step Functions when the process needs explicit workflow stages, branching, and bounded retry behavior. Its optimized Bedrock integration supports InvokeModel. The integration accepts Body up to 256 KiB; for larger input it supports Input.S3Uri, and Body and Input are mutually exclusive. Output.S3Uri can store the response and replace the response body with an S3 reference. These are integration payload controls, not permission or model-context controls.

Step Functions does not validate the model-specific Body. Put validation in your workflow before inference and after the transformation response. A Task performs a stage, while Map or Parallel can organize multiple searches. Use Retry with ErrorEquals and bounded MaxAttempts for selected transient failures, and Catch for the terminal application path. Do not retry semantically invalid output as if it were an infrastructure outage.

Bound the complete search plan

Set application limits for transformation attempts, alternative queries, per-query candidate depth, and total elapsed time. A limit on one retrieval call is insufficient when expansion multiplies calls. Keep a total candidate or context budget across branches and record the query responsible for each candidate.

Validate identity terms, dates, scope, and negation before searching. A rewrite that turns “not covered” into “covered” fails even if the retrieval results are highly ranked. Decide whether to use the original query as a fallback, ask for clarification, or stop with an explicit failure. The fallback must remain within the same request budget; see 1.2.5 for bounded recovery.

After retrieval, merge by document and chunk identity, retain provenance, and check clause coverage. Rerank the merged text set only if justified by 1.5.8. Never use repeated appearance across expansions as evidence that the source is more authoritative. The same passage found three times still supplies one piece of evidence.

Validated queries fan out under the same authorization filter and merge back by identity before clause coverage is checked.

Evaluate the transformation separately from the downstream answer. Label whether the proposed queries preserve intent, whether they find the necessary authorized evidence, and whether the final answer addresses each original clause. Compare with an untransformed baseline. Extra calls are justified only when they improve accepted outcomes within the response budget.

Key distinctions and trade-offs

The following approaches solve different retrieval problems:

Approach	Search plan	Main failure to detect
Rewriting	One clarified query	Changed meaning or invented context
Expansion	Several equivalent expressions	Topic drift and duplicate evidence
Decomposition	Several distinct question parts	Missing evidence for one required part

Bedrock supplies language reasoning; Lambda supplies deterministic validation you implement; Step Functions supplies workflow structure and error handling. None replaces the others’ responsibilities merely by appearing in the architecture. A short transformation path can stay in application code or Lambda. A visible workflow is useful when multiple stages and recovery branches need independent control.

Managed decomposition reduces custom orchestration but keeps transformation inside RetrieveAndGenerate. A custom Bedrock-and-Retrieve path gives you the intermediate queries and candidate sets to validate before generation. Choose according to the inspection boundary rather than assuming managed means more controllable.

Architecture / decision scenario

An engineering assistant receives “Compare the retention exceptions for Alpha and Beta, excluding trial accounts.” Rewriting resolves the product names from trusted conversation context while preserving the exclusion. Expansion adds approved policy terminology without replacing either product name. Decomposition creates one retention-exception search per product.

The team first tests Knowledge Bases QUERY_DECOMPOSITION against the original query. It then tests a custom path because reviewers need to inspect the proposed subqueries. Bedrock proposes the queries, Lambda rejects any that drop the trial-account exclusion, and Step Functions organizes the searches with a bounded retry policy. Every branch receives the same trusted caller filter.

The merge stage deduplicates passages and labels them by product. If Beta evidence is absent, the assistant reports that the comparison is incomplete. It does not borrow Alpha’s exception policy to fill the gap. The team retains expansion only if it improves evidence coverage beyond rewrite and decomposition alone, within the approved call and latency budgets.

Common exam traps

Treating rewriting, expansion, and decomposition as interchangeable.
Claiming QUERY_DECOMPOSITION is a plain Retrieve option.
Letting model-generated queries define tenant or permission filters.
Assuming Step Functions validates an InvokeModel request body.
Bounding each branch while allowing unlimited total queries and retries.
Answering a comparison when evidence covers only one side.

What to remember

Transform only the search representation, preserve the original intent, and validate before retrieval. Use the documented managed decomposition setting when its control boundary fits. For custom paths, separate model proposals, deterministic validation, workflow execution, and evidence merging. Judge improvement against the original query and the complete response budget.