AI-300: Designing Vector, Keyword, and Hybrid RAG Retrieval

Introduction

Use keyword retrieval when the query's terms carry essential evidence, vector retrieval when meaning is expressed differently from the stored wording, and hybrid retrieval when both signals matter. In retrieval-augmented generation (RAG), the choice should follow representative queries and required evidence. A hybrid design is a useful candidate for mixed workloads, but it still needs to demonstrate that relevant material reaches the answer context.

Azure AI Search separates candidate retrieval, Reciprocal Rank Fusion (RRF) across multiple result lists, and optional semantic reranking. Those stages solve different problems and produce different scoring signals. Design the index/query contract first, then select retrieval and ranking stages; do not turn one numerical cutoff into a universal definition of relevance.

Architecture Overview

The indexing path prepares source content, text fields, vectors and supporting metadata. The query path uses those representations to find evidence, orders the candidates, and returns material that the application can select for its generation context. Recommend preserving readable content and source identifiers alongside vector representations so the application can inspect and cite the evidence it actually uses.

Keep these contracts explicit:

These are application design responsibilities rather than a proposed index schema. A well-formed query can still retrieve poor evidence if it targets the wrong representation or if the answer-bearing passage was not indexed.

Core Components

Keyword and vector retrieval

Keyword retrieval searches text. It is a useful starting point for requests containing distinctive names, error codes or exact terminology. Test those terms against the actual index configuration; keyword retrieval should not be assumed to guarantee exact identifier preservation without checking how the content is represented.

Vector retrieval finds neighbors in embedding space. Azure AI Search supports approximate nearest-neighbor retrieval using Hierarchical Navigable Small World (HNSW) and exhaustive nearest-neighbor search. Approximate retrieval trades exhaustive comparison for efficiency; neither algorithm establishes that a passage answers the user's question.

Index and query vectors must come from the same embedding model. Azure AI Search does not host that model: vectors can be supplied by the application or produced through integrated vectorization connected to an external model. Do not equate “same vector length” with a verified shared embedding space. Detailed model selection and adaptation belong in AI-300: Selecting and Adapting Embedding Models.

Hybrid retrieval and RRF

A hybrid request combines keyword and vector retrieval. Azure AI Search uses RRF to fuse their ranked result lists; multiple vector result lists can also trigger fusion. This combines ranking evidence, rather than treating raw text and vector scores as interchangeable measurements.

For an illustrative support corpus, one passage might appear near the top of the keyword list because it contains an error code, while another appears high in the vector list because it describes the user's symptom. Inspect both contributions before deciding that the lexical path or the vector path is unnecessary. Hybrid search offers a way to retain both kinds of candidate evidence, not a guarantee that every result is useful.

Semantic reranking

Semantic ranking is a later ranking step over retrieved results, including fused hybrid results. It is distinct from embedding similarity at candidate retrieval. Its job in this architecture is to improve ordering among available candidates, so it cannot rescue an answer-bearing passage that never enters that candidate set.

The current vector-query guidance says semantic ranker uses up to 50 matches and recommends k of 50 when combining vector retrieval with semantic ranking. Treat that as input guidance for that configuration, not an instruction to place 50 passages into every generation prompt.

How the Retrieval Stages Work Together

Consider the sequence as candidate discovery, fusion when needed, optional semantic reranking, and application context selection. At each stage, preserve enough evidence to tell whether a relevant passage was missing, ranked too low, or discarded later.

Candidate counts are not all the same control:

The final response count and prompt context count should therefore be reviewed separately from vector candidate depth. Recommend recording the selected settings and the document identifiers surviving each stage. More candidates can help expose missing evidence, but more context can also add duplication or irrelevant text. Decide from the application's evidence and constraints rather than increasing every count together.

A nearest-neighbor query can return the requested neighbors even when their similarity is poor. A nonempty result set is not proof that the corpus covers the question. Plan an application response for insufficient evidence and assess it on out-of-scope queries.

Design Considerations

Compare the three choices on real query intent

Use the following original decision cases as hypotheses to validate, not benchmark results:

For each case, identify the passage that would support an acceptable answer and examine whether the proposed strategy retrieves it. Keyword-only design may be sufficient for a tightly controlled lookup workload. Vector-only design may be useful when phrasing varies substantially. Hybrid adds a second retrieval path and fusion, so qualify its benefit alongside operational complexity and latency. Optional semantic reranking is another decision to evaluate, not a synonym for hybrid search.

Preserve score meaning

For cosine-based pure-vector search, Azure AI Search's @search.score is a transformed score, not raw cosine similarity. A hybrid @search.score reflects RRF, with a different scale and dependence on the participating lists. Semantic reranking is another ranking signal. None of these is a probability that the eventual answer will be correct.

Recommend recording the query mode and ranking stage with any score used for analysis. Do not compare a raw cosine value, a pure-vector search score and a fused hybrid score as if they had one common scale. A cutoff copied from a vector experiment is not an appropriate raw hybrid-score policy.

The current vector-query documentation labels its threshold parameter as preview and applies it to vector results before fusion. This does not justify a universal cutoff on the final RRF score. This architecture guide intentionally supplies no threshold value or preview request template.

Diagnose the missing layer before changing models

If the correct passage is absent from the index, review content preparation. If it is indexed but absent from candidates, inspect the targeted representation and retrieval settings. If it survives retrieval but disappears before generation, review ranking and context selection. If the model receives the correct evidence but answers incorrectly, preserve that observation for application-level diagnosis.

Also retain access and content-eligibility requirements when comparing strategies. Relevance should not be treated as permission to expose material. Check what the application is allowed to retrieve and include before using a result to construct an answer.

Controlled configuration experiments and numerical tuning belong in the separate retrieval lab. This comparison establishes which architectural paths deserve those experiments and which evidence would distinguish their failures.

Common Mistakes

• Expecting semantic similarity to preserve every critical identifier without validation.
• Querying vectors from a different embedding model because their dimensions look compatible.
• Treating semantic reranking as a replacement for candidate retrieval.
• Confusing vector k, hybrid top and generation-context length.
• Assuming returned nearest neighbors prove that relevant evidence exists.
• Reusing one score threshold across pure-vector, hybrid and reranked results.
• Judging retrieval only by the fluency of the final generated answer.

Certification Relevance

For AI-300 learning, explain why a mixed exact-term and paraphrase workload may benefit from hybrid retrieval. Trace the evidence through indexing, candidates, fusion, reranking and context selection. The important distinction is which layer can fix the observed problem, rather than assuming a more sophisticated model or ranking step repairs every failure.

Conclusion

Choose retrieval around the query's evidence needs: important terms, semantic meaning, or both. Keep the index/query representations compatible, distinguish candidate discovery from later ranking, and preserve score context. A useful RAG architecture demonstrates that authorized, answer-bearing evidence reaches generation; a high score or nonempty result list alone does not establish that outcome.

Authoritative Sources

• Relevance in vector search
• Create a vector query in Azure AI Search
• Generate embeddings for search queries and documents

Related Reading

• AI-300: Choosing Foundry Model Deployment Options
• AI-300: Selecting and Adapting Embedding Models