Three plain ideas, put together: two ways of finding, one list of results, and a rule for merging them.

Elasticsearch can find documents in two quite different ways. The first is lexical search, also called keyword or full-text search. It breaks the query into terms, looks those terms up in an inverted index, and ranks documents by how well their words match, using a scoring formula called BM25. It is fast, precise, and easy to explain: a document matched because it contains the words you typed.

The second is semantic search. Here, the query and the documents are turned into vectors, lists of numbers that capture meaning, by an embedding model. Documents whose vectors lie closest to the query vector are returned. It finds paraphrases and related ideas even when no words are shared. But it is less precise with exact strings, and harder to explain.

Hybrid search uses both at once. A single request contains a lexical part and a semantic part. Elasticsearch runs each part, collects two ranked lists of candidate documents, and merges them into one final ranking. The merging rule is the heart of hybrid search, and much of this guide is about how to choose it well.

What it is not

Hybrid search is not a separate field type or a separate index. It is a way of asking. The documents still contain ordinary text fields, which have inverted indexes, and they also contain vector fields, which have graphs. Hybrid search is the request that uses both. It is also not a single fixed recipe. Elasticsearch offers several ways to combine the two legs, and the best one depends on your data, your users, and your tolerance for tuning. Finally, hybrid search is not the same as a filter plus a search. A filter narrows the set of documents. Hybrid search changes how the remaining documents are ranked.

The one-sentence version

If you remember one line from this chapter, make it this: hybrid search runs a keyword search and a vector search for the same query, then merges the two ranked lists into one, so that exact matches and meaning-based matches both have a fair chance of appearing near the top.

Hybrid search is not a fashion. It is an answer to a specific fact: keyword search and vector search fail in opposite ways.

Keyword search fails when the words do not match. A user types “cheap flights” and the page says “budget airfare.” A user types “how do I fix a leaking tap” and the article is titled “Repairing a dripping faucet.” The engine has no way to know that these are the same ideas. Search engineers built synonym lists, stemming, and spelling correction to patch this, with partial success.

Vector search fails when the words must match. A user types a part number, an error code, a person’s surname, an abbreviation, or a rare technical term. An embedding model may blur these into something similar rather than exact. It may return documents about a similar-looking part number, or about a different person with a related name. For queries where the exact string is the whole point, keyword search is simply better.

Real users send both kinds of queries, sometimes in the same session, sometimes in the same sentence: “error 0x80070057 when installing update.” A search engine that handles only one kind serves half of its users badly. Hybrid search removes the need to choose.

A short history

The exact release for each step is worth double-checking in the release notes of your version. The direction of travel is what matters: from “choose one method” to “run both and merge them well, then refine the top with a stronger model.”

Why the keyword side stays essential

It might seem that vectors, being smarter, should replace keywords entirely. Experience says otherwise. Independent evaluations of retrieval systems have repeatedly found that a well-tuned keyword search is a hard baseline to beat, especially on data unlike what an embedding model was trained on, such as specialist vocabularies, product catalogs, and internal jargon. Vectors often win on natural language questions, and often lose on exact terms. The combination tends to beat both, which is why hybrid search has become the default recommendation for many production systems.

A dozen words explain nearly everything about hybrid search. Learn them here, and later chapters will read like common sense.

Scores and ranks are different things

This distinction is the key to understanding fusion. A score is a number that a search leg gives a document: 12.4 for one, 8.1 for another. A rank is the position: first, second, third. Scores carry extra information, such as how much better the first result is than the second. But scores from different legs are on different scales and mean different things. A keyword score of 12.4 and a vector score of 0.84 cannot be added meaningfully. Ranks, on the other hand, are comparable across lists, because “third place” means the same thing in any contest.

Recall first, precision later

Hybrid search is usually built in stages. The first stage, retrieval, should be generous. Its goal is high recall: make sure that the good documents are among the candidates, even if many bad ones come along. Later stages, such as merging and reranking, aim at precision: put the best candidates at the top. Using two legs increases recall, because a document that one leg misses may be found by the other. This staged thinking explains most design choices in this guide.

Why the two legs see different worlds

The lexical leg sees only terms after analysis: lowercased, split, perhaps stemmed. The semantic leg sees only vectors: positions on a map. They share no internal structure, so each can find documents the other cannot see. That is exactly why they complement each other, and exactly why merging their scores is tricky.

