RAG效果差，很多时候不是模型不行，而是文档切错了

本文是「RAG 面试通关」系列的第 2 篇。 上一篇：第 1 篇《面试官问我 RAG 是什么？我不可能只说「检索增强生成」》 下一篇预告：第 3 篇《RAG 语义匹配：Embedding 模型到底怎么选？》

上周帮一个学员模拟 RAG 面试。

我问他：

“RAG 里为什么要做文档切分？”

他说：

“因为文档太长，模型放不进去，所以要切小一点。”

这个回答不能说错。

但如果你在面试里只答到这一步，基本就停留在入门水平。

因为真正做过 RAG 的人都知道，文档切分不是一个简单的预处理步骤。

它会直接影响后面的召回、重排、生成和最终回答质量。

很多 RAG 项目效果差，不是大模型不行，不是向量库不行，也不是 Prompt 不行。

而是文档一开始就切错了。

今天这篇，我们就把 RAG 面试里最容易被问到的文档切分问题，一次讲透。

如果你是准备面试 AI Agent、RAG、LLM 应用开发的同学，这一篇建议收藏。

01 新手最容易踩的坑

一、面试官问：RAG 中文档为什么要切分？

这个问题很基础，但非常容易答浅。

新手回答

文档太长，大模型上下文窗口有限，所以要把文档切成小块，方便 Embedding 和检索。

高手回答

RAG 中文档切分主要解决三个问题。

第一，解决模型上下文窗口限制。

原始文档可能是几十页 PDF、上百页 Word，不能全部塞进模型。

第二，提升检索粒度。

如果整篇文档作为一个单位去向量化，用户问一个很具体的问题时，系统很难精准命中相关内容。

第三，降低噪声。

大块文档里会混入很多无关信息，召回后塞给大模型，会干扰模型判断。

所以文档切分的本质，不只是“把长文档变短”，而是把知识整理成适合检索、适合理解、适合生成的最小信息单元。

这句话面试时可以直接用。

文档切分不是为了切而切，而是为了让检索系统更容易找到答案，让大模型更容易基于答案生成回复。

二、Chunk 到底是什么？

Chunk 就是文档被切分后的文本块。

比如一份公司制度文档有 20 页。

你可以按段落切，也可以按标题切，也可以按固定字数切。

切完之后，每一个小文本块就是一个 Chunk。

RAG 系统后面通常会对每个 Chunk 做 Embedding，然后把向量和原始文本一起存进向量数据库。

用户提问时，系统不是去整篇文档里找答案，而是先找最相关的几个 Chunk，再把这些 Chunk 作为上下文交给大模型。

所以你可以把 Chunk 理解为 RAG 系统里的“知识卡片”。

每张卡片不能太长，也不能太短。

太长，信息太杂，检索不准。

太短，语义不完整，模型看不懂。

这就是文档切分最难的地方。

02 Chunk 参数怎么权衡

三、Chunk Size 是不是越小越好？

不是。

这是面试里非常常见的坑。

很多新手一听说要提升检索精度，就会说：

“那我把 Chunk 切小一点，不就更精准了吗？”

听起来有道理，但实际不一定。

Chunk 太小的问题

如果 Chunk 太小，很容易丢上下文。

比如原文是：

“本公司的年假规则如下：员工入职满一年后，每年享有 5 天年假。入职满三年后，每年享有 10 天年假。年假不可跨年度累计。”

如果你切得太碎，可能变成：

Chunk 1：本公司的年假规则如下。

Chunk 2：员工入职满一年后，每年享有 5 天年假。

Chunk 3：入职满三年后，每年享有 10 天年假。

Chunk 4：年假不可跨年度累计。

用户问：

“入职三年的员工年假可以累计到下一年吗？”

答案其实需要同时结合 Chunk 3 和 Chunk 4。

如果只召回 Chunk 3，模型只能回答有 10 天年假，但可能漏掉不可累计。

这就是 Chunk 太小带来的语义断裂。

Chunk 太大的问题

Chunk 太大也有问题。

比如一个 Chunk 里同时包含年假制度、报销制度、加班制度、离职流程。

