RAG 文本切分：切多大才精准？一次讲清

什么是 RAG 文本切分

RAG 文本切分是把长文档拆成更小、更聚焦、可以独立检索的文本片段的过程。每个片段通常会被转换成向量，存入向量数据库，等待用户提问时被检索出来。

RAG 是 Retrieval-Augmented Generation 的缩写，中文叫“检索增强生成”。它相当于给大语言模型装上一个可以实时查询的外部知识库，让模型在回答前先查资料，而不是只依赖训练时记住的知识。

文本切分是 RAG 知识库建设的第一道工序。PDF、合同、产品手册、帮助中心、Markdown 文档和网页内容，通常都要先切成片段，再做 embedding 向量化和检索索引。

一句话总结：RAG 文本切分的目标，是让知识库里的每个 chunk 都足够小、足够准、又保留回答问题所需的上下文。

RAG 文本切分在整体流程里处于哪一步

RAG 的整体流程可以分为三步：文档预处理与入库、检索相关片段、基于片段生成答案。文本切分发生在第一步的最前端。

一个典型 RAG 系统会这样处理文档：

1. 文档预处理与入库：把原始文档切成小段，每段通过 embedding 模型转换成向量，再存进向量数据库。
2. 检索相关片段：用户提问后，系统把问题也转换成向量，找出最相似的 Top K 文本片段。
3. 生成答案：系统把命中的片段作为参考上下文，连同用户问题一起交给大语言模型生成答案。

如果第一步切得不好，后面的向量检索和生成都会受影响。检索系统可能找不到正确片段，也可能把大量无关内容送进提示词。

结论很直接：RAG 的答案质量不是只由大模型决定，文本切分会直接影响召回率、精确率、成本和响应速度。

为什么 RAG 一定要切分文档

RAG 需要切分文档，因为大模型输入窗口有限，整篇文档检索噪音太多，向量相似度也会被无关内容冲淡。

即使现在一些模型能处理很长的上下文，把一整本书或一整份说明书直接塞给模型仍然贵、慢、不稳定。更重要的是，长文档作为一条记录去做向量匹配时，会混入太多主题。

例如用户问：“这台咖啡机的保修期是多久？”如果整本咖啡机说明书只是一条向量记录，里面同时包含清洁方法、冲泡技巧、水箱容量、安全注意事项和配件说明。与“保修期”相关的信号会被其他内容稀释。

切分之后，说明书会变成多个主题明确的小块：

• 清洁与保养
• 使用操作指南
• 保修政策
• 水箱与配件
• 安全注意事项

当用户询问保修期时，系统更容易命中“保修政策”片段，并把准确答案交给大模型。

一句话总结：切分不是为了让文档变短，而是为了让每次检索都命中一个主题明确的信息单元。

RAG 文本切分的基本原则是什么

RAG 文本切分的基本原则是：每个片段离开原文后，仍然应该是一个信息完整、语义自洽、可以被检索和复用的最小单元。

“小”不等于按字数硬砍。切分真正要保护的是上下文。

例如技术文档里有一段话：

第一段：介绍背景。
第二段：说明关键参数。
第三段：基于以上参数，推荐设置如下。

如果切点正好落在“以上参数”之前，第三段单独检索出来后就会失去关键上文。用户和模型都不知道“以上参数”指什么。

好的切分通常满足四个条件：

• 语义边界清晰：尽量按标题、段落、列表、句子等自然边界切。
• 信息足够完整：片段里有定义、条件、步骤或结论，不只是半句话。
• 上下文可衔接：必要时通过重叠区或标题路径补充前后文。
• 长度可控：片段不能大到混入多个无关主题，也不能小到无法回答问题。

结论：RAG 切分不是“把文本切碎”，而是把长文档整理成一组可检索的知识卡片。

固定长度切分适合什么场景

固定长度切分适合快速处理大量普通文本，它通常按目标块大小切分，并优先保留段落、句子、空格等自然分隔符。

固定长度切分也常被称为递归字符分割。它通常会先设定一个目标块大小，例如 512 个字符或 512 个 token，然后按分隔符优先级逐层尝试：

1. 先按段落切。
2. 段落太长，再按句子切。
3. 句子仍然太长，再按空格、标点或字符切。
4. 最终确保每个片段不超过目标大小。

这种方法的优点是简单、快速、成本低，适合批量处理网页、普通说明文、日志、客服话术和结构不复杂的文档。

