Reranking
Reranking reorders retrieved candidates so the most relevant evidence is placed first.
Add reranking when initial retrieval finds useful candidates but does not rank them reliably enough.
Use when
- RAG with noisy retrieval
- Hybrid search pipelines
- High-value support answers
- Reducing irrelevant context
Avoid when
- Missing source data
- Tiny corpora
- Flows where latency must be minimal
- Cases where retrieval returns no good candidate
What reranking fixes
Reranking helps when the retriever returns a rough candidate set but the best evidence is not at the top. A reranker looks more carefully at the query and candidate chunks, then reorders them.
This is useful when the generation model has limited context budget or when irrelevant context causes hallucinated answers.
What it does not fix
Reranking cannot recover information that was never retrieved. If the candidate set is bad, fix indexing, chunking, hybrid search, or filters first.
Common mistakes
- Adding reranking before checking raw retrieval results.
- Reranking too many candidates and creating unnecessary latency.
- Using it without measuring answer quality.
Next decision
Use reranking after you have a baseline retrieval evaluation. It is an optimization step, not a replacement for good retrieval design.