What's changed: Initial: 5 sections for Domain 1 (FM integration, data management, compliance)
1.3Designing Vector Store Solutions
Learn vector database design for FM augmentation: Amazon Bedrock Knowledge Bases, OpenSearch Service (vector search/Neural plugin), Aurora pgvector, DynamoDB, metadata frameworks, and freshness via incremental updates.
The heart of RAG is the vector store: documents are converted to embeddings and stored, then searched by semantic similarity. Choose the store by requirements (scale, ops, existing assets).
1.3.1Choosing a vector store
- Amazon Bedrock Knowledge Bases: a managed end-to-end RAG (ingestion, chunking, embeddings, retrieval). The default to start RAG with minimal ops.
- OpenSearch Service (vector search): for large scale, hybrid search (keyword + vector), and fine control via sharding/hierarchical indexing.
- Aurora (pgvector): to keep vectors alongside existing relational data (PostgreSQL extension).
- Metadata frameworks: attach metadata (timestamps, authorship, domain tags) to improve retrieval precision and filtering.
Common: fastest managed RAG = Bedrock Knowledge Bases, large scale + hybrid search = OpenSearch vector search, alongside existing RDB = Aurora pgvector, freshness = incremental updates/auto-sync, precision = metadata + filters. Knowledge Bases can use OpenSearch Serverless, etc., as a managed vector store.
The axes are operational burden vs control granularity. For minimal ops use Bedrock Knowledge Bases (point it at data sources like S3 and ingestion→retrieval is automatic); for fine control or large-scale hybrid search use OpenSearch Service (integrate Bedrock embeddings via the Neural plugin; partition with sharding/multiple indexes). With existing PostgreSQL/Aurora, co-locate via pgvector. DynamoDB can store metadata/embeddings alongside. Maintain freshness with incremental updates (change detection → re-embed only affected chunks), scheduled re-ingestion, or real-time sync. Retrieval precision depends heavily on chunking, metadata, and filters. Knowledge Bases also supports integrating multiple sources like internal wikis and document management systems.
| Need | Choose | Notes |
|---|---|---|
| RAG with minimal ops | Bedrock Knowledge Bases | Automates ingestion→retrieval |
| Large/hybrid search | OpenSearch vector search | Keyword + vector / sharding |
| Alongside existing RDB | Aurora pgvector | PostgreSQL extension |
| Freshness | Incremental update/sync | Re-embed only changes |
Trap: “re-embed everything whenever a document changes” is inefficient and wrong—use incremental updates (re-embed only changed chunks). Also “you must always build OpenSearch yourself” is wrong—if minimal ops is the requirement, Knowledge Bases is the default.
1.3.2Section summary
- Minimal ops = Knowledge Bases / large·hybrid = OpenSearch / with RDB = Aurora pgvector
- Precision = metadata + filters / freshness = incremental updates
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. With minimal ops, you want to start RAG over internal docs in S3 quickly, with managed ingestion, chunking, embeddings, and retrieval. Which?
Q2. For a large knowledge base, you want fine-grained control of hybrid search combining keyword and semantic similarity. Best vector store?
Q3. You have business data in Aurora PostgreSQL and want to store and search embeddings in the same DB without new infrastructure. Best option?