firehose> #llmops

Reranking

After Rank Fusion you have a ranked list, but the ranking is purely mathematical — vector distances and keyword scores — with no understanding of what the user actually meant. Reranking takes that shortlist and passes each candidate to a model that scores it against the original query, applying nuanced relevance judgment the math can't. The model can be a general LLM or a specialized reranker like Cohere's. The tradeoff is cost and latency: it's another step and often another API call before final results.

The load-bearing design point is why not just start with a model for the whole search?speed and context-window limits. The first-stage search has to scan thousands of embeddings quickly; a model can't read them all cheaply. So the pattern is two-stage: cheap, fast, high-recall retrieval narrows thousands to a refined handful, then the slow, accurate model reranks only that shortlist. You've already offloaded the bulk of the work, so the expensive judgment runs over a small set. This is the same cheap-recall-then-expensive-precision split behind Search-Then-Get and the LLM-as-scorer stance of LLM-as-Judge.

Claims


Linked from