Primary reference: Bedrock Knowledge Bases retrieval operations
AWS documents retrieval-only inspection separately from retrieve-and-generate operations. Use the current Knowledge Base mechanics and operation references to verify the selected configuration boundary.
Read the Bedrock retrieval guideStart with a minimal, inspectable AWS path
A minimal cited path has an approved S3 corpus, tracked ingestion, a knowledge base, an application identity, and an answer policy that displays sources or abstains.
Test retrieval-only output before adding generation so evidence, filters, and source locations can be inspected.
Minimal cited RAG on AWS
Loading diagram...
Separate Managed Knowledge Base from customer-managed Knowledge Bases
AWS choice boundary
| Choice | AWS manages | You decide |
|---|---|---|
| Managed Knowledge Base | Ingestion, indexing, storage and retrieval infrastructure | Sources, permissions, application policy |
| Customer-managed Knowledge Base | Knowledge Base integration | Vector store, parsing, indexing, operations |
Managed and customer-managed knowledge bases reduce different infrastructure work, but neither choice removes application ownership for permitted data, identity, acceptance tests, and the answer contract. Recheck current feature, Region, model, and API support for the selected configuration before deployment.
Use evidence inspection before an integrated answer
Two deliberate test calls
Illustrative request shapes; use real SDK types in production.
Request
POSTANNOTATIONS
Response
Make the first deployment auditable
- Record source versions and ingestion status.
- Inspect retrieval citations and metadata.
- Test relevant, absent, stale, and unauthorized queries.
- Measure generation only after evidence quality is acceptable.
Choose Retrieve when evidence itself is the product
Use Retrieve to inspect source chunks or images returned for a query. This is the right first interface when a user or reviewer needs to judge relevance, source location, metadata filters, or an empty result before any model writes prose.
Operation decision record
| Question | Start with | Acceptance evidence |
|---|---|---|
| Which policy passages match? | Retrieve | Expected chunks, locations, and filters are inspectable. |
| Can the app produce a cited explanation? | RetrieveAndGenerate where supported | Each displayed claim is reviewed against returned citations. |
| Does managed infrastructure support this path? | Retrieve or AgenticRetrieveStream as applicable | Selected API is checked against current AWS documentation. |
AWS describes RetrieveAndGenerate as combining retrieval with model invocation and citations. Its current API reference states that RetrieveAndGenerate cannot be used with managed knowledge bases; use the documented managed-compatible retrieval operation instead. Do not infer product capability from an endpoint name, a prior experiment, or a different knowledge base type.
Make citation coverage and no-evidence behaviour explicit
Application evidence response contract
Illustrative application response after inspecting AWS retrieval output; it is not an AWS API schema.
Click on an annotation to highlight it in the JSON
A citation is not a blanket proof. In an acceptance set, label a response as supported only when its material claims can be traced to the returned chunks, qualified when sources conflict or are incomplete, and no-evidence when permitted retrieval returns nothing usable. Test that the UI does not invent a source, hide an empty result, or convert an authorization failure into a generic answer.
- Run an evidence-only test with Retrieve and save the result identifiers.
- Run the integrated path only where the selected knowledge base type supports it.
- Compare the answer against the saved result identifiers, not against model fluency.
- Reject a release if no-evidence, denied, or conflicting cases have no user-visible response mode.
Run a managed knowledge base boundary check before integration
Pre-integration operation checklist
Documentation-shaped checks to turn the selected API boundary into a deployment gate. Substitute real identifiers and SDK calls only after capability verification.
Request
POSTANNOTATIONS
Response
The control is simple: record the knowledge base type, selected operation, documentation URL and verification date in the change record. If the documented operation is unavailable or unsuitable, stop at retrieval and implement the application-owned answer policy only after a supported architecture decision. This avoids coupling a prototype to an API path that its target configuration cannot use.
Audit response sentences with a coverage ledger
Citations returned by an integrated operation identify relevant source chunks, but a release reviewer still needs to decide whether each material sentence is supported, qualified, or unsupported. A sentence-coverage ledger prevents a polished paragraph from borrowing confidence from a nearby citation that does not entail its claim.
Answer coverage ledger for one acceptance response
| Sentence or claim | Retrieved evidence | Reviewer outcome | Required action |
|---|---|---|---|
| Policy permits a named expense. | policy#expenses-3 | supported | Keep source link. |
| Policy applies to this employee. | No entitlement source | unsupported | Remove and direct user to the authoritative workflow. |
| Two policy clauses differ. | policy#expenses-3 and policy#expenses-7 | qualified | Cite both and request owner review. |
| No source answers the question. | Empty permitted result set | no-evidence | Show abstention without fabricated citation. |
Store the ledger beside the versioned query and retrieval result identifiers. Re-run it when a source, filter, retrieval configuration, or prompt changes. This makes answer quality a reviewable contract even when the underlying operation returns citations, and it separates evidence coverage from writing style or user satisfaction.
A useful negative case contains a highly ranked but out-of-scope chunk. The ledger should still mark the sentence unsupported when the application was not permitted to use that source for the principal or question. That distinction protects against treating retrieval rank as authority. It also gives a reviewer a concrete triage path: inspect the filter and corpus metadata first, then source scope, then generation behaviour.
Treat retrieval filters and session failures as product contracts
Retrieval request and failure contract
Illustrative application contract around a Bedrock request. AWS RetrievalFilter is a union: configure one valid filter member at each node rather than combining unrelated members in one object.
Click on an annotation to highlight it in the JSON
AWS documents retrieval filters as metadata conditions applied before results are returned, with a union-shaped filter object. Test a permitted filter, a denied filter, an invalid filter construction, and a filter referencing metadata absent from the corpus. Session-aware paths also need a failure rule: preserve only the minimum correlation data needed for review, and never let prior conversation context substitute for current permitted evidence.
Make filter construction a typed boundary in the application rather than allowing arbitrary user-provided JSON to reach the retrieval call. When a requested scope cannot be represented by the corpus metadata, return a bounded unavailable or no-evidence state; do not broaden the query as a convenience fallback. During incident review, compare the intended principal scope, submitted filter, resolved filter, and returned source locations in that order.
- Log the query class, principal class, filter shape, selected operation, and result mode without storing sensitive source text unnecessarily.
- Assert that a denied filter cannot return a chunk that the same principal could not access through the application policy.
- Retry transient transport failures only with the same principal and immutable request intent; record the attempt outcome.
- On a session failure, restart from a clean, bounded context or require human review rather than carrying forward an unverified draft answer.
Glossary: terms first introduced here
These are the technical terms introduced in this step. Later modules build on them rather than redefining them from scratch.
New vocabulary for this step
| Term | Plain-language meaning | Why it matters here |
|---|---|---|
| Knowledge base | A managed or application-owned retrieval layer that connects approved organisational sources to a question-answering workflow. | It is a retrieval boundary, not a substitute for identity, answer policy, or source ownership. |
| Ingestion | The controlled process that reads a source, prepares it for retrieval, and records what version entered an index. | Without inspectable ingestion, a team cannot explain stale or missing evidence. |
| Metadata filter | A rule that restricts retrieval using fields such as tenant, classification, source type, or lifecycle state. | Filters carry access and relevance rules into the retrieval path instead of leaving them to prompt wording. |
| Abstention | An explicit safe response when the system lacks permitted or sufficient evidence to answer. | A useful system knows when to ask, hand off, or say it cannot establish an answer. |
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.