AWSAWS Certified Generative AI Developer - Professional2026-100 Prerequisites
Locate failures across the RAG stages
Completed by the knowledge check
Learning objective
Understand RAG ingestion, retrieval, augmentation, and generation stages. You should be able to follow evidence from a source document into a generated answer and identify the boundary at which it is lost, distorted, or misused. Detailed chunking choices belong to 1.5.1; retrieval API selection belongs to 1.5.6.
Core idea
Retrieval Augmented Generation (RAG) supplies external information to a model when answering a request. Ingestion prepares information for search. Retrieval selects evidence for a query. Augmentation places that evidence into the model’s input. Generation produces a response from that input.
These stages have different failure modes and usually different schedules. Ingestion can run before any customer asks a question. The remaining stages run when the application handles a request. RAG changes the information available for inference; it does not require updating model weights whenever a source changes.
How it works
Ingest searchable evidence
Consider an unstructured-document vector RAG pipeline. Ingestion reads source content, extracts usable text, divides it into chunks, generates embeddings, and indexes those representations with their text and source relationships. AWS describes this pattern in the Amazon Bedrock Knowledge Bases documentation. Embeddings and similarity are introduced in 0.4.
The text and provenance matter as much as the vectors. A vector helps locate a chunk, but the generation step needs the source content. An answer also needs a way to identify the document that supports it. If extraction loses a table’s conditions or chunking separates a rule from its exception, later stages may retrieve an incomplete explanation even when the search operation succeeds.
For a configured data source in a customer-managed Bedrock knowledge base, StartIngestionJob starts ingestion using knowledgeBaseId and dataSourceId. GetIngestionJob retrieves information about the job using those identifiers and ingestionJobId. An accepted start request is not proof that every expected source is searchable. Inspect ingestionJob.status (STARTING | IN_PROGRESS | COMPLETE | FAILED | STOPPING | STOPPED), ingestionJob.failureReasons, and ingestionJob.statistics, including numberOfDocumentsFailed, numberOfNewDocumentsIndexed, and numberOfModifiedDocumentsIndexed. Check representative retrieval results before treating a source update as available to the application. Detailed reconciliation is covered in 1.4.11.
This is a scoped illustration, not the definition of every knowledge-base implementation. AWS distinguishes Managed Knowledge Bases, where it manages underlying ingestion, indexing, storage, and retrieval infrastructure, from Customer-managed Knowledge Bases with infrastructure and configuration under your control. The four conceptual RAG stages remain useful across those ownership choices. Do not infer that every retrieval system requires you to build and operate a vector store yourself.
Retrieve evidence for the query
In the vector pattern, the application embeds the query and searches for chunks with related representations. Retrieval returns candidate evidence; it does not create the final natural-language answer. Source applicability, filtering, and relevance determine whether those candidates belong in the response path.
Bedrock’s Retrieve operation accepts a knowledgeBaseId and retrievalQuery. It returns retrievalResults that include content, location, metadata, and score. The source location and metadata help you inspect what was found; the score describes relevance. A high score does not establish that a passage contains all facts required to answer the question.
For example, a passage about refunds is related to a refund question, but it may cover a different region or omit the deadline. Test retrieval independently: can the returned content answer the question using the applicable source? Filtering and permission enforcement belong to 1.4.6, and retrieval evaluation belongs to 5.1.8.
Augment the model input
Augmentation combines the user question, task instructions, and selected evidence into the input used for generation. It is the handoff between search and the model. Returning a good passage from a retrieval service is insufficient if the application drops it before making the model request.
With Retrieve, your application owns that handoff and can inspect or transform evidence before calling a model. Preserve the association between each passage and its source when assembling context. Keep source text identifiable as evidence rather than application-owned instructions. Detailed authorized context assembly belongs to 1.5.11.
Augmentation has a finite input budget. Several retrieved chunks can duplicate the same paragraph while excluding the one exception the question needs. Decide which evidence to retain rather than equating the maximum amount of text with the best context. If you reduce a passage, retain the conditions that determine its meaning and the source relationship needed to verify the answer.
Generate and inspect the answer
Generation uses the augmented input to produce the answer. It can still omit a condition, misinterpret a number, or introduce information absent from the source. A good retrieval result makes a supported answer possible; it does not prove that generation produced one.
RetrieveAndGenerate combines knowledge retrieval and generation. Its response includes output and citations. Citations associate segments of generated text with retrieved references. That association lets you inspect support, but a citation is not a substitute for reading the passage and checking the claim. Claim verification is covered in 3.1.6.
Use the operation boundary that matches the evidence gate. If the application must inspect retrieved content before generation, Retrieve exposes that boundary. If you choose combined retrieval and generation, inspect the resulting answer and references at the boundary that operation provides. This is a control choice, not a claim that one API is inherently more accurate.
Ingestion can run before any question, and the remaining stages search its index when the application handles a request.
Key distinctions and trade-offs
The following stage outputs help locate a defect:
| Stage | Output to inspect | Example defect |
|---|---|---|
| Ingestion | Searchable chunks with source relationships | A policy exception was lost during extraction |
| Retrieval | Candidate content, metadata, and locations | The query selected the wrong policy version |
| Augmentation | The exact input sent to the model | The selected exception never entered the request |
| Generation | Answer and source attribution | The model ignored an exception present in context |
RAG differs from training: the source enters the response path as inference context. Retrieval also differs from grounding: finding relevant material and checking answer support are different decisions. See 0.8 for that distinction.
Architecture / decision scenario
A warranty assistant answers that a device qualifies for replacement, but the policy excludes damage after an unauthorized repair. The team checks all four stages before replacing the model.
First, it inspects ingestion evidence and confirms that the exclusion survived in the indexed text. Next, a Retrieve test shows that the relevant exclusion is returned alongside the warranty rule. The application’s context assembly, however, keeps only the first passage. The defect is augmentation: generation never received the condition.
After correcting context selection, the team verifies the exact model input and repeats answer-support evaluation. If the answer still ignores the exclusion, that is a generation defect to investigate separately. It also tests a policy revision by starting ingestion, inspecting GetIngestionJob status and document statistics, and verifying retrieval so that an updated source does not remain invisible behind a successful document upload.
Common exam traps
- Treating a source upload or ingestion start as completed searchable ingestion.
- Assuming vector similarity proves a passage answers the question.
- Treating retrieval and augmentation as the same handoff.
- Changing generation instructions to repair missing indexed evidence.
- Describing RAG as retraining model weights on every source update.
- Assuming generated citations guarantee that every claim is supported.
What to remember
- Ingestion prepares evidence; retrieval selects it; augmentation supplies it.
- Generation remains a separate interpretation of the supplied evidence.
- Preserve source identity through every stage.
Retrieveexposes evidence before generation;RetrieveAndGeneratecombines them.- Diagnose stage outputs before changing a model or prompt.
Knowledge check
Inspection of the indexed chunks shows that extraction dropped an exception held in a policy table, so answers omit it. A teammate proposes adding “always mention policy exceptions” to the generation instructions. Where should the fix go?
A Retrieve test returns both the warranty rule and its exclusion, but the logged model request contains only the rule. Which stage needs repair?
A team uploads a revised policy to its knowledge base’s data source and StartIngestionJob returns successfully. When can it treat the revision as available to the assistant?
StartIngestionJob has returned a job identifierCOMPLETE and a retrieval test finds the revisionGetIngestionJob reports the status, failure reasons and statistics such as numberOfDocumentsFailed and numberOfModifiedDocumentsIndexed , and a representative retrieval test confirms that the revised text is actually found.A compliance rule requires the application to inspect and filter retrieved passages before any model sees them. Which Amazon Bedrock Knowledge Bases operation exposes that boundary?
Retrieve , followed by the application’s own model callRetrieveAndGenerate , inspecting its citations afterwardStartIngestionJob , run again before each questionGetIngestionJob , checked before each questionRetrieve returns content, location, metadata and score to the application, which then assembles the model input itself. RetrieveAndGenerate combines retrieval and generation, so its citations can be inspected only after an answer exists; neither API is inherently more accurate — the choice is about where the evidence gate sits.A product’s return policy changes every month. A stakeholder proposes fine-tuning the model after each change so the assistant knows the new rules. What does a RAG design do instead?