文档切得越细,RAG就一定找得越准吗?

这次继续上一篇的模拟客服场景。

用户问：“换完滤芯以后，蓝灯还在闪，怎么办？”

系统很快找到了相关资料：

“更换滤芯后，如果蓝色指示灯持续闪烁……”

到这里就没了。

AI盯着这半句话，最后只能回答：

“请检查滤芯是否安装正确，必要时联系售后。”

可产品手册的下一行明明写着：

“长按复位键三秒，等待指示灯熄灭。”

检索没有找错地方，Embedding也认出了“蓝灯闪”和“指示灯闪烁”说的是一回事。

但真正的解决办法，被切到了另一段。

这一次，答案不是没找到。

是被切碎了。

为什么文档不能整份存进去？

最开始接触RAG时，很容易产生一个想法：

既然切分会把答案切断，那就不要切了。直接把整份产品手册当成一条资料，不就完整了吗？

假设一份手册有几十页，里面同时包含安装方法、故障说明、清洗步骤、保修政策和安全提醒。

如果把整份手册生成一个向量，它最终只能得到一个非常笼统的“坐标”。

用户问蓝灯闪烁，它可能找到这份手册，但还得把大量无关内容一起交给大模型。

资料太大，不仅消耗更多Token，真正有用的两句话还可能被埋在中间。

整份文档太大，搜索不够准确。

可切得太小，上下文又会断掉。

RAG需要在两者之间找一个平衡。

这个过程就叫Chunk文档切分。

Chunk到底是什么？

Chunk可以理解成知识库里参与检索的最小资料块。

原始文档不会直接变成一条向量，而是先被切成多个Chunk。每个Chunk分别生成向量，再存进向量数据库。

用户提问时，系统检索到的也不是整份文档，而是几个相关的Chunk。

原始文档

→ 切成多个Chunk

→ 每个Chunk生成向量

→ 存入向量数据库

→ 检索相关Chunk

→ 交给大模型回答

所以，Chunk不是简单地把文档切小。

它真正决定的是：AI每次拿到的资料，能不能独立支撑一个答案。

切得越小，真的越准吗？

还是刚才那段产品手册。

如果按句号切分，可能变成这样：

Chunk 1：

“更换滤芯后，如果蓝色指示灯持续闪烁。”

Chunk 2：

“长按复位键三秒，等待指示灯熄灭。”

用户问“蓝灯一直闪怎么办”，第一个Chunk和问题最相似，很容易被检索出来。

第二个Chunk没有出现“蓝灯”和“滤芯”，反而可能排在很后面。

系统找到了现象，却漏掉了解决办法。

更合适的切法，是把它们放在同一个知识块里：

“更换滤芯后，如果蓝色指示灯持续闪烁，请长按复位键三秒，等待指示灯熄灭。”

这段内容既包含问题，也包含操作方法。即使脱离原文，单独拿出来仍然能够回答用户的问题。

文档切分最重要的标准，不是每段长度完全相同，而是一个Chunk里有没有相对完整的意思。

常见的三种切法

第一种是按固定长度切。

比如每到一定字符数或Token数就切一段。

这种方式简单，适合先快速搭建知识库。但切口不会照顾句子的意思，可能正好把问题和答案分开。

为了减少这种情况，可以让前后两个Chunk保留一小段重复内容，这叫Overlap，也就是重叠。

它相当于给切口加了一点保险。

不过重叠也不是越多越好。重复内容太多，会增加存储量，还可能让检索结果出现好几段几乎相同的文字。

第二种是按文档结构切。

遇到标题、段落、列表、表格或者问答边界时再切分。

对于产品手册、公司制度和客服FAQ，这种方式通常更自然。

一条“问题＋答案”可以作为一个Chunk；一个小标题和下面的说明可以放在一起；表格则要尽量保留表头，避免只拿出一行数字，却不知道每一列代表什么。

第三种是按语义切。

系统先判断前后内容是否还在讨论同一个主题，话题明显变化时再切开。

这种方式听起来更聪明，但实现和调试也更复杂。第一版客服AI不一定急着上，先把文档结构和基础切分做好，往往更容易发现问题。

Chunk除了正文，还要保存什么？

假设系统找到了这样一段话：

“长按复位键三秒。”

它看起来像答案，但我们仍然不知道：

适用于哪个产品？

来自哪一版手册？

对应哪个章节？

文档是否已经过期？

当前用户有没有权限查看？

因此，一个Chunk除了正文和向量，通常还要保存一些元数据：

文档名称。

章节标题。

产品型号。

版本号。

页码或原文地址。

更新时间。

权限信息。

这些信息既能帮助系统过滤错误资料，也能在回答后告诉用户答案来自哪里。

只保存一段文字，却扔掉它的出处，后面很容易把不同型号、不同版本的规则混在一起。

Chunk到底切多大？

这个问题没有一个适合所有项目的固定答案。

与其先纠结到底切500字还是1000字，不如先问一句：

“这段内容单独拿出来，能不能回答一个具体问题？”

客服FAQ可以把一组完整的“问题＋答案”作为一个Chunk。

产品手册可以优先按照章节和自然段切分。

遇到特别长的章节，再使用固定长度和适量重叠继续拆分。

完成第一版后，准备一批真实或经过确认的测试问题，检查三个地方：

系统有没有找到正确的Chunk？

找到的内容是否足够完整？

里面有没有混入太多无关信息？

根据测试结果继续调整，比直接照抄一个Chunk大小更可靠。

回到开头。

重新切分后，“蓝灯持续闪烁”和“长按复位键三秒”终于被放回了同一个Chunk。

用户再次提问，系统拿到了完整资料，AI也终于能把解决办法说清楚。

做到这里，我对Chunk的理解变成了一句话：

RAG能不能找到资料，要看检索；找到以后够不够回答，要看Chunk怎么切。

不过新的问题又来了。

如果一次检索出了十段看起来都很相关的资料，应该先把哪几段交给大模型？

下一篇，该轮到Rerank重排序了。

说明：文中的客服案例为帮助理解Chunk切分而设计，不代表真实产品规则。