它的缺点是“不懂语义”。固定长度切分可能把一段紧密论证拆散，也可能把两个无关句子留在同一个片段里。

一句话总结：固定长度切分是 RAG 的默认起点，但不是所有文档的最优解。

语义切分为什么更精准

语义切分更精准，因为它根据文本主题是否发生变化来决定切点，而不是预先固定每块必须多长。

一种常见做法是先把文本按句子或小段拆开，再用 embedding 模型计算相邻句子的语义相似度。当相似度突然下降，通常说明话题发生了转换，这里就可能是自然分割点。

另一种更精细的做法，是使用一个专门的小模型判断两个分句是否属于同一个语义段落。如果属于同一主题，就合并；如果话题切换，就分开。

语义切分的优势是块内内聚性更高。每个片段更可能围绕一个定义、一个步骤、一个风险或一个结论展开，检索命中后也更容易被模型理解。

语义切分适合这些文档：

• 技术方案：一段内容里可能包含背景、论证、配置和结论。
• 研究报告：章节长、概念多，主题转换不总是靠标题表达。
• FAQ 和客服知识库：问题相似但答案细节不同，需要减少混淆。
• 法律和合同文本：条件、例外、适用范围必须保持完整。

需要注意的是，语义切分通常比固定长度切分更贵。它要额外调用 embedding 或模型判断，也需要更多调参和评估。

结论：当文档语义复杂、检索精度比处理成本更重要时，语义切分通常更值得使用。

结构化切分如何提升召回率

结构化切分会利用文档自带的层级结构，例如 HTML 标题、Markdown 标题、PDF 目录、表格标题和章节编号。它的优势是把作者已经划好的语义边界直接用于检索。

很多文档天然有结构：

• HTML 有 h1、h2、h3 标题。
• Markdown 有 #、##、### 标题。
• 产品手册有章、节、小节和步骤。
• PDF 可能有目录树、页码、表格和图注。

结构化切分不仅按结构切，还可以把层级路径写入片段开头。例如：

产品说明书 > 维护章节 > 清洁步骤

每次使用后，应取出滤网并用温水冲洗...

这样做有一个重要好处：即使片段正文里没有直接出现“维护”两个字，标题路径仍然能帮助向量检索或混合检索召回它。

一句话总结：结构化切分把“文档本来怎么组织”变成检索线索，能显著提升召回质量。

RAG 文本切分切多大才精准

RAG 文本切分的常见经验区间是 256 到 1024 个 token。精确大小要根据文档类型、用户问题粒度、检索 Top K、模型上下文窗口和成本预算一起调整。

块大小决定每个片段包含多少信息。太大和太小都会降低效果。

如果用户问题很短、答案通常是一句话，例如“保修期多久”，块可以小一些。如果用户问题需要完整步骤，例如“如何配置单点登录”，块应该更大，或者使用结构化切分加重叠区。

一个实用起点是：

• FAQ 和客服知识库：200 到 400 token。
• 产品手册和帮助中心：300 到 800 token。
• 技术文档和教程：500 到 1000 token。
• 法律、合同、制度：按条款切分，再控制在 500 到 1200 token。
• 学术论文和报告：按章节或小节切分，再用语义切分细化。

结论：不要只问“切多大”，更应该问“这个片段能否独立回答一个真实问题”。

重叠区应该设置多少

重叠区是相邻片段之间故意保留的一段重复内容。它的作用是修复切点附近的上下文断裂，让检索到的片段读起来更连贯。

例如块大小为 500 字，重叠区为 50 字。片段 A 的末尾 50 字，会出现在片段 B 的开头。这样被切断的句子、条件或段落，在下一个片段里还能找回上文。

常见重叠区可以这样设置：

重叠区不是越大越好。重叠太小，上下文容易断；重叠太大，会造成索引膨胀、重复召回和输入 token 浪费。

一句话总结：重叠区的目标是补上下文，不是复制整段文档。

固定切分、重叠修复和语义切分有什么区别

固定切分、重叠修复和语义切分的核心区别，是切点由什么决定。固定切分主要由长度决定，重叠修复用重复内容弥补切断问题，语义切分则尽量让切点落在主题边界。

以厨具说明书为例，原文有两句话：

热水模式下，最高温度可达到 120 摄氏度。
在该模式下，建议配合不锈钢滤网使用，以免硅胶部件变形。

如果固定切分恰好把两句话分到两个片段，第二个片段里的“该模式”就会指代不明。检索出来后，模型不知道它指的是热水模式。

