Lesson 05 · Measuring · 12 min
Reranking
Embedding search is fast because the corpus is embedded once, ahead of time, and a query is a single vector comparison. That speed comes from the query and the passage never being looked at together.
Reranking gives up that speed on purpose. Retrieve twenty candidates cheaply, then examine each one against the query properly, and reorder. The pattern is retrieve wide, rerank narrow: recall from the first pass, precision from the second.
A dedicated cross-encoder is the usual tool, and it is not available on the endpoint this course runs against — so the lab teaches the alternative, which is asking a model to score relevance directly. That is slower and costlier per candidate, and it is what most teams reach for before they have the volume to justify anything else.
- Rerank when the right passage is usually retrieved but not first. That is a precision problem and reranking is its answer.
- Do not rerank to fix recall. Reordering twenty candidates cannot promote a passage that was never in the twenty.
- Cost scales with candidates, not with corpus size, so the number you rerank is the number to tune.
- Measure before and after on the same labelled set. Reranking is often assumed to help and not always checked.
The shared-vocabulary question is where this shows. Several passages mention furniture, polish and care; similarity ranks them by wording, and only reading the query against each candidate separates the one about brass fittings from the one about wood.
Reranking is a sensor in the harness sense: it detects and corrects after the fact. Better chunking is a guide — it prevents the problem. Where both would work, the guide is cheaper, because it costs nothing per query.
Checkpoint
Find a question where the answering passage is retrieved but ranked below an irrelevant one.