RAG Reranker Benchmark: Cohere vs BGE vs Jina vs ColBERT (2026)

A RAG reranker benchmark belongs in every production pipeline review, yet most teams skip it and instead push quality problems onto the LLM. This post closes that gap. What this covers: a clearly stated methodology, representative performance numbers across four leading rerankers — Cohere Rerank 3, BGE-reranker-v2-m3, Jina Reranker v2, and ColBERT — compared on retrieval quality, end-to-end latency, and per-query cost, plus a practical selection matrix you can apply to your own stack today.

One upfront integrity note: the numbers below are illustrative and representative of typical published ranges, drawn from our own small evaluation harness and cross-referenced against publicly available leaderboard data. They are not vendor-certified results, and they are not claimed to reproduce any specific third-party study. Relative orderings — cross-encoders and late-interaction models leading on quality, API-backed rerankers carrying network overhead, self-hosted models trading quality for cost — reflect well-established trends across the research literature.

Context: Why Rerankers Matter in a RAG Pipeline

Standard vector retrieval is fast and scalable, but it is not precise. A bi-encoder embeds query and document independently and then measures cosine similarity between two fixed vectors. That works well for recall — you surface a candidate pool — but it leaves semantic nuance on the table. Two passages can share high cosine similarity while one is a far better answer to the specific question.

Rerankers sit between the retriever and the LLM generator. Their job is to re-score a smaller candidate set — typically the top 50 to 100 chunks from ANN search — and return the 5 to 10 that most deserve the LLM’s limited context window. The quality gain from adding a reranker routinely exceeds the quality gain from doubling your embedding model size.

Cross-Encoder Rerankers

A cross-encoder is a transformer that takes the query and passage concatenated as a single sequence. Full self-attention flows across every token pair, giving the model rich cross-document signal. Cohere Rerank 3, BGE-reranker-v2-m3, and Jina Reranker v2 all use this architecture. Cross-encoders cannot pre-compute document representations; they score each candidate from scratch at inference time. That is the quality-versus-latency tradeoff at the heart of any cross-encoder reranker discussion.

Late Interaction: ColBERT

ColBERT takes a different path. It encodes query and passage separately, producing per-token vectors rather than a single pooled embedding. At scoring time, it computes a MaxSim operation: for each query token, it finds the passage token most similar to it, then sums those max similarities. This late-interaction design means passage vectors can be pre-computed and stored in an index. ColBERT therefore avoids the full cross-attention overhead at query time while retaining much of the quality advantage over standard bi-encoders.

The architecture differences matter directly for pipeline design decisions. See Figure 1 for the full pipeline view and Figure 2 for the architectural contrast.

Figure 1: A RAG pipeline with an explicit reranker stage between ANN retrieval and the LLM generator. The reranker scores only the top-k candidates, not the full corpus.

Figure 2: Left — a cross-encoder processes query and passage as a single concatenated sequence through full self-attention. Right — ColBERT encodes them separately and scores via per-token MaxSim, enabling offline passage indexing.

This architectural distinction also connects to how hybrid retrieval pipelines compose retrieval stages in practice.

Benchmark Methodology

Reproducibility requires committing to specific choices before you look at results. Here is exactly what we committed to.

Datasets and Query Sets

We used three datasets representing distinct retrieval difficulty levels:

MS MARCO Passage Ranking (dev small, ~6,980 queries): A broad web-query benchmark with sparse judgments. Widely used as the standard retrieval quality signal. We retrieved top-100 passages per query using a fixed BM25+dense hybrid retriever and then applied each reranker to re-score those 100 candidates.

BEIR — TREC-COVID subset (~50 queries, ~171K documents): A biomedical out-of-domain dataset. This tests how well each reranker generalises beyond its training distribution. Models trained primarily on web or Wikipedia text often lose quality here.

FinanceBench (custom subset, ~120 queries): Financial document QA drawn from 10-K filings and earnings call transcripts. Passages are dense, jargon-heavy, and long. This stresses chunking and passage-length sensitivity in cross-encoders.

We fixed retrieval at top-100 candidates before reranking for all conditions. Every reranker received the same candidate set. No query-side prompt engineering was applied. This isolates the reranker’s own contribution.

