切分：RAG 成败的第一步

切得太碎丢上下文，切得太大稀释重点。这一步定生死。

建知识库时，切分最先做、最没技术含量、也最容易被随便糊弄过去。但它决定了检索的最小单位——切错了，后面所有环节都在补救。

你会遇到的现象：

• 它答对了主条款，却漏掉了紧跟着的例外情况
• 召回的片段读起来像半句话，前后文都不知道在说什么
• 一段材料里塞了五个主题，模型抓错了重点

为什么这步最关键

因为**切出来的片段，就是检索能返回的最小单位。**库里没有一段能完整回答问题的内容，检索再准也拿不出来。

看图上的三种切法。

切得太碎：「七日内可无理由退货，但生鲜类除外」被切成四段。用户问能不能退，检索命中「七日内可无理由」段，「生鲜除外」留在另一段没被召回。模型于是答「可以退」——每一步看起来都没毛病。这类错误特别危险：自信、有出处、只在特定情况出现，测试时很难覆盖。

切得太大：一整章塞进一段。一段文字压成一个坐标，等于把所有主题平均了一下——退货、换货、发票、客诉混在一个坐标里，哪个都不突出，结果是什么问题都能召回一点，什么问题都不够准。而且这一大段塞进上下文，中间部分很可能被忽略。

按结构切：一段说完一件事，条件和它的例外在同一段里。这才是要的。

怎么切

按可靠性从高到低，三种做法。

**一、按文档自身的结构切（首选）。**按标题层级、按条款编号、按 Markdown 的小节。文档作者已经标好了「一个完整意思」的边界，直接用。覆盖大多数结构化文档：产品手册、政策条款、API 文档、帮助中心。**如果你的文档有清晰的小标题，几乎不用考虑别的方案。**Pinecone 的切分策略指南把「按语义与结构切」排在固定长度之前。pinecone-chunking

**二、按语义边界切。**文档没有明确结构时（如会议记录、长邮件），按段落和话题转折切，可用模型辅助判断话题在哪换。

**三、按固定长度切（下策）。**每 500 字切一刀。实现最简单，也最容易拦腰砍断一句完整的话。

如果不得不用固定长度，一定要加重叠——相邻两段共享一部分内容（比如重叠 10% 到 20%），即使切在关键句中间，至少有一段是完整的。重叠是固定长度切分的必备补丁，代价只是多一点存储。LangChain 的递归切分器把「保留分隔符、可配重叠」做成默认行为，就是这个道理。langchain-splitters

关于长度，给个起点：**多数场景下每段 200 到 500 个 Token 比较合适。**但要看内容——法律条款可以短，技术教程往往需要更长。别信任何「标准值」，拿自己的文档试。

带上标题再入库

这招几乎零成本，效果却明显，很多团队不知道。

做法：**每一段入库前，在开头拼上来源路径。**比如「售后政策 > 第三章 退货 > 3.2 不适用情形」。

为什么有用？因为切出来的片段常常是「无主」的——正文写着「本条不适用于以下情形」，但「本条」是哪条，信息在标题里，而标题被切走了。算向量时，这段文字不知道自己在讲什么主题，检索时也匹配不上。

拼上路径后，片段自带主题信息，向量位置准确多了，标注出处也方便。

同理，还应该给每段存上元数据：来源文档、章节、生效日期、版本、可见范围。检索时用它们过滤——比如只查当前有效版本，或只查这个用户有权限看的内容。过期版本被召回这个坑，就靠它来堵。

几类特殊内容

几种常见的、按普通方式切一定出问题的内容。

**表格。**按行切会丢表头，整表入库又可能太大。可行做法是把每行转成一句自然语言（「产品 A 的保修期是 12 个月」），或至少让每段都带着表头。直接把表格当普通文本切，基本等于废掉。

**问答对。**如果资料本来就是 FAQ，那太好了——一问一答就是天然的切分单位，问题本身和用户提问的向量天然接近，是效果最好的一类语料，值得优先整理。

长流程和步骤。「第五步」单独被召回没意义。要么整个流程作为一段，要么每段带上流程名和总步数。

**代码和配置。**按语法边界切（一个函数、一个配置块），别按行数。

最后一条务实建议：**切完随机抽二十段自己读一遍。**单看这一段能明白在说什么吗？信息完整吗？——这个五分钟的检查，比调任何参数都有价值。