加入重叠区后，第二个片段会带上上一块的最后一两句话，上下文更完整。

如果使用语义切分，系统更可能把这两句话归到同一个“热水模式使用注意事项”片段里，因为它们共同描述同一使用条件下的限制和建议。

结论：如果只是快速上线，可以从固定切分加重叠区开始；如果对准确率要求高，应逐步引入结构化切分或语义切分。

切分完成后还要做什么

文本切分完成后，通常还要添加元数据、筛选候选范围、执行向量匹配、排序结果，并把命中的片段拼接成提示词。

切分只是入库前的第一步。一个更完整的处理流程包括：

1. 添加元数据：给每个片段记录来源文档名、页码、URL、章节、版本、最后更新时间和权限范围。
2. 元数据筛选：检索前先按产品线、语言、时间、权限或文档类型缩小候选范围。
3. 向量相似度匹配：在候选片段中找出和用户问题最接近的内容。
4. 结果排序：按相关性得分排序，也可以保留原文顺序，让上下文更自然。
5. 插入分隔说明：在片段之间加入来源和分隔符，提醒模型这些信息来自不同位置。
6. 拼接提示词：把最终片段和用户问题一起交给大模型。

实际工程里，很多 RAG 系统还会加入关键词检索、重排序模型、去重、权限校验和引用生成。文本切分越清晰，后续步骤越容易稳定。

一句话总结：切分决定候选片段的质量，元数据和排序决定最终送给模型的上下文质量。

不同文档应该怎么选择切分策略

不同文档应该按内容结构、答案粒度和风险要求选择切分策略。没有一套参数可以适用于所有 RAG 知识库。

下面是一个可直接用于项目评估的选择表：

判断切分是否合适，可以用三个问题：

1. 这个片段单独拿出来，是否能被人理解？
2. 这个片段是否围绕一个明确主题？
3. 这个片段是否小到足够精准，不会把无关信息混进检索结果？

如果三个问题都能回答“是”，这个切分通常就是可用的。

RAG 文本切分有哪些常见错误

RAG 文本切分常见错误包括只按字数硬切、忽略文档结构、重叠区过大或过小、缺少元数据、没有用真实问题评估效果。

常见问题可以分成五类：

评估切分效果时，不要只看向量相似度分数。更应该准备一组真实用户问题，检查系统能否召回正确片段，并让模型基于片段给出完整答案。

结论：文本切分需要用真实问题验证，而不是只靠默认参数。

常见问题

RAG 文本切分和普通分段有什么区别

RAG 文本切分不是排版意义上的分段，而是检索意义上的知识单元划分。它要求每个片段能被向量化、能被检索、能作为模型回答问题的上下文。

Chunk Size 应该按字符算还是按 token 算

工程上更建议按 token 算，因为大模型上下文窗口和调用成本通常按 token 计算。中文场景也可以先用字符数做粗略控制，但最终评估应回到 token 数和检索效果。

RAG 文本切分越小越精准吗

不是。片段太小会丢失上下文，导致一个完整步骤、一个条款条件或一个技术说明被切散。精准切分的目标是“最小但完整”，不是越短越好。

重叠区越大越好吗

不是。重叠区太大会让索引变大、重复内容变多、检索结果相互冗余，还会浪费输入 token。重叠区只需要覆盖切点附近必要的上下文。

固定长度切分还能不能用

可以。固定长度切分适合作为快速上线的基线方案，尤其适合结构简单、主题变化不复杂的文档。对高价值知识库，可以在固定切分基础上加入标题路径、重叠区、语义切分和重排序。

怎么判断 RAG 切分参数是否合适

最可靠的方法是用真实问题测试。准备一组用户会问的问题，检查 Top K 检索结果是否包含正确片段，再观察大模型能否基于这些片段生成准确答案。

总结

RAG 文本切分是把长文档拆成可检索、可向量化、语义完整的小片段的过程。它发生在知识库入库的最前端，却会影响后续检索、排序、提示词拼接和最终回答质量。

切分大小没有统一答案。一个常用起点是 256 到 1024 个 token，并配合 10% 到 20% 左右的重叠区，再根据文档类型和真实问题评估结果调整。

最终目标始终不变：让每个片段离开原文后，依然是一个信息完整、语义自洽的最小单元；同时又要小到足够精准，不会把无关内容混进检索结果。

做好文本切分，RAG 才能从“能搜到”变成“搜得对”，大模型也才更可能给出值得相信的答案。