Chunking
A preprocessing technique in RAG systems that splits long documents into smaller text segments. Common strategies include fixed-size splitting, paragraph splitting, section splitting, and semantics-based dynamic segmentation. The granularity of the resulting chunks directly affects retrieval quality.
Core Facts
RAG tutorials rarely cover a key issue: chunk boundaries are almost always wrong; when documents are chunked and embedded, assumptions are actually being made about which context belongs together, and these assumptions often do not hold.
The core process of Retrieval-Augmented Generation (RAG) consists of three steps: chunking and vectorizing knowledge base documents for storage, retrieving the most semantically relevant segments, and injecting those segments as context into the LLM prompt.
A complete RAG pipeline consists of four stages: document chunking, vector storage, reranking, and retrieval-to-generation.
Timeline (last 90 days)
When chunks are too small, they lose context; the retrieved passage reads fine on its own, but the LLM cannot answer, because the answer's basis falls in other chunks that were not recalled.
Chunking is essentially a trade-off between "retrieval precision" and "context completeness," and this trade-off has no universal optimal solution; it depends on whether the query leans toward details or toward generalization.
When chunks are split across semantic boundaries, with the definition in one chunk and the example in another, only one of them is recalled, and the LLM gets only half the answer.
The correct chunking strategy depends on the structure of the source document and the form of the query, not on some blog's default number.
Chunking is the step most often glossed over in RAG tutorials, and most tutorials only suggest splitting documents into 500-token chunks, but poor retrieval performance often stems from exactly this.
RAG tutorials rarely cover a key issue: chunk boundaries are almost always wrong; when documents are chunked and embedded, assumptions are actually being made about which context belongs together, and these assumptions often do not hold.
In chunking, chunks that are too small lose contextual semantics, while chunks that are too large cause vector similarity to be diluted and irrelevant content to be mixed in.
Fixed-size chunking breaks semantic integrity, while paragraph- or semantic-boundary-based chunking requires more complex parsing logic.
Mainstream chunking strategies fall into three categories: fixed-length chunking, semantics-aware chunking, and sliding window chunking
RAG chunking quality directly determines retrieval recall rate; if a complete argument is cut across two chunks, vector retrieval may only recall half the content, causing the LLM to answer based on incomplete information.
9 more timeline events
All Facts (20)
RAG tutorials rarely cover a key issue: chunk boundaries are almost always wrong; when documents are chunked and embedded, assumptions are actually being made about which context belongs together, and these assumptions often do not hold.
70%VerifiedThe core process of Retrieval-Augmented Generation (RAG) consists of three steps: chunking and vectorizing knowledge base documents for storage, retrieving the most semantically relevant segments, and injecting those segments as context into the LLM prompt.
70%VerifiedA complete RAG pipeline consists of four stages: document chunking, vector storage, reranking, and retrieval-to-generation.
65%Unverified知识库文档在入库前需要经过分块（Chunking）处理，常见策略包括固定长度分块、按句子/段落分块、递归字符分块，以及父子块策略
90%Unverified处理长文本时，工程化的分块处理（Chunking）和滑动窗口（Sliding Window）策略是标准解法
90%Partially VerifiedThe overlap in text chunking is typically set to 10%–20% of the chunk_size.
65%UnverifiedChunking is essentially a trade-off between "retrieval precision" and "context completeness," and this trade-off has no universal optimal solution; it depends on whether the query leans toward details or toward generalization.
50%UnverifiedChunking is the step most often glossed over in RAG tutorials, and most tutorials only suggest splitting documents into 500-token chunks, but poor retrieval performance often stems from exactly this.
50%UnverifiedThe correct chunking strategy depends on the structure of the source document and the form of the query, not on some blog's default number.
50%UnverifiedWhen chunks are too small, they lose context; the retrieved passage reads fine on its own, but the LLM cannot answer, because the answer's basis falls in other chunks that were not recalled.
50%UnverifiedWhen chunks are split across semantic boundaries, with the definition in one chunk and the example in another, only one of them is recalled, and the LLM gets only half the answer.
50%UnverifiedIn chunking, chunks that are too small lose contextual semantics, while chunks that are too large cause vector similarity to be diluted and irrelevant content to be mixed in.
50%UnverifiedFixed-size chunking breaks semantic integrity, while paragraph- or semantic-boundary-based chunking requires more complex parsing logic.
50%UnverifiedMainstream chunking strategies fall into three categories: fixed-length chunking, semantics-aware chunking, and sliding window chunking
50%UnverifiedRAG chunking quality directly determines retrieval recall rate; if a complete argument is cut across two chunks, vector retrieval may only recall half the content, causing the LLM to answer based on incomplete information.
50%UnverifiedThe granularity of chunk splitting directly affects retrieval quality: segments that are too long introduce noise, while segments that are too short may lose context.
50%UnverifiedDocument chunk sizes that are too large introduce noise, while sizes that are too small lose context, requiring adjustment of chunk size and overlap length based on document type.
50%UnverifiedChunk size is typically recommended to be between 256 and 512 tokens, with a 10–15% overlap region preserved.
50%UnverifiedFixed-size chunking may forcibly split a complete answer across different chunks, destroying semantic integrity.
50%Unverified文档分块中通常设置10%-20%的重叠率以确保跨块信息不丢失
50%