Metrics

nDCG@10 — Normalised Discounted Cumulative Gain at rank 10. This is our primary quality metric. It rewards placing the most relevant documents at higher ranks within the top 10.

Recall@10 — Fraction of relevant documents appearing in the top 10. Complementary to nDCG, more sensitive to coverage.

p50 / p95 reranking latency (ms) — Wall-clock time from submitting 100 candidates to receiving ranked scores. Measured on the same machine for self-hosted models; measured as network round-trip for API-backed models from a single AWS us-east-1 instance.

Estimated cost per 1,000 queries — For API models, based on published pricing tiers. For self-hosted models, estimated from AWS g4dn.xlarge GPU instance cost at the observed throughput.

Evaluation Harness

We ran evaluation in Python 3.12 using the BEIR evaluation library for metric computation. API calls used the official Cohere Python SDK and Jina Python SDK. BGE-reranker-v2-m3 was loaded via FlagEmbedding from BAAI’s HuggingFace repository. ColBERT was evaluated using the RAGatouille library wrapping the ColBERTv2 checkpoint.

Latency measurements exclude first-request cold starts. We report median across 200 queries per dataset. All experiments ran with top-k=100 candidates in, top-n=10 out. Passage truncation was set to 512 tokens for cross-encoders (the standard model maximum) and 180 tokens per passage for ColBERT to match its training conditions.

Results and Interpretation

The table below reports representative scores across our three datasets. These numbers are illustrative, reflecting the range of results typical in our harness and in publicly available evaluations. They are not certified benchmarks. They are provided to give engineers a directional sense of relative performance rather than a precise ranking.

Reranker	MS MARCO nDCG@10	BEIR-COVID nDCG@10	FinanceBench nDCG@10	p50 Latency (ms)	p95 Latency (ms)	Est. Cost / 1K queries
Cohere Rerank 3	0.76	0.74	0.71	340	620	~$1.00
BGE-reranker-v2-m3	0.74	0.68	0.69	38	72	~$0.04 (self-hosted)
Jina Reranker v2	0.71	0.65	0.66	280	510	~$0.60
ColBERT (v2)	0.73	0.72	0.68	55	95	~$0.05 (self-hosted)

Table 1: Illustrative nDCG@10 and latency figures representative of typical published ranges. See methodology section for full harness details. Do not treat these as vendor-certified results.

Reading the Results

Cohere Rerank 3 leads on overall quality across two of three datasets. The biomedical BEIR-COVID score is strong relative to other cross-encoders, suggesting Cohere’s training corpus and multilingual fine-tuning provide broader generalisation. The tradeoff is latency: network round-trips to the Cohere API add ~300 ms at median, and the API cost scales linearly with usage. At 100 million queries per month, Cohere Rerank becomes prohibitively expensive for most startups.

BGE-reranker-v2-m3 is the strongest self-hosted cross-encoder. Developed by BAAI and available on HuggingFace, it supports multilingual input and runs comfortably on a single consumer GPU. Latency is excellent — under 40 ms at p50 for top-100 candidates on a g4dn.xlarge. The quality gap versus Cohere is meaningful on out-of-domain data (BEIR-COVID), suggesting BGE benefits more from domain fine-tuning when corpus characteristics diverge sharply from web text.

Jina Reranker v2 sits in the middle on both quality and latency. Its API-based delivery model, documented at Jina AI’s reranker endpoint, provides ease of integration but carries network overhead. Jina’s strengths include long-context support (up to 8,192 tokens per passage) and a transparent open-weights policy that lets teams self-host if cost becomes a concern at scale. On FinanceBench, the long-document capability matters — and yet Jina still trails Cohere, indicating that training data domain matters more than context window for financial text.

ColBERT v2 is the outlier. Its late-interaction design places it in a category of its own: competitive quality (especially on BEIR-COVID), very low latency for a model with this quality level, and low cost when self-hosted. The catch is infrastructure: ColBERT requires pre-building a per-token vector index over your corpus using PLAID indexes, which adds an indexing pipeline step that cross-encoders do not require. ColBERT does not fit easily into a “drop-in replace the reranker” slot; it is more of a retrieval architecture choice than a component swap.

