A deep dive into what RAG rerankers actually learn: not comprehension, but statistical keyword co-occurrence between query and passage tokens, learned from datasets like MS MARCO. The piece walks through the cross-encoder architecture versus bi-encoder embedders, demonstrates with test queries where rerankers rescue answers that don't lexically match the question, and shows where they fail on specialized enterprise vocabulary (e.g., company-specific jargon absent from training data). It argues that for bounded enterprise domains, a curated keyword dictionary maintained by domain experts is often cheaper, faster, auditable, and more durable than a reranker, and lays out four specific cases where a reranker still earns its place (in-domain distribution, semantic reranking of a keyword-filtered top-K, compliance scenarios needing a score artefact, and offline dictionary discovery).
Table of contents
1. What data scientists say, and why it isn’t enough2. What actually happens inside a reranker3. The mechanism, shown: where the reranker wins, where it hits a wall4. Why the answer matters in enterprise5. What to do instead, and when to keep the reranker6. Sources and further readingQuestions this post answers
What does a RAG reranker actually learn during training, beyond just being a cross-encoder?
A reranker learns keyword co-occurrence patterns between query tokens and passage tokens at the pair level, not comprehension. Trained on millions of labeled (query, passage, relevance) triples from datasets like MS MARCO, it learns statistical associations such as query token 'cancel' correlating with passage tokens like 'terminate' or 'unsubscribe' in relevant pairs, plus secondary signals like positional and syntactic patterns. Developers deciding whether to add a reranker to a RAG pipeline can dig deeper into these tradeoffs on daily.dev.
How much slower is a cross-encoder reranker compared to a bi-encoder embedder in a RAG pipeline?
A cross-encoder reranker runs 30 to 100 times slower per query than a bi-encoder embedder. Scoring 1000 candidates might take 20 ms with a bi-encoder versus 600 ms to 2 seconds with a reranker, though in practice teams rerank only the bi-encoder's top-20 or top-50 results, bringing added latency down to roughly 15 to 100 ms depending on depth and model. Teams weighing latency against relevance for RAG retrieval can track these performance tradeoffs on daily.dev.
Why does a RAG reranker fail on company-specific or specialized vocabulary?
A reranker fails on private vocabulary because its learned keyword associations only cover patterns present in its training data, typically general web search datasets like MS MARCO. For example, if a company term like 'non-employee labor compensated beyond 40h/week' never co-occurred with 'contractor overtime' during training, the reranker has no learned association for it and ranks a surface keyword match higher instead, the same failure mode embeddings have. Engineers building domain-specific RAG systems can follow guidance like this on daily.dev before betting on off-the-shelf rerankers.