分块切得对不对，决定检索灵不灵：把“文本分割的两个约束”落成分块策略清单
很多刚接触 RAG 的朋友，兴奋点往往在向量数据库选型、检索算法、Prompt 调优这些“高级环节”，而最容易跳过的，恰恰是看起来最朴素的数据准备阶段。但事实是：如果文档在入库前被切得稀碎或粘连，后面再强的检索模型也救不回来。这篇文章结合 Datawhale 的开源教程《all-in-rag》的章节体系，以及知乎文章《一文读懂：大模型RAG（检索增强生成）含高级方法》中对文本分割的拆解，把分块这件“脏活”整理成一份可操作的策略清单。
一、为什么数据准备阶段值得单独花时间
在《all-in-rag》的内容大纲中，数据准备被单独列为第二章，紧随 RAG 基础入门之后，包含“数据加载”与“文本分块”两节，之后才进入索引构建、检索优化、生成与评估。这个章节安排本身就在传递一个信号：分块是承上启下的枢纽——上游接多格式文档的加载与清洗，下游接向量嵌入和向量数据库。
知乎那篇文章对数据准备阶段的定位也很明确：它“一般是一个离线的过程”，主要包括数据提取、文本分割、向量化、数据入库等环节。其中数据提取又细分为数据加载（多格式数据加载、不同数据源获取）、数据处理（过滤、压缩、格式化）和元数据获取（提取文件名、Title、时间等关键信息）。
换句话说，分块不是孤立的一步，它前面有清洗和元数据提取做铺垫，后面有 embedding 和索引等着消费它的产出。跳过这一步的思考，等于让下游所有环节都在“垃圾进、垃圾出”。
二、文本分割的两个约束：token 限制 vs 语义完整性
知乎文章把文本分割需要考虑的因素总结为两条：
- embedding 模型的 Tokens 限制：超长的文本块无法被 embedding 模型完整编码，必须切到模型能接受的长度以内。
- 语义完整性对检索效果的影响：一个块如果把一句话、一个论点拦腰斩断，向量表达就会失真，检索时命中的可能是“半句话”。
这两个约束在方向上是冲突的：块越小越容易满足 token 限制，但语义越碎；块越大语义越完整，但容易撞上 token 上限，还会稀释向量中的核心语义。好的分块策略，本质上就是在这两个约束之间找平衡点。
三、两种基础切分方式的取舍
知乎文章列举了两种常见的文本分割方式，各自的优劣很典型：
句分割：以“句”为粒度切分，保留一个句子的完整语义，常见切分符包括句号、感叹号、问号、换行符等。
- 优点：语义天然完整，每个块都是一个自洽的语义单元，检索命中的内容可直接读懂。
- 局限：句子长短不一，可能过短导致上下文不足；对没有清晰句读的文本（如代码、表格）效果差。
固定长度分割：根据 embedding 模型的 token 长度限制，将文本切为固定长度（如 1024 或 512 个 tokens）。知乎文章明确指出，这种切分方式“会损失很多语义信息，一般通过在头尾增加一定冗余量（overlap）来缓解”。
- 优点：块长可控、处理统一，工程上最简单，适合快速搭建原型。
- 局限：切分点完全无视语义边界，容易把一句话切成两半；overlap 只是缓解手段，不是解决方案——冗余量设大了浪费存储和检索精度，设小了照样丢上下文。
两者的取舍可以概括为：句分割牺牲了长度均匀性换取语义质量，固定长度分割牺牲了语义质量换取工程简单。实际系统中往往不是二选一，而是组合使用。
四、可操作的分块策略清单
把上面的约束和取舍落成清单，你可以按顺序过一遍：
- 先做加载与清洗，再谈分块。按《all-in-rag》第二章的结构，多格式文档加载、数据过滤与格式化要先行。PDF 里残留的页眉页脚、乱码字符如果不清掉，会把切分符搞乱，块质量自然差。
- 元数据先行。按知乎文章的建议，在数据提取阶段提取文件名、Title、时间等关键信息。这样即使块被切小，标题、章节等元信息仍可附着在块上，检索命中后还能拼回完整语境。
- 确认你的 embedding 模型 token 上限。这是硬约束，分块长度必须留出余量，不要贴着上限切。
- 优先按语义边界切，再按长度兜底。先以段落、标题、句读符做天然切分点，得到语义完整的候选块；对于仍然超长的块，再降级用固定长度切分，并在头尾加冗余量缓解语义损失。
- 控制块长均匀性。避免出现大量“一个词的块”和“顶格的超长块”混杂，极端块长会让向量检索的召回分布失衡。
- 分块策略要配合下游评估来调。分块没有“一步到位”的参数，切多细、冗余多少，最终要看检索和生成环节的效果反馈来迭代。
五、适用范围与局限
这份清单主要适用于纯文本 RAG 的数据准备阶段，即知乎文章描述的“私域数据向量化后构建索引并存入数据库”的离线流程。它有几点明确的局限：
- 不覆盖多模态场景。《all-in-rag》大纲中有多模态嵌入、图文检索等内容，图片、表格的分块处理逻辑与纯文本不同，本文不展开。
- 不覆盖高级检索。混合检索、查询构建、Text2SQL、查询重构等进阶技术在《all-in-rag》第三、四章有专门讨论，分块只是它们的地基。
- 句分割对无句读文本失效。代码、日志、表格类内容需要专门的切分器，不能套用句号、问号这类切分符的思路。
- 参数没有万能默认值。块长、overlap 的最优值依赖具体语料、embedding 模型和业务问题，清单给的是方法框架，不是可以直接照抄的配置。
六、写在最后
RAG 系统的检索质量，很大一部分在数据入库那一刻就已被决定。与其在检索失败后反复调 Prompt，不如回到数据准备阶段，认真回答两个问题：我的块有没有超出 embedding 模型的 token 限制？我的块还保留着完整的语义吗？想清楚这两个约束，再按上面的清单逐条落地，分块这件“脏活”就会从 RAG 管道里最容易被忽略的环节，变成你最放心的环节。
参考资料：
- 《all-in-rag》（Datawhale，GitHub：datawhalechina/all-in-rag），第二章“数据准备”：数据加载与文本分块
- 知乎文章《一文读懂：大模型RAG（检索增强生成）含高级方法》，数据准备阶段对文本分割两个约束及句分割、固定长度分割的说明
参考资料
以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。
- GitHub - datawhalechina/all-in-rag: 🔍大模型应用开发实战一：RAG 技术全栈指南，在线阅读地址：https://datawhalechina.github.io/all-in-rag/ · GitHub
- 一文读懂：大模型RAG（检索增强生成）含高级方法
