A Cross-Encoder is a transformer-based architecture that takes a pair of sequences—typically a query and a document—concatenated into a single input string, separated by a special [SEP] token. Unlike a Bi-Encoder, which encodes each input independently into separate vectors for fast cosine similarity comparison, the Cross-Encoder applies full self-attention across the entire concatenated sequence. This allows the model to model fine-grained token-level interactions between the query and the document, capturing exact phrase matches, term importance, and complex semantic relationships that independent encoding misses.
Glossary
Cross-Encoder

What is Cross-Encoder?
A Cross-Encoder is a neural architecture that processes a concatenated pair of inputs simultaneously through full self-attention to generate a relevance score, offering higher accuracy than a Bi-Encoder at the cost of inference speed.
The primary trade-off is computational: a Cross-Encoder cannot pre-compute document embeddings offline. Every query-document pair must be processed through the full transformer stack at inference time, making it impractical for first-pass retrieval over millions of candidates. Instead, Cross-Encoders are deployed as a re-ranking stage in a multi-stage retrieval pipeline, where a fast Bi-Encoder or BM25 system retrieves a candidate set of 100-1000 documents, and the Cross-Encoder re-scores them with high precision. The output is typically a single logit passed through a sigmoid activation to produce a relevance probability between 0 and 1.
Cross-Encoder vs. Bi-Encoder
A technical comparison of the two dominant transformer-based architectures for scoring query-document relevance in neural information retrieval pipelines.
| Feature | Cross-Encoder | Bi-Encoder | Poly-Encoder |
|---|---|---|---|
Input Processing | Concatenated pair processed jointly | Each input encoded independently | Concatenated with condensed context codes |
Attention Mechanism | Full self-attention across both inputs | No cross-attention between inputs | Partial cross-attention via compressed representations |
Inference Latency | High (100-500ms per pair) | Low (< 10ms per query) | Medium (10-50ms per query) |
Indexing Capability | |||
Scoring Accuracy | Highest (state-of-the-art) | Moderate (approximate matching) | High (near Cross-Encoder quality) |
Scalability to Millions of Documents | |||
Typical Use Case | Re-ranking top-k candidates | First-pass retrieval | Multi-stage retrieval with cached codes |
Computational Complexity | O(n²) over concatenated length | O(n²) per input independently | O(n² + m·k) where k is code count |
Key Characteristics of Cross-Encoders
The defining technical attributes that distinguish Cross-Encoders from Bi-Encoders, explaining their superior accuracy and computational trade-offs in search and ranking systems.
Full Pairwise Self-Attention
Unlike a Bi-Encoder that processes a query and document independently, a Cross-Encoder concatenates the query-document pair into a single input sequence. This allows the Transformer's self-attention mechanism to compute attention weights across every token of both inputs simultaneously. Early token-level interactions enable the model to capture fine-grained semantic relationships, such as exact phrase matching, negation, and term dependency, that are lost when encoding each input in isolation.
Joint Relevance Scoring
The Cross-Encoder outputs a single scalar relevance score (typically passed through a sigmoid or softmax layer) representing the semantic relatedness of the pair. This is fundamentally different from the cosine similarity of independently generated embeddings. The model learns to weigh complex lexical and semantic interactions directly, making it exceptionally effective for tasks requiring precise judgment:
- Passage re-ranking after initial retrieval
- Natural Language Inference (NLI)
- Duplicate question detection
Computational Infeasibility for Indexing
The primary trade-off is quadratic inference cost. Because the Cross-Encoder requires both inputs to be present at runtime, it is impossible to pre-compute document representations offline. For a corpus of N documents, scoring every candidate against a query requires N forward passes through the full Transformer. This makes Cross-Encoders unsuitable for first-stage retrieval over large datasets. They are deployed exclusively as re-rankers on a small candidate set (e.g., top-100 results) pre-filtered by a Bi-Encoder or BM25.
Training with Hard Negatives
To maximize discriminative power, Cross-Encoders are typically fine-tuned using hard negative mining. Training data consists of positive pairs (query, relevant document) and carefully selected negative pairs that are topically similar but irrelevant. This forces the model to learn subtle distinction boundaries. Common training objectives include:
- Binary cross-entropy for relevance/non-relevance classification
- Ranking losses like LambdaRank for listwise optimization Without hard negatives, the model may fail to distinguish between a truly relevant document and one that merely shares keywords.
Asymmetric vs. Symmetric Tasks
Cross-Encoders are highly versatile and can be applied to both asymmetric and symmetric semantic matching. In asymmetric tasks like question-answering, the query and document have different structures and lengths. In symmetric tasks like paraphrase identification, the two inputs are semantically and structurally similar. The architecture adapts naturally because the attention mechanism does not assume any fixed relationship between the two input segments, treating them as a unified token sequence.
Distillation into Bi-Encoders
A common production strategy is to use a Cross-Encoder as a teacher model to distill knowledge into a faster Bi-Encoder student. The Cross-Encoder generates high-quality relevance scores on training triplets, and the Bi-Encoder is trained via MarginMSE or KL-divergence loss to mimic these scores in the embedding space. This transfers much of the Cross-Encoder's accuracy to an indexable architecture, bridging the gap between precision and scalability.
Frequently Asked Questions
Clear, technical answers to the most common questions about Cross-Encoder models, their mechanisms, and their role in modern retrieval pipelines.
A Cross-Encoder is a neural architecture that processes a concatenated pair of inputs—such as a query and a document—simultaneously through full self-attention to generate a single relevance score. Unlike a Bi-Encoder, which encodes each input independently into separate vector representations, the Cross-Encoder allows tokens from both sequences to attend to each other at every transformer layer. This early and complete interaction enables the model to capture fine-grained semantic relationships, lexical overlap, and nuanced contextual signals that independent encoding misses. The architecture typically takes the form [CLS] query [SEP] document [SEP], and the final hidden state of the [CLS] token is passed through a linear classification head to produce a scalar relevance score between 0 and 1. This joint processing is the source of both the Cross-Encoder's superior accuracy and its computational bottleneck.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core concepts for understanding how Cross-Encoders fit into the retrieval and ranking pipeline, including their architectural counterparts and training objectives.
Contrastive Loss
The foundational training objective for Cross-Encoders in retrieval tasks. The model is trained to assign a high relevance score to positive query-document pairs and a low score to negative pairs.
- Binary cross-entropy: Common for pointwise training with labeled relevance data
- Margin ranking loss: Ensures the positive pair score exceeds the negative by a specified margin
- Knowledge distillation: Cross-Encoders can be used as teachers to train faster Bi-Encoders via score distillation
Hard Negative Mining
The strategic selection of deceptively similar but irrelevant documents to train Cross-Encoders. Hard negatives force the model to learn fine-grained distinctions that simple random negatives cannot provide.
- Source: Top-ranked false positives from a Bi-Encoder retrieval pass
- Impact: Dramatically improves the Cross-Encoder's ability to discriminate near-miss candidates
- Dynamic mining: Re-mining hard negatives as the retriever improves during training
Siamese Network
The weight-sharing architectural paradigm that underpins both Bi-Encoders and Cross-Encoders. In a Cross-Encoder, the Siamese structure is implicit—the same transformer processes the concatenated input pair.
- Weight tying: Both inputs are processed by identical parameters before interaction
- Contrast with Bi-Encoder: Cross-Encoder applies Siamese weights but allows early cross-attention
- Training efficiency: Shared weights reduce parameter count and improve generalization
Cosine Similarity
The primary scoring metric for Bi-Encoder outputs, contrasted with the direct relevance logit produced by a Cross-Encoder. While Bi-Encoders measure vector alignment, Cross-Encoders output a calibrated relevance probability.
- Bi-Encoder: score = cos(E_query, E_doc)
- Cross-Encoder: score = σ(W · CLS_token + b)
- Calibration: Cross-Encoder scores are typically better calibrated for threshold-based decision making

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us