Skill 2.2.9: Optimize retrieval components and embedding models
Task 2.2: ML Model and Foundation Model (FM) Development — Train, fine-tune, and customize models for ML and AI solutions
Core Concept & Business Objective
Retrieval quality caps answer quality. In a RAG/generative AI application, the retriever decides what the model is allowed to know; the generator only phrases it. Optimization means raising recall (the answer-bearing passage is in the candidate set) and precision (irrelevant passages are filtered out before they reach the prompt).
The four optimizable components: (1) Embedding model — vector representation of documents and queries, (2) Chunking — how source content is segmented, (3) Vector store / index — similarity search, filtering, ranking, (4) Retrieval config — search type, top-K, reranking, query transformation.
Non-negotiable: The same embedding model and dimensions must be used at ingestion and at query time. A mismatch produces silently meaningless similarity scores — not an error.
Triage: Where Is the Failure? (Do This Before Changing Anything)
| Symptom | Actual fault | Correct lever |
|---|---|---|
| Retrieved passages are topically off / answer not present | Retrieval | Embedding model, chunking, hybrid search, top-K |
| Passages contain the answer but the response is wrong/vague/ignores them | Generation | Prompt engineering → then fine-tuning |
| Relevant passage exists but ranks below top-K | Ranking | Reranker, hybrid search, index tuning |
| Answers correct for one phrasing, wrong for synonyms/jargon | Embedding | Domain-tuned embedding model, hybrid search |
Exam trap: "The model gives wrong answers" almost always points to retrieval, not the generator. Changing temperature, max tokens, or fine-tuning the LLM does not fix bad retrieval.
Embedding Model Selection (Amazon Bedrock)
| Model | Dimensions | Max input | Use when |
|---|---|---|---|
| Titan Text Embeddings V2 | 1024 (default), 512, 256 | 8K tokens | Default text RAG; dimension reduction for cost/latency |
| Titan Text Embeddings G1 | 1536 | 8K tokens | Legacy — prefer V2 |
| Titan Multimodal Embeddings G1 | 1024 | Text + image | Image search, mixed text/image corpora in one vector space |
| Cohere Embed English v3 | 1024 | 512 tokens | Strong English semantic/retrieval benchmarks |
| Cohere Embed Multilingual v3 | 1024 | 512 tokens | 100+ languages, cross-lingual retrieval |
| Custom (SageMaker endpoint) | Yours | Yours | Domain jargon, specialized corpora, or a fine-tuned embedder |
Optimization levers:
- Dimension reduction — Titan V2's 256/512 outputs cut vector storage and search cost ~4x vs 1024 with modest recall loss. Set the index dimension to match the model output; you cannot mix.
- Normalization — normalize embeddings when the index uses cosine similarity; unnormalized vectors skew cosine scores.
- Domain adaptation — Bedrock's Titan/Cohere embedding models are not fine-tunable. For domain-specific vocabulary, train a custom embedder (contrastive learning with hard negatives) on SageMaker and expose it via a real-time endpoint as the KB's embedding model.
- Benchmark before switching — evaluate on your labeled query→passage pairs (recall@k, MRR, nDCG), not on public leaderboards alone.
Gotcha: Swapping the embedding model or changing output dimensions invalidates the entire vector index. A full re-chunk + re-embed + re-sync of every data source is mandatory.
Chunking Strategy Matrix (Bedrock Knowledge Bases)
| Strategy | Behavior | Best for | Watch out |
|---|---|---|---|
| Default | ~300-token splits, no overlap | Quick baseline | Ignores document structure |
| Fixed-size | Token size + overlap % | Uniform prose, predictable cost | Splits tables/sentences mid-thought |
| Hierarchical | Parent + child chunks; child retrieved, parent returned to the model | Long documents needing surrounding context | Higher storage; more tuning knobs |
| Semantic | Splits on meaning shifts (buffer size + breakpoint percentile) | Mixed-topic docs, transcripts | Nondeterministic chunk counts; slower ingestion |
| No chunking | One chunk per file | Short records, structured/CSV-like data | Useless for long PDFs |
| Custom (Lambda) | Post-chunk transformation (enrich, redact, tag metadata) | Compliance, metadata injection | Added latency/complexity |
Tuning heuristics:
- Too large → semantic signal diluted by noise, wasted prompt tokens, "lost in the middle."
- Too small → answers fragmented across chunks, missing context, poor recall.
- Overlap preserves boundary context at the cost of storage and duplicate hits.
- Always preserve structure: split on headings/sections before raw token counts.
Vector Store Selection for Knowledge Bases
| Store | Notes |
|---|---|
| Amazon OpenSearch Serverless (vector engine) | Default quick-create; richest KB feature set — hybrid search, reranking, query decomposition |
| Amazon OpenSearch Service (provisioned) | Existing clusters; more index-level k-NN tuning control |
| Amazon Aurora / RDS for PostgreSQL (pgvector) | Reuse relational data; SQL joins with metadata |
| Amazon Neptune Analytics | Graph + vector; entity/relationship-aware retrieval |
| Amazon S3 Vectors | Lowest-cost, cost-optimized; limited advanced retrieval features |
| Third-party (Pinecone, MongoDB Atlas, Redis Enterprise Cloud) | Existing investments; feature parity varies |
Gotcha: Advanced retrieval features (hybrid search, reranker, query decomposition) are store-dependent — primarily OpenSearch Serverless. If a scenario demands hybrid search, the vector store choice is effectively forced.
Retrieval-Time Tuning
- Top-K (number of results) — raises recall but lowers precision and inflates prompt tokens, latency, and cost. Retrieve wide, then narrow with a reranker.
- Hybrid search — combines semantic (vector) + keyword/lexical matching. Fixes exact-match failures: product SKUs, error codes, acronyms, proper nouns that embeddings blur.
- Reranking (Cohere Rerank via Bedrock) — a cross-encoder scores each query–passage pair jointly. Far more accurate than embedding similarity, but cannot be precomputed — it runs per query on the candidate set. Two-stage pattern: bi-encoder retrieve → cross-encoder rerank.
- Metadata filtering — filters on chunk attributes at the vector store, not in the LLM. Explicit filters (user/app supplies values) vs implicit (model extracts filter values from the natural-language query). Custom metadata supplied via sidecar metadata files alongside source documents.
- Query transformation / decomposition — splits multi-part questions into sub-queries retrieved separately. Essential for comparative or multi-document questions.
Index & Similarity Trade-offs
| Lever | Effect of increasing | Cost |
|---|---|---|
HNSW m / ef_construction |
Better recall, better graph quality | Slower index build, more memory |
HNSW ef_search |
Better recall at query time | Higher query latency |
| Approximate (ANN) vs exact k-NN | ANN = fast, slightly lower recall | Exact = guaranteed, slow, doesn't scale |
| Quantization (scalar/binary) | Large memory savings | Small recall loss |
| Distance metric (cosine / L2 / dot product) | Must match the embedding model's training objective | Wrong metric = degraded results, no error thrown |
Evaluation (Amazon Bedrock RAG Evaluation)
- Retrieval-only metrics: Context relevance (are retrieved passages on-topic?), Context coverage (is the needed evidence present?).
- Generation metrics: Faithfulness (grounded in retrieved context, no hallucination), Answer relevance, Correctness (requires ground-truth answers), plus completeness/helpfulness/harmfulness.
- LLM-as-a-judge requires selecting an evaluator model; supports bring-your-own-inference-response to score outputs from outside Bedrock.
- Run retrieval metrics first — if context relevance is low, generation scores are noise.
Anti-Patterns & Exam Gotchas
Retrieval ≠ generation. If retrieved passages lack the answer, no prompt, temperature, or fine-tune will produce it. Fix the embedding model, chunking, and ranking.
Never fine-tune the generator to "teach it facts" that belong in the knowledge base — that's a retrieval problem, and fine-tuning bakes in stale knowledge plus catastrophic forgetting.
Metadata filtering is pre-generation. It happens in the vector store query, before the LLM ever sees context.
Reranking cannot be precomputed. It is a per-query cross-encoder pass — expect added latency; budget for it.
Higher top-K is not free. More chunks = more tokens = higher cost, higher latency, and "lost in the middle" degradation.
- Mixing embedding models between ingestion and query — silent quality collapse.
- Changing chunking strategy without re-ingesting — the index still holds old chunks.
- Single-chunk long PDFs — guaranteed retrieval failure.
- Fine-tuning the embedder before trying hybrid search — lexical matching often solves jargon/exact-match issues at zero training cost.
- Ignoring the similarity metric — cosine vs L2 mismatch degrades silently.
- Optimizing the generator when retrieval metrics are poor — wasted iteration cycle.
X vs Y Quick Reference
| Decision | Choose X | Choose Y |
|---|---|---|
| Prompt engineering vs fine-tuning | Instructions, format, few-shot examples | Style/tone/format compliance at scale, labeled I/O pairs |
| RAG vs fine-tuning for knowledge | Facts change, need citations, large corpus | Behavior/format change, not fact recall |
| Semantic vs hybrid search | Natural-language, conceptual queries | Exact terms: SKUs, codes, names, acronyms |
| Reranking vs higher top-K | Precision matters, latency tolerable | Cost/latency constrained, recall already adequate |
| Smaller embedding dims vs larger | Cost/latency-sensitive at scale | Maximum recall on complex semantics |
| Managed embedder vs custom | General-domain text | Specialized jargon, multilingual niche, proprietary corpus |
| Wide retrieval + rerank | Multi-hop, comparative questions | Single-fact lookups with tight latency SLOs |