RAG 系统中为什么要进行文档切割？有哪些切割策略？
这道题考的是 RAG 系统中数据处理的核心理念——怎么把文档切得刚刚好，让检索既能命中关键信息，又不会引入一堆废话。面试官想看你是不是真的理解"粒度"这个概念，而不是只会背五种策略的名字。
我从四个方面来讲：切割的本质逻辑、五大切割策略、按文档类型选策略、常见坑和实战参数。
一、切割的本质：找准检索粒度
先问自己一个问题：为什么要切？
因为大模型和 Embedding 模型都有输入长度限制。一篇万字长文直接扔进去，Embedding 模型会直接傻掉。退一步说，就算模型吃得下，整篇文档做检索会引入太多无关信息，生成的时候模型被噪声淹没。
但切太小也不行。一个字一个 chunk，检索是精准了，但上下文全丢了，生成的时候模型根本不知道这句话在说什么。
好的切割 = 让每个 chunk 既有独立的语义，又能被精准召回。
类比一下：图书馆找书。整本书太大，你不会抱着书架找；一个字太小，你根本不知道在说什么。章节是最合适的单元——有完整的意思，又能精准定位。
过大块的痛点：噪声太多，检索相关性下降，生成质量差。
过小块的痛点：上下文断裂，重要信息被腰斩，回答不完整。
这块的核心就一句话：切割是在"检索粒度"和"语义完整性"之间找平衡点。
二、五大切割策略
1. 固定长度切割
最简单，按字数或 token 数硬切。比如每 500 token 一切。
优点：实现简单，适合对结构没要求的场景。
缺点：简单粗暴，经常把一句话、一段逻辑拦腰斩断。"今天天气很好，我们去公园"——正好卡在"公园"前面，那这个词就丢了。
适用场景：纯文本、快速 POC、对质量要求不高的场景。
2. 递归字符切割
固定长度是"一刀切"，递归字符是"先试着按段落切，段落太长就按句子切，句子还长就按逗号切"。
代码里常见的是按 \n\n、\n、 这些分隔符层层递进。
优点：尽量保持语义完整性，不会把一句话劈成两半。
缺点：实现相对复杂，分隔符选择需要调优。
适用场景：通用文本、格式不那么规整的文档。
3. 语义切分
这是"聪明"的切法。先用 Embedding 模型给文本打标签，找出语义相似的内容，然后按意义聚类分组。
简单说：语义相近的放一起，不相关的分开。
优点：切出来的 chunk 语义最完整，检索相关性最高。
缺点：计算成本高，需要多调用几次 Embedding 模型。另外切分结果不好预测，生产环境调试麻烦。
适用场景：对质量要求高、文本语义密度不均匀的场景。
4. 文档结构切分
有些文档天然有结构——Markdown 的标题层级、HTML 的标签、代码的函数类。
这种切法就是顺着文档的天然边界走，按标题、按段落、按函数切。
优点：完美保留结构信息，切出来的块语义完整。
缺点：过度依赖文档格式，格式乱的文档处理起来麻烦。
适用场景：Markdown、HTML、代码文件。
5. Parent-Child 切分
这是最近两年比较火的策略。分两层：
- Parent chunk：大块，保留完整上下文
- Child chunk：小块，用于实际检索
检索的时候用 Child，召回后把对应的 Parent 一起给大模型。
优点：兼顾检索精度和上下文完整性。
缺点：系统复杂度上升，需要维护两层数据。
适用场景：上下文依赖强的场景，比如法律文档、技术文档。
策略对比一句话：
固定长度是"蛮力"，递归字符是"尽量温柔"，语义切分是"按意义分"，结构切分是"按模板分"，Parent-Child 是"大小配合"。
三、按文档类型选策略
不同文档长得不一样，切法也要不一样。
Markdown / HTML
这类文档有明确的层级结构——标题、正文、列表、代码块。
推荐策略：结构感知切分。按 # 标题层级或者 HTML 标签切，保持每个块对应一个完整的内容单元。
不要硬按字数切，不然"## 小标题"和下一段"## 小标题"会被合并，结构全乱了。
代码
代码有天然边界——函数、类、方法。
推荐策略：按函数/类级别切，每个 chunk 对应一个完整的函数或类。
切太小：变量定义和使用被拆开，检索到了也看不懂。
切太大：整个文件几千行，上下文太长，检索精度下降。
实战建议：代码 chunk 大小约 100 token 左右，比文本小很多。
论文 / 长文章
论文有固定结构——摘要、引言、方法、实验、结论。
推荐策略：按章节切，保留每个章节的完整性。摘要和结论单独切，因为这两个地方信息密度最高。
表格
表格是个特殊问题。硬按字数切会把表格拆得稀碎，列名和数值被分到不同的 chunk。
推荐策略：表格要结构化抽取。可以把表格转成 JSON 格式，用列名作为 metadata，保留表格的完整性。
如果表格太大（比如上百行），可以考虑按行切，但要把列名作为 context 带上。
总结一下：Markdown/HTML 用结构切，代码按函数切，论文按章节切，表格要结构化处理。
四、常见坑和实战参数
三大语义丢失问题
1. 业务逻辑截断
有些业务逻辑跨段落甚至跨页。比如"如果用户满足条件A，且未超过期限B，则执行操作C"——这三个条件如果被切到三个 chunk，检索的时候只能召回一个，回答就错了。
应对：用重叠切分，或者在 metadata 里标注"前置条件"。
2. 专有名词截断
"我们公司自主研发的XXX技术"——"XXX技术"被拦腰截断，检索的时候根本搜不到。
应对：在切分前做预处理，把专有名词、人名、术语保护起来，不在中间换行。
3. 表格结构破坏
表格被硬切后，单元格和列名对不上，生成的时候就会出现"张冠李戴"。
应对：表格独立存储，用结构化方式处理，不参与普通文本的切分逻辑。
实战参数建议
| 文档类型 | chunk 大小 | 说明 |
|---|---|---|
| 通用文本 | 400-512 token | 通用场景下的经验值，兼顾语义完整和检索精度 |
| 代码 | ~100 token | 代码语义密集，需要更小的粒度 |
| 表格 | 按行或整体 | 保持表格结构完整 |
重叠比例：相邻 chunk 之间重叠 10%-20%。这样能避免边界信息丢失——上一段的结尾和下一段的开头有重叠，检索的时候不会漏。
重叠切分就像搬家的时候，单本书搬走，但每本书记得按顺序排好，相邻的书有一点点重叠内容，方便你知道上下文。
面试怎么答
基础版（100-150字）
文档切割是为了解决 Embedding 模型输入限制和检索精度的矛盾。切太大引入噪声，切太小丢失上下文，所以要找准粒度。
主流策略有五种：固定长度、递归字符、语义切分、文档结构切分、Parent-Child。固定长度最简单但容易截断语义；递归字符尽量保持语义完整；语义切分按意义聚类，质量最高但成本大；结构切分适合有明确格式的文档；Parent-Child 用小块召回大块提供上下文。
实战中通用文本建议 400-512 token，代码约 100 token，相邻 chunk 重叠 10%-20%。
加分版（在基础版上加这些）
点明本质：切割不是机械切分，是"为检索创造合适粒度"。知道这个本质，策略选择就不是死记硬背了。
说出具体坑：能提到业务逻辑截断、专有名词截断、表格破坏这三大问题，说明你真正踩过坑、想过解决方案。
针对具体文档类型说策略：能讲出 Markdown 按标题层级切、代码按函数切、表格结构化抽取，比泛泛而谈加分很多。
引用金句："把数据处理管线做到位，比换一百个 embedding 模型都管用。"这句话面试官听了会心一笑。
一句话总结
文档切割的核心是在检索粒度和语义完整性之间找平衡，五种策略各有优劣，按文档类型选对方法比硬套公式重要得多。