TECHNIQUE
Retrieval & Grounding
Reranking is usually deployed as a second pass over retrieved candidates; observed operators differ mainly on whether that pass is embedding-based, LLM-based, cross-encoder, MMR, or an unspecified production re-ranker.
Use reranking after an initial retrieval or search step, rather than relying on first-pass retrieval alone.
8 of 9 roster operators are cited with reranking evidence in this pool.Rerank or select from a narrowed candidate set to reduce what reaches the next stage: chunks, tables, runbooks, code changes, user-history entries, or general retrieval results.
7 of 9 roster operators cite candidate reduction, top-k selection, or context pruning as part of reranking.Combine reranking with hybrid, lexical, vector, or semantic retrieval rather than treating reranking as the retrieval index itself.
6 of 9 roster operators cite reranking alongside first-pass lexical, vector, hybrid, or semantic retrieval.Use reranking to manage context or downstream load: Dropbox puts relevant chunks at the top, Rippling reports 100–500x context-size reduction, Meta reduces hundreds of candidates to five, and Grab feeds a shortlist of 15 to the LLM.
4 of 9 roster operators cite explicit reranking outputs or reductions.Evaluate or tune reranking quality with task metrics, backtests, or comparisons against first-pass retrieval.
4 of 9 roster operators cite evaluation or measured impact tied to reranking/retrieval ranking.Across the cited reranking deployments, reranking is a later-stage operation over candidates produced by an earlier retrieval/search/shortlisting step.
Operators choose different reranking mechanisms.
APPROACH 01
Embedding-feature or embedding-model reranking.
APPROACH 02
LLM-based ranking or selection from retrieved candidates.
APPROACH 03
Cross-encoder reranking in a hybrid-retrieval RAG platform.
APPROACH 04
MMR reranking to balance query similarity with diversity among retrieved documents.
APPROACH 05
Production re-rankers used for aggressive context pruning, without the specific reranker model disclosed in the cited evidence.
Operators optimize reranking for different outputs.
APPROACH 01
Put the most relevant content chunks or search results at the top for RAG answers/search.
APPROACH 02
Select the most relevant structured-data tables before Text-to-SQL prompting.
APPROACH 03
Pick the correct support runbook from vector-retrieved candidates, or return not found when no good match exists.
APPROACH 04
Reduce investigation candidates to the top five likely root-cause code changes.
APPROACH 05
Prune agent context size by 100–500x.
APPROACH 06
Retrieve and rerank long-retention user-history entries for ads recommendation feature augmentation/training rehearsal.
Reranking with LLMs can add latency; Grab explicitly says real-world applications must consider additional latency from the extra LLM query.
Candidate volume and context limits shape reranking design: Meta used election-style ranking to accommodate context-window limitations, while Rippling cites aggressive pruning to reduce context size by 100–500x.
Long-history or large-corpus reranking has efficiency pressure: Meta AI reports attention dilution and system-efficiency problems with naive history scaling, and describes chunking, quantization, and asynchronous serving to keep retrieval latency under 10 ms.
Reranking gains are use-case dependent: Grab reports that effectiveness may depend on data quality, data complexity, use case, and query patterns, and that raw similarity search can remain viable for simpler queries when efficiency matters.
| Name | Kind | When | Maturity |
|---|---|---|---|
| bge-reranker | library | self-hosted cross-encoder reranking with GPU available | established |
| Cohere Rerank | service | managed reranking without hosting a model | established |
| ms-marco MiniLM cross-encoder | library | CPU-friendly baseline reranker for modest volumes | commodity |