Hybrid Search for RAG in n8n: BM25 + Vector, and When to Use Each

Your RAG chatbot works fine until a user pastes an error code like E0427, a product SKU, or a function name, and the answer comes back about something only loosely related. The retrieval step pulled chunks that mean something similar instead of the chunk that contains the exact string. Hybrid search fixes this by running keyword search (BM25) and vector search side by side, then merging their two ranked lists into one.

Pure vector search is strong on meaning and weak on exact tokens. The fix is not a better embedding model or smaller chunks. It is adding the keyword leg back and fusing the results.

Why does pure vector search miss the obvious match?#

Vector search encodes meaning, not literal strings, so it blurs exact tokens like IDs, SKUs, error codes, and function names into their semantic neighborhood. When the token itself is the point, the embedding for E0427 sits near other error codes, and retrieval returns something similar instead of the exact line the user typed.

Embeddings are built to capture concepts. That is exactly why they struggle with identifiers: a version string, a stack trace, or a clause number has little semantic content, so the model has nothing meaningful to encode and the match drifts.

Picture a knowledge base that documents error codes E0427, E0428, and E0429, each with a different cause and fix. To an embedding model these three strings look almost identical and sit in nearly the same spot in vector space, so a query for E0427 can easily surface the chunk for E0428 first. The user gets a confident answer about the wrong error. BM25 has no such problem: it indexes E0427 as a literal token and ranks the one chunk that contains it at the top.

BM25 is the opposite tool. It is a probabilistic keyword ranking function built from term frequency, inverse document frequency, and document length normalization. It is lexical, fast, explainable, and a long-standing search baseline. The name means "Best Matching 25", the 25th iteration of the probabilistic model developed by Robertson, Sparck Jones, and colleagues in the Okapi system. Where a vector matches meaning, BM25 matches the exact token.

If two or more of these hit, add the keyword leg before you touch chunking or models.

When does BM25 win, and when does vector win?#

BM25 wins on exact tokens: IDs, SKUs, order numbers, source code and function names, error strings, proper nouns, acronyms, and legal clause numbers. Vector wins on meaning: paraphrases, synonyms, and conceptual questions where the words differ but the intent matches. Most real corpora carry both kinds of query, which is why hybrid tends to beat either leg alone.

Think about the two questions "how do I cancel" and "terminate my subscription". They share almost no keywords, so BM25 scores them as unrelated, while a vector matches them easily. Now think about a user searching for the exact error TLS_HANDSHAKE_FAILED. The vector smears it across networking concepts; BM25 lands on the one document that contains the string.

Lexical search nails exact tokens; vector search nails meaning. Hybrid keeps both.

One pgvector write-up reports that pure vector search "caps out around 62% precision" on its data, and that adding keyword search with RRF lifts it to "84%+". Treat that as one author's directional claim, not a benchmark: the source publishes no corpus, query set, or methodology behind those numbers, and retrieval precision does not transfer between datasets. The signal to take is the direction (hybrid helps on mixed queries), not the specific percentages, which you should never restate as your own result.

What is Reciprocal Rank Fusion, and why not just add the scores?#

BM25 scores are unbounded positives shaped by term frequency; cosine similarities are bounded between -1 and 1. Adding or averaging them is meaningless because the two scales do not compare. Reciprocal Rank Fusion sidesteps the problem by using only each document's rank position, not its raw score, to merge the two lists into one.

One query, two retrievers, one fused list. RRF needs only ranks, not comparable scores.

The formula is small. For a document d, the fused score sums one term per retriever:

RRF_score(d) = sum over retrievers of  1 / (k + rank_r(d))

rank_r(d) is the document's position in retriever r's list (1 for the top hit), and k is a smoothing constant. The original paper (Cormack, Clarke, and Büttcher, SIGIR 2009) found k = 60 gives the best average result, and 60 is the common default. A document near the top of both lists collects two large terms and rises; one that appears in only one list still contributes. No score normalization is needed.