Quick glossary

Where do the two legs live, how do their results meet, and what happens after the merge?

A hybrid search touches the same documents in two different structures. The text fields of each document are held in inverted indexes, one per field per segment. The vector fields are held in vector files and graphs, one per field per segment. The request runs a lexical search against the first and a vector search against the second. The results meet at a merge step, and optionally pass through a reranker before going back to the user.

flowchart TB
    U["User query"] --> QU["Query understanding: clean, classify, and expand"]
    QU --> LX["Lexical leg: BM25 over the inverted index"]
    QU --> EM["Embedding step: turn the query into a vector"]
    EM --> SM["Semantic leg: nearest-neighbor search over vectors"]
    LX --> FU["Fusion: merge the two ranked lists"]
    SM --> FU
    FU --> RR["Optional reranker: re-order the top results"]
    RR --> OUT["Final ranked results"]
    

Read the picture from top to bottom. The user’s query may first be cleaned or classified. Then two things happen in parallel: the lexical leg searches the inverted indexes using the words of the query, and the query is embedded and used by the semantic leg to search the vectors. Each leg returns a ranked list of candidates. The fusion step merges the two lists into one. An optional reranker then re-orders the best candidates using a stronger model. The final list goes back to the user.

The main components

Two structures, one document

A key point of the architecture is that the same document carries both representations. A product might have a title and a description, indexed as text, and also a vector made from its title and description, stored in a vector field. The document has one identifier, so when both legs return the same document, the fusion step can recognize it and combine its evidence. Documents that only one leg found are still kept, with evidence from one side.

Walking one hybrid search through the machine

A hybrid search is only as strong as its two legs. The keyword leg is older and better understood, and worth tuning first.

How the lexical leg finds documents

The query text passes through an analyzer, which splits it into terms, lowercases them, and applies the same kind of processing that was applied to the documents. For each term, Lucene reads the postings list of documents that contain it, combines the lists according to the query, and scores each matching document with BM25. The score depends on how rare the term is in the collection, how often it appears in the document, and how long the field is. A rare term in a short title counts far more than a common term in a long body.

Choosing the lexical query

What makes a strong lexical leg

The lexical leg is a strong baseline

Before adding vectors, it pays to know how good the keyword side is on its own. Build a set of real queries with judgments, measure it, and improve it with analyzers, field weights, and synonyms. Many teams find that a carefully tuned keyword leg solves a large share of their problems, and that vectors then add value on the remaining hard cases. The measurement also gives you a baseline that hybrid search must beat, or it is not worth its extra cost.

Where keywords are weak

• Vocabulary mismatch. The query uses different words from the documents.
• Long natural questions. Many function words and little signal, which can dilute matching.
• Intent. The user’s goal is not stated in any word of the query.
• Cross-language search. Words in one language never match words in another.
• Very short documents. Few terms to match, so many relevant items are missed.

The second leg finds documents by meaning. There is more than one way to build it, and each has its own strengths.

Three ways to build the semantic leg

How the dense leg works

The query is turned into a vector by the same model that produced the stored vectors. Elasticsearch then searches the graphs of each segment for the vectors nearest to it and returns the closest documents, with a score that grows as closeness grows. You control how many neighbors are wanted, and how many candidates each shard examines. More candidates find more of the true neighbors, but cost more time. A minimum similarity can be set, so that results below it are dropped.

How the sparse leg works

At indexing time, a model reads each document and produces a set of terms with weights, for example “hiking 1.9, trail 1.4, boots 1.1, outdoor 0.8, mountain 0.6,” where some terms were never in the text. These are stored in a sparse vector field. At search time, the query is expanded the same way, and documents are ranked by the overlap of weighted terms. Because it is built on term overlap, it works like keyword search with a learned vocabulary. It needs no graph, uses less memory than dense vectors, and lets you see which terms drove a match.

Choosing the model

The choice of model shapes the semantic leg more than any setting. It must fit your language, your content type, and your budget. Test candidate models on your own queries before you commit, and remember the rule that queries and documents must be embedded by the same model. A more detailed treatment of models, dimensions, similarity metrics, and quantization is beyond this guide, but the essential point is that hybrid search inherits the strengths and weaknesses of whichever model you pick.

Chunking for the semantic leg