Figure 3 shows the quality-versus-latency tradeoff across all four models visually.

Figure 3: Illustrative quality-versus-latency quadrant. ColBERT and BGE occupy the high-quality, low-latency quadrant for self-hosted deployments. Cohere achieves the highest quality but adds API network latency. Jina trades quality for long-context support.

Trade-offs and What Goes Wrong

Rerankers are not a universal cure for poor retrieval. Several failure modes are common in production systems.

Latency Budget Violations

A cross-encoder scoring 100 passages per query adds real time to your pipeline’s critical path. If your target end-to-end latency is under 500 ms and your LLM already consumes 300 ms, an API-based reranker with 300 ms p50 latency breaks your SLA immediately. The fix is not to remove the reranker — it is to right-size the candidate set. Dropping from top-100 to top-30 before reranking cuts cross-encoder latency roughly proportionally while sacrificing relatively little recall, since the marginal value of candidates 31 through 100 is usually low.

Top-k Starvation

The opposite mistake is sending too few candidates to the reranker. If your retriever returns top-10 and your reranker re-ranks 10, you have not expanded recall — you have only reordered candidates the retriever already liked. The reranker needs a candidate pool large enough to contain passages the retriever ranked poorly but that a cross-encoder would rank highly. In practice, top-50 to top-100 is the sweet spot for most corpora.

Domain Mismatch

Cross-encoders trained on MS MARCO web queries do not automatically transfer to highly specialised domains. Legal, biomedical, and financial corpora have vocabulary and reasoning patterns that differ sharply from general-purpose training data. Our FinanceBench results reflect this: all four models show a quality drop versus MS MARCO. BGE is the most amenable to domain fine-tuning given its open weights and well-documented training pipeline via FlagEmbedding. Cohere offers a fine-tuning API but it is gated and costly. Jina’s open-weights release enables fine-tuning but documentation at the time of writing is limited.

Passage Length Sensitivity

Standard cross-encoder transformers truncate at 512 tokens. A passage longer than 512 tokens gets silently truncated during scoring. If your corpus chunks average 700 to 800 tokens — common when chunking PDFs or long-form technical documents — this truncation degrades quality substantially. Either reduce chunk size before reranking, use Jina’s long-context model explicitly, or use ColBERT with its per-token architecture which handles longer passages more gracefully.

Caching Blindspots

API-backed rerankers are stateless by default — every query-passage pair is scored from scratch. If your user base issues repetitive queries (common in enterprise search, FAQ systems, and LLM agent pipelines), you leave significant cost and latency savings on the table. A Redis-backed cache keyed on (query, passage_hash) can serve repeat scores without an API call. Typical enterprise search workloads see 20–40% cache hit rates on the reranker layer.

Figure 4 maps these failure modes into a decision flow for debugging a reranker that is not improving recall.

Figure 4: A decision flow for diagnosing common reranker failures: top-k starvation, domain mismatch, latency SLA violations, and chunk length issues.

Practical Recommendations

No single reranker wins across all use cases. The right choice depends on your latency budget, corpus size, domain, and infrastructure constraints. Here is a selection framework.

Selection Matrix

Choose Cohere Rerank 3 when:
– Query volume is moderate (under 5 million queries per month)
– Your team has no GPU infrastructure and wants a managed API
– You need multilingual or cross-lingual retrieval out of the box
– The quality ceiling matters more than cost — e.g., legal research, medical QA, or high-stakes enterprise search

Choose BGE-reranker-v2-m3 when:
– You have GPU infrastructure or can justify a single GPU instance
– You want the lowest per-query cost at production scale
– Your corpus is domain-specific and you plan to fine-tune the reranker
– Sub-50 ms reranking latency is required to meet your SLA
– You are already using the BAAI embedding model stack (natural fit with BGE embeddings)

Choose Jina Reranker v2 when:
– Your passages regularly exceed 512 tokens and truncation is unacceptable
– You want an API option with a path to open-weights self-hosting as scale grows
– Your stack is polyglot or your documents are multilingual
– You are evaluating rerankers and want a mid-tier cost point for comparison

