On 29 June 2026, Voyage AI released voyage-context-4, an embedding model for search and retrieval. MongoDB, which bought Voyage in February 2025, announced it under the headline “Stop Worrying About Chunking”. Voyage’s own post says the model’s features “together remove chunking as a design concern.” The API still returns one vector per chunk. What’s new is that each of those vectors is computed with the whole document in view, so a paragraph on page six is supposed to know what page one said.
We wanted to know what that does in practice, so we tried it on three kinds of text: the articles in this journal, research papers and commercial contracts. The short answer is that context writes the document’s identity into every chunk. That helps when a question is about the document or names it among others that look alike. It does nothing, or harm, when you need to tell one paragraph from the next inside a text about a single subject. Chunking didn’t go away, and the experiments show where it still matters.
The problem context is meant to fix
A retrieval system turns text into vectors and returns the vectors closest to a question. Embedding the whole document as one vector works badly when questions target a passage. Aapo Tanskanen measured this in April 2024 on Thoughtworks.com articles: with BGE-M3, 204 questions written by people over 50 test articles, chunked retrieval put the right article first 84.2% of the time and whole-article retrieval 73.9%. A vector for a whole article is roughly an average of everything in it, and a question about paragraph twelve has to match that average.
Chunking has the opposite problem. A chunk embedded on its own loses everything around it: “the term ends on the date in clause 2” means little when clause 2 sits in another chunk. Three approaches have tried to keep small chunks while giving them memory. Anthropic’s contextual retrieval (September 2024) has a language model write a short preamble for each chunk; on Anthropic’s evaluation it cut failed top-20 retrievals by 35%, and by 67% with BM25 keyword search and a reranker added. Jina’s late chunking (Günther et al., September 2024) runs the whole document through the model once and cuts it into chunk vectors afterwards. Voyage’s contextualised chunk embeddings train the model to do it directly. voyage-context-3 introduced the idea in July 2025; voyage-context-4 adds a new mixture-of-experts backbone and splits the document for you.
What the model does, and what Voyage measured
You send a document, with enable_auto_chunking=True if you want Voyage to choose the boundaries, and get back one vector per chunk. It costs $0.12 per million tokens. A request can carry 120,000 tokens with auto-chunking and 32,000 without, and documents over 32,000 tokens are, in Voyage’s words, “split and embedded transparently”.
Voyage’s evaluation covers 39 datasets in eight domains, scored with NDCG@10. Against voyage-context-3, it reports gains of 2.08% on chunk-level retrieval and 1.40% on document-level retrieval. Its headline comparisons with Jina’s late chunking (23.66%) and Anthropic’s contextual retrieval (6.76%) come from voyage-context-3’s evaluation in 2025, not from tests of the new model. The figure closest to the chunking question is that on LongEmbed, contextualised chunks beat single vectors by 7.11%. LongEmbed scores whether a query retrieves the right document from up to a thousand candidates, not the right passage within one, and finding the document is where our results say context helps most.
How we tested it
We used three collections, chosen to differ in the ways that should matter:
| Collection | Documents | Length (tokens) | Questions | Who wrote the questions |
|---|---|---|---|---|
| This journal | 9 articles | 1,600–3,200 | 37 | Us, reworded to avoid the passages’ wording |
| QASPER research papers | 18 NLP papers | 3,200–7,200 | 59 | NLP practitioners who had read only the title and abstract |
| CUAD contracts | 12 commercial contracts | 3,200–6,500 | 148 | Clause descriptions from CUAD, with answers marked by legal experts |
The papers and contracts were a fixed-seed random sample from the public QASPER and CUAD datasets. We split every document on paragraph breaks at about 256 and about 512 tokens, with no overlap, and counted a hit when the top result contained at least half of the answer passage. Questions were answered within their own document for the papers and contracts, and across all posts for the journal. For the papers we also searched across all 18, with the paper’s title written into the question, as someone searching a library would.
The main comparison holds the model fixed: voyage-context-4 with each chunk embedded on its own, against the same model embedding a document’s chunks together. Around it we ran Voyage’s auto-chunking, a middle setting where chunks are embedded in fixed groups of four consecutive chunks, so each sees only the text around it, voyage-4-large (Voyage’s standard model) and BM25. Confidence intervals are 95% and come from resampling whole documents, because questions about the same document aren’t independent.
We ran everything on Voyage’s free tier, which caps an account at 10,000 tokens a minute. A whole document has to fit in one request, so we dropped two papers and three contracts that didn’t, and nothing we tested is longer than about 7,200 tokens. Voyage’s case for the model rests on documents several times that size.
Every chunk learns which document it’s in
The clearest effect showed up before we asked a single question. Embedded on their own, two chunks from the same document had an average cosine similarity of 0.51 in the journal, 0.52 in the papers and 0.33 in the contracts (at 256 tokens). Embedded with document context, those rose to 0.80, 0.85 and 0.85. At 512 tokens the pattern was the same, ending between 0.85 and 0.89. Between chunks of different journal posts, similarity barely moved (0.27 to 0.30).
So context mostly does one thing: it adds a strong, shared signal saying which document a chunk belongs to. Every result that follows is that signal helping or getting in the way.
When knowing the document helps
Searching a library of similar documents, by name. Across all 18 papers, with the paper’s title in the question, context put the right passage first for 32 of 59 questions at 256 tokens, against 20 without (interval +7 to +35 points). At 512 tokens it was 33 against 26, a smaller gap that could be noise. Picking the right paper wasn’t the difference: plain vectors put a chunk from the right paper first for 57 of 59. The difference was where in the paper they landed. Without context, the title in the question pulled 9 of the 39 misses onto the chunk containing the paper’s title and abstract. With context every chunk already carries the paper’s identity, so the title stops favouring one chunk, and the rest of the question picks the passage. That happened once in 27 misses.
Questions about the document itself. Two of CUAD’s clause types ask who the parties are and what the contract is called. At 512 tokens, context found the right passage first for 19 of those 24 questions, against 3 without (interval +50 to +83 points). At 256 tokens, 11 against 2.
When it doesn’t
Telling paragraphs apart in short, single-topic texts. In our journal, context made things worse. At 256 tokens it found the right passage first for 17 of 37 questions, against 26 without (interval −40 to −8 points); at 512 tokens, 25 against 27. Most of the extra misses were the right post and the wrong paragraph. Naming the post in the question didn’t rescue it (21 against 25, within noise), because each post is about a different subject and plain vectors already found the right post for 35 of 37 questions.
Finding the passage inside a paper. Within a single paper, context made no difference to the first result: 26 against 27 at 256 tokens, 33 against 33 at 512. At 512 tokens it did worse further down the list, with the answer in the top three for 42 questions against 50 (interval −23 to −5 points).
Finding a clause in a contract. Leaving out the two identity clause types, the other 124 contract questions saw no change in the first result: 77 against 76 at 512 tokens, 73 against 79 at 256. The one gain was at 256 tokens in the top five, 117 against 107 (interval +2 to +14 points). For a pipeline that passes five chunks to a language model, that’s a modest improvement.
- 20 → 32
- of 59, right passage first across 18 papers, title in question (QASPER)
- 3 → 19
- of 24, contract parties and title found first (CUAD)
- 26 → 17
- of 37, right paragraph first in our journal
- 0.52 → 0.85
- similarity between chunks of the same paper
What else we tried
Less context. If a whole document makes chunks too alike, perhaps a little context is better. We embedded chunks in fixed groups of four consecutive chunks, about 1,000 tokens of context instead of the whole document. Similarity within a document rose less (to 0.64 in the papers, 0.42 in the contracts), and results were never meaningfully better than chunks alone in any collection. Where context helped, the help came from the whole document, not the paragraphs next door.
Two stages. We tried letting contextual vectors pick the paper and plain vectors pick the passage inside it. It scored 21 of 59, no better than plain vectors alone, because picking the paper was never the hard part.
Voyage’s own boundaries. Auto-chunking at 512 tokens never beat our paragraph-based chunks embedded with context: 29 against 33 within papers, 88 against 96 within contracts, 22 against 25 in the journal. Auto-chunking removes the code, not the need to check what it produced.
The model as a plain embedder. Used without context, voyage-context-4 matched voyage-4-large on the papers and the journal and edged it on the contracts (79 against 76 first results, 125 against 115 in the top five). That fits Voyage’s claim that it’s competitive as an ordinary embedding model.
Keyword search on its own was well behind on every collection: 11 of 59 within papers and 44 of 148 within contracts at 256 tokens. On an earlier set of journal questions that shared words with their answers, though, blending BM25 with embeddings was the best configuration we ran, so keyword search still belongs in the test.
The limits of what we did
Read these results as a careful afternoon of experiments, not a benchmark. The samples are small: 18 papers, 12 contracts and 9 posts, with 244 questions between them, and many of the intervals are wide. Nothing we tested exceeds 7,200 tokens, so the regime Voyage is selling, contracts of 30,000 tokens and more, is untested here. CUAD’s “questions” are the dataset’s clause descriptions rather than questions people asked, and its identity categories may suit a document-level signal unusually well. We wrote the journal questions ourselves, knowing the answers. We chose the chunk sizes, the neighbour window and the 50% hit rule before running anything and didn’t tune them, and each configuration ran once.
The vendor numbers and ours don’t actually conflict. Voyage’s strongest long-document result is a document-level test, and the document level is where we saw context earn its keep.
Where we’d use it
Libraries of documents that look alike. Contract repositories, policy libraries, research archives, sets of proposals or reports built from one template. Questions there often name the document (“the Acme supply agreement”, “the 2025 annual report”), and our results suggest that’s where context pays most.
Questions about the document rather than inside it. Who signed, what is this, which version: context lifted these from almost never found to usually found.
First-stage retrieval feeding a language model. On the contracts, context improved what landed in the top five at 256 tokens. If a model reads the top results anyway, that’s the number that matters.
Not for focused collections of short pages. Help-centre articles, blog posts, FAQs, product pages: each is already about one thing, plain vectors find the right page easily, and context made it harder to find the right paragraph. The same goes for chat-with-one-document tools, where context made no difference to the first result in our tests.
The switch costs almost nothing to try. It’s one model setting at the same price per token, and indexing both ways doubles storage rather than effort. Which way wins is a property of your documents and your users’ questions, and a few dozen questions with known answers will tell you.
Is this where retrieval is going?
We think the direction is right and the claim is too broad. Putting the document into every chunk is a genuine step: it lets one vector carry both where a passage lives and what it says, and that combination is exactly what a question like “what does the Acme agreement say about termination?” needs. The cost we measured is the other side of the same design. When every chunk shouts its document’s name, the differences between paragraphs get quieter.
What we’d want next is control over that balance: a way to say how much document context a chunk should carry, set per collection. Late chunking already lets you choose how much surrounding text each chunk vector is computed from, with open models, and nothing about Voyage’s approach rules out a similar setting. As language models read more of each document themselves, the retriever’s job shifts towards handing them the right few thousand tokens out of a large, repetitive collection, which is the job context does best. We’d also want independent tests at the lengths Voyage targets, including our own if a client’s documents allow it.
The chunking decision didn’t go away; it got a new option. For us that means the same practice as before: chunk size, context and keyword search are choices we make against real questions from a client’s own documents, with the embedding model behind an interface so it can change, and a vendor’s headline treated as the hypothesis the evaluation is there to test.
Sources
- Voyage AI, voyage-context-4, 2026
- MongoDB, voyage-context-4: Stop Worrying About Chunking With Our Best-Performing Model, 2026
- MongoDB, Contextualized Chunk Embeddings (documentation)
- MongoDB, MongoDB announces acquisition of Voyage AI, 2025
- Aapo Tanskanen, Guidebook to state-of-the-art embeddings and information retrieval, 2024
- Anthropic, Introducing Contextual Retrieval, 2024
- Günther et al., Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models, 2024
- Zhu et al., LongEmbed: Extending Embedding Models for Long Context Retrieval, 2024
- Dasigi et al., A Dataset of Information-Seeking Questions and Answers Anchored in Research Papers (QASPER), 2021
- Hendrycks et al., CUAD: An Expert-Annotated NLP Dataset for Legal Contract Review, 2021