Explainers · updated July 2026
Your AI search runs twice. The second pass is the reranker.
A reranker is a second model that reorders the results your first search returned, keeping only the few most relevant before they reach the LLM. It is why a Pinecone-style RAG chatbot pulls exactly the right paragraph, and part of how Cursor decides which snippets of your code the model actually sees. Here is what it does, why retrieval pipelines add one, and the large class of questions where a second model is work you can skip entirely.
TL;DR · the short version
A reranker is a second, more accurate model that reorders an initial list of retrieved results by true relevance, so only the best few reach the LLM.
It exists because first-stage retrieval is fast but coarse: it casts a wide net and gets the order roughly right; the reranker reads the query and each candidate together and gets it precisely right.
The pattern is retrieve many → rerank → keep the top few: standard in Pinecone-style RAG, and the reason hosted rerank endpoints exist.
Its ceiling is recall a reranker can only reorder what stage one already found. Miss the right document in retrieval and no reranker can bring it back, plus it adds a second model’s latency and, often, a cloud round-trip.
For exact questions (a name, a symbol, a string, an error message) an exact index returns every literal match with no first pass to correct: 139 μs across 4.47M files, fresh about a millisecond after you save.
What a reranker actually is
A second grader for the first search. Slower, sharper, last.
A reranker is a second, more accurate model that takes the shortlist of results your first search returned and reorders it by how well each one truly answers the query, so only the top few reach the LLM. It runs in two stages for a reason. The first stage, retrieval, has to scan the whole corpus in milliseconds, so it compares a pre-computed summary of the query against a summary of each document, separately. That is cheap and fast, but coarse: the right answer usually lands in the top hundred, not the top five. The reranker (typically a cross-encoder) reads the query and one candidate together, which is far more accurate, and far too slow to run over millions of documents. So you retrieve a hundred cheaply, rerank those hundred carefully, and keep the best five. Here is the whole shape:
Notice where the intelligence sits: stage one decides what gets considered, the reranker only decides the order of what survived. The retriever and reranker are usually different models: one built for speed over everything, one for judgment over a few. The answer the LLM finally reads is only ever as good as what the net caught in the first place.
Why RAG pipelines add one
Fast retrieval is coarse. A reranker buys back precision.
This isn't a takedown: for meaning-based search, a reranker is a genuine relevance upgrade, and Pinecone-style RAG stacks document it as a best practice. It exists because of four honest facts about the way retrieval works:
To search millions of chunks in milliseconds, it compares pre-computed summaries of the query and each document separately. That is fast, but coarse: good enough to get the right answer into the top 100, rarely precise enough to put it in the top 5.
Reading the query and a document together (what a cross-encoder does) gives a much sharper relevance score. But it runs once per candidate, so it is far too slow to point at the whole corpus. You can only afford it on a shortlist.
Cast the wide net cheaply, then spend the expensive model only on the candidates that survived stage one. Retrieval maximizes recall; the reranker maximizes precision. Together they get the right chunk to the top.
A second model means extra latency, and for a hosted rerank endpoint it often means your text leaving the machine to be scored. And it can’t fix a miss: reranking only reorders what retrieval already found.
Keep it. Nothing below asks you to drop your reranker for meaning-based search. The point is only that the whole two-stage dance exists to correct an approximate first pass, and a very common question doesn't have an approximate answer to correct.
The limit worth knowing
A reranker can't find. It can only re-sort.
Here is the ceiling: a reranker only ever sees the shortlist stage one handed it. If the right chunk wasn't retrieved (the wrong words, a fresh edit, an exact string the fuzzy first pass couldn't place) no amount of reranking can promote a document that was never in the list. It sharpens order; it cannot repair recall. That gap barely shows for conceptual questions, where a wide net usually catches something close. It shows badly the moment an agent needs the opposite of fuzzy: the exact symbol, the current bytes, the error message that appeared thirty seconds ago, anywhere on the machine. That is not a relevance judgment. It is a lookup, and a lookup has one right answer, or every right answer, not a ranked guess.
When the thing you want is literal and known, the entire retrieve-then-rerank pipeline is effort spent correcting a guess you never needed to make. The two lanes, side by side:
| Retrieve + rerank | Exact index (Interlinked) | |
|---|---|---|
| The job | Reorder fuzzy matches by relevance | Return every literal match, in order |
| Stages | Two: retrieve, then rerank | One: look it up |
| Can it miss the answer? | Yes, if stage 1 never retrieved it | No, every exact match is returned |
| Models running | Two (a retriever + a reranker) | None |
| Freshness | Stale until you re-embed | Fresh to the last save (~1 ms) |
| Code leaves the machine? | Often (cloud rerank endpoints) | Never |
| Best for | “Which of these is most relevant?” | “Where is this exact thing?” |
The exact lane, measured · Ryzen 9 9950X3D · 4.47M files
No first pass. Nothing to rerank.
When the query is a known literal (a name, a symbol, a string, an error message) an exact index returns every match directly. There is no approximate shortlist to correct, so there is nothing to rerank and no second model to run. The results are already the ground truth: every literal hit, deterministically, fresh to the last save, across the whole machine, including every repo and the files that never entered git. 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. At rest the engine sits near 44 MB in Task Manager, and the on-disk index stays under 1% of the drive. Full method in the backbone write-up.
The thesis
Keep the reranker for meaning. Add the exact lane for literal.
A reranker and a live index aren't rivals: they answer different questions, so they run in parallel. Point the reranker at “which of these is most relevant?”, where re-scoring a fuzzy shortlist is the whole 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 first pass, no second model: every hit is a literal match you can verify, not a ranked guess. Interlinked is the exact-retrieval lane. It replaces neither your reranker nor your vector database; it is the deterministic floor they stand on.
RERANK FOR MEANING · EXACT INDEX FOR THE LITERAL · NO MODEL IN THE LOOP.
FAQ · what people ask
Rerankers, in plain answers.
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 lane at its job. Keep your reranker for meaning: the fuzzy shortlists worth re-scoring. 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 shortlist to rebuild: 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 RAG? · What is a vector database? · RAG, a live index, or grep?