用户问年假，系统召回了这个大 Chunk。

虽然答案在里面，但无关内容太多。

大模型需要在一堆噪声里找重点，回答就容易跑偏。

同时，Chunk 太大会占用更多上下文窗口，导致能塞进去的检索结果变少。

所以 Chunk Size 没有固定标准。

它要根据文档类型、问题粒度、Embedding 模型能力、上下文窗口大小和业务场景共同决定。

面试时不要说“越大越好”或“越小越好”。

更好的回答是：

Chunk Size 的选择核心是平衡语义完整性和检索精度。太小会丢上下文，太大会引入噪声，实际项目里通常需要结合测试集反复评估。

四、Chunk Overlap 有什么作用？

Overlap 指的是相邻 Chunk 之间保留一部分重复内容。

举个例子。

如果每个 Chunk 是 500 字，Overlap 是 100 字。

那第一个Chunk 覆盖第 1 到 500 字，第二个Chunk 可能从第 401 字开始，到第 900 字结束。

中间重复的 100 字，就是 Overlap。

它的作用是减少切分边界造成的信息丢失。

因为真实文档里的答案不一定刚好落在一个完整 Chunk 里面。

很多时候，问题的条件在上一段，答案在下一段。

如果没有 Overlap，这两个信息可能被硬切开。

有了 Overlap，边界附近的信息会被保留到相邻 Chunk 里，召回时更容易拿到完整语义。

但 Overlap 也不是越大越好。

Overlap 太大，会带来三个问题。

第一，存储成本增加。

重复内容越多，需要存的 Chunk 越多。

第二，检索结果重复。

用户问一个问题，可能召回好几个高度相似的 Chunk，浪费 TopK 名额。

第三，上下文浪费。

最后塞给大模型的内容里重复信息太多，会挤占真正有用的信息。

所以 Overlap 的合理做法是：

根据文档结构和答案跨段概率来设置，不是固定套一个数。

如果是规章制度、说明文档，段落之间依赖比较强，可以适当增加 Overlap。

如果是 FAQ，每个问答本身就比较独立，Overlap 可以很小，甚至不需要。

五、固定长度切分和语义切分有什么区别？

固定长度切分，就是按字数或 Token 数切。

比如每 500 字切一段，每段重叠 100 字。

它的优点是简单、稳定、容易实现。

缺点是容易切断完整语义。

比如一个标题下面有三段解释，固定长度切分可能把标题和正文切开，也可能把一个完整步骤切成两半。

语义切分，是尽量按照自然语义边界切。

比如按标题、段落、章节、列表、问答对来切。

它的优点是语义完整，特别适合结构化比较明显的文档。

缺点是实现更复杂，需要先做好文档解析和结构识别。

面试时可以这样回答：

固定长度切分适合快速搭建 Demo，语义切分更适合生产系统。真正上线的 RAG 系统通常不会只靠固定长度切分，而是结合标题层级、段落结构、Token 限制和业务语义来做混合切分。

这句话很重要。

因为真实项目里很少有一种切分方法能解决所有问题。

更常见的是组合策略。

先按文档结构粗切，再在过长的段落里按 Token 做二次切分，最后加上必要的标题、路径、页码等元信息。

03 复杂文档处理真相

六、不同文档类型应该怎么切？

这部分特别适合在面试里体现项目经验。

很多人只会说“按 500 字切”，但面试官真正想听的是，你有没有处理过不同格式的复杂文档。

下面这张表可以直接记。

注意，PDF 是最容易出问题的。

因为 PDF 看起来是文档，实际更像一张排版后的页面。

它里面的文字顺序不一定等于人眼看到的阅读顺序。

如果是双栏论文，解析器可能先读左栏第一行，再读右栏第一行，最后拼出一段完全混乱的文本。

这种情况下，你后面 Embedding 模型再好也没用。

因为输入本身已经乱了。

所以复杂文档处理里，第一步不是切分，而是解析和清洗。

顺序应该是：

文档解析，文本清洗，结构识别，语义切分，元数据补充，质量抽检。

七、表格数据怎么处理？

表格是 RAG 文档处理中非常容易翻车的地方。

