reciprocal rank fusion for hybrid search

keyword and semantic search return incomparable scores — bm25 and cosine distance live on different scales, and any weighted sum of them is a magic number that breaks when either distribution shifts. reciprocal rank fusion sidesteps this by throwing the scores away and fusing positions:

rrf_score(doc) = Σ over lists 1 / (k + rank_in_list) with k = 60

pub-search (a search service over atproto publications) runs both paths in its hybrid mode, computes 1/(60 + rank) per list (1-based rank), sums per-uri, sorts descending, takes 20. a document that's rank 3 in keyword and rank 5 in semantic beats one that's rank 1 in only one list — agreement is the signal.

the two paths must fail independently

keyword serves from a local sqlite replica (~10ms); semantic is an embedding call plus an ann query (~550ms). either path failing degrades to an empty list for that leg — the hybrid result gets thinner, never errors. this matters more than it looks: the failure modes are disjoint (fts replica adoption windows vs embedding-api latency), so hybrid availability is better than either leg alone, but only if a leg's failure is contained.

related, from the same system: the keyword leg's fallback path (replica not ready → query upstream turso, the hosted database the replica syncs from) once self-amplified into a ~38-concurrent-request storm of 26s queries. the fix was to wait briefly (400ms) for replica readiness, then hard-cap concurrent fallbacks at 4 and shed the rest with a fast empty result. degraded-but-fast beats correct-but-stampeding.

bookkeeping the fusion needs

• track which list(s) each doc came from (a bitmask works: 01 keyword, 10 semantic, 11 both) — it's the honest label for the ui and for debugging why a result surfaced.
• semantic-only results have no fts snippet — a second pass against the local sqlite store fills in previews and covers for them.

sources

• pub-search/backend/src/server/search.zig — hybridSearch, RRF_K, the fallback cap