Practice: Retrieval-augmented generation infrastructure and vector search
Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.
Main tool: AWS Bedrock · Bedrock Knowledge Bases runs both RAG pipelines (parse, chunk, embed and index offline, then retrieve, rerank and generate online) as one managed service, so you can practise every stage of the lesson and see which parts you would otherwise operate yourself.
Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1
Setup (one time)
1. Create or pick an AWS account and set up programmatic credentials on your laptop; note that Bedrock is a paid cloud service with no local mode, so keep a pgvector container on PostgreSQL as the local substitute for the vector store.
Every later item calls the Bedrock API with these credentials. Knowing the local substitute up front lets you rehearse vector search at no cost before spending in the cloud.
Explained in: AWS General Reference - AWS General Reference (docs.aws.amazon.com), checked 2026-10-11
Done when: A call that returns your caller identity succeeds from your terminal with the credentials you configured.
2. Attach the permissions that let your user or role create and manage knowledge bases.
Knowledge base creation touches several services, and missing permissions are the most common first failure. Setting them once avoids debugging access errors in the middle of the path.
Explained in: Set up permissions for a user or role to create and manage knowledge bases - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: Your user or role shows the knowledge base permissions attached and the console opens the Knowledge Bases page without an access error.
3. Install the AWS SDK and command line tools listed for Bedrock on your laptop.
You will drive ingestion and queries from scripts, not only from the console. A working SDK is what makes the path repeatable.
Explained in: Documentation and SDKs (docs.aws.amazon.com), checked 2026-10-11
Done when: A short script lists the foundation models available to your account without an error.
4. Pick one Region where knowledge bases, an embedding model and a reranking model are all supported, and use it for the whole path.
Feature availability differs by Region, and mixing Regions causes confusing failures later. Choosing once keeps every step consistent.
Explained in: Supported models and Regions for Amazon Bedrock knowledge bases - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: You have written down one Region that appears in the support tables for knowledge bases, embeddings and reranking.
Steps
1. Run the Bedrock quickstart to send one prompt to a foundation model from your laptop (needs the paid cloud account; there is no local substitute for the model call).
This proves credentials, Region and model access work before any retrieval is involved. It also gives you an ungrounded answer to contrast with later grounded ones.
Explained in: Overview - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: You see a model response printed for your prompt and can repeat the call from a script.
2. Run a query against a single document without creating a knowledge base, and save the question and answer as your baseline.
This is the smallest form of grounding: no index, no persistence. Saving the result gives you something to compare against once a real index exists.
Explained in: Query a document without creating a knowledge base - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: You have a saved file with three questions, the answers and the cited passages from the single document.
3. Read how knowledge bases work and sketch the two paths: the offline indexing path and the online query path.
Most RAG failures sit in one of these two pipelines, so you need to be able to place each component in the right one. The sketch becomes your map for the remaining steps.
Explained in: How Amazon Bedrock knowledge bases work - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: Your sketch names the parse, chunk, embed and index stages on one side and the retrieve, rank and generate stages on the other.
4. Compare the Bedrock managed and customer-managed knowledge base options and write down which one you will build and why.
The choice decides who operates the vector store, the scaling and the upgrades. A platform engineer is expected to justify this trade-off, not just accept the default.
Explained in: Build a managed knowledge base - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: You have a short note listing what each option makes you responsible for and your chosen option.
5. Compare the supported embedding models and record the model and vector dimensions you will use for ingestion.
The embedding model fixes the vector dimensions of the index and cannot be swapped without re-embedding everything. It is the most expensive decision to reverse in the ingestion pipeline.
Explained in: Supported models and Regions for Amazon Bedrock knowledge bases - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: Your notes state one embedding model, its dimensions and confirmation that it is supported in your Region.
6. Create a knowledge base with a vector store over a small folder of documents in object storage, choosing a chunking strategy and, where offered, a PostgreSQL store with pgvector (paid cloud; rehearse the same table and index locally in a pgvector container first).
This is the full ingestion pipeline: parsing, chunking, embedding and indexing into a persistent store. Using pgvector as the store connects the managed service to the index you would tune yourself.
Explained in: Build a knowledge base with vector stores - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: The knowledge base shows as ready and the data source sync reports your documents as indexed with no failures.
7. Query the knowledge base details to confirm its status, embedding model, storage configuration and data source sync history.
Reading back the persisted configuration is how you verify what was actually built rather than what you intended. It is also the first thing you check when retrieval quality drops.
Explained in: View information about an Amazon Bedrock knowledge base - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: You can state the knowledge base identifier, the embedding model, the vector store and the time of the last successful sync from the output.
8. Run test queries against the knowledge base in retrieval-only mode and in generate mode, switching between semantic and hybrid search and changing the number of results.
Looking at retrieved chunks separately from generated answers shows whether a bad answer is a search problem or a model problem. Hybrid search adds keyword matching that pure vector search misses on exact terms and identifiers.
Explained in: Test your knowledge base with queries and responses - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: You have a table of the same three baseline questions showing the retrieved chunks and answers for each search setting, next to your baseline from the single-document run.
9. Configure a reranking model that is supported in your Region and compare the order of the top results with and without it.
Reranking reorders a wider candidate set with a stronger relevance model, which is often the cheapest quality gain in the query path. Seeing the reorder on your own data shows when it is worth the added latency and cost.
Explained in: Supported models and Regions for Amazon Bedrock knowledge bases - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: For at least one question the top result changes with reranking on, and you have noted whether the answer improved.
10. Enable logging for the knowledge base and trigger a new ingestion sync so that log events are produced.
Ingestion fails silently on individual documents unless you log it. Operating RAG as a service starts with being able to see what each sync did.
Explained in: Monitor knowledge bases using CloudWatch Logs - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: Log events for your sync job appear in the log group you configured.
11. Query the knowledge base logs with the example debug queries to find documents that failed or were skipped during ingestion.
These queries are the day to day tool for answering why a document is missing from answers. Running them on a deliberately broken file teaches you what a failure looks like.
Explained in: Monitor knowledge bases using CloudWatch Logs - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: A query returns the status of each ingested file and you can point to the entry for a file you intentionally made unparseable.
12. Deploy the knowledge base for an application by wiring it behind a small script or service that calls it with a scoped role, logging on and your chosen search and reranking settings (paid cloud; delete the knowledge base afterwards to stop charges).
This is the production-like shape: an application calls a stable knowledge base with least privilege access, observability and fixed retrieval settings. It ties the indexing path, the query path and the operations view together.
Explained in: Deploy your knowledge base for your AI application - Amazon Bedrock (docs.aws.amazon.com), checked 2026-10-11
Done when: Your script answers the three baseline questions with citations through the deployed knowledge base and each call is visible in the logs.
Back to Retrieval-augmented generation infrastructure and vector search