A vector for a long document blurs many ideas together. The usual answer is to cut long content into chunks of a few hundred words, embed each, and search the chunks. This has consequences for hybrid search: the semantic leg now returns chunks, while the lexical leg may return whole documents. Chapter 12 covers how to line the two up, so that fusion compares like with like.

The semantic leg on its own is not enough

The most direct way to merge two legs is to add their scores. It works, but only when you handle one important problem.

The simple approach

In a single request, you can send a lexical query and a vector search together. For each document, Elasticsearch takes the lexical score, if the document matched the query, and the vector score, if the document was among the nearest neighbors, and adds them. Each part can carry a boost, a multiplier that says how much it should count. Boosting the lexical part by 0.9 and the vector part by 0.1 means that the final score is mostly lexical with a small semantic contribution. A document found by only one leg simply has no contribution from the other.

The problem: different scales

Lexical scores from BM25 are not bounded. They depend on the query, the field lengths, and the collection, and can be anywhere from a fraction to dozens. Vector scores, by contrast, are bounded, typically between zero and one. If you add them raw, the larger numbers dominate, and the vector leg has almost no influence, whatever you intended. The weights you choose then have to fight the scale difference, and a weight that works for one query may fail for another, because the lexical score range changes with the query.

A numbers walkthrough

Let us use invented numbers with four documents, A, B, C, and D. The lexical leg returns A with a score of 12.4, B with 8.1, and C with 3.2. It does not find D. The vector leg returns C with 0.91, D with 0.88, and A with 0.84. It does not find B.

If we add the raw scores, A gets 12.4 plus 0.84, which is 13.24. B gets 8.1. C gets 3.2 plus 0.91, which is 4.11. D gets 0.88. The order is A, B, C, D. Notice that the vector leg made almost no difference: even D, the vector leg’s second choice, comes last, and C, the vector leg’s first choice, is third.

Now scale each leg’s scores to a range from zero to one, using the lowest and highest score in that leg. For the lexical leg, A becomes 1.0, B becomes about 0.53, and C becomes 0. For the vector leg, C becomes 1.0, D becomes about 0.57, and A becomes 0. Adding with equal weights, A gets 1.0, B gets 0.53, C gets 1.0, and D gets 0.57. Now A and C tie for first, D is third, and B is fourth. Both legs count, and the result reflects their agreement. The difference between the two orders is the whole reason for normalization.

Ways to normalize

Choosing the weights

Weights express how much you trust each leg. There is no universal answer. A catalog full of part numbers deserves a heavy lexical weight. A support site full of natural language questions may lean semantic. Start with equal weights after normalization, and adjust using a judged set of queries. Change one weight at a time, measure a ranking metric, and beware of tuning to a handful of examples.

How documents found by only one leg are treated

In a union-style merge, a document found by only one leg still appears, with the other leg contributing nothing. This is usually what you want, because it is the source of the recall gain. But it also means that the meaning of “zero” matters: when scaled, a missing score is treated as zero contribution, the same as the worst found score. Some designs prefer to treat missing as slightly worse than the worst found, to penalize documents that only one leg likes. Be aware of the choice your method makes.

The vector leg as a clause in a larger query

Newer versions allow the vector search to appear as a clause inside a boolean query, next to lexical clauses, filters, and boosts. This makes it possible to mix legs in more flexible ways, for example, requiring a lexical match and using vector similarity only as a scoring boost. The flexibility is useful, but adds ways to make mistakes, since the scoring of a boolean query has its own rules.

If scores cannot be compared, compare positions. That simple idea is the basis of the most popular fusion method.

The idea

Reciprocal rank fusion, often shortened to RRF, ignores the scores of each leg completely. It looks only at where each document stands in each leg’s ranking. For every list in which a document appears, the document earns a small amount of credit, larger when it is near the top and smaller when it is farther down. The credit is one divided by a constant plus the rank. The credits from all lists are added, and documents are sorted by the total. The constant, by default sixty, softens the difference between the very top positions.

flowchart LR
    L1["Lexical ranking: A first, B second, C third"] --> R["For each list, a document earns one divided by sixty plus its rank"]
    L2["Vector ranking: C first, A second, D third"] --> R
    R --> F["Fused order: A, C, B, D"]
    

A worked example

