Keyword search finds lexical matches, vector search finds similarity in an embedding space, and hybrid search combines signals from both. For enterprise RAG, choose and tune retrieval against representative questions, relevant evidence and permission boundaries. Hybrid is a useful candidate when questions mix exact identifiers with conceptual language, but its value must be measured on the actual corpus.

Retrieval and answer generation are separate stages. A fluent answer cannot repair evidence that the retriever missed or was not allowed to expose. This comparison includes a query test set, ranking-fusion demonstration and evaluation checklist without invented vendor benchmarks.

Choose by the question and the evidence

• Test lexical retrieval for product codes, policy identifiers, names and exact phrases.
• Test vector retrieval for paraphrases and conceptual questions.
• Test hybrid retrieval when both kinds of signal matter.
• Evaluate reranking separately from candidate retrieval.
• Apply access and freshness rules before evidence reaches the model.

What each retrieval method contributes

Keyword and full-text search

Lexical retrieval ranks content using the words and analyzed terms in the query and index. Exact identifiers and specialized names can be valuable signals. Tokenization, analyzers, synonyms and field configuration affect behavior, so do not assume an exact-looking code will be preserved without testing.

Vector search

Vector retrieval compares representations generated in a compatible embedding space. It can surface related wording without a direct lexical match. Similarity is not proof that a passage answers the question, is current or is permitted. Microsoft’s vector-ranking documentation explains exhaustive and approximate nearest-neighbor retrieval in Azure AI Search.

Hybrid retrieval and reranking

A hybrid request combines lexical and vector candidate rankings. Azure AI Search, for example, uses reciprocal rank fusion to merge parallel result lists. An optional later reranker is a separate stage, not the same operation as generating embeddings. See the hybrid search overview.

Keyword vs vector vs hybrid: practical comparison

Worked example: combining two ranked lists

Reciprocal rank fusion combines contributions based on positions in result lists. The following original demonstration uses fictional document IDs and already-ranked lists. It does not implement keyword search, embeddings or a production search engine. The formula is described in Microsoft’s RRF documentation.

def fuse(rankings, constant=60):
    if constant <= 0:
        raise ValueError("Use a positive fusion constant")
    scores = {}
    for ranking in rankings:
        if len(set(ranking)) != len(ranking):
            raise ValueError("Each ranking must contain unique IDs")
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (constant + rank)
    return sorted(scores.items(), key=lambda item: (-item[1], item[0]))

lexical = ["policy-23", "vacation", "expense"]
vector = ["vacation", "leave-guide", "policy-23"]
for doc_id, score in fuse([lexical, vector]):
    print(doc_id, round(score, 6))

Running this demonstration produces vacation 0.032522, policy-23 0.032266, leave-guide 0.016129 and expense 0.015873. The first two documents benefit from appearing in both lists. These scores illustrate the calculation, not relevance judgments or search accuracy. The fusion constant is distinct from a vector query’s requested number of neighbors.

Do not add raw lexical and vector scores without an intentional calibration or fusion strategy. Their scales can differ. Also inspect duplicate chunks from the same source so a fused ranking does not waste the context window repeating nearly identical evidence.

Build a query set that reflects enterprise use

The following fictional questions help expose different retrieval needs. For each one, identify the permitted passages that genuinely support an answer before comparing systems.

Include misspellings, abbreviations, multilingual inputs where required and questions that need more than one passage. Keep development queries separate from the held-out evaluation set. Otherwise tuning can look successful while failing on new requests.

Measure retrieval and answer quality separately

Recall at a chosen depth asks how much of the known relevant evidence appears in the retrieved set. Precision at that depth asks how much of the retrieved set is relevant. Define what counts as a relevant passage and how duplicate chunks are treated before computing either.

For a simple illustration, if a question has four labeled relevant passages and the top five results contain three of them, recall is 3/4 and precision is 3/5. Those arithmetic values are 75% and 60%. They are not results of an actual retriever experiment.

Evaluate answer support after retrieval: does the response follow the evidence, preserve qualifications and cite the right source? A retriever can find the correct passage while the generator misstates it. Conversely, a model may know a plausible answer without retrieving approved evidence. For an enterprise RAG task, those are different outcomes.

Compare controlled variants

Hold the corpus version, permission scope and evaluation questions constant. Compare lexical, vector and hybrid retrieval, then test any reranker as a separate change. Record the candidate depth, embedding configuration, chunking policy and latency. Change one meaningful variable at a time so improvements can be attributed.

Cost, freshness and operational choices

Vector retrieval introduces embedding and vector-index responsibilities. Hybrid retrieval retains text and vector paths. Reranking adds another processing stage. Measure total ingestion and query cost, not only one API call. Include reindexing after source changes and embedding-model migrations.

Permission changes and document retirement need a propagation path. An expired policy should not remain authoritative because its embedding still exists. Filter design, retrieval behavior and source checks must jointly prevent unauthorized or superseded evidence from reaching the model.

Choose the simplest configuration that meets the evaluated task. Exact-reference workloads may need stronger lexical treatment; paraphrase-heavy questions may benefit from vector candidates; mixed workloads justify testing hybrid. Avoid declaring a universal winner from a small demonstration.

For the surrounding application design, read RAG architecture explained and RAG vs fine-tuning vs prompt engineering.

Common questions about enterprise retrieval

Review retrieval against your evidence and questions

Request an enterprise RAG architecture review with Prominent AI Services LLP. Bring representative questions, approved sources and known no-answer cases.

Technical references reviewed 2 November 2026. The fusion code was run locally; rankings and metric examples are illustrative, not production search benchmarks.