Choose ColBERT when:
– Latency is paramount and you cannot afford cross-encoder scoring at query time
– Your corpus is large but stable (pre-built indexes are feasible)
– You are building a research or domain-specific search system where architectural investment is justified
– You want the quality of a cross-encoder at latency closer to a bi-encoder

Deployment Checklist

Before shipping any reranker to production, verify each item:

[ ] Candidate pool size set correctly — retriever returns 50–100 candidates before reranking
[ ] Chunk size within model limits — passages truncated to model’s max (512 tokens for most cross-encoders; verify for Jina long-context)
[ ] Latency measured end-to-end — including API round-trip or GPU scheduling overhead, not just model inference time
[ ] Baseline established — nDCG@10 with reranker off vs. on, so you can quantify the lift
[ ] Domain evaluation set created — at least 50 real queries with human relevance judgments from your actual corpus
[ ] Cost projections modelled — at current query volume, at 10x, and at 100x
[ ] Cache layer scoped — decide whether to cache reranker scores and what the eviction policy will be
[ ] Fallback path defined — if the reranker API is unavailable, does the pipeline degrade gracefully to the raw retriever order?
[ ] Monitoring instrumented — track mean nDCG, p95 reranking latency, and reranker error rate separately from overall pipeline metrics

Frequently Asked Questions

What is a reranker in a RAG pipeline and why is it separate from the retriever?

A retriever performs fast approximate nearest-neighbour search across potentially millions of documents using pre-computed embeddings. Speed requires the query and documents to be encoded independently, which limits cross-attention quality. A reranker operates on a much smaller candidate set — typically 50 to 100 passages — and can afford to score each query-passage pair jointly through full cross-attention. The two-stage design gives you the recall of a fast retriever and the precision of a slower, more accurate model.

Does adding a reranker always improve RAG answer quality?

Not always. If your retriever already surfaces the correct passage in its top-3, a reranker adds latency without changing the LLM’s context. Rerankers provide the largest gains when (a) the right passage is retrievable but buried in the top-50, or (b) the retriever is noisy on your specific domain. The best way to know is to measure nDCG@10 before and after on a representative evaluation set from your own corpus.

How does ColBERT differ from a standard cross-encoder reranker like Cohere or BGE?

A cross-encoder concatenates query and passage into a single sequence and runs full self-attention across all tokens simultaneously. This is computationally expensive because it cannot pre-compute passage representations. ColBERT encodes query and passage separately, producing per-token vectors. Scoring uses a lightweight MaxSim operation over those vectors. Passage vectors can be pre-indexed, making ColBERT much faster at query time while retaining most of the quality advantage over bi-encoders.

What top-k value should I use before reranking?

Most practitioners use top-50 to top-100 for the retriever and then rerank down to top-5 or top-10 for the LLM. Going below top-50 risks top-k starvation — the relevant passage may not be in the candidate pool at all. Going above top-100 increases reranker latency substantially and offers diminishing recall returns in most corpora. If your retriever recall@100 is below 70%, fix the retriever first rather than increasing k.

Can I fine-tune a reranker on my own domain data?

Yes, and it is often the highest-leverage action for domain-specific retrieval. BGE-reranker-v2-m3 supports fine-tuning through the FlagEmbedding library with a standard pairwise cross-entropy loss on (query, positive_passage, hard_negative_passage) triples. Jina’s open-weights model can also be fine-tuned via standard HuggingFace Trainer workflows. Cohere offers a fine-tuning API, but it requires a labelled dataset and incurs additional cost. ColBERT fine-tuning is well-supported in the RAGatouille library with domain-specific training sets.

How do I measure whether my reranker is actually helping in production?

Instrument two metrics at the pipeline level: (1) reranker lift — the fraction of queries where the top-1 result after reranking differs from the top-1 result before reranking; and (2) downstream LLM answer quality on a held-out evaluation set with human or LLM-judge scores. If reranker lift is below 10%, your retriever is already performing well for those queries and the reranker is adding cost without benefit. Segment by query type and domain to find where the reranker adds the most value.

RAG Reranker Benchmark: Cohere vs BGE vs Jina vs ColBERT