检索是 RAG 系统的搜索引擎，分块则是这个搜索引擎的基础。分块太长、太短、有噪声、切错了位置——随便犯哪个错LLM 都会有问题。行业里有句话流传很广："分块决定了 RAG 质量的 70%。"
这个说法不夸张：好的分块让检索器拿到完整、有上下文、真正相关的信息；差的分块把文档打成碎片，上下文断裂，LLM 只能靠"编"来填补空白。
什么是分块？
RAG 的起点是文档收集与摄取：把所有原始材料（文档、文章、知识库条目）汇聚到一起。在进入检索环节之前，这些文档要经过文本分块处理也就是切分成更小的、有意义的片段。
每个分块应当是连贯且自包含的，这样检索器才能在面对查询时快速定位、排序，并返回最相关的信息。
分块就是在生成 Embedding 之前，把大段文本拆成更小语义单元的过程。检索器真正搜索的对象而不是整篇文档就是这些分块。
分块做得好，文档中的内容就能被干净地捕获，上下文得以保留LLM 能做出有意义的推理。分块做得差，语义被割裂检索充满噪声。向量存储、Embedding 模型、Reranker——这些统统排在分块之后，分块才是真正的起点。
固定大小分块
这是最简单的方式。按预设的字符数或 Token 数直接切分，比如每 500 个 Token 一块完全不管句子和段落的边界在哪。
速度快，行为可预测，处理大规模、结构混乱的数据集时很实用。但缺点也很明显——语义经常被拦腰切断。一个句子在这个分块里开了头，到下一个分块才结束，Embedding 的语义表达力就会打折扣。
实践中一般会在相邻分块之间设置一定的重叠来缓解这个问题：
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50
)
chunks = splitter.split_text(long_text)
切分文本时，连续的分块之间通常会加入一小段重叠区域来维持上下文的连贯。所谓重叠，就是前一个分块的尾部几句话，在下一个分块的开头再出现一次。
这么做是为了防止跨越分块边界的关键信息丢失。没有重叠的话，检索器可能只拿到部分内容LLM 因此漏掉了关键上下文，给出残缺甚至误导性的回答。重叠量一般控制在分块长度的 10% 到 20%，在冗余和效率之间找一个平衡点。
固定大小分块适合的场景包括日志文件、邮件、代码仓库，以及结构参差不齐的大型语料库。
基于句子的分块
这种方式按完整句子来划分文本，而不是按任意长度一刀切。每个分块至少包含一个或多个完整的句子，语法完整，语义连贯。
好处是每个分块都是一个有意义的思想单元。检索器向 LLM 返回的信息更精确、更易理解，碎片化回答的风险降低不少。实际使用中通常也会搭配小幅重叠，进一步保证分块之间的衔接。
基于段落的分块
以完整段落为单位切分，不再拘泥于单个句子或固定 Token 数。这种方式天然保留了文档的结构和行文节奏，检索器更容易抓到完整的想法。
每个分块往往对应一个独立的主题或子主题，LLM 处理起来更从容，也更容易给出准确的回答。对长篇文档、研究论文、综述类文章来说，段落级分块效果不错。和句子级分块一样，也可以加重叠来保持连贯。
语义分块
语义分块的切入点不是长度，而是语义本身。它利用 Embedding 或相似度分数来识别文本中天然的断裂点——主题切换、上下文转折、章节边界。
产出的分块语义清晰度更高，边界和语义对齐，检索质量有明显提升，尤其在知识库、技术文档、结构化文章这类内容上效果突出。代价是计算开销更大而且分块长度不一致，后续处理需要额外考虑。
from langchain_experimental.text_splitter import SemanticChunker
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("all-MiniLM-L6-v2")
chunker = SemanticChunker(model, breakpoint_threshold=0.4)
chunks = chunker.split_text(long_text)
如果文档质量高、主题流转有明确脉络，语义分块往往是精度最高的选择。
递归分割
递归分割是固定大小和语义分块之间的一个折中方案。核心思路是优先尊重文档结构，只有在必要时才进一步拆分。
具体做法是先尝试按标题切分。如果某个章节还是太长，就按段落切。段落还不够就按句子。句子仍然超限，最后才按字符兜底。这样得到的分块既保有语义完整性，尺寸也在可控范围内。
recursive_splitter = RecursiveCharacterTextSplitter(
separators=["\n## ", "\n### ", "\n", ". ", ""],
chunk_size=600,
chunk_overlap=80
)
chunks = recursive_splitter.split_text(long_doc)
开发者文档、技术手册、学术论文、研究报告——凡是层级结构明确的内容，递归分割都很适合。
滑动窗口分块
有些文本的语义天然是跨句分布的。法律合同、科学论文、长段论证，一个完整的意思可能横跨好几个句子。滑动窗口就是为这种场景设计的。
它不生成彼此独立的分块，而是创建相互重叠的窗口。比如窗口大小 400 Token，每次滑动 200 Token，这样相邻的分块之间有一半的内容是共享的，语义在边界处不会断裂。
上下文保持得很好，但分块数量会膨胀，存储和检索的成本都会上升。
法律 RAG、金融分析、医学文献检索、合规审查——这些领域用滑动窗口的比较多。
层次化分块
层次化分块是一个多层级的架构：小分块负责细粒度精确检索，中等分块支撑平衡的推理，大分块维持全局上下文。
检索时，系统先用小分块锁定精确位置，再把关联的大分块拉进来补充完整上下文。这种组合能有效压制幻觉，提升推理的深度。
企业级 RAG 系统和 LlamaIndex 这类多粒度检索框架，背后都有层次化分块的影子。
实践中常见的分块失误
多数 RAG 项目翻车根源都是分块层面的问题。分块过大模型被不相关的细节淹没。分块过小语义丧失殆尽。句子被拦腰切断、不相关的段落被混到一个分块里，Embedding 质量直接垮掉。没有重叠，上下文断裂。没有元数据，检索器找不到方向。还有一个常见错误——所有类型的文档套用同一种分块策略。
分块没有万能方案。政策文件和教科书不一样，通话记录和研究论文不一样。策略必须跟着文档类型和检索任务走。
总结
分块不是一个可有可无的预处理环节，它是 RAG 管道的脊梁。好的分块是一个有意义的、自包含的知识单元；差的分块是一个孤零零的碎片，把 LLM 带向歧途。
检索是引擎分块是燃料。燃料的质量决定了整个系统是输出干净、可靠的结果，还是不断产出噪声和幻觉。LLM 本身再好，也救不了烂分块。
https://avoid.overfit.cn/post/e6520bd283254415ae61cfa28fb2ef32
作者：Abinaya Subramaniam