A worked example makes the behavior concrete. Say a chunk sits at rank 2 in the BM25 list and rank 5 in the vector list. Its fused score is 1/(60+2) + 1/(60+5) = 0.0161 + 0.0154 = 0.0315. A different chunk that is rank 1 in the vector list but absent from the BM25 list scores 1/(60+1) = 0.0164. The first chunk wins, because two solid placements beat one strong placement. That is exactly the behavior you want from hybrid: a result both retrievers half-agree on outranks a result only one of them loved. Note how small k makes the early ranks matter more, and a large k flattens the gap between rank 1 and rank 20.

Two practical notes. Pull more candidates than you keep: a common pattern is top-20 from each retriever fused down to top-10, since the extra candidates give RRF a stronger signal. And know the alternative. Weaviate also offers relativeScoreFusion, which normalizes each list to 0 to 1 and adds them, plus an alpha knob where alpha=1 is pure vector, alpha=0 is pure keyword, and 0.5 is the default.

RRF is the cheap, robust default. It fuses ranks; it does not rerank by relevance.

Route each query by what it contains: exact tokens, meaning, or both.

Which retrieval should you use per query type?#

Match the retriever to the query. Use keyword-only (BM25 or Postgres tsvector) for pure exact-token lookups, vector-only for purely conceptual questions, and hybrid when a single query needs both an exact match and meaning. The flowchart above routes each case, and most production RAG ends up hybrid because real traffic is mixed.

• Keyword only when queries are almost always identifiers: order-status lookups, code search, a parts catalog.
• Vector only when queries are almost always natural language with no fixed vocabulary: a "how do I" help bot over prose.
• Hybrid for the common middle, where one question carries both a product name and a paraphrased intent.

How do you wire hybrid search in n8n (pgvector, Qdrant, Weaviate)?#

Hybrid search in n8n is a build, not a toggle. The built-in PGVector and Qdrant Vector Store nodes do vector similarity plus a metadata filter, not BM25 and not fusion. You add the keyword leg and the RRF merge yourself, through Qdrant's Query API, a Postgres SQL function, or a Weaviate hybrid query over HTTP.

Qdrant path. Qdrant 1.10 added a Query API that fuses search methods, with built-in RRF that Qdrant calls "the de facto standard". You store a dense vector and a sparse (BM25-style) vector, retrieve each in a separate prefetch branch, and combine them with FusionQuery(fusion=RRF). From n8n, call it through the HTTP Request node or the official Qdrant Query Points node. The official n8n template "Evaluate hybrid search for legal question-answering" wires exactly this: BM25 plus mxbai-embed-large dense retrieval, fused with RRF.

pgvector path. Keep one chunks table with both a tsvector full-text column and a vector(1536) column, each indexed. Write a single SQL function that runs the vector kNN and the full-text ranking, then fuses them with RRF, and call it from the Postgres node. Native tsvector gives "BM25-flavored" ranking out of the box; for true BM25 inside Postgres, the ParadeDB (pg_search) and pg_textsearch extensions add it.

Weaviate path. Weaviate is closest to built-in hybrid: one query carries the alpha balance and a fusion type, called from n8n over the HTTP Request node.

Hybrid is not free, and it is worth saying so. You now build and store a second representation of every chunk (a sparse vector or a tsvector column), and every query runs two retrievals before the fusion step. That is a modest increase in index size and a second lookup per request, not a new model bill, since BM25 and tsvector ranking are cheap CPU operations with no token cost. The payoff is the exact-token recall a single vector index cannot give you, so spend it where the failing queries prove you need it, not on every collection by default.

If you are still choosing a store, the pgvector vs Chroma vs Qdrant comparison covers the trade-offs, and why your RAG chatbot gives wrong answers walks the upstream retrieval failures that hybrid alone will not fix.

What should you set up this weekend?#

Start from the failures, not the architecture. Pull the last week of queries your RAG got wrong and sort out the ones that contain an exact token: an ID, a code, a name, a clause number. That set is your evidence that the keyword leg is missing, and it becomes your test bench.

Then add the second retriever. On Qdrant, add a sparse vector and a Query API call with two prefetch branches fused by RRF; on Postgres, add a tsvector column and one fusion function. Retrieve 20 per leg, fuse to 10, and rerun your failing queries. Tune k (and alpha on Weaviate) against your own corpus, never against someone else's published percentage.