Elasticsearch / Advanced: resilient and recoverable retrieval / Lesson 17

Vector search and hybrid retrieval

Connect embeddings, approximate candidates and rank fusion to measured catalog relevance and access constraints.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain vector dimensions, model compatibility and approximate recall.
Evaluate hybrid ranking without adding incomparable scores blindly.

A vector is meaningful within its model

An embedding model can represent an artifact description as a numeric vector so semantically related descriptions lie nearby under a chosen similarity. A three-number teaching vector is not a trained museum language model. Document and query vectors need compatible dimensions, preprocessing and model semantics; equal length alone does not prove compatibility. Keep the embedding model version with indexed data and plan a rebuild when it changes. Exact accession codes, names and filters still need lexical or structured retrieval. Semantic similarity can retrieve a plausible but factually wrong object, so it cannot authorize access or establish catalog truth.

Declare the vector contract explicitly

The mapping fragment declares an indexed dense_vector with three dimensions and cosine similarity. Real embeddings commonly use larger dimensions determined by their model; three is chosen solely for transparent local reasoning. Cosine compares directions and is undefined for a zero vector, so validate model output and the chosen metric’s requirements. Vector indexing introduces data structures and memory or cache demands beyond ordinary keyword fields. Do not claim that a vector field is a free addition to an existing catalog. Review index options and defaults for the exact release rather than assuming every 8.x and 9.x configuration behaves identically.

json Illustrative technical example; logical results are reasoned, not engine-tested.

{"mappings":{"properties":{"embedding":{"type":"dense_vector","dims":3,"index":true,"similarity":"cosine"},"status":{"type":"keyword"}}}}

A synthetic three-dimensional teaching mapping, not a recommendation for a production embedding model.

Approximate search trades candidate work against recall

The kNN body requests five neighbors from a larger candidate search and applies a displayed-status filter inside the kNN clause. Candidate settings are scenario values, not universal tuning numbers. Approximate search may miss true nearest neighbors; increasing candidate work can improve recall at a latency and resource cost. An access filter applied only after retrieval can also leave too few eligible results or expose unintended intermediates, so enforce the supported policy at the correct retrieval stage. Exact brute-force scoring can serve as a small evaluation reference but scales differently and should not be run casually over a large corpus.

json Illustrative technical example; logical results are reasoned, not engine-tested.

{"knn":{"field":"embedding","query_vector":[1,0,0],"k":5,"num_candidates":20,"filter":{"term":{"status":"displayed"}}},"_source":["artifact_id","title"]}

Requires compatible indexed vectors and supported kNN semantics. The unit vector is synthetic; no nearest-neighbor engine result is claimed.

Combine rankings without pretending scores share a scale

Lexical BM25 scores and vector similarity scores arise from different models. Adding them with arbitrary equal weights can let one scale dominate. Reciprocal rank fusion combines rank positions from result lists, using a rank constant and a bounded rank window under the documented retriever API. It still depends on candidate quality and window choices; fusion cannot recover a relevant document absent from every candidate list. Verify RRF, inference and model feature availability against the exact version and subscription rather than assuming every documented feature is included. A conceptually simple rank-fusion formula is separate from licensed product availability.

Measure relevance, cost and language coverage together

Compare lexical, vector and hybrid candidates on judged intents, including exact names, rare accession codes, Arabic descriptions and misleading semantic neighbors. Measure recall at the chosen candidate depth and final ranking quality separately. For local geometry only, [1,0,0] has cosine one with itself and zero with [0,1,0]; this arithmetic does not predict semantic usefulness or Elasticsearch’s final score transformation. Keep model provenance, privacy of submitted text and inference costs in the design. No model is downloaded, embedding service called, vector index created or retrieval benchmark executed by this course.

Common errors and fixes

Vector dimensions match but retrieval is poor

Why it happens: Document and query vectors came from incompatible model semantics or preprocessing.
How to fix it: Align model versions and rebuild the affected representation.
Prevent it next time: Persist model provenance and test known semantic pairs.

Hybrid results ignore exact catalog identifiers

Why it happens: Semantic ranking overwhelmed or omitted the lexical identity path.
How to fix it: Preserve an explicit identifier retrieval rule and judged evaluation.
Prevent it next time: Include rare exact-code intents in every relevance experiment.

Increasing k is assumed to guarantee exact neighbors

Why it happens: Returned count was confused with approximate candidate recall.
How to fix it: Evaluate candidate depth and compare a small exact reference where justified.
Prevent it next time: Label approximation and resource tradeoffs in the acceptance criteria.

Check your understanding

1. What is cosine similarity between [1,0,0] and [0,1,0]?

Show worked solution

Zero, because their dot product is zero and both have unit norm. That is a geometric statement only. Real semantic quality depends on the embedding model, and Elasticsearch may transform similarity into its own score according to the configured metric.

2. Can RRF recover an artifact absent from both lexical and vector candidate lists?