VoyageAI by MongoDB: rerank-2.5-lite

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.

A lightweight second-stage relevance decision

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.

Instructions express what the user wants prioritized

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.

Read the ranking and return the source passage

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.

Limits and a practical candidate budget

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.