With Jina Embeddings v3
Explains late chunking, a technique that embeds full documents before splitting into chunks to preserve context, improving retrieval recall by 3-10%.
What this file does
Explains late chunking, a technique that embeds full documents before splitting into chunks to preserve context, improving retrieval recall by 3-10%.
When to use it
- Building a retrieval system for technical documentation or academic papers
- Handling long-form content with cross-references or pronoun references
- Evaluating whether to replace standard chunking in a quality-critical RAG pipeline
- Comparing embedding strategies for legal or multi-section documents
Assumes this stack
What is Late Chunking?
Late chunking is a technique where you embed the entire document first with a long-context embedding model, then chunk the resulting contextualized representations, rather than chunking text first then embedding each chunk independently.
Traditional Chunking Problem
Standard Approach:
- Split document into chunks (500 tokens)
- Embed each chunk independently
- Store chunk embeddings
Issues:
- Context loss at boundaries
- Chunks lack full document context
- Related information split
- Lower retrieval quality
Late Chunking Process
- Embed Full Document: Use long-context model (8K+ tokens)
- Get Token Embeddings: Each token has contextualized embedding
- Chunk After Embedding: Split token embeddings
- Pool Chunk Embeddings: Average or max pool
- Store: Chunks with full context
Advantages
Better Context:
- Each chunk knows about entire document
- Cross-reference awareness
- Section relationships preserved
Improved Retrieval:
- 5-10% better recall
- Especially for technical docs
- Better handling of references
Semantic Coherence:
- "It" and "they" properly contextualized
- Forward/backward references resolved
- Better pronoun handling
When to Use
Best For:
- Technical documentation
- Academic papers
- Legal documents
- Documents with cross-references
- Long-form content
Not Needed For:
- Short documents
- Independent chunks
- Simple content
- No cross-references
Requirements
Long-Context Model:
- jina-embeddings-v3 (8K)
- Nomic Embed (8K)
- voyage-3 (16K)
- Must support long contexts
Implementation Support:
- Requires model API supporting token-level embeddings
- Custom chunking logic
- More complex than standard
Implementation Example
# With Jina Embeddings v3
from transformers import AutoModel
# 1. Get token embeddings for full doc
token_embeddings = model.encode(
full_document,
return_dense=True,
return_sparse=False,
return_colbert_vecs=True # Token-level
)
# 2. Define chunk boundaries (tokens)
chunk_boundaries = [(0, 512), (512, 1024), ...]
# 3. Pool token embeddings per chunk
chunk_embeddings = [
pool(token_embeddings[start:end])
for start, end in chunk_boundaries
]
# 4. Store with full context
for i, emb in enumerate(chunk_embeddings):
store(chunk_text[i], emb)
Performance Impact
Pros:
- Better retrieval quality
- Improved context understanding
- Worth the complexity for quality-critical apps
Cons:
- More computation (embed full doc)
- Requires long-context model
- Implementation complexity
- Limited model support
Comparison to Alternatives
vs Standard Chunking:
- Late: Better context, more complex
- Standard: Simpler, faster, context loss
vs Sliding Window:
- Late: No overlap needed
- Sliding: Redundant storage
vs Hierarchical:
- Late: Single-level, contextual
- Hierarchical: Multi-level, summarized
Best Practices
- Use with long-context models only
- Test on your document type
- Compare vs standard chunking
- Monitor computational cost
- Combine with other techniques
- Document chunking strategy
Supported Frameworks
- Jina AI: Native support
- LlamaIndex: Experimental
- LangChain: Custom implementation
- Direct: Model API + custom code
Future Development
Late chunking is gaining traction as:
- More long-context models available
- Better tooling support
- Quality benefits proven
- Implementation simplifies
Measuring Impact
Compare:
- Standard chunking recall@10
- Late chunking recall@10
- Measure improvement
- Check computational cost
- Decide if worth trade-off
Typical improvement: 3-8% better recall on technical documents.
What's inside
13 sections covering process, advantages, requirements, implementation example, performance trade-offs, and best practices
Change this for your project
- Replace
full_documentwith your actual document variable - Replace
chunk_boundaries = [(0, 512), (512, 1024),...]with your own token ranges - Replace
store(chunk_text[i], emb)with your vector database's insert method
Where it goes
Reference documentation for a retrieval pipeline. Keep with the ingestion or retrieval code it describes.
Worth borrowing
- Embed entire document first, then pool token embeddings per chunk to retain global context
- Compare recall@10 between standard and late chunking to quantify improvement before committing
Related Documents
SUMMARY
Proposes three on-prem AI architectures, modular, hybrid, and fully local RAG, with hardware specs and vendor lists.
Retrieval & Prompts
Explains how CharMemory's extraction prompt and Vector Storage settings determine memory retrieval quality in SillyTavern.
Advanced RAG Techniques
Surveys advanced RAG architectures, Agentic, Corrective, Self-RAG, Graph RAG, RAPTOR, Multimodal, Temporal, with design trade-offs and decision guidance.
RFC-BLite: High-Performance Embedded Document Database for .NET
Specifies an embedded document database for.NET with zero-allocation I/O, C-BSON format, and ACID transactions.