rerank-2.5-lite is the lightweight member of Voyage AI's 2.5 reranker release. The manufacturer describes it as a generalist model balancing latency and relevance quality, with natural-language instruction following and multilingual support. Its input is a query and candidate texts, and its output is a refined order of those candidates with relevance scores.
The Lite model jointly processes each query–document pair as a cross-encoder. It can follow a first-stage embedding or lexical search, refining the passages that stage selected. This differs from preparing a reusable embedding index: the reranker examines the submitted query and document text together for the current relevance decision.
For an interactive help search, submit the candidate explanations that might answer the user's question. Keep enough of each passage to convey the behavior and its qualifications, and preserve the association between the input index and source item. A focused candidate set helps make the reranking task clear while leaving the retrieved evidence usable for display or a later answer.
Like rerank-2.5, Lite accepts natural-language instructions before or after the query. The maker's examples use them to emphasize document components, select a preferred source type or add context to an ambiguous word. An application can provide a standing relevance preference, or the current question can include a more specific one.
An illustrative support query can ask which passage explains an error, with an instruction to prioritize troubleshooting steps over general product descriptions. A document search can ask for original policy wording rather than a discussion of the policy. Describe the intended evidence and keep the instruction concise. Instructions influence relevance scores; prepare any strict version, date or permission restrictions in the candidate selection rather than treating a relevance preference as a guaranteed filter.
The output is sorted by decreasing relevance. Each result includes the original document index and a floating-point score; the optional return-documents setting also returns the corresponding input text. The top-k option determines the number of leading results returned, while omitting it returns the ranking for all submitted candidates.
Use those indices to recover the source passage and its identifier. A reranked candidate can become a search result or evidence for the next RAG step, but the output is an ordering of provided text rather than a rewritten answer. Evaluate whether the leading passages satisfy both the question and the relevance instruction, including on the languages and document types actually present in the collection.
The 2.5 Lite edition has a documented 8,000-token query maximum and a 32,000-token limit for the query plus each individual document. It is distinct from the earlier rerank-2-lite model and its smaller context. At most 1,000 documents can be submitted, and total input is limited to 600,000 tokens under the formula: query tokens multiplied by candidate count, plus the sum of candidate-document tokens.
For latency-sensitive use, the maker's FAQ recommends rerank-2.5-lite with no more than 200,000 total tokens per request. This is practical guidance below the stated maximum, not a different per-document window. A longer query or instruction is counted once for every candidate pair, so candidate count and query length both affect the total.
Truncation is enabled by default and shortens over-length query/document input to fit; disabling it returns an error for an over-length query or pair. Prepare compact, answer-bearing candidates deliberately so useful evidence is not left beyond a truncated boundary. Selecting fewer output results through top-k does not remove the other supplied candidates from the token calculation. Inspect the returned source passages and refine input preparation around the actual questions the search interface needs to answer.
", "aboutText": "rerank-2.5-lite is the lightweight member of Voyage AI's 2.5 reranker release. The manufacturer describes it as a generalist model balancing latency and relevance quality, with natural-language instruction following and multilingual support. Its input is a query and candidate texts, and its output is a refined order of those candidates with relevance scores.\n\n### A lightweight second-stage relevance decision\n\nThe Lite model jointly processes each query–document pair as a cross-encoder. It can follow a first-stage embedding or lexical search, refining the passages that stage selected. This differs from preparing a reusable embedding index: the reranker examines the submitted query and document text together for the current relevance decision.\n\nFor an interactive help search, submit the candidate explanations that might answer the user's question. Keep enough of each passage to convey the behavior and its qualifications, and preserve the association between the input index and source item. A focused candidate set helps make the reranking task clear while leaving the retrieved evidence usable for display or a later answer.\n\n### Instructions express what the user wants prioritized\n\nLike rerank-2.5, Lite accepts natural-language instructions before or after the query. The maker's examples use them to emphasize document components, select a preferred source type or add context to an ambiguous word. An application can provide a standing relevance preference, or the current question can include a more specific one.\n\nAn illustrative support query can ask which passage explains an error, with an instruction to prioritize troubleshooting steps over general product descriptions. A document search can ask for original policy wording rather than a discussion of the policy. Describe the intended evidence and keep the instruction concise. Instructions influence relevance scores; prepare any strict version, date or permission restrictions in the candidate selection rather than treating a relevance preference as a guaranteed filter.\n\n### Read the ranking and return the source passage\n\nThe output is sorted by decreasing relevance. Each result includes the original document index and a floating-point score; the optional return-documents setting also returns the corresponding input text. The top-k option determines the number of leading results returned, while omitting it returns the ranking for all submitted candidates.\n\nUse those indices to recover the source passage and its identifier. A reranked candidate can become a search result or evidence for the next RAG step, but the output is an ordering of provided text rather than a rewritten answer. Evaluate whether the leading passages satisfy both the question and the relevance instruction, including on the languages and document types actually present in the collection.\n\n### Limits and a practical candidate budget\n\nThe 2.5 Lite edition has a documented 8,000-token query maximum and a 32,000-token limit for the query plus each individual document. It is distinct from the earlier rerank-2-lite model and its smaller context. At most 1,000 documents can be submitted, and total input is limited to 600,000 tokens under the formula: query tokens multiplied by candidate count, plus the sum of candidate-document tokens.\n\nFor latency-sensitive use, the maker's FAQ recommends rerank-2.5-lite with no more than 200,000 total tokens per request. This is practical guidance below the stated maximum, not a different per-document window. A longer query or instruction is counted once for every candidate pair, so candidate count and query length both affect the total.\n\nTruncation is enabled by default and shortens over-length query/document input to fit; disabling it returns an error for an over-length query or pair. Prepare compact, answer-bearing candidates deliberately so useful evidence is not left beyond a truncated boundary. Selecting fewer output results through top-k does not remove the other supplied candidates from the token calculation. Inspect the returned source passages and refine input preparation around the actual questions the search interface needs to answer.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "25643989737813a45686da6d97f9a40c4af1868f47888d38b1e304784b6d9618", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "voyageai/rerank-2.5-litererank-2.5-lite is Voyage AI’s latency-oriented instruction-following reranker for a supplied text candidate set. It retains a 32,000-token query–document context and multilingual support, returning an ordered list of relevance scores and original document indices.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
rerank-2.5-lite is the lightweight member of Voyage AI's 2.5 reranker release. The manufacturer describes it as a generalist model balancing latency and relevance quality, with natural-language instruction following and multilingual support. Its input is a query and candidate texts, and its output is a refined order of those candidates with relevance scores.
The Lite model jointly processes each query–document pair as a cross-encoder. It can follow a first-stage embedding or lexical search, refining the passages that stage selected. This differs from preparing a reusable embedding index: the reranker examines the submitted query and document text together for the current relevance decision.
For an interactive help search, submit the candidate explanations that might answer the user's question. Keep enough of each passage to convey the behavior and its qualifications, and preserve the association between the input index and source item. A focused candidate set helps make the reranking task clear while leaving the retrieved evidence usable for display or a later answer.
Like rerank-2.5, Lite accepts natural-language instructions before or after the query. The maker's examples use them to emphasize document components, select a preferred source type or add context to an ambiguous word. An application can provide a standing relevance preference, or the current question can include a more specific one.
An illustrative support query can ask which passage explains an error, with an instruction to prioritize troubleshooting steps over general product descriptions. A document search can ask for original policy wording rather than a discussion of the policy. Describe the intended evidence and keep the instruction concise. Instructions influence relevance scores; prepare any strict version, date or permission restrictions in the candidate selection rather than treating a relevance preference as a guaranteed filter.
The output is sorted by decreasing relevance. Each result includes the original document index and a floating-point score; the optional return-documents setting also returns the corresponding input text. The top-k option determines the number of leading results returned, while omitting it returns the ranking for all submitted candidates.
Use those indices to recover the source passage and its identifier. A reranked candidate can become a search result or evidence for the next RAG step, but the output is an ordering of provided text rather than a rewritten answer. Evaluate whether the leading passages satisfy both the question and the relevance instruction, including on the languages and document types actually present in the collection.
The 2.5 Lite edition has a documented 8,000-token query maximum and a 32,000-token limit for the query plus each individual document. It is distinct from the earlier rerank-2-lite model and its smaller context. At most 1,000 documents can be submitted, and total input is limited to 600,000 tokens under the formula: query tokens multiplied by candidate count, plus the sum of candidate-document tokens.
For latency-sensitive use, the maker's FAQ recommends rerank-2.5-lite with no more than 200,000 total tokens per request. This is practical guidance below the stated maximum, not a different per-document window. A longer query or instruction is counted once for every candidate pair, so candidate count and query length both affect the total.
Truncation is enabled by default and shortens over-length query/document input to fit; disabling it returns an error for an over-length query or pair. Prepare compact, answer-bearing candidates deliberately so useful evidence is not left beyond a truncated boundary. Selecting fewer output results through top-k does not remove the other supplied candidates from the token calculation. Inspect the returned source passages and refine input preparation around the actual questions the search interface needs to answer.
POST /v1/reranktextrerank| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fielddocuments | Typearray | RequirementRequired | Values & limits | Default— |
Fieldmodel | Typestring | RequirementRequired | Values & limits voyageai/rerank-2.5-lite | Default— |
Fieldprovider | Typeschema | RequirementOptional | Values & limits | Default— |
Fieldquery | Typestring | RequirementRequired | Values & limits | Default— |
Fieldsession_id | Typestring | RequirementOptional | Values & limits | Default— |
Fieldtop_n | Typeinteger | RequirementOptional | Values & limits Minimum: 1 | Default— |
Fieldtrace | Typeschema | RequirementOptional | Values & limits | Default— |
Fielduser | Typestring | RequirementOptional | Values & limits | Default— |
Fielddocuments[].text | Typestring | RequirementOptional | Values & limits | Default— |
Fielddocuments[].image | Typestring | RequirementOptional | Values & limits | Default— |
text_rerank · Required: query, documents array with minItems1
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, query, documents |
Parametermaterial_types | Contracttext |
Parameteroptional_controls | Contractprovider, session_id, top_n, trace, user |
Parametermultimodal_input_binding | Contractnull |
Lifecycle: synchronous
Send the exact model ID and retain the complete native response.
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 |
| ConfigurationUltra | Rate schedule— | Billing unit/ 1K tokens | Charge Input · input 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 →
{\n "documents": [\n "Paris is the capital of France.",\n "Berlin is the capital of Germany."\n ],\n "model": "voyageai/rerank-2.5-lite",\n "query": "What is the capital of France?",\n "top_n": 3\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='voyageai/rerank-2.5-lite'\nPath('request.json').write_text(json.dumps(p,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 result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Keep every complete returned response, file and content part.
Every actual result index, finite relevance_score and original document object is retained. Indices bind the original document array. Entire original JSON is stored and returned only after settlement.
Preserve original operation and full/partial reply; do not replay POST.
| Field | Type |
|---|---|
Fieldmodel | Typestring |
Fieldid | Typestring |
Fieldprovider | Typestring |
Fieldresults[].index | Typeinteger |
Fieldresults[].relevance_score | Typenumber |
Fieldresults[].document.text | Typestring |
Fieldresults[].document.image | Typestring |
Fieldusage.search_units | Typeinteger |
Fieldusage.total_tokens | Typeinteger |
Fieldusage.cost | Typenumber |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required field, representation or value | Next stepCorrect the indicated request field. |
Ailoot Ultra voyageai/rerank-2.5-lite
Use the method paths shown above.