Chapter•60 Minutes

Items per page

7. Retrieval Algorithms and Search Strategies

Implement lexical, vector, hybrid, multi-query, and multi-hop retrieval with measured ranking behavior.

Lexical Search and BM25

Lexical search ranks based on term matches and their distribution. BM25 accounts for term frequency, inverse document frequency, and document length. It is strong for exact product names, error codes, identifiers, and rare terms, but may miss paraphrases. Analyzer choices, stemming, stop words, field boosts, and exact-match fields matter.

Keep lexical search as a baseline even when adding vectors. For code and IDs, punctuation and casing can carry meaning, so use appropriate analyzers and keyword fields.

Implementation example

Query "ERR_AUTH_401" -> lexical index -> matching runbook section

💡 Exact identifiers are often a strength of lexical retrieval.

Key Takeaways

Inspect the relevant pipeline stage instead of guessing.
Preserve source provenance, versions, and access scope.
Measure quality on representative queries.

Knowledge Check

Which query is especially suited to lexical search?

Vector Retrieval and Top-K

Vector retrieval embeds a query and finds nearby document vectors. TopK controls candidate count: too few can miss evidence, while too many can add noise, latency, and cost. Tune with recall and answer-quality measurements. Apply trusted filters and treat low-relevance results as a reason to abstain rather than forcing an answer.

Capture candidate IDs, scores, and filter metadata in evaluation traces so retrieval failures are reproducible.

Implementation example

const candidates = await vectorStore.search({
  vector: queryEmbedding, topK: 20, filter: trustedFilter
});

💡 The API is illustrative; topK is an experiment parameter, not a universal default.

Key Takeaways

Inspect the relevant pipeline stage instead of guessing.
Preserve source provenance, versions, and access scope.
Measure quality on representative queries.

Knowledge Check

What is the risk of always increasing topK?

Hybrid Search and Reciprocal Rank Fusion

Hybrid search combines lexical and vector results. Since their raw scores may use different scales, rank fusion such as Reciprocal Rank Fusion (RRF) can merge result lists using rank positions. A practical pipeline applies the same access filters, merges and deduplicates candidates, optionally reranks them, and selects a bounded context.

Hybrid retrieval is not always best; compare it against lexical-only and vector-only baselines on your corpus.

Diagram

Implementation example

Question -> lexical search ----\
                                -> RRF merge -> deduplicate -> rerank
Question -> vector search -----/

💡 Rank fusion avoids blindly adding incomparable raw scores.

Key Takeaways

Inspect the relevant pipeline stage instead of guessing.
Preserve source provenance, versions, and access scope.
Measure quality on representative queries.

Knowledge Check

Why use RRF?

Query Rewriting and Multi-Query Retrieval

A follow-up or domain-specific query may use wording that differs from the corpus. Rewriting creates a standalone query; multi-query retrieval generates several formulations; decomposition splits a complex request into subquestions. These techniques can improve recall but add cost and may introduce assumptions or duplicates.

Keep the original question, preserve authorization scope, and evaluate whether extra calls improve quality. Ask for clarification when intent remains ambiguous.

Implementation example

Original: "Does that apply to contractors too?"
Rewrite: "Does the paid leave policy apply to contractors?"
Keep original text for final answer context.

💡 Rewrites should clarify referents without changing the user's intent.

Key Takeaways

Inspect the relevant pipeline stage instead of guessing.
Preserve source provenance, versions, and access scope.
Measure quality on representative queries.

Knowledge Check

What must query rewriting preserve?

Multi-Hop Retrieval

Multi-hop questions require evidence from multiple documents. Retrieve an initial fact, derive a subquestion, retrieve the next evidence, and maintain a claim-to-source graph. Do not let the model invent intermediate relationships. Each conclusion should be supported by the premises and source passages.

Multi-hop retrieval is more expensive than one pass. Use it when evaluations show single-pass retrieval misses necessary evidence, and enforce a step budget.

Implementation example

Chunk A: Product X requires Runtime Y
Chunk B: Runtime Y is supported on Platform Z
Conclusion must cite both A and B.

💡 A source supporting one premise does not automatically support the whole conclusion.

Key Takeaways

Inspect the relevant pipeline stage instead of guessing.
Preserve source provenance, versions, and access scope.
Measure quality on representative queries.

Knowledge Check

What is essential in multi-hop RAG?

Lexical Search and BM25

Vector Retrieval and Top-K

Hybrid Search and Reciprocal Rank Fusion

Query Rewriting and Multi-Query Retrieval

Multi-Hop Retrieval

STAY UPDATED WITH BYTES!