Take the same four documents. In the lexical ranking, A is first, B second, and C third. In the vector ranking, C is first, A second, and D third. With the constant at sixty, a document in first place earns one over sixty-one, about 0.01639. Second place earns one over sixty-two, about 0.01613. Third place earns one over sixty-three, about 0.01587.

Document A is first in one list and second in the other, so it earns 0.01639 plus 0.01613, about 0.03252. Document C is third in one list and first in the other, so it earns 0.01587 plus 0.01639, about 0.03226. Document B appears only in the lexical list, in second place, and earns 0.01613. Document D appears only in the vector list, in third place, and earns 0.01587. The fused order is A, C, B, D. Documents that both legs like rise to the top, while documents that only one leg likes follow, ordered by how highly that leg placed them.

The two knobs

Strengths and weaknesses of rank fusion

Retrievers: describing multi-stage searches

Newer versions let you describe a search as a tree of building blocks called retrievers. A standard retriever runs an ordinary query. A vector retriever runs a nearest-neighbor search. A fusion retriever takes several child retrievers and merges their results. A reranking retriever takes another retriever’s results and re-orders them with a model. Because retrievers nest, a hybrid search with reranking is described as one tree, which is easier to read, test, and change than a pile of separate options.

Choosing between the methods

flowchart TD
    A["Need to combine two result lists"] --> B{"Do the scores share a comparable scale?"}
    B -- No --> C{"Do you have judged queries to tune weights?"}
    C -- No --> D["Reciprocal rank fusion: uses positions, little tuning"]
    C -- Yes --> E["Weighted combination after normalizing scores"]
    B -- Yes --> F["Simple weighted sum may work, verify with tests"]
    D --> G["Optionally rerank the top results with a stronger model"]
    E --> G
    F --> G
    

A practical starting recipe

Retrieval is fast but coarse. Reranking is slow but sharp. Using them in sequence gives quality that neither could reach alone at a sensible cost.

flowchart LR
    A["Millions of documents"] --> B["Stage 1: hybrid retrieval of the top 100 to 1000"]
    B --> C["Stage 2: a reranker reads query and text together"]
    C --> D["Top 10 shown to the user"]
    

Why a second stage helps

Both retrieval legs judge a document without ever looking at the query and the document together. The keyword leg counts term matches. The vector leg compares two separately made vectors. Neither reads the query and the passage side by side, the way a human would. A cross-encoder model does exactly that: it takes the query and one candidate document as a pair, reads both at once, and outputs a relevance score. It is much more accurate, and much too slow to run on millions of documents. But it is affordable for a few hundred candidates.

Bi-encoders and cross-encoders

How reranking fits into Elasticsearch

In the newer retriever style, a reranking retriever wraps a first-stage retriever, such as a fusion of the two legs. It sends the query and the text of the top candidates to a reranking model, which is called through an inference endpoint, and re-orders them by the returned scores. The number of candidates sent is a window you choose. Older approaches use a rescore step with a second query over the top results, or a learned ranking model that combines many signals, but the idea is the same: spend more effort on fewer documents.

Choosing the window

A larger window gives the reranker more chances to find good documents, and costs more in time and money. A smaller window is cheap, but the reranker can only reorder what the first stage gave it. Typical windows are in the tens to low hundreds. Measure the gain at several sizes on your queries, and choose the point where more candidates stop paying for themselves.

Cost and latency

Business signals after relevance

Relevance is not the only thing that matters. A shop may want to favor products that are in stock, popular, well-rated, or on promotion. A news site may want fresh articles. These signals can be applied after the merge, as gentle boosts on top of the relevance order, for example by multiplying the score by a factor that grows with popularity or recency. Keep such boosts modest, or they will drown out relevance, and test their effect with the same judged queries.

Understanding the path of a request through the cluster explains its cost and its limits.

flowchart TB
    Req["Search request with lexical and vector parts"] --> Coord["Coordinating node"]
    Coord --> S1["Shard 1: keyword top window and vector top candidates"]
    Coord --> S2["Shard 2: keyword top window and vector top candidates"]
    S1 --> M["Coordinating node merges each list across shards"]
    S2 --> M
    M --> Fu["Fusion computes the final scores"]
    Fu --> Fe["Fetch phase loads the documents of the winners"]
    

The phases

The cost adds up

A hybrid search is roughly the cost of a keyword search plus a vector search, plus the fusion, plus any reranking, plus the query embedding. The legs run in parallel on each shard where possible, so the elapsed time is closer to the slower leg than to the sum, but the total work is the sum. That work multiplies with the number of shards, because each runs both legs, and with the size of the windows and the candidate counts.

