zELO, rerankers, and the “cheap LLM” trick

Oct 05, 2025

I thought reranking was just sorting vectors. Then I read this paper and realized it is more like running a tournament.

A few weeks ago I went down a rabbit hole to understand why retrieval pipelines feel great at recall but shaky at true relevance. Dense embeddings are magic until they are not. When a query quietly mixes law, tax, time, and location, vector closeness starts to wobble. That is where a good reranker matters.

This is my study-notes-turned-story after reading zELO: ELO-inspired Training Method for Rerankers and Embedding Models and talking through the tricky bits. Paper link: arXiv:2509.12541. I will keep it student-level intuitive, with examples, and enough math to be precise.

I also attended a discord walkthrough held by ZeroEntropy's CTO: Nicholas Pipitone where he dove deep into model complexity and optimizations used by his team to build this. Here, I try to break it down step by step.


0) What I first believed, and why it was incomplete

I used to think: embed query and docs, sort by cosine similarity, ship it. That is the bi-encoder mindset. It is fast and excellent for retrieval of candidates, but it compresses meaning into one fixed vector per text. If relevance depends on several interacting details, a single vector cannot represent all of them cleanly.

A cross-encoder reranker reads the query and one document together. The model attends across both texts and outputs one score. Example:

A cross-encoder can notice the year, the states, and that “franchise tax” is not capital gains, so Doc A gets a higher score.


1) The hidden pain: labels for training rerankers

To train a strong reranker you need labels.

Where do labels come from

My intuition after reading: the more you outsource “find me adversarial negatives” to a very smart miner, the more likely the miner finds documents that are in fact good, which poisons the signal.


2) The zELO idea, step by step

That raises two immediate questions.

  1. How do we avoid paying for a quadratic number of LLM comparisons
  2. How do we turn separate, possibly miscalibrated LLM outputs into one consistent scoring scale The next two sections answer those.

3) The cost problem and the “tournament” trick

With K=100K=100 retrieved docs, full pairwise would be K(K−1)/2=4,950K(K-1)/2 = 4{,}950 LLM comparisons per query. That is not viable.

Trick: compare only a well chosen sparse subset of pairs.

Why this works

Tournament analogy


4) Why these graph rules matter, not just how

Rules the paper enforces on the comparison graph

Why these help in practice

Concrete example


5) From pairwise to absolute, with the right amount of math

We want one score per document for the current query. The LLM ensemble gives us pairwise preferences, for example "Doc A beats Doc B with probability 0.80.8". Statistical ranking models turn those into absolute scores.

Two classic choices

We fit {si}\{s_i\} by maximizing the likelihood of the observed pairwise outcomes on the sparse set of compared pairs. That gives one absolute score per document for the query.

If the equations feel heavy, keep this intuition


6) The calibration problem that pairwise fixes

Problem, stated simply

Why this matters

How the paper addresses it

Tiny example


7) Training the pointwise cross-encoder, and the loss

After fitting scores {yi}\{y_i\} for the KK docs of each query, we train a pointwise reranker Rpoint(q,d)R_{\text{point}}(q, d).

At inference time

  1. retrieve top KK with BM25, embeddings, or hybrid
  2. score each (q,d)(q, d) with the pointwise reranker
  3. sort by the score

No LLM ensemble, no graph fitting, no Bradley–Terry or Thurstone at inference. Only the trained reranker.


8) RLHF-style refinement, but targeted

Even after training, sometimes the student model ranks the human top document too low. The paper applies a small loop:

This is “RLHF-like” because it uses preference feedback to correct the model’s behavior, but it stays cheap because it is targeted, not a full-blown policy optimization run.


9) How zELO compares to other rerankers

The tables below are pasted from the paper. Metrics are NDCG@10. Benchmarks cover several domains.

Performance comparison across different tasks and benchmarks

Task/BenchmarkDefault(embedding)cohere-rerank-v3.5Salesforce/Llama-rank-v1zerank-1-smallzerank-1
Code0.6780.7240.6940.7300.754
Conversational0.2500.5710.4840.5560.596
Finance0.8390.8240.8280.8610.894
Legal0.7030.8040.7670.8170.821
Medical0.6190.7500.7190.7730.796
STEM0.4010.5100.5950.6800.694

Performance comparison across different tasks and benchmarks

TaskCohere/rerank-v3.5Salesforce/Llama-rank-v1VoyageAI/rerank-2zerank-1-smallzerank-1
Legal0.7180.7660.7460.7990.854
Enterprise Search0.6740.6290.7350.7650.799
Conversational0.7270.6530.7270.7470.787
Healthcare0.7060.7560.7490.8850.898

The paper also reports that zerank-1 is competitive or faster at common input sizes, and that it outperforms simply prompting a cheaper frontier LLM as a reranker when both use the same preference prompts for pairwise judgments.


10) The mental model I am keeping


11) Closing thoughts, plus suggested readings

This paper reframed reranking for me. Instead of “find harder negatives”, the mindset becomes “ask a few good pairwise questions, then let statistics stitch them into one scale”. The budget saver is not a cheaper LLM, it is the graph that picks the right few comparisons.

Suggested readings and rabbit holes

My personal learning

Paper link again, for easy access: zELO: ELO-inspired Training Method for Rerankers and Embedding Models.