Voyage AI, or embeddings without rebuilding the index

Voyage AI, or embeddings without rebuilding the index

Voyage AI supplies embedding models and models that reorder search results. The company was acquired by the maker of a well known document database in 2025, while the standalone API remained available and integration with that database is an additional route rather than a condition of use.

This offering's differentiator is unusual and worth understanding, since it solves a problem that is a nuisance with every other provider. The whole Voyage 4 family, from the smallest model to the largest, produces vectors in the same space.

That means switching to a stronger or cheaper model requires no recomputation of the collection. Vectors from different models in this family are comparable, so you can index an archive with a cheap model and query it with an expensive one, or swap models without touching the index.

Why a shared space matters

The thread deserves developing, since from outside it looks like a detail and in practice it changes how a project is run.

With every other provider, vectors from two different models sit in different spaces and comparing them yields random results. The consequence is that choosing a model at the start is a decision for years: changing means recomputing the whole archive, rebuilding the index, and a window where search runs across two inconsistent sets.

On a large archive that prospect effectively blocks any change. Teams stay with a model chosen two years ago not because it is best but because migration is too expensive for anybody to propose.

A shared space removes that cost. You can start with the cheapest model and, once accuracy proves insufficient, swap it in configuration and query the same index with a stronger one. You can also index a rarely used archive with a cheap model and current documents with an expensive one, keeping everything in one place.

A caveat worth stating honestly: that compatibility covers the Voyage 4 family. Vectors from earlier generations and from other providers' models remain incomparable, so moving to this family requires a one off recomputation.

Understand too what a shared space does not solve. Models differ in quality, so switching to a stronger one improves accuracy only for documents indexed with the stronger model. Querying a weakly computed index with a strong model gives an intermediate result, better than the weak model alone and worse than a full recomputation. That remains a considerable convenience, but it does not replace recomputation where you want maximum quality.

The models and choosing between them

The family holds four models differing in size, price, and quality while sharing a space.

The largest costs the most and delivers the highest accuracy. The base model is half the price at a slight loss. The lightweight one costs a fraction of that and suits large volumes where throughput matters.

The fourth is the most interesting: an open weights model available under a permissive licence and runnable locally. That is rare among commercial providers and opens an arrangement the competition does not offer.

import voyageai

client = voyageai.Client()

response = client.embed(
    chunks,
    model="voyage-4-lite",
    input_type="document",
)

A practical scenario using both ends of the family looks like this. You develop the application locally on the open model, with no keys, no cost, and no data leaving your machine. In production you switch to a paid model, and since the space is shared, the index built locally keeps working.

That solves a real nuisance in embedding work: the gap between development and production environments, which with other providers requires either paying for every test or maintaining two separate indexes.

Reordering results

The second half of the offering concerns a model scoring the fit between a query and a document, and that is the step that raises accuracy most in typical search.

The mechanism differs from embeddings. An embedding model computes a document's vector once, without knowing the question, so comparison reduces to the distance between two points. A reordering model sees the query and the document together and scores the fit directly, giving markedly better results at a much higher price per operation.

The practical arrangement has two stages. Vector search returns fifty candidates cheaply, and the scoring model picks the best five from them. You pay for fifty scorings instead of comparing everything with everything, and result quality comes close to what the exhaustive comparison would give.

results = client.rerank(
    query="What is the notice period?",
    documents=candidates,
    model="rerank-2.5",
    top_k=5,
)

Measure this step before deploying, since its value depends on the collection. On thematically varied documents, vector search alone usually suffices. On a collection where many fragments discuss similar things, the difference can be large and justifies the extra cost and latency.

Pricing and the free tier

Billing follows tokens, and rates differ noticeably between models in the family, from a few cents to over ten cents per million tokens.

The free tier is generous for this category and covers building and testing a prototype without spending anything. The price list puts it at two hundred million tokens per account for every model in the Voyage 4 family and the same again for the reordering models. That matters when comparing providers, since it lets you check accuracy on your own data before deciding.

There is an exception here that is easy to miss on a first large indexing run. The free allowance does not cover batch processing: tokens sent that way are billed from the first one and do not draw down the free balance, but they go at a rate a third lower, with a completion window measured in hours. For a one off recomputation of an archive that usually still works out cheaper, though it is worth knowing the two do not combine.

The open weights model costs nothing beyond the hardware you run it on. Under steady, high volume that can be decisive, since the cost moves from a variable line to a fixed one and stops growing with traffic.

Price both variants against your own numbers. Indexing a million fragments of five hundred tokens is five hundred million tokens, meaning anywhere from around ten to sixty dollars depending on model, while search costs considerably less afterwards, since queries are short.

