Skill 3.2.7: Create and manage Amazon Bedrock knowledge bases with vector database configurations, document indexing, and retrieval optimization.
Task 3.2: Deployment and Orchestration of ML and AI Workflows - Provision and configure resources for ML and AI workloads based on existing architecture and requirements.
Core Concept & Objective
- Amazon Bedrock Knowledge Bases: fully managed RAG service that ingests private data, converts it to embeddings, stores them in a vector database, and retrieves relevant chunks to ground foundation model responses.
- Primary objective: reduce hallucinations, keep private data secure, and avoid building custom ingestion/retrieval pipelines.
- Architecture flow: Data source → parsing/chunking → embedding model → vector store → retrieval (search + filters + reranking) → FM generation.
- Existing architecture constraint: vector store choice must align with what the organization already runs (OpenSearch, Aurora, Neptune, third-party).
Vector Store Selection Matrix
| Vector Store | Best For | Retrieval Capabilities | Trade-offs / Traps |
|---|---|---|---|
| Amazon OpenSearch Serverless | Default managed RAG; hybrid search | Vector, hybrid (BM25 + k-NN), metadata filtering, auto-scaling | OCU cost; hybrid requires filterable text field |
| Amazon OpenSearch Service (managed) | Existing OpenSearch clusters; fine-grained control | Vector, hybrid, metadata filtering, VPC | Ops overhead; capacity planning |
| Amazon Aurora PostgreSQL (pgvector) | Embeddings beside relational records; SQL joins | Vector, metadata filtering (SQL), transactional | Not hybrid by default; dimension/extension limits |
| Amazon Neptune Analytics | Graph relationships; multi-hop retrieval | Graph + vector; relationship traversal | Overkill for generic text RAG |
| Amazon S3 Vectors | Low-cost, large vector sets, infrequent queries | Vector, metadata filtering | Limited hybrid/advanced retrieval vs OpenSearch |
| Third-party (Pinecone, Redis, MongoDB) | Existing investments; specific features | Varies; check hybrid/filter support | Credentials via Secrets Manager; network path |
Exam Gotcha: OpenSearch is the vector store that natively supports hybrid search over a filterable text field. If the requirement mixes exact IDs/keywords with semantic meaning, choose OpenSearch + hybrid.
Vector Database Configuration
- Index dimensions: must exactly match the embedding model's output dimension. Mismatch = ingestion/retrieval failure.
- Distance metric: cosine / Euclidean / dot product. Must align with embedding model training.
- Field mapping: declare vector field, text field (for hybrid), and metadata fields before ingestion. Cannot change without reindexing.
- Index algorithm: HNSW (fast, memory-heavy) vs IVF (lower memory, slower). Tune for latency/recall.
- Metadata fields: mark as filterable for tenant, date, classification, ACL.
- Re-index triggers: change embedding model, dimensions, chunking, field mapping, or vector store.
Hard Rule: Vector dimensions and field mapping are immutable after ingestion. Plan before you ingest.
Document Indexing & Ingestion
- Data sources: Amazon S3, Confluence, SharePoint, Salesforce, web crawler, custom.
- Parsing: extract text, tables, images from PDFs/HTML/docs. Use multimodal parsing if needed.
- Chunking strategies:
- Default: token-based split.
- Fixed-size: consistent chunks + overlap; predictable.
- Hierarchical: parent/child; retrieve child, return parent for context.
- Semantic: groups sentences by meaning; better coherence, higher compute.
- Chunk size trade-off: smaller = precise retrieval, more vectors, fragmented context; larger = more context, diluted relevance.
- Overlap: preserves meaning across boundaries; typical 10–20%.
- Metadata: attach source, title, date, access tags. Enables filters and access control.
- Ingestion job: initial full sync. Resync is incremental — processes only new/changed/deleted documents since last successful sync.
Exam Gotcha: Resync does not re-embed the entire corpus. It only processes changes. A full re-embed is required only when embedding model, dimensions, chunking, or field mapping changes.
Retrieval Optimization
Retrieval Pipeline = Search Type + Top-K + Metadata Filters + Reranking
| Component | Purpose | Tuning / Trade-off |
|---|---|---|
| Semantic search | Meaning-based similarity | Good for natural language; misses exact IDs |
| Hybrid search | Vector + keyword (BM25) | Best for exact part numbers + semantics; OpenSearch only |
| Top-K | Number of chunks retrieved | Higher = recall up, latency/cost/noise up |
| Metadata filtering | Pre-filter by tenant/date/ACL | Reduces search space, enforces security, improves relevance |
| Reranking | Cross-encoder reorders candidates | Improves precision; adds latency/cost; use with larger Top-K |
| Chunk size/overlap | Context granularity | Tune with retrieval; smaller for Q&A, larger for summarization |
- High precision: retrieve large Top-K, then rerank to small Top-N (e.g., 100 → 5).
- Multi-tenant / compliance: metadata filters are mandatory; never rely on semantic similarity for isolation.
- Exact match + semantic: hybrid search, not pure vector.
- Cost control: reduce Top-K, use S3 Vectors for infrequent, cache frequent queries.
Exam Gotcha: If users must not see other tenants' data, metadata filtering is the answer — not prompt instructions, not separate models.
Security & Compliance
- IAM: KB service role needs read access to data source (S3), vector store access (OpenSearch/Aurora/Neptune/third-party), Bedrock model invoke, KMS decrypt, Secrets Manager for third-party credentials.
- KMS: encrypt S3, vector store, KB, and Secrets Manager with CMKs. Use separate keys for audit boundaries.
- Network: private subnets + security groups for VPC-based vector stores. VPC endpoints for S3 (gateway), Bedrock, KMS, Secrets Manager, OpenSearch. No public internet for sensitive data.
- Data governance: metadata filters for row-level ACL; Guardrails for PII; CloudTrail/CloudWatch for audit and trace.
- Least privilege: scope IAM to specific S3 prefixes, OpenSearch collections, KMS keys.
Hard Rule: If the vector store is in a VPC, the KB must have a private network path to it. Missing VPC endpoints = retrieval failures.
Anti-Patterns & Distractor Traps
- Mismatched dimensions → ingestion fails; always match embedding model.
- Changing embedding model without reindex → retrieval breaks.
- Assuming resync re-embeds everything → it only processes changes.
- Semantic search for exact part numbers → use hybrid.
- No metadata filtering in multi-tenant → data leakage.
- Large Top-K without reranking → noisy context, lost-in-the-middle.
- Graph store for generic RAG → overkill; use OpenSearch/Aurora/S3 Vectors.
- Hardcoding credentials → use IAM roles and Secrets Manager.
- Public vector store endpoint → use VPC endpoints/private access.
- Ignoring chunking → poor retrieval; tune size/overlap/strategy.
Quick Decision Matrix
| Requirement | Choose |
|---|---|
| Managed RAG + hybrid search | OpenSearch Serverless |
| Existing OpenSearch cluster | OpenSearch managed |
| Embeddings + relational joins | Aurora PostgreSQL pgvector |
| Graph relationships | Neptune Analytics |
| Low-cost large vector set | S3 Vectors |
| Exact IDs + semantic | Hybrid search |
| Multi-tenant isolation | Metadata filtering |
| High precision | Reranking |
| Incremental updates | Resync ingestion job |
| Full re-embed | Change embedding model/dimensions/chunking |