Comparisons · measured July 2026
Embeddings vs keyword search: which finds your code?
Search a codebase for chargeCard and a keyword tool hands back every exact hit before you blink. Ask it “where do we bill the customer?” and it finds nothing: those words never appear. Flip to embeddings and it's the mirror image: the plain-English question lands, but the exact symbol you typed gets buried under six near-misses. Same code, two engines, opposite blind spots. Here is the line between them, and why the fastest agents run both.
TL;DR · the short version
Two questions, two tools. Keyword (literal) search matches the exact characters you type. Embeddings (semantic) search matches meaning. They answer different questions, not the same one better or worse.
Embeddings own discovery. They find the right function even when you don’t know its name: the case Pinecone-style RAG was built for. That is a genuine superpower, and it is where meaning-match wins outright.
Keyword search owns precision. Every exact call site, deterministically (including the constants, strings and comments embeddings skip), and it never drifts stale after an edit.
On code, most searches are exact. The symbol you typed, the string in a log, the name you renamed a minute ago: that is a lookup, not a meaning question.
Fastest setup runs both. Embeddings for “what is this about?”, a live exact index for “where is this exact thing?” On the benchmark machine below, one content query fell from 93.8 s to 16 ms, 58,625× across the set.
The same query, two engines
Meaning on one side. Exact text on the other.
Keyword search is a lookup by exact characters: it returns the literal strings you typed, all of them, and nothing it can't see spelled out. Semantic search is a lookup by meaning: it turns text into vectors and returns the nearest neighbours in concept-space, so it can find the right code under a name you never guessed. That difference is the whole ballgame.
Run one query (the word charge) through both and the split is clean. This is the article in one picture; everything after it just walks the two columns.
The left column is what a semantic engine returns; the right is what a literal one returns. Read it as a rule of thumb: you can name it → go right; you can only describe it → go left. It is the same divergence we map in what semantic search is (and where it fails on code).
Side by side · seven properties
Where each one wins, property by property.
| Property | Embeddings · semantic | Keyword · literal |
|---|---|---|
| Matches on | meaning / concept | the exact characters |
| Finds a name you can’t recall | yes, its whole point | no |
| Finds the exact symbol you typed | sometimes buries it | always, every hit |
| “Did I catch all of them?” | approximate, a ranked list | complete, a deterministic set |
| After you edit the code | stale until re-embedded | fresh (index ~1 ms; grep reads now) |
| Offline & private | often a cloud / API hop | fully local, no model |
| Best for | discovery, fuzzy questions | refactors, exact lookups, agent loops |
Blue marks the clear winner on that row. Embeddings take the one that matters most for exploring an unfamiliar codebase:finding what you can't name. Keyword search takes the everyday cluster: exactness, completeness, freshness, privacy. Neither list makes the other tool bad; it makes them a pair, each covering the other's blind spot.
The honest failure modes
Embeddings drift. Keyword search can't read minds.
A vector is a snapshot of meaning. Rename a function, refactor a module, add a file, and the embeddings keep pointing at the old version until you re-embed, which is compute, latency, and, for cloud setups, your code leaving the machine to be turned into numbers. Retrieval is nearest-neighbour, approximate by design, so “did I catch every call site?”has no clean answer. Drift and blur are the tax you pay for meaning.
Keyword search never guesses and never goes stale: it reads the real characters. Its two limits are different: it can't match an idea that isn't spelled out, and the classic tools re-walk the disk on every query. On the machine below, one whole-machine content query took 93.8 s under ripgrep: exact and fresh, but unworkable inside an agent loop firing the same class of query over and over. The fix isn't a smarter match; it's a pre-walked one.
So the meaning lane is right for discovery and the literal lane is right for precision, but grep's delivery is wrong for an agent. Which raises the obvious question: what if a keyword search were already pre-walked, exact like grep, but answered from memory and fresh to the last save? That is the same three-way map we lay out in RAG, a live index, or grep?
The exact lane, measured · Ryzen 9 9950X3D · 4.47M files
Exact like grep. Fast like memory. Fresh like a save.
A purpose-built live index keeps keyword search's two virtues (literal matches, current characters) and drops its cost: the walk already happened, so the answer is waiting. There is no model in it to drift and nothing to re-embed. Point it at a name, a symbol, a string, or an error message and you get every exact hit, whole-machine, fresh to the last save. Measured on the machine below:
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename figures are medians: 139 μs across 20 queries, 85 μs single-file; the same lookup is 412,000× a VS Code search and ~480,000× Windows Search. Content queries run ~7 to 9 ms typical, exact phrases ~16 ms; the 58,625× is measured across a five-query set. At rest the engine sits near 44 MB in Task Manager, and the on-disk index stays under 1% of the drive (~24 GB on a 4 TB machine). The engine ran crash-free with correct ranking and 0 errors across ~1,500 validation queries. Full method in the ripgrep comparison.
The thesis
Keep your embeddings. Add the exact lane under them.
Embeddings and a literal index aren't rivals: they answer the two different questions from the diagram, so they run in parallel. Point your vector search at meaning, where fuzzy recall is the feature. Point the index at the exact file, symbol, string, or error message: whole-machine, across every repo and the files git ignores, fresh to the last save. No model in the loop: every hit is a literal match you can verify, not a ranked guess. And the same index carries something no per-repo vector store can see: a machine-wide relationship layer it builds itself. Interlinked is the exact lane; it replaces neither your model nor your embeddings. It's the deterministic floor they stand on, the backbone under every agent.
PARALLEL TO EMBEDDINGS · EXACT, FAST, FRESH · NO MODEL IN THE LOOP.
Frequently asked
The questions people actually ask.
Is semantic search better than keyword search for code?
Neither is universally better: they answer different questions. Semantic (embeddings) search wins when you don’t know the exact name and want conceptually related code; keyword search wins when you need every literal occurrence, fast and fresh. The strongest setups run both in parallel.
What’s the difference between embeddings and keyword search?
Embeddings turn text into vectors and retrieve by nearest-neighbour meaning, so “bill the customer” can surface chargeCard(). Keyword search matches the exact characters, so it returns only literal hits, but all of them, deterministically, including strings and comments.
Do I need a vector database to search my codebase?
Only for meaning-based discovery. For exact lookups (a symbol, a string, an error message) a live keyword index is faster, always fresh, and needs no model or embedding step. Many teams run a vector store for discovery and a literal index for precision.
Why does semantic search miss the exact function I searched for?
Nearest-neighbour ranking is approximate by design, so a similar-meaning function can rank above the exact name you typed, and edits leave vectors stale until you re-embed. When you already know the token, an exact index is the right shape.
Can keyword search find code by meaning?
No: that’s the one thing it can’t do. If the concept isn’t spelled anywhere in the code, literal search returns nothing. That gap is exactly what embeddings fill, which is why the two run alongside each other rather than competing.
Do this today
Give every agent the exact lane.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON to edit, no cloud account, no keys.
Point each engine at its job. Keep embeddings for meaning: the plain-English questions you can’t name. Hand the agent the exact lane for names, symbols, strings and error messages you already know.
Scope when you know, sweep when you don’t. Whole-machine when you have no idea where something lives; scoped to a folder when you do. Scoped queries return in microseconds.
Let it stay fresh. Save a file and it’s searchable in about a millisecond. No re-embedding, no re-index step, no drift: the walk already happened.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows.
Related: What is semantic search? · RAG, a live index, or grep? · Content search vs ripgrep