bge-reranker-base

Smaller BGE reranker for rescoring top retrieval results with less compute than the larger reranker checkpoints.

BAAI · BGE

Editorial review

Reviewed byOpenSourcesAI EditorialLast updatedAugust 2026SourcesExact model card

Model checkpoints, context windows, provider support, local runtime compatibility, and license terms can change quickly. Verify the exact model card before production or commercial use.

Best for

Builders who want a practical reranking step in RAG or search without adding a heavyweight cross-encoder to every request.

Who should use it

Builders who want a practical reranking step in RAG or search without adding a heavyweight cross-encoder to every request.
Builders who want local or self-hosted testing options.
RAG builders comparing retrieval quality, latency, and multilingual coverage.

Common workflows

Lightweight reranking workflows
reranking workflows
rag workflows
retrieval workflows
semantic search workflows

Deployment and hardware notes

~1.11 GB in fp32 (278M parameters); CPU handles small candidate lists, and a modest GPU keeps pair scoring interactive.

License and usage notes

MIT. Open weights. Verify the exact model card and license terms for the checkpoint or hosted provider you use.

Strengths

Open weights model option for BGE workflows.
Builders who want a practical reranking step in RAG or search without adding a heavyweight cross-encoder to every request.
Feed it (query, passage) pairs from your first-stage retriever; it returns a relevance score per pair and produces no embeddings to store.

Limitations

A cross-encoder scores every query-document pair at query time, so cost scales with the candidate count — rerank a shortlist of 20-100, never the whole corpus. Coverage is strongest on Chinese and English.
~1.11 GB in fp32 (278M parameters); CPU handles small candidate lists, and a modest GPU keeps pair scoring interactive.
Context window and limits: 512 tokens.
Verify the exact model card, provider docs, license, and serving support before production use.

Local workflow notes

Feed it (query, passage) pairs from your first-stage retriever; it returns a relevance score per pair and produces no embeddings to store.

Local runtimes: Ollama where supported, LM Studio where supported, llama.cpp where supported, Transformers

Platforms: Windows, macOS, Linux

Reranker spec

Memory~1.11 GB in fp32 (278M parameters) · ~0.56 GB in fp16OutputRelevance score per query-passage pair (a cross-encoder emits no vectors)Max input512 tokens

The lighter of the two classic BGE rerankers. Its 512-token pair limit covers the query and the passage together, so long chunks get truncated at scoring time even if your embedder indexed them whole.