Paging: the window is the limit

With rank-based fusion, only the documents inside the rank window can appear in the final list. So the deepest page you can reach is limited by the window. Asking for results beyond it returns nothing, or an error, depending on the version. For interfaces that need deep paging, either raise the window, accepting the cost, or use a different technique for deep results, such as filtering more narrowly. Most search interfaces need only the first few pages, where the window is ample.

Facets and aggregations

Counts by category, brand, or price range are usually computed over the documents that match the query. In hybrid search, the set of matching documents is less clear, since it is the union of candidates from both legs, limited by windows. Aggregations may therefore reflect only the retrieved candidates and not the whole matching population, and counts may differ from what a pure keyword search would show. Test facet behavior carefully in your version, and consider computing facets from the lexical leg alone if consistent counts matter.

Sorting

Hybrid search produces a ranking by relevance. If you ask to sort by another field, such as price or date, the relevance fusion no longer determines the order, and the value of the merge is lost. A better design is to keep relevance ordering, and offer sorting only on the final small set, or to apply gentle boosts for the signals that matter.

Highlighting and explanations

Highlights show the matching words in a snippet. They work naturally for the lexical leg, because the words matched. They do not exist in the same way for a document that was found only by meaning, since no word matched. Some fields designed for semantic search can highlight the most relevant chunk instead. For debugging, explanation options show, for rank fusion, the rank contributed by each leg, which is very useful for understanding why a result appeared.

Timeouts and partial results

A search can be given a time limit. If a leg is slow, partial results may be returned instead of waiting forever. In a hybrid search, a partial result from one leg may distort the fusion, so decide deliberately how the application should behave: fail fast, fall back to the lexical leg, or accept partial results with a marker.

Filters are simple in a keyword search. In a hybrid search, they must be applied to both legs, or the results can be wrong, or worse, unsafe.

Filters restrict candidates, not scores

A filter is a yes-or-no condition: only documents in stock, only documents in English, only documents this user may see. It removes documents from consideration before ranking. It does not change scores. In a keyword search, you place the filter in the boolean query, and it is done. In a hybrid search, the two legs are separate searches, and each needs the filter.

flowchart TD
    F["Filter: permissions, language, availability"] --> L["Applied to the lexical leg"]
    F --> V["Applied inside the vector leg"]
    L --> M["Only allowed documents reach the fusion"]
    V --> M
    

The danger of forgetting one leg

Suppose a permission filter is put on the lexical query, but not inside the vector search. The lexical leg will return only allowed documents. The vector leg will return the nearest neighbors among all documents, including ones the user must not see. The fusion merges both lists, and a forbidden document appears in the results. This is not a hypothetical bug: it is one of the most common ways that hybrid search leaks data. Always test with a user who has restricted access, and confirm that no forbidden document appears from either leg.

Filtering inside the vector search

As explained in the vector search literature, a filter given inside the nearest-neighbor part is applied while walking the graph, so that all the returned neighbors satisfy it. A filter applied only after the nearest neighbors are found can leave fewer results than requested, and in the extreme, none. For hybrid search, use the filter inside the vector part. Newer retriever-style requests allow a single top-level filter to be applied to all child retrievers, which reduces the chance of forgetting one.

Filters that are too restrictive

When a filter leaves only a small number of documents, the vector search may switch to an exact comparison against just those documents, which is cheap and precise. When a filter leaves none, both legs return nothing, and the application should say so, not silently drop the filter. When a filter is very selective for one leg but not the other, for example a rare language, the legs may return very different numbers of candidates, which affects the fusion.

Permissions and chunks

If documents are split into chunks for the vector leg, every chunk must carry the permission information of its parent. A chunk without it either leaks, if unrestricted, or is invisible, if the filter cannot match it. The simplest design copies the permission fields into each chunk at indexing time, and updates all chunks whenever the parent’s permissions change. Treat this update as a security-critical step, and test it.

Facets and counts

Facet counts, such as “Brand: 120 results,” are computed over the documents that match. In hybrid search, the matching set is fuzzier, as Chapter 10 explained. Filters applied by the user, such as clicking a brand, should be applied to both legs, and the counts should be consistent with what is displayed. If your interface relies on exact counts, compute them from a well-defined query, such as the lexical leg, or from the filter alone, and explain what the counts mean.

