AWSAWS Certified Generative AI Developer - Professional2026-101.5 Design retrieval mechanisms for FM augmentation
Place the boundary before evidence becomes context
Completed by the knowledge check
Learning objective
Choose Knowledge Bases Retrieve, RetrieveAndGenerate, or a custom retrieval pipeline based on control over context and generation.
Core idea
The deciding question is where your application must intervene. If it needs to inspect, combine, or reject retrieved evidence before generation, choose a boundary that returns evidence to the application. If the supported managed retrieval-and-generation sequence meets the requirement, one call can reduce application orchestration.
Amazon Bedrock Knowledge Bases exposes Retrieve for evidence retrieval and RetrieveAndGenerate for a combined workflow. A custom pipeline can retain Knowledge Bases retrieval while owning subsequent steps, or own vector queries as well. “Custom” describes responsibility; it does not necessarily mean replacing every managed component.
How it works
Use Retrieve when the application owns the next step
Retrieve queries a knowledge base and returns information rather than a generated answer. Supply knowledgeBaseId and retrievalQuery.text. For a self-managed vector knowledge base, retrieval settings go under retrievalConfiguration.vectorSearchConfiguration.
The response’s retrievalResults contains evidence items with content, location, metadata, and score. Preserve those associations as you select passages. The content is the retrieved evidence; the location and metadata let your application retain source identity. A score is a retrieval signal, not proof that an answer’s individual claims are supported.
If the response includes nextToken, pass it in another Retrieve request to obtain the next batch. Pagination is separate from the configured candidate maximum. Do not discard a continuation token and then report that the first response necessarily contained every available result.
Use this boundary when the application must compare conflicting revisions, merge evidence from another source, enforce an application-owned evidence rule, or send a controlled context to a separately chosen generator. You can also return passages directly for a search experience without generating an answer. The application owns context assembly and the later generation call, including its source-attribution format.
For managed knowledge bases, AWS documents managedSearchConfiguration instead of vectorSearchConfiguration. Their retrieval uses hybrid search, and semantic-only search is unavailable. Do not copy the self-managed request settings into the managed path merely because both use the Retrieve operation.
Use RetrieveAndGenerate for the supported combined workflow
RetrieveAndGenerate queries a knowledge base and generates a response using the selected foundation model or inference profile. For the knowledge-base path, set retrieveAndGenerateConfiguration.type: KNOWLEDGE_BASE and provide knowledgeBaseConfiguration.knowledgeBaseId and modelArn.
The combined call still offers configuration, including knowledgeBaseConfiguration.orchestrationConfiguration for orchestration controls before generation. Its knowledgeBaseConfiguration accepts retrievalConfiguration for search settings and generationConfiguration for generation behavior. A custom prompt goes in generationConfiguration.promptTemplate.textPromptTemplate; inference controls are available through inferenceConfig and additionalModelRequestFields where supported.
This means a custom prompt alone does not require you to replace the combined API. The stronger reason to separate retrieval and generation is an application step that must run after evidence is returned but before the model receives its context. A prompt instruction is not the same intervention as inspecting retrieved objects in application code.
For custom templates, AWS documents $search_results$ as the placeholder for retrieved results and $output_format_instructions$ as necessary for citations in the response. Preserve the documented placeholder behavior when changing formatting. Removing citation instructions and then assuming the API will still return the same attribution is an interface mistake.
The response includes output.text, citations, and sessionId. Citations associate generated response segments with retrieved references. On the first request, Bedrock generates the session identifier. Reuse that returned identifier for later requests in the same conversational session; do not invent it for the initial request.
The API documentation explicitly states that RetrieveAndGenerate cannot be used with managed knowledge bases. It names Retrieve or AgenticRetrieveStream as managed-mode alternatives. Thus the choice among these operations must begin with the knowledge-base mode, not only with the amount of desired prompt control.
Own a custom pipeline when the evidence path requires it
A custom pipeline can begin with Retrieve, inspect retrievalResults, select evidence under application rules, and invoke the chosen generation interface. This retains Knowledge Bases ingestion and search while moving context construction into your application.
Only the Retrieve path gives the application a step after evidence is returned and before the model receives its context.
Alternatively, own the vector query when you need store-level behavior outside the supported Knowledge Bases contract. For OpenSearch, the application can own the vector query; see 1.5.5 for its query interface and store configuration. The application then owns query embedding compatibility, result fields, source associations, and the eventual context. That responsibility is broader than selecting Retrieve instead of RetrieveAndGenerate.
Define the custom path’s acceptance conditions before adding steps. For example, require approved source revisions, retain one passage per duplicate evidence unit, bound total context, and abstain when no valid supporting source remains. These are application policies. Implement them against concrete retrieved metadata and content, and test the selected evidence set before evaluating generated prose.
Do not assume Knowledge Bases guardrails sanitize all retrieved evidence. AWS states that guardrails apply to the input and generated model response, not to runtime retrieved references. Treat source text as evidence to evaluate rather than as instructions your application automatically trusts. A custom path provides an intervention point; it does not make the policy correct without implementation and validation.
Key distinctions and trade-offs
Compare the ownership boundaries:
| Path | Returned object | Application responsibility |
|---|---|---|
Retrieve | Retrieved evidence and source information | Inspect evidence, assemble context, and optionally generate |
RetrieveAndGenerate | Generated output, citations, and session state | Configure and evaluate the supported combined workflow |
| Custom retrieval and generation | Application-defined evidence and answer contracts | Own query behavior, compatibility, context, attribution, and error handling |
numberOfResults controls a maximum candidate count for the self-managed vector path, not a guaranteed number of distinct evidence units. Hierarchical children can collapse into parents; see 1.5.1. Increasing that setting is not a substitute for resolving conflicting or unauthorized source versions.
For self-managed knowledge bases, overrideSearchType selects HYBRID or SEMANTIC. AWS documents hybrid support for Amazon RDS, OpenSearch Serverless, and MongoDB stores with a filterable text field. Other configurations use semantic search. Scope search behavior to the store and knowledge-base mode rather than assuming every API choice unlocks the same capabilities; see 1.5.7 for hybrid retrieval.
Architecture / decision scenario
A documentation assistant has three use cases. General product questions need a cited answer with a tested prompt. The self-managed knowledge base can use RetrieveAndGenerate, including its generation template and returned session identifier.
A policy assistant must resolve revision conflicts before generating a recommendation. It calls Retrieve, reads revision metadata and source locations, rejects superseded passages, and assembles the approved evidence for a separate generation step. Moving the same rule into a prompt would not provide the required application review point.
A specialist search workflow needs a store query outside the Knowledge Bases integration contract. It owns OpenSearch retrieval and its source mappings, preserving the embedding contract described in 1.5.4. If the general assistant moves to a managed knowledge base, the team reconsiders the combined API because RetrieveAndGenerate is unsupported in that mode. All three paths are evaluated on selected evidence and resulting behavior, not on answer fluency alone.
Common exam traps
- Assuming
Retrievegenerates an answer or manages the application’s generation context. - Replacing
RetrieveAndGeneratesolely because a custom prompt is needed. - Treating a retrieval score or citation as proof of every generated claim.
- Inventing the initial
sessionIdinstead of reusing the returned identifier. - Assuming guardrails apply to runtime retrieved references.
- Calling
RetrieveAndGenerateagainst a managed knowledge base.
What to remember
- Choose the API boundary from the required evidence intervention point.
Retrieveexposes evidence; the application controls what happens next.RetrieveAndGeneratesupports configuration within its combined workflow.- A custom store query adds compatibility and attribution responsibilities.
- Knowledge-base mode and store support constrain the available choices.
Knowledge check
A policy assistant on a self-managed knowledge base must reject superseded document revisions after retrieval and before the model receives any context. Which design provides that control point?
RetrieveAndGenerate , then remove superseded claims from the answerRetrieveAndGenerate with a template telling the model to ignore old revisionsRetrieve , drop superseded results in code, then generate separatelyRetrieve with a higher numberOfResults so current revisions rank firstRetrieve returns evidence objects with their metadata, so application code can reject a revision before generation. A prompt instruction is not a code-level gate, filtering the answer is too late because the model has already consumed the passage, and a larger candidate count changes nothing about which revisions are eligible.A self-managed knowledge base needs a tested custom generation prompt with citations, and no application step is required between retrieval and generation. Which option meets this with the least application orchestration?
RetrieveAndGenerate and set its generation prompt templateRetrieve , which applies a prompt template to its resultsRetrieve and apply the template in a separate generation callRetrieveAndGenerate and prepend the instructions to the user’s questionRetrieveAndGenerate accepts a custom template in generationConfiguration.promptTemplate , so a custom prompt alone is no reason to split the workflow. Retrieve generates nothing, and a separate generation step adds orchestration that only an intervening evidence check would justify.A workload that calls RetrieveAndGenerate against a self-managed knowledge base is moving to a managed knowledge base. What must change?
managedSearchConfiguration within the same callSEMANTIC within the same callRetrieve , with generation handled separatelyRetrieveAndGenerate cannot be used with managed knowledge bases and names Retrieve or AgenticRetrieveStream instead. Managed retrieval is also always hybrid, so semantic-only search is not an option there.A team configures a guardrail on RetrieveAndGenerate and expects it to block instructions planted inside retrieved documents. Why is that expectation wrong?
Retrieve