Price the reranking step separately, because there the arithmetic runs the other way. Embeddings are paid for once at indexing, while scoring candidates happens on every query. At a thousand queries a day and fifty candidates per query that item is comparable to the whole indexing cost, except repeated every month. Cutting candidates from fifty to twenty more than halves it and usually does not change the outcome, since the right document rarely sits below twentieth place after vector search.

Dimensions and compression

Models in this family let you shorten a vector without recomputing it, and the smallest supports a range from a few hundred to over two thousand dimensions.

The gain shows only on larger collections, where it is substantial. A two thousand dimension vector stored as floating point takes eight kilobytes; the same one truncated to five hundred and twelve takes two. Across five million fragments that is the difference between forty and ten gigabytes in the vector database.

The models are also prepared for number format compression, so storing as single bytes does not degrade results the way it would with a model not trained for it. That matters practically, since it cuts the footprint another fourfold, usually at an accuracy loss measured in percentage points.

Choose the settings by measurement rather than from a table. Index the same collection at full and truncated dimension counts, run the same question set through both, and compare how often the right document landed in the top five. If the difference is a percentage point and the saving three quarters of the space, the decision makes itself.

Record the chosen settings alongside the index. Vectors computed at different dimension counts are not comparable even within one model, so adding documents under a different setting corrupts search silently, with no message at all.

Deployment step by step

Showing the whole thing pays off, since embeddings are one element rather than the entire system.

The first step is splitting documents into fragments matching the unit in which an answer fits: a documentation section, a contract clause, a report page. That choice affects accuracy more than the model choice and gets skipped most often. With PDFs and scans it begins earlier still, since the text has to be extracted together with the page layout, which is the job of a separate tooling layer such as Unstructured; its mistakes, a merged table or scrambled columns, then carry into every later step.

The second is computing vectors in batches, with progress written to a file. On a large collection you will hit request rate limits, and an interrupted run should resume from where it stopped rather than from the beginning.

The third is writing to a vector database along with metadata. A page number, file name, and date let you show the user the answer's source and narrow searches, and recovering them later means reprocessing the archive. In MongoDB Atlas Vector Search, run by the company that acquired Voyage AI, the two preceding steps can disappear, since the database computes vectors with these models as documents are written. The feature sits in public preview, and its price is tying the index to one vendor's models.

The fourth is search with two layers: vector based for meaning and classic for exact matches, since a query for an invoice number or an error code will not land through meaning similarity alone.

The fifth, optional, is scoring the candidates with a reordering model. Enable it only once you measure that the previous four steps fall short, since it adds cost on every query and lengthens the response time.

Voyage AI against the alternatives

The first row wins in one specific case: when you do not yet know what quality you need and recomputing the archive in six months would be costly. A shared space turns that decision from a one off binding choice into a reversible one.

The last row deserves distinguishing from this family's open model. The latter has the advantage of staying compatible with the paid models, so moving from local to hosted needs nothing beyond a configuration change.

Common mistakes

The first is assuming the shared space covers everything. It applies to the Voyage 4 family rather than to earlier generations or other providers' models.

The second is omitting the input type parameter. A document and a query are embedded differently, and using the same value for both worsens accuracy in a way easily missed.

The third is adding a reordering step without measuring. On a thematically varied collection vector search alone usually suffices, and the extra step costs money and latency.

The fourth is scoring the whole collection rather than the candidates from search. It is a two stage arrangement and only makes economic sense in that form.

The fifth is running the local model in production without measuring the accuracy gap. Open weights tempt with price, and a smaller model usually performs worse, which is worth quantifying.

The sixth is indexing without recording which model and dimension count produced the vectors. Six months later nobody remembers, and adding new documents under different settings corrupts the index silently.

FAQ

What does a shared space mean?

Every model in the Voyage 4 family produces vectors comparable with each other. Switching to a stronger or cheaper model requires no recomputation and no index rebuild, which on a large archive turns a binding decision into a reversible one.

Is there really a model I can run myself?

Yes, the family's smallest model has open weights under a permissive licence and runs locally. More importantly, it stays compatible with the paid models, so you can develop locally and switch to a hosted model without touching the index.

How does embedding differ from reordering results?

An embedding model computes a document's vector once, without knowing the question. A reordering model sees the query and the document together, so it scores the fit more precisely at a much higher price per operation. Hence the two stage arrangement: cheap search, then scoring the candidates.

Must I use the vendor's document database?

No. The standalone API works independently, and vectors go into any vector database, such as those covered in the pieces on Qdrant or pgvector. Integration with the vendor's database is an additional route rather than a requirement.

How do I check whether switching is worthwhile?

Build a set of fifty real questions with expected answers, index the same collection with your current and the new model, and compare how often the right document landed in the top five. The free tier covers that test without spending anything.

Documentation sits on the vendor's site, and the Voyage 4 family's details in its release post.