文档切分为什么重要？chunk size 和 overlap 应该怎么选？
这道题考察的是你对RAG系统"地基"的理解。文档切分看似简单，却是决定召回质量的关键环节。下面我们逐个拆解。
板块1：文档切分决定了RAG的召回上限
RAG的流程大家都熟悉：文档→切分→向量化→检索→生成。
但很多人没意识到，"切分"这一步直接框死了召回的天花板。Embedding模型再强、LLM再聪明，如果chunk本身切得乱七八糟，检索阶段就不可能召回正确的内容。
类比一下：Chunk就像盖房子的地基。你可以在上面设计漂亮的屋顶、精致的装修，但地基没打好，整个房子都站不住。
具体来说，chunk的大小、边界、完整性，会直接影响：
- 检索时能不能命中用户问题的相关上下文
- 召回的内容是否包含完整的语义信息
- 生成阶段LLM拿到的是有效信息还是碎片噪音
所以数据处理管线做到位，比换一百个embedding模型都管用。
板块2：chunk size的选择是精度和完整性的博弈
选chunk size，本质上是在两件事之间找平衡：语义完整度 和 embedding精度。
chunk太小会有问题
想象一个200字的段落，里面讲了"问题背景→解决方案→效果结论"，你非把它切成50字一段。结果呢？每段都只有半个意思，检索时可能召回"背景"但漏掉"解决方案"。
太小的chunk会导致：
- 语义断裂，上下文丢失
- 关键信息被拆散，召回不完整
- 很多检索其实是在"盲人摸象"
chunk太大也会有问题
反过来，如果把整篇文章塞进一个1000 tokens的chunk，embedding模型会把所有信息压缩成一个向量。问题是：一个向量能代表一篇文章的所有主题吗？ 当然不能。
太大的chunk会导致：
- 语义稀释，多主题内容互相干扰
- embedding失真，"平均"后的向量失去区分度
- 检索时召回大量无关内容，增加LLM的处理负担
那到底怎么选？
通用场景下，400-512 tokens是经验上的"甜点区间"。这个范围既能保证语义的相对完整，又不会让embedding过度稀释。
但不同场景要有不同策略：
- 代码文档：建议~100 tokens，按函数/方法切
- 长篇论述：建议400-512 tokens，按段落切
- FAQ问答：保留完整问答对，一刀切都不行
类比一下：切西瓜。切太大吃不完浪费，切太小吃不过瘾。找到刚好一口能吃掉的大小，才是目标。
板块3：overlap解决跨chunk的边界丢失问题
假设有一段话：
"Transformer通过自注意力机制捕捉序列中的依赖关系，其核心是Query、Key、Value三个矩阵的计算。"
如果刚好在"核心是"后面切了一刀，检索"Query矩阵"的用户就可能拿到后半段，而漏掉了前面"Transformer通过自注意力机制"这个关键上下文。
这种跨chunk的边界丢失很常见，尤其是当关键信息跨越两个chunk时。
Overlap的解决方案
很简单：让相邻的chunk有重叠区域。比如：
- Chunk1： tokens 1-512
- Chunk2： tokens 450-962（重叠62个token）
这样即使关键信息刚好在边界处，下一个chunk也能捞回一部分上下文。
推荐的重叠比例是10%-20%。太高会引入大量冗余信息，检索质量反而下降；太低就起不到保护边界的作用。
再用一个类比：拼图。每块拼图边缘都有一小部分图案是"重复"的，这样拼的时候才能确保图案连贯不断裂。Overlap就是那个"重复的边缘"。
板块4：不同场景要用不同切分策略
前面说的都是通用原则，但实战中不同文档类型要用不同的切分策略。这才是面试官想听你展开的地方。
策略优先级：结构切分 > 语义切分 > 固定长度
1. 按文档结构切分是最高优先级
- Markdown文档：按H1、H2标题切
- PDF文档：按页切
- 代码文件：按函数、类、方法切
这样做的好处是保留了文档原有的逻辑结构，语义完整性最好。
2. 语义切分最精准但成本高
用NLP模型识别句子边界、段落主题，然后按语义相似度切分。效果好，但实现复杂，适合对精度要求极高的场景。
3. 固定长度是保底方案
按字符数或token数硬切，优点是简单稳定，缺点是可能破坏语义边界。仅在没有结构信息时使用。
具体场景的具体策略
| 场景 | 推荐策略 | 关键点 |
|---|---|---|
| 企业知识库 | 按文档结构切，保留标题层级 | 保留文档原有的组织逻辑 |
| 技术文档/代码 | 按函数/方法切，chunk size ~100 | 代码有强逻辑边界，按自然单元切 |
| FAQ | 保留完整问答对，不能切 | FAQ的核心是"问-答"完整对应 |
| 结构化数据（表格） | 整表保留，或按行拆 | 表格内容不能随意截断 |
一个容易踩的坑：很多人图省事，所有文档都用固定长度切分。这在Demo阶段没问题，但上线后迟早会碰到"检索结果答非所问"的问题。
更好的做法是Parent-Child Chunk策略：用小chunk（比如100 tokens）做检索，用大chunk（包含小chunk的父级段落）给LLM提供完整上下文。兼顾检索精度和上下文完整性。
面试怎么答
基础版
文档切分是RAG系统的地基，直接决定召回精度。chunk size太小会导致语义断裂，召回不完整；太大则语义稀释，embedding失真，通用场景推荐400-512 tokens。overlap用于解决跨chunk的边界丢失问题，推荐10%-20%。不同场景要用不同策略：技术文档按函数切，FAQ保留完整问答对，Markdown按标题层级切。按文档结构切分是最高优先级，而非简单按字符长度切。
加分版
数据处理管线做到位，比换一百个embedding模型都管用。chunk size的选择要结合具体场景：代码文档建议~100 tokens，通用文本建议400-512 tokens。对于需要保留完整上下文的重要信息，可以采用Parent-Child Chunk策略：小chunk负责检索精度，大chunk负责上下文完整性。overlap比例控制在10%-20%，既能保护边界又不会引入过多冗余。总结一句话：先按结构切，再按语义调，最后用overlap兜底。
一句话总结
文档切分是RAG召回质量的天花板：按结构切、用400-512的chunk、加10%-20% overlap，三步搞定。