Title: Quiz 6 — Hybrid Search: Combining Dense Retrieval with BM25
Course: AIINFRA 301: Production RAG & LLMOps — Observability and Evaluation > Section: Week 06 — Hybrid Search: Combining Dense Retrieval with BM25

Q: Which type of query is BM25 (lexical search) most likely to answer correctly when dense retrieval fails?
- A conceptual question phrased in unfamiliar wording
- A query containing an exact product SKU or rare technical term
- A query with no keyword overlap with the target document
- A general summarization request
A: A query containing an exact product SKU or rare technical term

Q: Dense vector search is strictly better than BM25 in all cases, which is why BM25 is considered obsolete in modern RAG systems.
- True
- False
A: False

Q: Write the Reciprocal Rank Fusion (RRF) formula for combining ranked result lists.
Feedback: Sample/expected answer: score(d) = Σ 1 / (k + rank(d))**, summed across each result list the document appears in.

Q: What is the empirically-derived default value for the RRF constant k, found on TREC data?
- 10
- 60
- 100
- 1
A: 60

Q: Naive score-averaging (normalizing BM25 and cosine similarity to \[0,1\] and adding them) is a safe, standard way to combine lexical and dense search results.
- True
- False
A: False

Q: Why does RRF avoid the score-incompatibility problem that naive score-averaging runs into?
Feedback: Sample/expected answer: RRF operates on rank position (where a document placed in each result list), not on raw scores, so it never needs to reconcile BM25's unbounded scale with cosine similarity's bounded scale.

Q: According to cited studies, roughly how much improvement does hybrid search show over dense-only retrieval, alongside consistently higher NDCG?
- 2–5%
- 10–15%
- 26–31%
- 60–70%
A: 26–31%

Q: In Qdrant's implementation pattern for hybrid search, how are the dense and sparse (BM25) representations typically stored and queried?
- In two separate collections queried independently, with results merged client-side
- As a `dense_vector` and a `bm25_sparse_vector` on the same point in one collection, queried via the Query API's `prefetch` plus a fusion parameter
- Only the dense vector is stored; BM25 is computed on the fly from raw text at query time
- BM25 scores are pre-computed and stored as metadata filters, not vectors
A: As a `dense_vector` and a `bm25_sparse_vector` on the same point in one collection, queried via the Query API's `prefetch` plus a fusion parameter