Voyage rerank-3-lite is the latency-focused edition of Voyage’s Rerank 3 series. It takes a text query and candidate documents, evaluates each query-document pair together, and returns relevance scores in ranked order. It serves the second stage of search: an embedding or keyword retriever finds the candidates, then Lite refines their order. The result is a ranking to use in search or a retrieval-augmented generation workflow.
What changes in Rerank 3 Lite The producer emphasizes stronger retrieval on long documents and code compared with rerank-2.5-lite. Both Rerank 3 editions retain instruction following and the same 32K context class, while Lite is designed for latency-sensitive applications. This makes it a practical candidate for interactive knowledge-base search, support-document retrieval and code lookup when users need relevant results promptly. Choose it on the quality and response-time requirements of the actual collection, rather than assuming that a smaller edition means a smaller context window.
Guide relevance with the query Natural-language instructions can accompany the query to explain what counts as relevant. Keep the question and the relevance preference concise and consistent. For a software support search, use “Find the procedure for resetting a device; prioritize instructions for the stated hardware revision.” For an ambiguous product name, include the product category so unrelated meanings do not dominate. A preference in the query guides semantic scoring; use explicit collection metadata to select the correct product, document version or access scope before building the candidate list.
Prepare a shortlist of text candidates The input documents are strings. Extract readable text from source material and retain useful titles, headings, identifiers and surrounding context. Keep a stable mapping from each input position to the original record. For a troubleshooting article, include the symptom and relevant procedure, not only a detached sentence. For source-code search, include the function and nearby information needed to distinguish it from similarly named functions. Remove repetitive navigation or boilerplate when it crowds out the useful passage.
The reranker can reorder only the documents it receives. If the first search never retrieves the relevant article, this stage cannot recover that missing candidate. Inspect both the shortlist and the final ordering when a result seems wrong. Where a long document covers many topics, separate coherent sections and retain their parent-document references so a relevant section can be selected without losing its source.
Context and request limits The maker’s current guide specifies a query maximum of 8,000 tokens and a combined maximum of 32,000 tokens for the query plus each individual document. It allows up to 1,000 candidate documents and a total request budget of 600,000 tokens, calculated as query tokens multiplied by document count, plus all document tokens. A long query therefore consumes space in every pair and contributes repeatedly to the aggregate budget. Count the submitted text with the appropriate model tokenizer rather than treating characters, words and tokens as interchangeable.
For example, a 500-token query with 100 documents of 4,000 tokens each accounts for 450,000 input tokens under that formula. This illustrates budgeting, not a recommended shortlist size or a measured speed result. The documented truncation option is enabled by default; oversized text can be shortened before scoring. Prepare important sections deliberately so truncation does not remove the very passage you need to match.
Read and use the result Results are sorted from highest relevance score downward. Each result identifies the document’s original input position, allowing the application to attach its own title, record identifier and source. The top_k setting controls how many ranked candidates are returned; without it, all candidates are returned. The maker’s REST interface can also return the document text. Retain the original identifiers alongside the selected results when showing a search page or passing evidence into an answer-generation step.
A relevance score expresses how well a candidate matches the query; it does not establish that the candidate’s statements are correct. Compare the highest-ranked items with the user’s actual question, including exclusions and document-version differences. If every candidate is irrelevant, a highest-ranked item still exists. Decide how your application handles that case using representative queries from the collection.
Upgrading and choosing the edition The maker describes rerank-3-lite as an upgrade to rerank-2.5-lite with unchanged API semantics and scores calibrated to the corresponding predecessor’s distribution. Preserve the existing record mapping and retrieval stage, then compare the resulting order on meaningful queries before relying on an established score cutoff. Use Lite for a search experience where response time matters; use the quality-focused rerank-3 edition as a comparison when relevance on difficult candidates is the stronger priority.
", "aboutText": "Voyage rerank-3-lite is the latency-focused edition of Voyage’s Rerank 3 series. It takes a text query and candidate documents, evaluates each query-document pair together, and returns relevance scores in ranked order. It serves the second stage of search: an embedding or keyword retriever finds the candidates, then Lite refines their order. The result is a ranking to use in search or a retrieval-augmented generation workflow.\n\nWhat changes in Rerank 3 Lite\nThe producer emphasizes stronger retrieval on long documents and code compared with rerank-2.5-lite. Both Rerank 3 editions retain instruction following and the same 32K context class, while Lite is designed for latency-sensitive applications. This makes it a practical candidate for interactive knowledge-base search, support-document retrieval and code lookup when users need relevant results promptly. Choose it on the quality and response-time requirements of the actual collection, rather than assuming that a smaller edition means a smaller context window.\n\nGuide relevance with the query\nNatural-language instructions can accompany the query to explain what counts as relevant. Keep the question and the relevance preference concise and consistent. For a software support search, use “Find the procedure for resetting a device; prioritize instructions for the stated hardware revision.” For an ambiguous product name, include the product category so unrelated meanings do not dominate. A preference in the query guides semantic scoring; use explicit collection metadata to select the correct product, document version or access scope before building the candidate list.\n\nPrepare a shortlist of text candidates\nThe input documents are strings. Extract readable text from source material and retain useful titles, headings, identifiers and surrounding context. Keep a stable mapping from each input position to the original record. For a troubleshooting article, include the symptom and relevant procedure, not only a detached sentence. For source-code search, include the function and nearby information needed to distinguish it from similarly named functions. Remove repetitive navigation or boilerplate when it crowds out the useful passage.\n\nThe reranker can reorder only the documents it receives. If the first search never retrieves the relevant article, this stage cannot recover that missing candidate. Inspect both the shortlist and the final ordering when a result seems wrong. Where a long document covers many topics, separate coherent sections and retain their parent-document references so a relevant section can be selected without losing its source.\n\nContext and request limits\nThe maker’s current guide specifies a query maximum of 8,000 tokens and a combined maximum of 32,000 tokens for the query plus each individual document. It allows up to 1,000 candidate documents and a total request budget of 600,000 tokens, calculated as query tokens multiplied by document count, plus all document tokens. A long query therefore consumes space in every pair and contributes repeatedly to the aggregate budget. Count the submitted text with the appropriate model tokenizer rather than treating characters, words and tokens as interchangeable.\n\nFor example, a 500-token query with 100 documents of 4,000 tokens each accounts for 450,000 input tokens under that formula. This illustrates budgeting, not a recommended shortlist size or a measured speed result. The documented truncation option is enabled by default; oversized text can be shortened before scoring. Prepare important sections deliberately so truncation does not remove the very passage you need to match.\n\nRead and use the result\nResults are sorted from highest relevance score downward. Each result identifies the document’s original input position, allowing the application to attach its own title, record identifier and source. The top_k setting controls how many ranked candidates are returned; without it, all candidates are returned. The maker’s REST interface can also return the document text. Retain the original identifiers alongside the selected results when showing a search page or passing evidence into an answer-generation step.\n\nA relevance score expresses how well a candidate matches the query; it does not establish that the candidate’s statements are correct. Compare the highest-ranked items with the user’s actual question, including exclusions and document-version differences. If every candidate is irrelevant, a highest-ranked item still exists. Decide how your application handles that case using representative queries from the collection.\n\nUpgrading and choosing the edition\nThe maker describes rerank-3-lite as an upgrade to rerank-2.5-lite with unchanged API semantics and scores calibrated to the corresponding predecessor’s distribution. Preserve the existing record mapping and retrieval stage, then compare the resulting order on meaningful queries before relying on an established score cutoff. Use Lite for a search experience where response time matters; use the quality-focused rerank-3 edition as a comparison when relevance on difficult candidates is the stronger priority.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "cc3ee47c11a0596d72ed891a7049eb6055be6fcbddd9b82d2ccbd320096deef0", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "voyageai/rerank-3-liteVoyage rerank-3-lite scores and reorders candidate text documents for a query, with a focus on responsive search. It supports relevance instructions and a 32,000-token query-document window, making it useful after vector or keyword retrieval in search and RAG workflows.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Voyage rerank-3-lite is the latency-focused edition of Voyage’s Rerank 3 series. It takes a text query and candidate documents, evaluates each query-document pair together, and returns relevance scores in ranked order. It serves the second stage of search: an embedding or keyword retriever finds the candidates, then Lite refines their order. The result is a ranking to use in search or a retrieval-augmented generation workflow.
What changes in Rerank 3 Lite The producer emphasizes stronger retrieval on long documents and code compared with rerank-2.5-lite. Both Rerank 3 editions retain instruction following and the same 32K context class, while Lite is designed for latency-sensitive applications. This makes it a practical candidate for interactive knowledge-base search, support-document retrieval and code lookup when users need relevant results promptly. Choose it on the quality and response-time requirements of the actual collection, rather than assuming that a smaller edition means a smaller context window.
Guide relevance with the query Natural-language instructions can accompany the query to explain what counts as relevant. Keep the question and the relevance preference concise and consistent. For a software support search, use “Find the procedure for resetting a device; prioritize instructions for the stated hardware revision.” For an ambiguous product name, include the product category so unrelated meanings do not dominate. A preference in the query guides semantic scoring; use explicit collection metadata to select the correct product, document version or access scope before building the candidate list.
Prepare a shortlist of text candidates The input documents are strings. Extract readable text from source material and retain useful titles, headings, identifiers and surrounding context. Keep a stable mapping from each input position to the original record. For a troubleshooting article, include the symptom and relevant procedure, not only a detached sentence. For source-code search, include the function and nearby information needed to distinguish it from similarly named functions. Remove repetitive navigation or boilerplate when it crowds out the useful passage.
The reranker can reorder only the documents it receives. If the first search never retrieves the relevant article, this stage cannot recover that missing candidate. Inspect both the shortlist and the final ordering when a result seems wrong. Where a long document covers many topics, separate coherent sections and retain their parent-document references so a relevant section can be selected without losing its source.
Context and request limits The maker’s current guide specifies a query maximum of 8,000 tokens and a combined maximum of 32,000 tokens for the query plus each individual document. It allows up to 1,000 candidate documents and a total request budget of 600,000 tokens, calculated as query tokens multiplied by document count, plus all document tokens. A long query therefore consumes space in every pair and contributes repeatedly to the aggregate budget. Count the submitted text with the appropriate model tokenizer rather than treating characters, words and tokens as interchangeable.
For example, a 500-token query with 100 documents of 4,000 tokens each accounts for 450,000 input tokens under that formula. This illustrates budgeting, not a recommended shortlist size or a measured speed result. The documented truncation option is enabled by default; oversized text can be shortened before scoring. Prepare important sections deliberately so truncation does not remove the very passage you need to match.
Read and use the result Results are sorted from highest relevance score downward. Each result identifies the document’s original input position, allowing the application to attach its own title, record identifier and source. The top_k setting controls how many ranked candidates are returned; without it, all candidates are returned. The maker’s REST interface can also return the document text. Retain the original identifiers alongside the selected results when showing a search page or passing evidence into an answer-generation step.
A relevance score expresses how well a candidate matches the query; it does not establish that the candidate’s statements are correct. Compare the highest-ranked items with the user’s actual question, including exclusions and document-version differences. If every candidate is irrelevant, a highest-ranked item still exists. Decide how your application handles that case using representative queries from the collection.
Upgrading and choosing the edition The maker describes rerank-3-lite as an upgrade to rerank-2.5-lite with unchanged API semantics and scores calibrated to the corresponding predecessor’s distribution. Preserve the existing record mapping and retrieval stage, then compare the resulting order on meaningful queries before relying on an established score cutoff. Use Lite for a search experience where response time matters; use the quality-focused rerank-3 edition as a comparison when relevance on difficult candidates is the stronger priority.
POST /v1/reranktextrerank| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fielddocuments | Typearray | RequirementRequired | Values & limits | Default— |
Fieldmodel | Typestring | RequirementRequired | Values & limits voyageai/rerank-3-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-3-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-3-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-3-lite
Use the method paths shown above.