Voyage AI

Voyage AI develops embedding and reranking models for applications that need to locate useful information across large collections of documents. Its technology helps software compare queries with source material, retrieve relevant passages, and organize search results before a language model uses them to produce an answer.

The platform is aimed mainly at developers building semantic search, retrieval-augmented generation (RAG), enterprise knowledge tools, coding assistants, and research applications. It is not a conventional chatbot that people use primarily to have a conversation. Instead, it provides components that developers can connect to an application they already operate or are planning to build.

Voyage AI joined MongoDB in February 2025. Its product range now includes general-purpose text embeddings, contextualized chunk embeddings, code-oriented retrieval, multimodal embeddings, and rerankers. These models can be used with MongoDB Vector Search or connected to other compatible retrieval stacks.

The main decision is whether a particular Voyage model improves search results enough to justify its cost, response time, and integration work. That is best answered by testing it on the documents and questions the application will actually receive.

What Voyage AI Does Behind the Scenes

Voyage AI concentrates on two related parts of information retrieval: embedding content and reranking search results.

An embedding model turns information into a vector, which is a list of numbers representing aspects of the input’s meaning. A retrieval system can compare those vectors to find documents that are semantically related to a query, even when the documents use different wording.

A reranker works after an initial search has produced a group of candidate results. It evaluates the query alongside those candidates and gives the application a revised relevance ordering. This can help bring the most useful passages closer to the top.

These jobs become important when a language model needs external information. A model may produce fluent text while lacking the latest documentation, internal business rules, or a specific passage from a large document collection. A retrieval layer can locate such information and pass it along as context.

Consider a support team with thousands of product manuals, troubleshooting articles, and policy documents. A user asks how to resolve a particular problem. The system searches the collection, retrieves likely matches, optionally reranks them, and sends the strongest passages to a language model. The model can then prepare a response informed by the documents rather than relying only on general training knowledge.

Voyage AI handles parts of that retrieval process. It does not automatically supply every part of the finished application: developers still need a source collection, storage or indexing, an interface, access control, and answer-generation logic.

The modular design is useful because teams do not have to replace their entire stack to experiment with a different embedding model. They can test an alternative model, measure how it changes retrieval quality, and decide whether a migration makes sense.

MongoDB describes Voyage AI as part of its AI search and retrieval offering.

Picking a Model From the Voyage 4 Family

Voyage’s general-purpose text embedding lineup includes voyage-4-large, voyage-4, and voyage-4-lite. These models serve different priorities, so the largest version is not automatically the right choice for every workload.

voyage-4-large is positioned as the flagship general-purpose model for projects where retrieval quality is especially important. It is a reasonable candidate when the cost of missing an important document is higher than the additional API expense.

voyage-4 aims to provide a middle ground between quality and efficiency. It can be a sensible starting point for projects that want a capable general-purpose embedding model without immediately selecting the largest option.

voyage-4-lite focuses on a lighter cost and latency profile. It is worth assessing for applications that process high volumes of queries or documents and need to keep their retrieval pipeline efficient.

The published documentation lists a 32,000-token context length for these three models. It also supports configurable vector dimensions: 1,024 by default, with options for 256, 512, or 2,048 dimensions. The models share an embedding space, which is useful when a system needs to evaluate or migrate among members of the Voyage 4 family.

Vector dimensions influence storage requirements and retrieval behavior. Lower-dimensional vectors take less space, but the effect on search quality depends on the dataset and task. Choosing a smaller vector solely to save storage can be a poor trade if it makes relevant passages harder to find.

A useful model-selection process starts with representative questions and documents. Build a small evaluation set, run each candidate model, and compare relevance, failure cases, latency, and cost. For a code knowledge base, a specialized code model may be more appropriate than a general-purpose text model. For multilingual corporate documents, language coverage and cross-language retrieval quality might matter more than raw throughput.

Voyage also lists voyage-4-nano as an open-weight embedding option for local development. This may interest teams that want to experiment with local inference, but the license and permitted use should be reviewed before adopting it for commercial production.

Preserving Meaning Across Long Documents and Visual Content

Retrieval quality can suffer when a long document is split into chunks that no longer retain enough surrounding context. A passage might mention “the second method,” a product code, or a legal clause without repeating the definition that makes it meaningful. If the passage is embedded in isolation, a search system may struggle to recognize its relevance to a question.

Voyage-context-4 is designed for contextualized chunk embeddings. It incorporates broader document context into the representation of a chunk instead of treating every piece as completely independent. This can be useful for long manuals, technical reports, policy documents, and other material where nearby sections help explain a passage.

The official model documentation describes support for input lengths up to 120,000 tokens when automatic chunking is enabled, subject to the endpoint’s specific constraints. The limits differ depending on how input is supplied, so developers should confirm the current reference before designing a large-document ingestion process.

Voyage also offers voyage-multimodal-3.5, which is designed for supported combinations of text, images, and video. This opens up retrieval workflows in collections that contain screenshots, slides, diagrams, tables, and video frames rather than just ordinary prose.

For instance, a technical knowledge base may contain written instructions alongside screenshots of software settings. A text-only index could miss useful visual information, whereas an appropriate multimodal model can help represent the supported content for retrieval.

Multimodal indexing still takes planning. Developers need to extract or prepare the right source assets, store references to the originals, choose how much information to index, and account for differences in model input requirements. The cost model also differs from plain text: image and video processing is charged based on pixels, and each video frame is treated as an image for billing purposes.

A multimodal model is not necessary for every project. If the collection contains only ordinary text, a dedicated text embedding model may be simpler and more economical. If users need to find information within visual records, the additional capability may be justified.

before choosing an approach.

When to Add a Reranker to the Search Pipeline