新手常见做法是直接把表格按行提取成文本。

但这样经常会丢掉表头。

比如原表格是：

如果抽取后只剩：

普通员工，满一年，5 天。

普通员工，满三年，10 天。

模型可能还能猜出意思。

但如果表格更复杂，缺少表头就会非常危险。

更好的做法是把每一行转成带字段名的文本。

比如：

岗位：普通员工；工作年限：满一年；年假天数：5 天。

岗位：普通员工；工作年限：满三年；年假天数：10 天。

如果表格有标题，也要一起保留。

比如：

表格标题：员工年假规则。

岗位：普通员工；工作年限：满三年；年假天数：10 天。

这样检索和生成都会更稳定。

如果是复杂表格，比如合并单元格、多级表头、财务报表，就不能简单按行切。

需要先还原表格结构，再根据业务查询方式决定怎么转文本。

有些场景甚至不适合直接用普通 RAG 解决，而应该走结构化查询，比如 SQL 或专门的数据分析链路。

这也是面试里很加分的一点。

你要敢说：不是所有表格都适合直接切成 Chunk。

八、如何保留文档结构信息？

这是新手最容易忽略的一点。

很多人切分时只保留正文，不保留标题。

结果 Chunk 本身看起来很完整，但脱离标题之后就不知道它属于哪个主题。

比如一个 Chunk 内容是：

“员工应在系统中提交申请，经直属负责人审批后生效。”

这句话单独看，根本不知道是在说请假申请、报销申请，还是离职申请。

如果保留标题路径，就清楚多了。

文档路径：员工手册 > 请假制度 > 年假申请流程

正文：员工应在系统中提交申请，经直属负责人审批后生效。

这样 Embedding 时语义更完整，召回时也更容易命中。

实际项目中，常见的元数据包括：

1. 文档 ID
2. 文档标题
3. 章节标题
4. 标题层级路径
5. 页码
6. 段落编号
7. 来源链接
8. 创建时间和更新时间
9. 权限信息
10. 业务标签

这些信息有两个作用。

第一，帮助检索。

比如用户问“报销流程”，标题路径里有“报销制度”的 Chunk 更容易被召回。

第二，帮助展示引用来源。

企业级 RAG 通常不能只回答一句话，还要告诉用户答案来自哪份文档、哪一页、哪一节。

所以文档结构信息不是锦上添花，而是生产级 RAG 的基础能力。

九、一个答案分散在多个 Chunk 中怎么办？

这是 RAG 里非常常见的问题。

用户问的问题，可能不是一个 Chunk 能回答的。

比如用户问：

“试用期员工离职需要提前几天通知，公司是否需要支付年终奖？”

这个答案可能分散在两个章节。

一个在离职制度里。

一个在薪酬福利制度里。

如果只召回其中一个，答案就不完整。

解决这类问题，可以从几个方向入手。

第一，合理设置 Chunk 和 Overlap

不要把强相关内容切得太碎。

如果一个小节本身就围绕同一个主题，尽量保持在同一个 Chunk 里。

第二，使用 Parent Document Retriever

可以先切小 Chunk 用来精准检索。

命中小 Chunk 后，再把它所属的更大父文档片段一起拿出来给模型。

这样既保留检索精度，又保留上下文完整性。

简单理解就是：

小块负责找得准，大块负责讲得全。

第三，使用多路召回

对于复杂问题，可以同时使用向量召回、关键词召回、标题召回、规则召回。

这样能提高不同信息片段被找回来的概率。

第四，让模型做问题拆解

如果用户问题包含多个子问题，可以先拆成多个检索问题。

比如把“试用期员工离职需要提前几天通知，公司是否需要支付年终奖？”拆成：

1. 试用期员工离职提前通知规则是什么？
2. 试用期员工是否有年终奖？

分别检索，再汇总回答。

这类方法在多跳问答里很常见。

04 项目面试怎么讲

十、项目里实际怎么做文档切分？

如果面试官问你“你们项目里怎么做的”，不要只讲概念。

你可以按这个流程回答。

第一步，先根据文档类型做解析。

Markdown 走标题解析，Word 走段落和样式解析，PDF 先做版面和 OCR 质量检查，HTML 先清理无关 DOM。

