bge-reranker-v2-m3

Name: bge-reranker-v2-m3
Author: BAAI

by BAAI

The cross-encoder behind Mixpeek's rerank stage, and the most-downloaded reranker on HuggingFace

568Mparams

HuggingFace Run it on your own data, free

Identifiers

Model ID

BAAI/bge-reranker-v2-m3

Feature URI

Overview

A reranker does not produce a vector. It takes a query and a document together and returns one number, how relevant that document is to that query. That is why it cannot be an ingest-time extractor and lives in the retriever instead: it needs the query, which does not exist until someone searches.

Mixpeek's rerank stage runs this model by default. A first stage retrieves a wide candidate set by vector similarity, cheaply and approximately, and the reranker reorders the top of it by reading the query and document together. The precision gain comes from the cross-attention that a bi-encoder gives up in exchange for being able to precompute.

At 18.1 million monthly downloads it is the most-used reranker on HuggingFace, and it is multilingual, built on bge-m3 rather than an English-only backbone.

Architecture

XLM-RoBERTa-large for sequence classification, 567,755,777 parameters, initialised from bge-m3. Input is a concatenated query and passage pair; output is a single logit that a sigmoid maps into [0, 1]. Because it reads both sides at once it cannot precompute document representations, which is what makes it accurate and what makes it a second stage rather than a first.

Mixpeek SDK Integration

import { Mixpeek } from "mixpeek";

const mx = new Mixpeek({ apiKey: "API_KEY" });

// A reranker is a retriever STAGE, not an extractor, because it needs the query.
// inference_name defaults to this model, so the parameter below is written out
// only to show what is running. Contract read from GET /v1/discovery/stages.
const retriever = await mx.retrievers.create({
  namespace_id: "my-namespace",
  retriever_name: "search-then-rerank",
  stages: [
    {
      stage_name: "candidates",
      stage_id: "feature_search",
      parameters: { limit: 100 },
    },
    {
      stage_name: "rerank_results",
      stage_id: "rerank",
      parameters: {
        inference_name: "BAAI__bge_reranker_v2_m3",
        query: "{{INPUT.query}}",
        document_field: "content",
        top_k: 10,
      },
    },
  ],
});

Capabilities

Direct query-document relevance scoring rather than an embedding
Multilingual, inherited from the bge-m3 backbone
Score maps to [0, 1] through a sigmoid for thresholding
Reorders a shortlist that a vector stage retrieved

Use Cases on Mixpeek

Second-stage precision on top of feature_search in a Mixpeek retriever

Cutting a 100-candidate recall set down to the 10 that get shown

Multilingual search where the first stage retrieves across languages

Any pipeline where recall is fine and the top of the list is not

Performance

Input SizeVariable

GPU LatencyInput dependent

GPU ThroughputBatch dependent

GPU MemoryModel dependent

Mixpeek's rerank stage sends at most max_document_chars of each document, default 2,000, in batches of 32 with up to 3 concurrent batches. Those are the knobs that decide the stage's latency, and they are stage parameters rather than properties of the model.

Common Pipeline Companions

intfloat/multilingual-e5-large-instruct

First-stage retrieval this model then rescores

BAAI/bge-m3

The backbone it was initialised from

Qwen/Qwen3-Embedding-8B

Alternative first stage when English quality dominates

Frequently Asked Questions

Why is reranking a retriever stage and not an extractor?

Because it needs the query. An extractor runs at ingest, when nobody has searched yet, and can only produce something that does not depend on a query, which for retrieval means a vector. A cross-encoder scores a pair, so it can only run once a query exists. That is the whole architectural difference, and it is why no amount of configuration will let you set a reranker as a collection's feature extractor.

How many candidates should the first stage return?

Enough that the right answer is somewhere in the set, because the reranker can only reorder what it is handed. 100 into 10 is a reasonable default. The cost is linear in candidates: Mixpeek batches 32 at a time with up to 3 batches concurrent, so 100 candidates is four batches. Raising the limit past the point where recall stops improving buys latency and nothing else.

Can I point the stage at a different reranker?

Yes, two ways. inference_name selects another reranking inference service Mixpeek hosts. feature_uri points at a custom reranker plugin, which is the path for a model of your own and is an Enterprise capability. What you cannot do is pass an arbitrary Hugging Face id and have it served.

Why does only the first 2,000 characters of a document get scored?

max_document_chars defaults to 2,000 because the cross-encoder tokenizer truncates at roughly 512 tokens regardless, so sending more costs bandwidth and buys nothing. The consequence worth planning for is that relevance living late in a long document is invisible to the reranker. Chunk documents so the scored span is the span that matters.

Is a reranker worth the latency?

It depends on whether your problem is recall or precision. If the right answer is not in the candidate set, a reranker cannot help and the fix is upstream. If the right answer is in the set at rank 40, that is exactly what a cross-encoder repairs. Measure where the answer currently lands before adding the stage; on a pipeline that already puts it at rank 1, this is latency for nothing.