BM25
Full-text · keyword precision
Hybrid Search —
semantic + keyword
in one search bar.
BM25 finds the exact word. Semantic search finds the meaning. Reciprocal Rank Fusion merges the two ranked lists. Fuzzy fallback rescues your typos. Four engines, one search bar, one ranked answer.
4
engines
in parallel
in parallel
RRF
SIGIR '09
Cormack et al.
Cormack et al.
1
postgres
no separate db
no separate db
§ 3 — The 4 Engines
Four engines. Each catches what the others miss.
The first three run on every search. The fourth, fuzzy fallback, only wakes up when keyword search comes back empty — typos, misremembered words, cross-language guesses.
Engine 01 BM25
BM25 — full-text
The exact-word engine.
The keyword search engine that runs the rest of the web. BM25 looks at how often each query word appears in each document, weighted against how rare the word is across your whole corpus. Anchors search to the exact spelling — names, codes, version numbers, jargon you actually wrote.
- →PostgreSQL native — built on the same full-text engine that runs on every modern database.
- →Phrase queries get a precision bonus when the words appear together.
Engine 02 pgvector
Semantic — pgvector
The meaning engine.
Each note becomes a point in a high-dimensional embedding space. Queries become points too, and the engine returns the nearest neighbors. Throttle policy, backpressure, rate limiter all sit close to each other, even when they share zero words. Catches what you meant when you forgot what you wrote.
- →Chunk-level matching first — long notes return their most relevant section, not the whole page.
- →HNSW index for sub-millisecond nearest-neighbor lookup at scale.
Engine 03 RRF
Reciprocal Rank Fusion
The unifier.
Cormack, Clarke and Büttcher introduced this at SIGIR 2009. The math is naive on purpose: each document's final score is the sum, over rankers, of one over a constant plus its rank. The constant softens the curve — lower-ranked documents still contribute, just less. No score normalization needed; ranks are unitless.
- →Calibrated for personal-scale workspaces. You won't tune it.
- →Used today by Elastic, Weaviate, Azure AI Search, Qdrant — and Knovya.
Engine 04 Fuzzy
Fuzzy fallback — trigram
The safety net.
When BM25 returns nothing, fuzzy fallback wakes up. It splits each word into three-letter chunks (trigrams) and matches by overlap — postgress and postgres share six trigrams out of seven, close enough. Catches typos, missing letters, and fuzzy half-memories. Title matches get a higher tolerance than body matches.
- →PostgreSQL pg_trgm extension — battle-tested trigram similarity.
- →Stays on stand-by; only runs when keyword search returns zero.
§ 4 — The problem
Most search bars pick a side.
And lose the other half.
Scene 01
Pure keyword search misses synonyms. You searched throttle; the note titled API rate limiting never surfaced. The right answer was there. The query just spelled it differently.
Scene 02
Pure vector search misses exact identifiers. Your error code SQL-2204, your customer ID, your version tag — they get blurred into embedding space and lose to a dozen "similar but wrong" notes.
Scene 03
Most note apps lean on one or the other and call it search. The conceptual matches and the exact identifiers live in your notes. Only one of them comes back per query.
Every search is two questions at once — did I write that exact word and what did I mean. Knovya runs both engines in parallel, then lets RRF merge the answer. Whichever side the query leans toward, the right note surfaces.
§ 5 — Lineage
Where this search comes from.
Hybrid retrieval is built on three decades of search research and one paper that's still doing the heavy lifting in 2026.
-
1994
Robertson — BM25
Stephen Robertson and colleagues publish the ranking function that becomes the keyword-search default for the next thirty years. Term frequency, inverse document frequency, length normalization — still under the hood of every full-text engine.
-
2009
Cormack et al. — RRF
Cormack, Clarke and Büttcher publish a two-page SIGIR paper in Boston: a naive rank-fusion formula that outperforms every learned method they compared it to. The constant has stayed at sixty.
-
2018 — 2022
Transformers make vectors practical
BERT, sentence-transformers, OpenAI embeddings — semantic search becomes good enough for production. Vector databases — Pinecone, Weaviate, Qdrant — go from research toy to enterprise category.
-
2023 — 2025
Hybrid becomes default
Elastic ships ELSER and BM25+vector RRF, Azure AI Search makes RRF its hybrid recipe, Weaviate and Qdrant add native fusion APIs. Pure vector and pure keyword both fall behind in published benchmarks.
-
2026
Knovya — 4 engines, personal scale
BM25, pgvector semantic, RRF, fuzzy fallback. Native to Postgres — no separate vector DB. The only personal note app shipping a four-engine hybrid out of the box.
§ 6 — First mover
Other note apps pick a side. Enterprise tools pick a price. Knovya picks every engine, on a notebook scale.
Notion · Mem.ai · Reflect.app
Keyword-mostly search with a thin layer of AI suggestions. No native semantic search, no hybrid fusion, no typo recovery beyond what the browser does.
Obsidian · Logseq · Roam
Keyword search core, semantic search through community plugins (Smart Connections, Omnisearch). Hybrid retrieval is a build-it-yourself project.
Elastic · Weaviate · Pinecone · Qdrant · Azure AI Search
Production-grade hybrid retrieval — for engineering teams. Developer SDKs, separate vector databases, infrastructure to operate. Not the search bar inside a note app.
Knovya — Hybrid Search
Four engines, native to one Postgres database, in one search bar. The retrieval depth of an enterprise search platform — at the scale of one person's notes, with no infrastructure to run.
§ 7 — Surfaces
Where the four engines show up.
Hybrid search isn't a settings page you visit once. It's the default everywhere a note can be looked up — by you, by your AI agents, by the editor itself.
Surface 01 · Command bar
⌘ K — anywhere in the app
A floating command bar opens over whatever you're working on. Type, get hybrid results, hit return to jump. Source badges show which engine found each hit.
› throttle policy
API rate limiting — design decision
B+V
Throttle policy for /v2 endpoints
V
Backpressure design pattern
V
Rate limiting policy v3
B
Surface 02 · Search page
Full results, with source coloring
A dedicated workspace for deeper search. Filter by folder, tag, type, status. Each result row carries an accent — keyword (amber), semantic (purple), or both (blue) — so you can see which engine pulled it.
All Plans Decisions This month
API rate limiting — design decision Engineering · plan · 2 weeks ago
Throttle policy for /v2 endpoints Engineering · framework · 1 month ago
Rate limiting policy v3 Engineering · decision · 3 months ago
Backpressure design pattern Engineering · journal · 6 months ago
Surface 03 · Agentic
For your AI agents
Connected agents (Claude, ChatGPT, Cursor, Gemini, Copilot) call knovya_search via MCP. Same hybrid pipeline, structured response — they never have to re-invent retrieval.
// knovya_search(query="rate limit", mode="hybrid")
{
"results": [
{
"title": "API rate limiting",
"sources": ["bm25", "vector"],
"matched_heading": "Throttle policy"
}
],
"mode": "hybrid",
"fused_with": "rrf"
}
Surface 04 · Recovery
When you typo, fuzzy speaks up
If keyword search comes back empty, fuzzy fallback fires and lets you know — quietly. The query still resolves; you don't lose the rhythm of writing.
Typo recovered
No exact match for postgress migrtaion. Fuzzy fallback returned 4 results that look close — top hit: Postgres 14 migration runbook.
§ 8 — Bonded with
Hybrid Search is the way other elements reach your notes.
Search is the substrate — every other Group II element calls it under the hood. NoteRank reranks the fusion. Knowledge Graph boosts neighbors. Experience Envelope pulls evidence. Agentic Memory queries through it.
11 Nr
NoteRank
Reranks the RRF list with ten more signals — connection weight, freshness, your engagement.
12 Ee
Experience Envelope
Surfaces past decisions and evidence — the retrieval that fills each envelope is hybrid search.
13 Kg
Knowledge Graph
Boosts the neighbors of strong matches — graph context lifts conceptually adjacent notes.
16 Ag
Agentic Memory
Every MCP recall call from your AI agents goes through the same four-engine pipeline.
Frequently asked.
What is hybrid search?
Hybrid search is a retrieval method that runs both keyword search (BM25 or similar) and semantic vector search at the same time, then merges the two ranked lists into one. Pure keyword search misses synonyms and conceptual matches; pure vector search misses exact names, codes, and rare terms. Hybrid keeps both. Knovya's implementation goes a step further by adding a third engine — Reciprocal Rank Fusion as the merge algorithm — and a fourth — a fuzzy fallback for typos.
Hybrid search vs vector search — which is better?
Vector search alone is good when your queries are conceptual and your corpus has consistent semantic vocabulary. It tends to lose exact identifiers — SKUs, error codes, proper names, version numbers — because they get blurred in embedding space. Hybrid keeps vector's conceptual reach but adds keyword precision back. For mixed personal notes — names, jargon, half-remembered phrases — hybrid wins by roughly 20-30% recall in most published benchmarks.
What is Reciprocal Rank Fusion (RRF)?
RRF is a way to merge multiple ranked result lists into one without needing the lists to share a score scale. Cormack, Clarke and Büttcher introduced it at SIGIR 2009. The formula is plain: each document's final score is the sum, across rankers, of one over a constant plus its rank in that ranker. The constant softens the contribution of lower-ranked documents without zeroing them out. Knovya uses RRF to merge the BM25 list with the vector list, with a calibrated constant tuned for personal-scale workspaces.
Does Knovya support filtering and metadata search?
Yes — by folder, tag, type (plan, decision, journal, framework), status, NoteRank score, and arbitrary metadata. You can also run filter-only searches with no query at all (useful for finding all active plans in a folder, for example). Filters compose with hybrid retrieval, narrowing the candidate set before fusion.
Does hybrid search work in different languages?
Yes. Knovya detects language per note (English, Cyrillic, CJK, others) and routes each query through the appropriate full-text configuration. Vector embeddings cross language boundaries naturally, so a Turkish note can surface for an English query if the meaning matches. Title boost and snippet highlighting work in all supported languages.
Is hybrid search slower than keyword search?
Marginally. Running two engines in parallel adds a small amount of latency over keyword-only — public benchmarks from production hybrid systems put it around six milliseconds. The recall improvement is usually worth it. Knovya caches recent queries for sixty seconds and uses an HNSW index for vector lookups, so repeat searches return effectively instantly.
What happens if I make a typo?
When BM25 returns zero results, the fuzzy fallback engine takes over — it uses trigram similarity (the same technique that makes 'fasion' match 'fashion' in good search bars) to recover the intent. Vector search may also catch typos in some cases because embeddings are tolerant of spelling variation. The graph still finds what you meant — typos are not a wall.
Hs · 14 · ★
Find what you forgot the words for.
Twenty notes in, search is overkill. Two hundred in, keyword starts to fail you. Two thousand in, hybrid retrieval is the difference between writing more and digging through the past.