Keyword Search vs Semantic Search: BM25, Vectors and Why Hybrid Usually Wins

If you're building search over documents, notes, support tickets or transcripts, you'll hit this choice early: match the words, or match the meaning? The terms get blurred in marketing ("AI search", "smart search"), so this guide lays out what each actually does, where each breaks, and how to combine them.

Quick answer

Keyword search (full-text search, usually ranked with BM25) finds documents containing the words you typed. It is fast, cheap, explainable and excellent for exact terms. Semantic search (vector or embedding search) finds documents whose meaning is close to your query, even with no shared words. It is better for natural-language questions and synonyms. For most real applications, especially retrieval for AI assistants, hybrid search that runs both and merges the results is the safest default.

How keyword search works

Keyword search builds an inverted index: for every word, a list of documents containing it. At query time the engine looks up each query word and scores matching documents.

The most widely used scoring function is BM25 (Best Matching 25), developed in the 1990s by Stephen Robertson, Karen Sparck Jones and colleagues. BM25 rewards three things:

• Term frequency: a document mentioning "diarization" five times is likely more relevant than one mentioning it once, but with diminishing returns.
• Inverse document frequency: rare words count more than common ones. Matching "diarization" matters more than matching "the" or "video".
• Length normalization: a long document isn't rewarded just for containing more words.

Most engines also apply stemming (so "transcribing" matches "transcribe"), stop-word handling and sometimes synonym lists.

Where keyword search fails

• Vocabulary mismatch. The user types "how do I get paid by sponsors" and the relevant passage says "brand deals and affiliate income". No overlapping words, no match.
• Natural-language questions. Long questions full of common words give weak signals.
• Spoken language. Transcripts contain filler, informal phrasing and transcription errors, so the exact word the user expects may not be there.

How semantic search works

Semantic search uses an embedding model to turn each chunk of text into a vector: a list of numbers that places the text in a space where similar meanings sit close together. The query is embedded the same way, and the system returns chunks whose vectors are nearest, usually by cosine similarity.

To make this fast over many vectors, indexes use approximate nearest-neighbor methods such as HNSW graphs or IVF clustering, trading a little recall for large speed gains.

Where semantic search fails

• Exact strings. Product SKUs, error codes, people's names, version numbers and acronyms are often represented fuzzily. A query for "error 0x80070005" may return passages about other errors.
• Negation and specifics. "Videos that are not about cooking" may return cooking videos, because the meaning is close.
• Topical but wrong. Results are often about the right subject without answering the question, which can look convincing.
• Domain drift. A general-purpose embedding model may not separate fine distinctions in legal, medical or internal jargon.

Why hybrid search usually wins

The failure modes are complementary. Keyword search nails the exact string and misses paraphrase; semantic search catches paraphrase and fumbles the exact string. Run both and you cover more of the ways people actually search.

The question is how to merge two ranked lists whose scores aren't comparable (a BM25 score and a cosine similarity live on different scales).

Reciprocal rank fusion

Reciprocal rank fusion (RRF), described by Cormack, Clarke and Buettcher in 2009, ignores the raw scores and uses only rank positions:

Here rank_L(d) is the document's position in list L (starting at 1), and k is a constant, commonly 60, that softens the advantage of the very top positions. A document ranked well in both lists rises to the top; one that appears in only one list still gets credit.

def reciprocal_rank_fusion(result_lists, k=60):
    scores = {}
    for results in result_lists:
        for rank, doc_id in enumerate(results, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

keyword_hits = ["chunk_12", "chunk_40", "chunk_7"]
vector_hits = ["chunk_40", "chunk_3", "chunk_12"]
print(reciprocal_rank_fusion([keyword_hits, vector_hits]))
# chunk_40 and chunk_12 appear in both lists, so they rank first

You can weight one list more heavily by multiplying its contribution, but plain RRF is a strong, tuning-free starting point.

Reranking: the precision layer

First-stage search, keyword or vector, is built for speed over many documents. A reranker (often a cross-encoder model) reads the query and each candidate passage together and scores relevance more carefully. The usual pipeline:

1. Retrieve the top 50 to 100 candidates with hybrid search.
2. Rerank them with a cross-encoder or an LLM-based scorer.
3. Keep the top handful for display or for the model's prompt.

Reranking adds latency and cost per query, so it's applied only to the short list. For AI assistants it often makes a larger difference than switching embedding models.

Doing it in Postgres

If your data already lives in Postgres, you may not need a separate search service at first:

• Full-text search: Postgres has built-in tsvector columns, tsquery parsing and GIN indexes for keyword search, with ranking functions such as ts_rank. Note that the built-in ranking isn't BM25; extensions exist if you need BM25 specifically.
• Vector search: the pgvector extension adds a vector column type, distance operators and approximate indexes (HNSW and IVFFlat).
• Hybrid: run both queries, then merge with RRF in SQL or in application code.

This keeps your data, permissions and backups in one place. Dedicated search engines and vector databases become worth it at larger scale, or when you need features like faceting, typo tolerance or very high query volume.

Searching transcripts specifically

Spoken-word content stresses both methods in particular ways:

• Names and jargon get mangled. Speech recognition may write a product or person's name several different ways. Keyword search misses the variants; semantic search may catch some. Fixing names in the transcript before indexing helps both.
• Filler dilutes meaning. "So, um, basically what we found was..." adds noise. Light cleanup before embedding improves vector quality. See verbatim vs clean verbatim transcription for where to draw the line.
• Chunk boundaries matter. Splitting mid-thought hurts both methods. Chunk by speaker turn or topic, and keep timestamps as metadata. The transcript chunking guide covers this in depth.
• Users want the moment, not the file. Return the timestamp so a result links straight to "minute 23:10", which is far more useful than "this 90-minute recording mentions it."
• Researchers need exact quotes. For qualitative work, keyword search is essential for verifying that a quote exists verbatim; see how to analyze interview transcripts.

Common myths

• "Vector search replaced keyword search." Most major search systems now combine them; neither replaced the other.
• "A better embedding model fixes everything." Chunking, hybrid merging and reranking often matter more.
• "Keyword search is outdated." BM25 remains a strong baseline that many fancier systems struggle to beat on exact-match tasks.
• "Semantic search understands the question." It measures similarity. It doesn't check whether a passage answers anything.

Building searchable video and audio libraries

To search spoken content, you first need it as text with timestamps. YouTubeTranscript.dev pulls existing captions or AI-transcribes a YouTube video and returns timestamped JSON, ready to chunk and index with either method above. If you're deciding how much to send to the model after retrieval, read RAG vs long context next.