Jina Reranker v2 Base Multilingual is a text-ranking model for the second stage of retrieval. Give it a query and candidate documents or passages; it evaluates each query–document pair and returns a relevance score. The useful result is a better-ordered candidate set for search or a retrieval-augmented workflow. It does not write the answer to the query or create document embeddings.
Write the query so that it states the information need. Then provide the texts that an earlier retrieval step has found. Keep a stable identifier beside each candidate so that its relevance score can be connected to the original document, section or record.
For a support search, use the actual question and candidate excerpts that contain the relevant procedure. A query about resetting a particular device should be paired with passages that retain the device name, version and reset conditions. A passage that merely mentions the device can be less useful than one that explains the requested operation. Supply the content the model needs to compare, rather than only a document title.
Use coherent passages. A table heading, definition or exception can change how a paragraph relates to the query, so do not remove it merely to make every candidate equally short. The reranker evaluates supplied candidates; it cannot recover a relevant document that the earlier retrieval stage omitted.
This is a cross-encoder: the query and a candidate text are processed together. The direct scoring interface returns a floating-point relevance score for each corresponding pair. Higher scores indicate greater relevance in that comparison. The score is a ranking signal, rather than a generated explanation or proof that the document is true.
The maker also provides a reranking helper that returns ordered documents with their scores. A top-result control selects how many ranked candidates to retain. Preserve their identifiers and text when passing them into the next stage. For a question-answering workflow, the following model still needs the query and the selected evidence; the ranked list itself is not an answered question.
When comparing retrieval changes, keep the query and evaluation criteria fixed. Inspect whether the passages promoted to the top actually contain the requested information. Set any filtering threshold using examples from your own collection, instead of treating a relevance score as a universal measure of answer correctness.
The model supports a context length of up to 1,024 tokens. Its documented rerank() helper handles longer documents with a sliding-window approach, scores the pieces separately and combines them into document-level results. Chunking is behavior of that helper; it should not be confused with a single model input that has an unlimited context window.
The helper exposes query-length and chunk-length controls and an overlap setting. Its documented default overlap is 80. The published usage example specifies a maximum query length of 512 and a chunk length of 1,024; these are example helper settings that should be kept distinct from a promise that every caller or route uses them.
For a long manual, retain enough nearby text for an instruction and its conditions to appear together. When assessing the result, inspect the relevant portion of a highly ranked document rather than assuming that every section of it answers the query equally well.
The v2 model is multilingual. The maker's examples rank English queries against English, German, Spanish, Chinese and Japanese passages. This supports a collection where relevant material is written in several languages without requiring every candidate to be translated into the query's language first.
The documented task scope also includes code retrieval and ranking text representations related to functions or SQL. These remain relevance-ranking tasks: the model evaluates the supplied text. It does not execute a function, run SQL or produce a tool result merely because those kinds of candidates appear in the retrieval set.
Keep this v2 Base Multilingual profile separate from Jina's earlier English-only reranker, Jina Reranker v3 and multimodal reranking profiles. They are different models with different task and input characteristics. This profile's input is query–text pairs; image or video content needs its own suitable representation or model.
The maker's reference implementation supports direct scores and a document-ranking helper, with optional accelerated attention. Those implementation choices affect the way inputs are prepared and processed; they do not establish that every integration exposes identical controls.
Use the ranked output for multilingual search, support knowledge bases, document retrieval and evidence selection before generation. Review the top passages, keep the original candidate mapping and distinguish relevance from factual validity. A useful retrieval result brings the right supplied evidence forward while leaving the next task—answering, summarizing or deciding—to the appropriate workflow.
", "aboutText": "Jina Reranker v2 Base Multilingual is a text-ranking model for the second stage of retrieval. Give it a query and candidate documents or passages; it evaluates each query–document pair and returns a relevance score. The useful result is a better-ordered candidate set for search or a retrieval-augmented workflow. It does not write the answer to the query or create document embeddings.\n\n### Prepare the query and the candidate passages\n\nWrite the query so that it states the information need. Then provide the texts that an earlier retrieval step has found. Keep a stable identifier beside each candidate so that its relevance score can be connected to the original document, section or record.\n\nFor a support search, use the actual question and candidate excerpts that contain the relevant procedure. A query about resetting a particular device should be paired with passages that retain the device name, version and reset conditions. A passage that merely mentions the device can be less useful than one that explains the requested operation. Supply the content the model needs to compare, rather than only a document title.\n\nUse coherent passages. A table heading, definition or exception can change how a paragraph relates to the query, so do not remove it merely to make every candidate equally short. The reranker evaluates supplied candidates; it cannot recover a relevant document that the earlier retrieval stage omitted.\n\n### Query–document scoring\n\nThis is a cross-encoder: the query and a candidate text are processed together. The direct scoring interface returns a floating-point relevance score for each corresponding pair. Higher scores indicate greater relevance in that comparison. The score is a ranking signal, rather than a generated explanation or proof that the document is true.\n\nThe maker also provides a reranking helper that returns ordered documents with their scores. A top-result control selects how many ranked candidates to retain. Preserve their identifiers and text when passing them into the next stage. For a question-answering workflow, the following model still needs the query and the selected evidence; the ranked list itself is not an answered question.\n\nWhen comparing retrieval changes, keep the query and evaluation criteria fixed. Inspect whether the passages promoted to the top actually contain the requested information. Set any filtering threshold using examples from your own collection, instead of treating a relevance score as a universal measure of answer correctness.\n\n### Model window and longer documents\n\nThe model supports a context length of up to 1,024 tokens. Its documented `rerank()` helper handles longer documents with a sliding-window approach, scores the pieces separately and combines them into document-level results. Chunking is behavior of that helper; it should not be confused with a single model input that has an unlimited context window.\n\nThe helper exposes query-length and chunk-length controls and an overlap setting. Its documented default overlap is 80. The published usage example specifies a maximum query length of 512 and a chunk length of 1,024; these are example helper settings that should be kept distinct from a promise that every caller or route uses them.\n\nFor a long manual, retain enough nearby text for an instruction and its conditions to appear together. When assessing the result, inspect the relevant portion of a highly ranked document rather than assuming that every section of it answers the query equally well.\n\n### Multilingual and specialized text retrieval\n\nThe v2 model is multilingual. The maker's examples rank English queries against English, German, Spanish, Chinese and Japanese passages. This supports a collection where relevant material is written in several languages without requiring every candidate to be translated into the query's language first.\n\nThe documented task scope also includes code retrieval and ranking text representations related to functions or SQL. These remain relevance-ranking tasks: the model evaluates the supplied text. It does not execute a function, run SQL or produce a tool result merely because those kinds of candidates appear in the retrieval set.\n\n### Edition and practical limits\n\nKeep this v2 Base Multilingual profile separate from Jina's earlier English-only reranker, Jina Reranker v3 and multimodal reranking profiles. They are different models with different task and input characteristics. This profile's input is query–text pairs; image or video content needs its own suitable representation or model.\n\nThe maker's reference implementation supports direct scores and a document-ranking helper, with optional accelerated attention. Those implementation choices affect the way inputs are prepared and processed; they do not establish that every integration exposes identical controls.\n\nUse the ranked output for multilingual search, support knowledge bases, document retrieval and evidence selection before generation. Review the top passages, keep the original candidate mapping and distinguish relevance from factual validity. A useful retrieval result brings the right supplied evidence forward while leaving the next task—answering, summarizing or deciding—to the appropriate workflow.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "4ec636a9c226088c030961d6b1394eb7efce8b68a002c47e826147513e9f5b05", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "jina-reranker-v2-base-multilingualJina Reranker v2 Base Multilingual scores a query against candidate texts and orders them by relevance. Its cross-encoder handles multilingual retrieval, while the maker's reranking helper chunks longer documents around a 1,024-token model window.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Jina Reranker v2 Base Multilingual is a text-ranking model for the second stage of retrieval. Give it a query and candidate documents or passages; it evaluates each query–document pair and returns a relevance score. The useful result is a better-ordered candidate set for search or a retrieval-augmented workflow. It does not write the answer to the query or create document embeddings.
Write the query so that it states the information need. Then provide the texts that an earlier retrieval step has found. Keep a stable identifier beside each candidate so that its relevance score can be connected to the original document, section or record.
For a support search, use the actual question and candidate excerpts that contain the relevant procedure. A query about resetting a particular device should be paired with passages that retain the device name, version and reset conditions. A passage that merely mentions the device can be less useful than one that explains the requested operation. Supply the content the model needs to compare, rather than only a document title.
Use coherent passages. A table heading, definition or exception can change how a paragraph relates to the query, so do not remove it merely to make every candidate equally short. The reranker evaluates supplied candidates; it cannot recover a relevant document that the earlier retrieval stage omitted.
This is a cross-encoder: the query and a candidate text are processed together. The direct scoring interface returns a floating-point relevance score for each corresponding pair. Higher scores indicate greater relevance in that comparison. The score is a ranking signal, rather than a generated explanation or proof that the document is true.
The maker also provides a reranking helper that returns ordered documents with their scores. A top-result control selects how many ranked candidates to retain. Preserve their identifiers and text when passing them into the next stage. For a question-answering workflow, the following model still needs the query and the selected evidence; the ranked list itself is not an answered question.
When comparing retrieval changes, keep the query and evaluation criteria fixed. Inspect whether the passages promoted to the top actually contain the requested information. Set any filtering threshold using examples from your own collection, instead of treating a relevance score as a universal measure of answer correctness.
The model supports a context length of up to 1,024 tokens. Its documented rerank() helper handles longer documents with a sliding-window approach, scores the pieces separately and combines them into document-level results. Chunking is behavior of that helper; it should not be confused with a single model input that has an unlimited context window.
The helper exposes query-length and chunk-length controls and an overlap setting. Its documented default overlap is 80. The published usage example specifies a maximum query length of 512 and a chunk length of 1,024; these are example helper settings that should be kept distinct from a promise that every caller or route uses them.
For a long manual, retain enough nearby text for an instruction and its conditions to appear together. When assessing the result, inspect the relevant portion of a highly ranked document rather than assuming that every section of it answers the query equally well.
The v2 model is multilingual. The maker's examples rank English queries against English, German, Spanish, Chinese and Japanese passages. This supports a collection where relevant material is written in several languages without requiring every candidate to be translated into the query's language first.
The documented task scope also includes code retrieval and ranking text representations related to functions or SQL. These remain relevance-ranking tasks: the model evaluates the supplied text. It does not execute a function, run SQL or produce a tool result merely because those kinds of candidates appear in the retrieval set.
Keep this v2 Base Multilingual profile separate from Jina's earlier English-only reranker, Jina Reranker v3 and multimodal reranking profiles. They are different models with different task and input characteristics. This profile's input is query–text pairs; image or video content needs its own suitable representation or model.
The maker's reference implementation supports direct scores and a document-ranking helper, with optional accelerated attention. Those implementation choices affect the way inputs are prepared and processed; they do not establish that every integration exposes identical controls.
Use the ranked output for multilingual search, support knowledge bases, document retrieval and evidence selection before generation. Review the top passages, keep the original candidate mapping and distinguish relevance from factual validity. A useful retrieval result brings the right supplied evidence forward while leaving the next task—answering, summarizing or deciding—to the appropriate workflow.
POST /v1/reranktextrerank| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits jina-reranker-v2-base-multilingual | 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.0001 / 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': 'jina-reranker-v2-base-multilingual', '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 jina-reranker-v2-base-multilingual
Use the method paths shown above.