Hybrid search asks each document to be searchable in two ways. That shapes how you design the index, and how you keep it healthy.

One index, two representations

The usual design keeps text fields and vector fields in the same index and, where possible, in the same document. A product has a title and a description, indexed as text, and a vector, derived from the same words, stored in a vector field. Because the document identifier is shared, fusion can recognize a document found by both legs. Keeping both in one index also makes filters simple, since one set of metadata fields serves both legs.

What text to embed

The vector should capture what users will search for. Often, that means combining several fields into one text for embedding, such as the title, a short description, and key attributes. Do not embed noise, such as boilerplate footers or navigation. Do not rely on the embedding to capture things it cannot, such as exact numbers. Keep the embedded text within the model’s input limit, and record how it was built, so that it can be rebuilt the same way later.

Documents and chunks

Long documents are cut into chunks for the vector leg, as explained before. This makes the modeling of hybrid search interesting, because the lexical leg naturally works on whole documents, or on the same chunks, while the vector leg works on chunks. There are three common designs.

The first design is the easiest to start with. When users complain that the same article appears three times, add grouping by the parent identifier, keeping the best chunk of each. Many systems use the grouping feature of search for this, and show the matching chunk as the snippet.

The memory and disk bill doubles

A hybrid index holds both the inverted indexes and the vectors with their graphs. The text side needs disk and file cache for postings. The vector side needs disk and, above all, file cache for vectors and graphs. Plan for both. In particular, do not assume that a cluster sized for keyword search can carry vectors too. The vector side often dominates the memory need, and compression is the usual way to keep it in check.

Keeping the legs in step

Both representations are derived from the same source text, and both must be updated when it changes. A frequent bug is to update the text and forget the vector, so that the lexical leg finds the document for its new content, while the vector leg still sees the old meaning. Build your update path so that changing the embedded text always triggers a new embedding, and consider storing a hash of the embedded text to detect stale vectors.

Documents without vectors

During a backfill, or when the embedding service fails, some documents may have text but no vector yet. In a hybrid search, such documents are simply missing from the vector leg, and still available to the lexical leg. This is a good property: the system degrades gracefully. But it also means that quality varies across documents. Track the share of documents with vectors, and finish the backfill before judging the vector leg.

Changing the model

Replacing the embedding model means recomputing every vector, as the old ones are meaningless to the new model. Build a new index, load it, evaluate it against the current one on judged queries, and move an alias when the new index wins. Because the lexical leg does not depend on the model, the keyword side is unchanged and continues to work during the rebuild.

Not every query deserves the same recipe. A little understanding of the query, before the legs run, can lift quality more than any weight tweak.

flowchart TD
    Q["Incoming query"] --> C{"What kind of query is it?"}
    C -- "Looks like an identifier or exact phrase" --> L["Weight the keyword leg higher"]
    C -- "Natural language question" --> V["Weight the semantic leg higher"]
    C -- "Mixed or unclear" --> H["Balanced hybrid"]
    L --> F["Fuse and return"]
    V --> F
    H --> F
    

Why one recipe does not fit all

A query such as “XR-450” is best served almost entirely by exact matching. A query such as “what should I wear for a rainy hike” is best served largely by meaning. A query such as “waterproof jacket XR-450 women’s” is a mixture. A single fixed balance is a compromise that serves each kind a little worse than a tailored one. Query routing tries to give each query the mix that suits it.

Signals that help

Turning parts of a query into filters

Many queries contain conditions hidden in words: “under fifty dollars,” “in stock,” “from last year,” “in French.” An understanding step can pull these out and turn them into filters, leaving the rest of the text for the legs. This improves precision, because the conditions are enforced exactly rather than left to fuzzy matching. It needs care: a wrongly extracted filter can silently hide good results, so log the extracted filters and test them.

Cleaning and correcting

• Spelling correction. Fix obvious typos before the legs run, or let the lexical leg tolerate them with fuzzy matching. Vector models often tolerate small typos by themselves.
• Normalization. Remove stray punctuation, unify units, and expand known abbreviations.
• Synonyms for known vocabulary. A small curated list helps the lexical leg with company-specific terms.
• Stop-phrase removal. Strip filler such as “please show me,” which adds noise to keyword matching.

