Using reranking to fix missing candidates
Symptom: reranker cannot promote gold evidence because it never received it.
Better move: improve first-stage retrieval or candidate k.
Reranking and Retrieval Optimization
First-stage retrieval is built for speed and recall. Reranking is built for judgment. In production RAG, a common pattern is retrieve many candidates, rerank carefully, and return only the strongest evidence to the prompt.
How to read this chapter
- Separate recall from precision: first retrieve enough candidates, then rerank to choose the best few.
- Understand cost: rerankers improve ordering but add latency and compute.
- Use reranking for the right failures: it helps when the gold chunk is in candidates but ranked too low.
- Optimize with eval loops: retrieval tuning is a measured cycle, not a one-time setting.
Reranking cannot recover a chunk that retrieval never found. It can only reorder the candidates it receives.
Core ideaReranking takes a candidate set from retrieval and applies a stronger relevance model or scoring rule to choose the best chunks for context.
Why Reranking Matters
At a glance
- Initial retrieval often optimizes recall and speed.
- Reranking improves precision among candidates.
- Reranking is useful when the correct chunk is retrieved but not ranked high enough.
- It adds latency, so use it where quality gain justifies cost.
Imagine a vector search returns 30 chunks. The correct answer is there, but it sits at rank 11. If your prompt only receives the top 5, the model still misses the answer. A reranker can inspect the query and candidate chunks more carefully, move the strongest evidence upward, and reduce context noise.
Reranking north starRetrieve enough candidates for recall, rerank enough candidates for precision, and send only useful evidence to the model.
Reranking should be justified by measured gains in gold rank, citation support, and answer quality.
01
Retrieve broad candidates
Use dense, sparse, hybrid, or multi-query retrieval to build a candidate pool.
02
Rerank carefully
Score query-candidate relevance with a stronger model or rule set.
03
Select context
Choose final chunks by relevance, diversity, token budget, and citation quality.
04
Evaluate loop
Measure Recall@candidate_k, MRR, gold rank, latency, and answer groundedness.
Real-Life Analogy: Hiring Shortlist
First-stage retrieval is like collecting resumes from a big job board. You want a wide enough pool so strong candidates are not missed. Reranking is the hiring panel reading the shortlist carefully and deciding who truly fits the role.
If the right candidate never enters the shortlist, the panel cannot choose them. If the shortlist is too big, the panel becomes slow and expensive. The art is choosing the right candidate pool size.
First-Stage Retrieval
First-stage retrieval should usually optimize for recall and speed. It may use vector search, BM25, hybrid search, query rewriting, or multi-query retrieval.
Candidate k
The larger pool sent to reranking, such as 30, 50, or 100 candidates.
Final k
The smaller set sent to the prompt, such as 4, 6, or 8 chunks.
Key question
Does the gold evidence appear in the candidate pool before reranking?
Reranking
A reranker takes the query and candidate chunks and returns a new relevance order. Some rerankers are neural models; others are rule-based or weighted scoring systems.
Retrieve many, return few
query
-> retrieve top 40 candidates
-> rerank 40 candidates
-> dedupe and diversify
-> send top 6 to context
-> answer with citationsCross-Encoder Intuition
A bi-encoder embeds query and documents separately, which is fast for search. A cross-encoder reads the query and candidate text together, which is slower but often more precise.
Bi-encoder
Fast search
Great for first-stage retrieval across large collections.
Cross-encoder
Careful scoring
Great for reranking a smaller candidate set.
Trade-off
Quality vs latency
More careful scoring costs more runtime.
Rule
Small pool
Rerank candidates, not the whole corpus.
When Reranking Helps
Good fit
- Gold evidence appears in top 50 but not top 5.
- Dense and sparse retrieval produce mixed candidate quality.
- Many candidates are related but only a few directly answer the query.
- High-risk answers need stronger evidence ordering before prompt assembly.
- Context budget is tight and every chunk must earn its place.
Mentor note: if the correct evidence is not in the candidate pool at all, fix retrieval, chunking, filters, or query rewriting first.
Architecture View
Optimization Loop
Retrieval tuning loop
collect failure trace
-> label miss
-> inspect candidate pool
-> tune retrieval or reranking
-> run golden queries
-> compare quality + latency
-> release or roll backOptimization is not "turn on reranking." It is repeated measurement across failure types: missing evidence, wrong order, duplicates, stale chunks, access-filter misses, and context overflow.
Cost and Latency
Reranking can be expensive because every candidate may require a query-chunk relevance score. Candidate pool size matters.
Rerank 10
Fast but may miss gold evidence if candidate recall is low.
Rerank 50
Higher recall opportunity but more latency and cost.
Rerank 200
Often too expensive unless offline, batch, or high-value workflow.
Metrics
Before rerank
Candidate Recall@k, gold candidate presence, duplicate rate, stale-hit rate.
After rerank
MRR, gold final rank, final Recall@k, context precision, citation support.
Operations
Rerank latency, cost per query, timeout rate, fallback rate, and token savings.
Common Mistakes
Reranking too many chunks
Symptom: latency spikes and user experience suffers.
Better move: cap candidate pool and use routing for high-value cases.
Evaluating only final answers
Symptom: team cannot tell whether retrieval or reranking helped.
Better move: measure before and after rerank metrics separately.
No dedupe after rerank
Symptom: top results contain repeated chunks from same section.
Better move: dedupe and diversify final context.
Ignoring access and freshness
Symptom: reranker promotes restricted or stale chunks.
Better move: enforce filters before and after rerank.
No latency budget
Symptom: quality improves in tests but product feels slow.
Better move: track p50/p95 rerank latency and timeouts.
One reranker for every domain
Symptom: legal, code, and support behave differently.
Better move: evaluate by domain and risk slice.
No fallback on reranker failure
Symptom: retrieval path fails hard when reranker times out.
Better move: fallback to first-stage rank with lower confidence.
Interview-Level Understanding
A strong answer sounds like this: "Reranking is a second-stage retrieval step. I first retrieve a broader candidate pool for recall, then rerank candidates with a stronger relevance model, dedupe, and send a smaller context set to the prompt. I measure candidate recall before rerank and final rank/citation support after rerank, while watching latency and cost."
Mini Assignment
Design a reranking policy for three flows: low-risk FAQ, high-risk policy answer, and Sev1 runbook. Define candidate k, final k, reranker use, fallback, latency budget, and metrics.
Points To Remember
- Reranking improves ordering, not candidate discovery.
- Use first-stage retrieval for recall and reranking for precision.
- Measure before and after reranking separately.
- Reranking adds cost and latency, so use it intentionally.
- Optimization is an eval loop, not a single switch.
Next, test reranking judgment in the quiz, then build a reranking policy planner in exercises and project.