Anthropic does not offer its own embedding model. For the retrieval half of a Claude RAG pipeline, its documentation points builders to external providers, naming Voyage AI as one with a wide range of options — while explicitly advising that you "assess a variety of embeddings vendors to find the best fit for your specific use case." Among the Voyage models Anthropic's embeddings guide lists, one pair is architecturally different from the rest and specifically aimed at long documents: the contextualized chunk models, voyage-context-4 and voyage-context-3.
The problem: chunks lose their document
Standard embedding workflows split a long document into chunks and embed each chunk independently. The embedding model sees only the chunk's own words. That creates two familiar retrieval failures:
- Ambiguous references. A chunk reading "the Company shall remedy the defect within 30 days" embeds identically whether it came from your cloud vendor's SLA or a construction subcontract. Which company? Which product? The answer lived elsewhere in the document.
- Near-duplicate chunks across documents. Boilerplate-heavy corpora — contracts, policies, financial filings — produce thousands of chunks that are textually similar but semantically distinct because of their surrounding context. Isolated embeddings can't tell them apart, so retrieval returns the wrong document's clause.
Teams have historically patched this by prepending metadata to each chunk ("Document: Acme MSA 2025, Section 8...") before embedding — helpful, but manual and lossy.
What contextualized chunk models do differently
Per Anthropic's embeddings guide, voyage-context-4 and voyage-context-3 support a 120K-token context and embed chunks with their surrounding document in view: you submit the document's chunks together, and the model produces one embedding per chunk that is informed by the rest of the document. The chunk about "the defect remedy" now carries a signal of which agreement, which parties, and which section it belongs to — without you manually stuffing that context into the chunk text. With a 120K-token window, even very long contracts, manuals, and filings fit as a single contextual unit.
The result is a drop-in upgrade at the index level: you still store one vector per chunk in your vector database, still search the same way. Only ingestion changes.
The different call pattern: contextualized_embed()
The API shape differs from standard embedding calls, and the difference is the point. A standard call (Voyage's embed()) takes a flat list of texts and embeds each independently. The contextualized call — contextualized_embed() — needs to know which chunks belong to which document, so it takes the chunks grouped per document and returns per-chunk embeddings computed in that shared context. Practically, that means your ingestion pipeline must preserve document boundaries all the way to the embedding step, rather than flattening everything into one big list of strings. Consult Voyage's own API reference for exact parameters; Anthropic's guide documents the model names, the 120K context, and the distinct call pattern, and links out for the rest (including pricing, which Anthropic does not list).
General retrieval guidance from the same page still applies: set input_type="document" when embedding corpus content and input_type="query" for queries, and note that Voyage embeddings are normalized to length 1, so dot-product and cosine similarity rank identically.
When to use it — and when not to bother
| Corpus shape | Standard embeddings | Contextualized chunk embeddings |
|---|---|---|
| Short, self-contained items (FAQs, tickets) | Good fit | Little to gain — each item is its own context |
| Long documents, cross-referencing prose | Chunks lose antecedents | Strong fit |
| Boilerplate-heavy families of similar docs | Near-duplicate collisions | Strong fit — context disambiguates |
Where retrieval quality is already limited by something else — bad chunk boundaries, missing metadata filters, no reranking — fix those first; Anthropic's guide also lists rerankers (rerank-2.5, rerank-2.5-lite) as a complementary lever. And once retrieval returns the right chunks, pass them to Claude as documents or search-result blocks with citations enabled so the generation side stays attributable.
Where to go next
The Voyage embeddings overview covers the general-purpose model family; search result content blocks and custom content documents cover the hand-off from retrieval into cited generation.