Rewriting and expansion with a language model

A language model can rewrite a vague or conversational query into a clearer one, generate several variants to search in parallel, or produce a short hypothetical answer whose embedding is used to search. These techniques can improve recall for hard queries, and they add cost, latency, and new ways to go wrong, since the rewritten query may drift from what the user meant. Use them selectively, for the query types that need them, and measure the benefit on judged examples before adopting them widely.

Routing without machine learning

Simple rules go a long way. If the query matches the pattern of an identifier, search the identifier fields with an exact query first, and fall back to hybrid search if nothing is found. If the query has more than eight words, raise the semantic weight. Start with rules, log which route each query took, and evaluate. Introduce learned routing only when rules clearly fall short.

Keeping routing safe and explainable

A hybrid search costs more than either leg alone. Knowing where the time and memory go tells you where to save them.

A latency walkthrough

Let us use invented numbers for one query. Embedding the query takes 30 milliseconds. The keyword leg takes 20 milliseconds on each shard, and the vector leg takes 25 milliseconds, running at the same time, so the shard phase takes about 25 milliseconds once the vector exists. The coordinating node spends 5 milliseconds merging and fusing. A reranker takes 80 milliseconds for 50 candidates. Fetching the winners takes 15 milliseconds. The total is about 30 plus 25 plus 5 plus 80 plus 15, or 155 milliseconds. Without the reranker, it is about 75. The point is that the embedding call and the reranker are often the largest parts, larger than the searches inside Elasticsearch.

Where the resources go

Tuning levers

Throughput and concurrency

Because each hybrid query does two searches and possibly two model calls, the cluster handles fewer hybrid queries per second than keyword queries on the same hardware. Plan capacity with realistic tests: measure queries per second at your target latency, with your real mix of query types. Replicas add read capacity, and each replica needs its own memory for vectors. Model services have their own limits and rate caps, which can become the true ceiling.

Caching

Every design carries a price. Here is the honest balance sheet of hybrid search.

When is hybrid worth it?

A hybrid search has more parts that can fail. Its great advantage is that it can keep working when one of them does.

Failures and fallbacks

The keyword leg is the lifeboat

Because the keyword leg depends only on the inverted indexes inside Elasticsearch, it is more stable than the semantic leg, which depends on models and possibly outside services. Design your application so that it can fall back to keyword-only search on any sign of trouble with embedding, and can tell the user or the logs that it has done so. A search that returns slightly less clever results is far better than one that returns an error.

Timeouts, retries, and circuit breakers

Replicas and consistency between legs

Each replica builds its own inverted index and its own graph, so the two legs on different copies of a shard can differ slightly at the edges, especially for approximate vector results. Identical queries may occasionally return slightly different lists. If your application needs stable results for one user within a session, use a stable routing preference so that the same user is served by the same copies.

Upgrades and rebuilds

The keyword side and the vector side may be affected differently by upgrades. Vector features have evolved quickly across versions, and defaults for compression and options have changed. Test upgrades on a copy, compare a fixed set of queries before and after, and read the release notes for changes in vector and retriever features. Keep the ability to roll back, including the old index if a model change is involved.

A hybrid search touches your data in two ways and often calls outside services. Each adds a place where things can go wrong.

Permissions on both legs

As Chapter 11 stressed, every access rule must be enforced on both legs. This is the most important security point of hybrid search. Use one definition of the filter, apply it in both places, and test with restricted users. Where platform features such as document-level or field-level security are available in your subscription, verify that they are applied to the vector leg, and not only to keyword queries.

Vectors are sensitive

Embeddings carry the meaning of the content and can leak information, and parts of the original text may be reconstructed from them. Treat vectors with the same care as the text: restrict access to the vector fields, encrypt data at rest, secure snapshots, and do not return vectors to users who do not need them.

The embedding and reranking paths

Caches and shared results

Caching is a performance tool and a security risk. A cache of search results must be keyed by everything that affects the results, especially the user’s permissions. Otherwise, one user’s results may be served to another. Caches of query embeddings are safer, since a vector depends only on the text, but the cached text itself may be sensitive, so protect and expire it.

Risks when feeding a language model

When a hybrid search supplies text to a large language model, retrieved documents become part of the model’s input. If a retrieved document contains hidden instructions, the model may follow them. This is called prompt injection through retrieved content. Limit what can enter the index, mark retrieved text clearly as data, restrict what the model may do with it, and review outputs where the stakes are high. Also make sure that the model never sees documents the user is not allowed to see, which again depends on the filters being applied to both legs.

