Hybrid Search: Combine Keywords and Vectors

Vector search is good at finding passages that mean the same thing as a question, even when they use different words. It is less reliable with exact terms: product codes, error numbers, names and acronyms. Keyword search has the opposite profile. Hybrid search runs both and combines the results, which often gives retrieval-augmented generation systems and site search a better chance of finding the right passage. This guide explains how hybrid search works, how results are combined, how to build it with common tools, including PostgreSQL, and how to tell whether it actually helps your users.

Why one search method is not enough

Imagine an internal assistant asked about error E-4031 in a billing export. A vector search may return passages about billing errors in general, because they are semantically close, while missing the one page that mentions E-4031 exactly. A keyword search finds that page immediately. Now imagine the question is phrased as "why won't my invoices sync?" while the documentation says "export failures". Keyword search struggles; vector search copes.

Real questions mix both kinds, so combining the methods covers more cases than either alone.

How hybrid search works

Weaviate's documentation gives a concise definition: hybrid search combines the results of a vector search and a keyword search, using BM25F, by fusing the two result sets, with a configurable fusion method and relative weights (Weaviate: Hybrid search). Its examples use an alpha parameter to control the balance between the vector and keyword sides.

The general flow is the same in most tools:

1. Run a keyword search, typically using a ranking function such as BM25.
2. Run a vector search over embeddings of the same content.
3. Combine the two ranked lists into one.
4. Optionally rerank the top results with a more expensive model.

Combining results with reciprocal rank fusion

The two searches produce scores on different scales, so you cannot simply add them. A common answer is reciprocal rank fusion, which uses each document's position in each list rather than its raw score. Elastic's documentation describes reciprocal rank fusion as a method for combining multiple result sets with different relevance indicators into a single result set, and says it requires no tuning and that the relevance indicators do not have to be related to each other (Elastic: Reciprocal rank fusion). It also exposes a rank constant that controls how much individual result sets influence the final ranking.

Weighted score combination is the main alternative. It gives more control, but scores must be normalised first and weights tuned for your content.

Building hybrid search in PostgreSQL

If your data already lives in PostgreSQL, you may not need a separate search engine. PostgreSQL has built-in full text search (PostgreSQL: Full text search), and the pgvector extension adds vector similarity search. The pgvector README notes that by default it performs exact nearest neighbour search, that you can add an approximate index such as HNSW or IVFFlat to trade some recall for speed, and it shows full text search used together with pgvector for hybrid search (pgvector on GitHub).

The README also compares the two index types: HNSW has better query performance in terms of the speed-recall trade-off but slower build times and more memory use than IVFFlat. Test both on your data if speed matters.

A typical PostgreSQL design keeps the text, a full text search column and an embedding column in the same table, runs both queries and merges the results in SQL or in application code.

Filters and permissions come first

Whatever engine you use, apply filters before or during the search, not after. Filters might restrict results to documents a user may see, to a product line or to the current version of a policy. Filtering after fusion can leave you with too few results, or worse, can briefly expose results the user should not see. Our guide to private RAG explains why permission checks belong in retrieval.

Chunking still matters

Hybrid search works on whatever chunks you index. Poorly split chunks, such as tables cut in half, hurt both keyword and vector matching. Our guide to RAG chunking covers how to split different document types and test chunk sizes.

Worked example: comparing retrieval on test questions

The table below is a hypothetical evaluation for an internal support assistant. Each row is a type of test question, and the cells show whether the correct passage appeared in the top results. It illustrates the kind of comparison to run, not real results.

Question typeExampleKeyword onlyVector onlyHybridExact error codeWhat does E-4031 mean?FoundMissedFoundParaphrased problemWhy won't invoices sync?MissedFoundFoundProduct name plus conceptRefund rules for the Pro planFoundFoundFoundAcronymHow do I reset SSO?FoundPartlyFoundVague questionSomething is wrong with exportsMissedPartlyPartly

The last row is a reminder that hybrid search is not magic. Vague questions may need a clarifying question from the assistant rather than better retrieval.

Measure before and after

Build a test set of real questions with known correct passages, run them through keyword, vector and hybrid configurations and measure how often the right passage appears near the top. Include exact-term questions, paraphrased questions and questions in the language your users actually use. Repeat the test when you change embedding models, chunking or fusion settings.

Also watch production signals: questions where users rephrase immediately, low-rated answers and searches that return nothing useful. These show where retrieval is still failing.

Keep both indexes in step

Hybrid search depends on two indexes describing the same content. If a document is updated in the keyword index but its embedding is not refreshed, or the other way round, the two halves disagree and results become confusing. Update both in the same job, store a content version with each entry and run a periodic check that every document appears in both indexes with the same version.

Consider reranking

After fusion, a reranking model can reorder the top results by reading the question and each candidate together. Weaviate's documentation lists reranking among its search features, and many platforms offer similar options. Reranking adds cost and latency, so apply it to a short list of candidates and test whether it improves your measured results.

Frequently Asked Questions

What is hybrid search?

It is a retrieval approach that runs keyword search and vector search on the same content and combines the results, so that both exact terms and meaning are taken into account.

Why combine keyword and vector search?

Keyword search handles exact terms like codes and names well, while vector search handles paraphrased questions. Combining them covers more real questions than either alone.

What is reciprocal rank fusion?

It is a way to merge ranked lists using each result's position rather than its score. Elastic describes it as requiring no tuning and working with unrelated relevance measures.

Can I do hybrid search in PostgreSQL?

Yes. PostgreSQL's full text search can be combined with the pgvector extension, as the pgvector documentation shows, and results merged in SQL or application code.

Improve how your systems find answers

We design retrieval for RAG and search systems, including hybrid search, filtering and evaluation against real questions. See our AI agent orchestration and RAG service, or talk to us about hybrid search.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.