Embeddings, hybrid search, and rerankers

Lesson 2 of 4 in Retrieval Engineering.

Two decisions sit under every retrieval stack. First, the embedding model: Amazon Titan Text Embeddings V2 offers configurable output dimensions — 1,024, 512, or 256 — over an 8K-token window, with float or binary vectors. The dimension dial is a real architecture decision: 256-dim vectors cost a quarter of 1,024-dim to store and compare, at some fidelity loss; "based on dimensionality and domain fit" is how the AIP-C01 exam guide words the choice, and fit is measured by evaluating candidate embedding models on your own retrieval set (Lambda batch jobs generate the vectors at corpus scale).

Second, the search architecture. Pure vector search misses exact identifiers — part numbers, error codes, names — that lexical BM25 nails; lexical search misses paraphrase that vectors catch. Hybrid search runs both and merges normalized scores (OpenSearch's hybrid query; Aurora pgvector and Knowledge Bases offer their own routes). Then a reranker — the Bedrock Rerank API, callable directly or inside Knowledge Bases' Retrieve/RetrieveAndGenerate — scores each candidate against the query with a cross-encoder and reorders, so you can pass fewer but better chunks to the model: quality up, token cost and latency down. Reranking applies to text only.

Key terms: Amazon Titan Text Embeddings V2, Embedding, Hybrid search, Reranker, HNSW

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.