Knowledge Bases (managed RAG)

This creates a Knowledge Base (KB) — Amazon's managed version of the RAG pipeline you hand-built in Ch 3. Instead of writing code to chunk, embed and store documents, you describe what you want and AWS runs the machinery. This one block declares all three pieces a KB needs: where documents live, which model turns text into vectors, and where those vectors are stored.

1. boto3.client("bedrock-agent", ...) opens a connection to the AWS service that manages Knowledge Bases (the "control plane" — the part that creates and configures things). region_name="us-east-1" picks the AWS data-centre region.
2. agent.create_knowledge_base(...) is the single call that builds the KB. Everything inside the parentheses is configuration passed as named arguments.
3. name is a human label; roleArn is an AWS IAM role — an identity with permission to read your S3 documents and write to the vector store. The KB acts as this role when it works.
4. knowledgeBaseConfiguration says the KB is a VECTOR store and names the embedding model (amazon.titan-embed-text-v2) — the model that converts each chunk of text into a list of numbers (a vector) capturing its meaning.
5. storageConfiguration points at OpenSearch Serverless, the default vector database. fieldMapping tells it which fields hold the vector, the original text, and metadata. collectionArn is the unique address of that store.
6. print("KB id:", ...) pulls the new KB's ID out of the reply. You'll reuse this ID in every later call, so note it down.

What the output means: On success AWS prints something like KB id: KB123. That ID is the handle you pass to the ingestion and query calls below. The ARNs and IDs shown are placeholders — swap in your own.

Try this: Read the three sub-configs top to bottom and match them to the KB's three needs: S3 docs (added next), embedding model (embeddingModelArn), and vector store (opensearchServerlessConfiguration). Seeing all three named here is the whole point.

Creating the KB in W4.1 built the empty container. Your documents are not indexed yet. An ingestion job is the step that actually reads the files from S3, chunks them, calls the embedding model on each chunk, and writes the resulting vectors into OpenSearch. You run this once after setup, and again every time the documents change.

1. We reconnect to bedrock-agent — the same control-plane client as W4.1, because starting an ingestion job is a management action.
2. agent.start_ingestion_job(...) kicks off the indexing work. knowledgeBaseId is the KB from W4.1; dataSourceId identifies the S3 data source you attached to it (KB123 / DS456 are placeholders).
3. The job runs asynchronously — the call returns immediately with a starting status rather than waiting for all documents to finish. print(...job["ingestionJob"]["status"]) shows that first status.

What the output means: You'll see a status like STARTING. Behind the scenes it moves STARTING → IN_PROGRESS → COMPLETE (the comment spells this out). You would poll the job again later, or check the console, to confirm it reached COMPLETE before querying.

Try this: Think about why re-running matters: if you add a new support doc to S3 tomorrow, the KB won't know about it until you start another ingestion job. Managed RAG syncs on demand, not by magic.

Now we ask a question against the indexed KB. Bedrock offers two query styles: retrieve returns just the matching chunks (you then write your own prompt to Claude), and retrieve_and_generate — used here — does the whole RAG loop in one call: find relevant chunks, feed them to Claude, and return a written answer plus citations pointing back to the sources.

1. boto3.client("bedrock-agent-runtime", ...) connects to the data plane — the part that uses the KB to answer queries (as opposed to the control plane that built it). Different job, different client.
2. rt.retrieve_and_generate(...) is the one-call RAG. input={"text": "How do I reset a customer's password?"} is the user's question in plain English.
3. retrieveAndGenerateConfiguration tells it how to answer: type: KNOWLEDGE_BASE means "use a KB", knowledgeBaseId picks which KB, and modelArn chooses the model that writes the answer — here Claude 3.5 Sonnet.
4. print(resp["output"]["text"]) prints Claude's final written answer, grounded in your documents.
5. The for c in resp["citations"] loop walks the citations. Each citation lists retrievedReferences — the actual document chunks used — and we print each ref["location"], i.e. where that fact came from. This is how you prove the answer isn't made up.

What the output means: You get a natural-language answer to the password question, followed by one or more source: lines showing which S3 documents backed it. Citations are the key advantage of managed RAG — grounding and traceability come free.

Try this: Decide which call you'd want for two tasks: (1) a chatbot that shows a polished answer — retrieve_and_generate; (2) a custom prompt where you control every instruction to Claude — plain retrieve, then build the prompt yourself.