BGE Reranker v2 M3 is a multilingual relevance model built on BGE-M3. It receives a query and a candidate passage together and returns a score for their relationship. BAAI positions this edition as an efficient multilingual reranker, including for Chinese and English retrieval, where a search application needs to refine an existing list of candidates.
A cross-encoder processes both texts jointly, allowing their content to interact before the relevance score is produced. This differs from an embedding model, which encodes texts independently for reusable vector comparison. The reranker’s output is a scalar score for a particular pair, rather than a document vector or a written answer.
Use the model after an initial search has selected plausible passages. Pair the question with each candidate and order the candidates by the resulting scores. This focuses the more detailed comparison on a manageable shortlist instead of asking a cross-encoder to inspect every passage in a large collection.
The maker identifies BGE-M3 as the base model and lists multilingual support as a principal feature. Within its v2 reranker family, M3 is the efficient multilingual option; the Gemma-based and layer-selection variants are distinct models with different implementation choices. The name M3 here does not mean the reranker returns the dense, sparse and multi-vector embeddings of the original embedding model.
This distinction matters when choosing the result your application requires. Select an embedding model to represent and search a document collection. Select this reranker when you already have candidate text and need to decide which passage is most relevant to the current query.
Provide the actual question and the complete candidate text needed to interpret it. Preserve headings or nearby definitions when they determine the meaning of a passage. In the published Transformers example, the query and passage are tokenised together with truncation and max_length=512. That is an example setting rather than a model-wide limit. Keep the question and required evidence within the selected pair budget, and check what truncation removes. A result mentioning the same product as a query can still be irrelevant if it addresses the wrong operation or condition; prepare examples that distinguish those cases when evaluating retrieval quality.
For a document assistant, keep candidate identifiers alongside their text, score the question–passage pairs and pass the selected original passages to the answering step. The answering model then receives the evidence rather than a relevance score without its source. This is an illustrative retrieval workflow; the reranker itself neither searches an external collection nor writes the answer.
The manufacturer returns raw relevance scores, with a higher value indicating a closer match. Its documented optional normalisation applies a sigmoid function to place the score between 0 and 1. A normalised score has a convenient range, but that transformation alone does not establish a calibrated probability that the candidate is correct.
Choose ranking or filtering thresholds using representative query–passage pairs from your workload. Include passages that share keywords but answer a different question, as well as relevant passages with different wording. This makes the selected threshold meaningful for the collection being searched.
For an Ailoot API project, define what the final context should contain and how many candidates can be examined efficiently. The useful result is a better ordered evidence set for the next application step. Keep this edition’s relevance output separate from document embeddings, generated prose and the layer-selection controls documented for other rerankers.
", "aboutText": "BGE Reranker v2 M3 is a multilingual relevance model built on BGE-M3. It receives a query and a candidate passage together and returns a score for their relationship. BAAI positions this edition as an efficient multilingual reranker, including for Chinese and English retrieval, where a search application needs to refine an existing list of candidates.\n\n### Relevance from a query–passage pair\n\nA cross-encoder processes both texts jointly, allowing their content to interact before the relevance score is produced. This differs from an embedding model, which encodes texts independently for reusable vector comparison. The reranker’s output is a scalar score for a particular pair, rather than a document vector or a written answer.\n\nUse the model after an initial search has selected plausible passages. Pair the question with each candidate and order the candidates by the resulting scores. This focuses the more detailed comparison on a manageable shortlist instead of asking a cross-encoder to inspect every passage in a large collection.\n\n### The v2 M3 edition\n\nThe maker identifies BGE-M3 as the base model and lists multilingual support as a principal feature. Within its v2 reranker family, M3 is the efficient multilingual option; the Gemma-based and layer-selection variants are distinct models with different implementation choices. The name M3 here does not mean the reranker returns the dense, sparse and multi-vector embeddings of the original embedding model.\n\nThis distinction matters when choosing the result your application requires. Select an embedding model to represent and search a document collection. Select this reranker when you already have candidate text and need to decide which passage is most relevant to the current query.\n\n### Preparing candidates that can be ranked usefully\n\nProvide the actual question and the complete candidate text needed to interpret it. Preserve headings or nearby definitions when they determine the meaning of a passage. In the published Transformers example, the query and passage are tokenised together with truncation and max_length=512. That is an example setting rather than a model-wide limit. Keep the question and required evidence within the selected pair budget, and check what truncation removes. A result mentioning the same product as a query can still be irrelevant if it addresses the wrong operation or condition; prepare examples that distinguish those cases when evaluating retrieval quality.\n\nFor a document assistant, keep candidate identifiers alongside their text, score the question–passage pairs and pass the selected original passages to the answering step. The answering model then receives the evidence rather than a relevance score without its source. This is an illustrative retrieval workflow; the reranker itself neither searches an external collection nor writes the answer.\n\n### Reading and normalising scores\n\nThe manufacturer returns raw relevance scores, with a higher value indicating a closer match. Its documented optional normalisation applies a sigmoid function to place the score between 0 and 1. A normalised score has a convenient range, but that transformation alone does not establish a calibrated probability that the candidate is correct.\n\nChoose ranking or filtering thresholds using representative query–passage pairs from your workload. Include passages that share keywords but answer a different question, as well as relevant passages with different wording. This makes the selected threshold meaningful for the collection being searched.\n\nFor an Ailoot API project, define what the final context should contain and how many candidates can be examined efficiently. The useful result is a better ordered evidence set for the next application step. Keep this edition’s relevance output separate from document embeddings, generated prose and the layer-selection controls documented for other rerankers.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "6f457b5327ea49a5dc4aeaf91c0a130f2f818d3ecf24fbcc5e414dfb77353fd6", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "bge-reranker-v2-m3BAAI’s multilingual cross-encoder for ranking candidate passages against a query. It reads each query–passage pair together and returns a relevance score, refining a search shortlist without generating an answer or creating document embeddings.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
BGE Reranker v2 M3 is a multilingual relevance model built on BGE-M3. It receives a query and a candidate passage together and returns a score for their relationship. BAAI positions this edition as an efficient multilingual reranker, including for Chinese and English retrieval, where a search application needs to refine an existing list of candidates.
A cross-encoder processes both texts jointly, allowing their content to interact before the relevance score is produced. This differs from an embedding model, which encodes texts independently for reusable vector comparison. The reranker’s output is a scalar score for a particular pair, rather than a document vector or a written answer.
Use the model after an initial search has selected plausible passages. Pair the question with each candidate and order the candidates by the resulting scores. This focuses the more detailed comparison on a manageable shortlist instead of asking a cross-encoder to inspect every passage in a large collection.
The maker identifies BGE-M3 as the base model and lists multilingual support as a principal feature. Within its v2 reranker family, M3 is the efficient multilingual option; the Gemma-based and layer-selection variants are distinct models with different implementation choices. The name M3 here does not mean the reranker returns the dense, sparse and multi-vector embeddings of the original embedding model.
This distinction matters when choosing the result your application requires. Select an embedding model to represent and search a document collection. Select this reranker when you already have candidate text and need to decide which passage is most relevant to the current query.
Provide the actual question and the complete candidate text needed to interpret it. Preserve headings or nearby definitions when they determine the meaning of a passage. In the published Transformers example, the query and passage are tokenised together with truncation and max_length=512. That is an example setting rather than a model-wide limit. Keep the question and required evidence within the selected pair budget, and check what truncation removes. A result mentioning the same product as a query can still be irrelevant if it addresses the wrong operation or condition; prepare examples that distinguish those cases when evaluating retrieval quality.
For a document assistant, keep candidate identifiers alongside their text, score the question–passage pairs and pass the selected original passages to the answering step. The answering model then receives the evidence rather than a relevance score without its source. This is an illustrative retrieval workflow; the reranker itself neither searches an external collection nor writes the answer.
The manufacturer returns raw relevance scores, with a higher value indicating a closer match. Its documented optional normalisation applies a sigmoid function to place the score between 0 and 1. A normalised score has a convenient range, but that transformation alone does not establish a calibrated probability that the candidate is correct.
Choose ranking or filtering thresholds using representative query–passage pairs from your workload. Include passages that share keywords but answer a different question, as well as relevant passages with different wording. This makes the selected threshold meaningful for the collection being searched.
For an Ailoot API project, define what the final context should contain and how many candidates can be examined efficiently. The useful result is a better ordered evidence set for the next application step. Keep this edition’s relevance output separate from document embeddings, generated prose and the layer-selection controls documented for other rerankers.
POST /v1/reranktextrerank| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits bge-reranker-v2-m3 | Default— |
Fieldquery | Typestring | RequirementOptional | Values & limits | Default— |
Fielddocuments | Typearray | RequirementRequired | Values & limits | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, documents |
Parametermaterial_types | Contracttext |
Parametermaterial_conditions | ContractSet your actual query and nonempty array of original text documents. Result indices refer to that original array. |
Lifecycle: synchronous_result_then_owned_library
GET /v1/media/assets/{asset_id}/content
GET /v1/media/assets
GET /v1/media/assets/{asset_id}
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Billing unit | Charge |
|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Billing unit— | Charge Input · Input tokens — / 1K tokens Output · Output tokens — / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| Configurationtotal token | Rate schedule— | Billing unit/ 1K tokens | Charge Input · total token $0.00004 / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_QUERY:?Set the actual documented input value}"\nexport AILOOT_QUERY\n: "${AILOOT_DOCUMENTS_JSON:?Set the actual documented input value}"\nexport AILOOT_DOCUMENTS_JSON\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\nrequest={'model': 'bge-reranker-v2-m3', 'query': '${ACTUAL_QUERY}', 'documents': '${ACTUAL_DOCUMENTS}'}\nrequest['query']=os.environ['AILOOT_QUERY']\nrequest['documents']=json.loads(os.environ['AILOOT_DOCUMENTS_JSON'])\nPath('request.json').write_text(json.dumps(request,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/rerank \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o response.bin\n# Retain the complete response and headers, every actual output, original returned identifiers and all usage fields. Recover the original operation without submitting creation again.\nComplete original native JSON result with the configured response model, original document indices, relevance scores, document strings and native token usage. Retain every actual result and usage field.
GET /v1/media/assets/{asset_id}/contentGET /v1/media/assetsGET /v1/media/assets/{asset_id}Keep every complete returned response, file and content part.
Retain the complete response and headers, every actual output, original returned identifiers and all usage fields. Recover the original operation without submitting creation again.
Retain the actual X-Client-Request-ID and complete response. Read the original owned assets and their exact signed content URLs; never resubmit an uncertain creation.
| Field | Type | Meaning |
|---|---|---|
Fieldmodel | Typestring | MeaningExact response model required by the configured Source consumer. |
Fieldresults[].index | Typeinteger | MeaningUnique original input document index. |
Fieldresults[].relevance_score | Typenumber | MeaningFinite relevance score. |
Fieldresults[].document | Typestring | MeaningOriginal text document required by this configured response consumer. |
Fieldusage.total_tokens | Typeinteger | MeaningFinite nonnegative native token count required by the current accepted tariff. |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionThe JSON body or explicit canonical model ID is invalid. | Next stepRetain the response and correct the indicated request field. |
Response401 · authentication_error | ConditionThe Ailoot API key is invalid. | Next stepUse your authorized Ailoot API key. |
Response403 · permission_error | ConditionThe key group does not admit this method. | Next stepRetain the returned error details. |
Response404 · not_found_error | ConditionThe selected method has no admitted route. | Next stepRetain the returned error details. |
Response422 · price_unavailable | ConditionThe accepted tariff cannot obtain its required input quantity or bound. | Next stepRetain the response; use the input representation required by the accepted tariff. |
Response503 · | ConditionRequired storage, route, method price or reservation is unavailable. | Next stepKeep the complete original response. An uncertain reservation is not permission to resubmit. |
Response502 · billing_requires_check | ConditionThe original result, usage or settlement requires checking. | Next stepRetain the actual request ID and original response. Read the existing owned record; do not resubmit creation. |
Ailoot Ultra bge-reranker-v2-m3
Use the method paths shown above.