A semantic search system usually retrieves an initial set of candidate documents. The candidates may be related to the question, but their order is not guaranteed to reflect which documents most directly answer it.

A reranker adds a second relevance check. It evaluates each candidate in relation to the query and gives the application scores or an ordering that can be used to select the most useful results.

Voyage’s current recommended reranking models include rerank-3 and rerank-3-lite. The standard model is intended for use cases that prioritize ranking quality, while the lite option offers a more cost-conscious choice. Their documented context length is 32,000 tokens.

Imagine a coding assistant searching dozens of pages about a programming library. Several results might mention the requested function, but only a few explain its current parameters or show the correct usage pattern. A reranker can help prioritize passages that better answer the original query.

A typical two-stage system works like this:

1. An embedding or keyword search retrieves a broader set of candidate documents.
2. The application sends the user’s query and those candidates to the reranker.
3. The reranker scores and orders the candidates by relevance.
4. The application selects the most useful passages.
5. A language model uses those passages to prepare the response.

The benefit is more selective context for the model. Better-ranked passages can reduce the chance that the answer is based on loosely related material. This is not a guarantee of factual correctness, but it gives developers another point at which to improve retrieval.

There are trade-offs. Reranking adds processing time and usage cost, and it cannot recover a document that was absent from the candidate set in the first place. The quality of the initial retrieval stage therefore remains important.

The right decision should come from evaluation. Compare the pipeline with and without reranking and look at whether important sources are ranked higher, whether answer quality improves, and whether the extra cost and delay are acceptable.

For new implementations, consult the The lifecycle page matters because older model families can be designated legacy and may require a migration plan.

Integrating Voyage AI Into a RAG Application

Voyage AI fits into an application architecture that combines retrieval with a language model. The embedding service generates vectors, a vector store indexes them, retrieval finds candidate documents, and an optional reranker improves the candidate ordering before selected material is supplied to the generation model.

The overall workflow starts with the source data. Documents are collected, cleaned, and divided into sections that make sense for retrieval. Each section is embedded and stored alongside its original text, document identifier, URL or file reference, permissions, and any useful metadata.

When a user asks a question, the application embeds the query and searches the index. It can apply filters for source, date, department, or access permissions. If the workload benefits from reranking, the candidate results are passed through the reranker before the final passages are selected.

The selected evidence is then sent to a language model with instructions to answer from the supplied information, distinguish uncertainty, and avoid making claims that the source material does not support. The application can include citations or links so users can review the original material.

Voyage documents integrations with tools and frameworks such as LangChain, LlamaIndex, Haystack, Weaviate, LanceDB, Redis, DataStax, Milvus, Pinecone, and Qdrant. Support and configuration can differ by platform, so developers should use the current integration documentation rather than assume every library works in exactly the same way.

Teams already using MongoDB Atlas may find MongoDB Vector Search a natural option for storing and searching embeddings. Other teams can keep an existing vector database when that better fits their architecture.

Voyage’s API documentation includes REST access and client options for common environments, including Python and TypeScript. An API key is required for authenticated requests and usage accounting. Production implementations should protect that key, handle failures and rate limits, and avoid exposing credentials in browser code or public repositories.

For large ingestion jobs, the Batch API can handle work that does not need an immediate response. The documentation lists a 12-hour completion window and a 33% discount compared with standard endpoints. Batch jobs are charged separately from the free token allocation, so developers should include them in their budget.

A good implementation is not defined by which model it uses alone. Data quality, chunking, index design, permissions, monitoring, and answer evaluation all influence the final experience. Voyage supplies useful retrieval components, but the engineering around them remains part of the project.

Understanding Voyage AI Pricing and Its Limitations

Voyage AI does not use one flat subscription price for every model. Its published API rates depend on the selected model and the amount or type of data processed. Text requests are billed according to token usage, while multimodal requests can also incur pixel-based charges.

The current published rates include $0.12 per million tokens for voyage-4-large, $0.06 per million for voyage-4, and $0.02 per million for voyage-4-lite. The listed rate for voyage-context-4 and voyage-code-4 is $0.12 per million tokens.

The official pricing documentation lists 200 million free tokens for the main Voyage 4 text models, contextualized embeddings, and code-4. Free allowances can differ for older or specialized models, and some legacy models no longer offer a free allocation. Developers should verify the allowance that applies to their chosen model and account before estimating a project’s initial cost.

For voyage-multimodal-3.5, the listed rates include $0.12 per million text tokens and $0.60 per billion pixels. The published free allocation is 200 million text tokens and 150 billion pixels. Minimum and maximum pixel billing rules apply, which means the size and processing of images should be considered when calculating a multimodal workload.

Reranking uses a different billing calculation. The number of query tokens is multiplied by the number of documents being reranked, then the tokens in the documents are taken into account. Published rates are $0.05 per million processed tokens for rerank-3 and $0.02 for rerank-3-lite, with 200 million free tokens listed for each.

These rates describe the model API, not the total price of an entire AI product. Vector storage, data ingestion, language-model generation, repeated searches, monitoring, and application infrastructure can all contribute to the operating budget.

There are technical limitations to consider as well. An embedding represents meaning but does not certify that a document is true or complete. Search quality depends on source material, preprocessing, chunking, indexing, and query design. A reranker can improve candidate order but cannot compensate for a missing source or a badly prepared collection.

Model lifecycle changes are another reason to review documentation before production deployment. If an older model becomes legacy, a team may need to evaluate a replacement and verify compatibility with its existing vector index. Even models within a broad product family can have different operational requirements.

The best approach is to benchmark the intended workload before making a final decision. Measure retrieval relevance, response latency, token usage, and the quality of the answers that depend on retrieved content. This provides a more useful comparison than choosing a provider based only on a headline price or a general benchmark.