Abuse and cost attacks

• Expensive queries. Very long queries, huge windows, and large candidate counts multiply the work. Set limits on all of them.
• Model call flooding. Each search may cost a model call. Rate-limit by user, and cap the query length that is embedded or reranked.
• Content poisoning. Someone who can add documents may write content designed to rank highly for popular queries. Moderate public content and separate it from trusted content.
• Enumeration. Repeated queries can be used to discover the contents of an index. Rate limits and permissions reduce this.

Logging and retention

Search logs are valuable for improving quality and dangerous for privacy. Decide what to log, for how long, and who may read it. Remove or mask sensitive fragments, and keep the model version and route with each entry so that logs remain useful for analysis.

A hybrid search can look clever and be wrong. Only measurement tells the difference. This chapter is about knowing whether it works.

flowchart LR
    A["Collect real queries and judgments"] --> B["Run each configuration"]
    B --> C["Compute ranking metrics"]
    C --> D{"Better than the current setup?"}
    D -- Yes --> E["Adopt it and keep monitoring"]
    D -- No --> F["Adjust weights, windows, or analyzers"]
    F --> B
    

Judged queries: the foundation

To measure quality, you need examples where you know what a good answer is. A judged query set is a collection of real queries, each with documents marked as relevant, or graded from “perfect” to “irrelevant.” Sources include human reviewers, click and purchase data, and support staff who know the right answers. Some teams also use a language model to help judge, which is cheap and fast but can be biased, so check its judgments against humans on a sample. A few hundred good queries are far more valuable than thousands of careless ones. Include every kind of query your users send: identifiers, natural questions, vague descriptions, typos, and rare terms.

Ranking metrics

Elasticsearch includes a rank evaluation feature that runs a set of judged queries against a search definition and reports such metrics. It lets you compare two configurations, such as keyword only, vector only, and hybrid with different fusion methods, on the same queries. Use it in a script that runs on every change.

Measure each leg, then the combination

Offline and online evaluation

Offline evaluation, on judged queries, is cheap and repeatable, and is the tool for development. Online evaluation, on real users, tells you what people actually do. It includes experiments that split traffic between configurations and compare behavior such as clicks, purchases, or time to a useful result, and techniques that mix the results of two configurations in one list and see which results users prefer. Use offline testing to narrow the choices, and online testing to confirm the winner.

What to monitor in production

Tools for looking inside a query

A troubleshooting playbook for a bad result

Good habits make hybrid search accurate and affordable. Bad habits are behind most disappointing results and most security surprises.

Patterns that work

Anti-patterns to avoid

A short list you could hand to a new teammate on their first day.

Best practices

Common mistakes

• Assuming hybrid is always better. On some data, a tuned keyword search is already excellent, and vectors add cost and little else. Measure.
• Comparing raw scores across legs. They live on different scales and mean different things.
• Forgetting the rank window. It limits both recall and paging.
• Judging by demos. A few impressive examples hide the failures on identifiers and rare terms.
• Mixing embedding models. Query and document vectors must come from the same model and version.
• Ignoring analyzers. A poorly analyzed keyword leg makes the whole hybrid weaker.
• Neglecting cold caches after restarts. Vector latency is high until the cache warms.
• Not testing the fallback. The first outage should not be the first time you see it.
• Assuming facets and paging behave as in keyword search. They depend on windows and candidate sets.

Myths versus facts

Where does hybrid search quietly change what users can do?

Many well-known organizations have said publicly that Elasticsearch is part of their systems, including Wikipedia’s search, Netflix, Uber, and Stack Overflow. They rarely publish how they combine keyword and semantic search, so the scenarios below are typical patterns for such workloads, not descriptions of anyone’s private configuration.

Short answers to the questions that come up most often.

If you skim only one part of this guide, make it this one.

Hybrid search gives Elasticsearch two ways of finding documents and a rule for merging what each finds. The keyword leg is precise with exact terms. The semantic leg understands meaning. Fusion turns two rankings into one, a reranker can sharpen the top, and query understanding can choose the recipe for each query. Its real value shows up only when it is measured, and its safety depends on filters, fallbacks, and care with the data that flows through it.