第二步，做文本清洗。

去掉页眉页脚、重复页码、目录噪声、广告内容、乱码和空白段落。

第三步，按结构做初步切分。

优先按标题、小节、段落、问答对、列表项切，而不是直接按固定字数切。

第四步，对过长片段做二次切分。

如果一个章节太长，再按 Token 长度切，并加适当 Overlap。

第五步，补充元数据。

给每个 Chunk 加上文档标题、章节路径、页码、来源、权限、更新时间等信息。

第六步，做抽样评估。

随机抽一些 Chunk 看三件事：

1. 单个 Chunk 是否语义完整
2. Chunk 之间是否有大量重复
3. 用户常见问题能否召回正确 Chunk

第七步，用真实问题做回归测试。

不要只看切得漂不漂亮，要看最终能不能答对用户问题。

因为 RAG 不是文档处理比赛，最终目标是让用户问得出、查得到、答得准。

十一、面试可以这样回答

如果面试官问：

“你会怎么设计 RAG 的文档切分策略？”

你可以这样答：

我不会一上来就固定每 500 字切一段，而是会先看文档类型和业务问题。

如果是 FAQ，我会按问答对切，保证问题和答案在同一个 Chunk。

如果是制度文档，我会按标题层级和段落切，保留章节路径，再对过长章节做二次切分。

如果是 PDF，我会先关注解析质量，尤其是阅读顺序、页眉页脚、表格和 OCR 错误。

Chunk Size 上，我会平衡语义完整性和检索精度。太小会丢上下文，太大会引入噪声。

Overlap 用来缓解边界信息丢失，但不会设置太大，否则会造成重复召回和成本浪费。

最后我会用测试集评估切分效果，看常见问题是否能召回正确 Chunk，而不是只凭经验拍一个参数。

这个回答比“按 500 字切，重叠 100 字”要强很多。

因为它体现了三个能力。

第一，你知道文档切分不是固定参数问题。

第二，你知道不同文档要用不同策略。

第三，你知道最终要用评估结果说话。

十二、面试官追问清单

最后给你一组高频追问。

你可以拿来自测。

1. Chunk Size 一般怎么设置？
2. Overlap 设置太大会有什么问题？
3. 为什么固定长度切分容易影响 RAG 效果？
4. 语义切分一定比固定长度切分好吗？
5. 如何处理 PDF 里的表格？
6. 如何保留标题层级信息？
7. 如果答案跨多个 Chunk，怎么解决？
8. 如何判断文档切分策略好不好？
9. 文档更新后，原来的 Chunk 怎么处理？
10. 文档权限应该在切分阶段处理，还是检索阶段处理？

这里面第 8 个问题特别关键。

文档切分好不好，不能只靠肉眼看。

要看检索指标和最终回答质量。

比如常见问题是否能召回正确 Chunk，正确 Chunk 是否排在前面，模型是否能基于这些 Chunk 给出可信答案。

总结

最后总结一下。

RAG 文档切分，核心不是把文档切小。

而是把文档切成适合检索、适合理解、适合生成的知识单元。

面试时记住这五句话。

第一，Chunk 太小会丢上下文，太大会引入噪声。

第二，Overlap 是为了解决边界信息丢失，但太大会造成重复和成本浪费。

第三，固定长度切分适合快速 Demo，生产系统更需要结合语义结构。

第四，复杂文档要先解析清洗，再谈切分策略。

第五，文档切分效果最终要用真实问题和评估指标来验证。

如果你能把这五点讲清楚，文档切分这类 RAG 面试题，基本就不会只停留在新手回答了。

下一篇我们讲 RAG 面经系列第 3 篇：Embedding 模型到底怎么选。

这也是面试里非常容易被问深的一块。

本文是「RAG 面试通关」系列的第 2 篇。下一篇预告：RAG 语义匹配：Embedding模型到底怎么选？，记得星标不走丢。

我把大家公认最容易翻车的 Agent 开发面试考点 整理成了一份 PDF，我自己面了不少人，也被面了不少次，这些东西说实话，外面那些面经基本看不到。