RAG 真正让人头疼的地方，从来不是“搭不起来”
如果你已经做过一段时间 RAG，大概率会有一种非常熟悉的感觉：
系统是能跑的，流程也是完整的，embedding 用的也不差，向量库、召回、rerank 该有的都有，但整体效果始终差点意思。
有时候是召回的内容看起来“擦边”，
有时候是答案明明就在文档里，模型却像没看到，
还有时候，模型引用了一堆内容，但就是没真正解决用户的问题。
很多人第一反应是换 embedding 模型、加 reranker、堆上下文窗口，甚至怀疑是不是模型本身太弱。但在真实项目里，我越来越确定一件事：RAG 的问题，绝大多数并不出在模型上，而是出在文档切分上。
切分这件事，太容易被低估了。
它看起来不像模型那么“高大上”，甚至很多教程里一笔带过，但它却决定了 RAG 系统能不能真正理解你的知识。
一个非常现实的事实：RAG 本质上是“先切碎，再找回”
在讨论切分策略之前，有必要先把 RAG 的工作方式说清楚。
不管你的 RAG 架构多复杂，本质流程都绕不开这几步：
- 原始文档 → 切分成 chunk → embedding → 相似度搜索 → 拼上下文 → 交给大模型生成答案。
也就是说，从模型的视角来看，它从来没有见过完整文档，它看到的永远只是你提前切好的碎片。
这件事如果你不刻意去想，很容易忽略。但一旦你意识到这一点，很多 RAG 的“怪现象”就说得通了。
模型答不上来，有可能不是因为模型不懂，而是因为你切出来的 chunk，本身就无法支撑模型理解问题。
原始文档 → chunk → embedding → 检索 → 生成的整体流程示意图
为什么大多数 RAG 项目一开始都会“切错”
我见过太多团队，一开始做切分时，采用的都是一种非常“工程直觉”的方式：
按固定长度切，比如 500 token 一段，100 token overlap。
这种方式本身不能说错，它甚至是很多教程里的默认方案。但问题在于，它只考虑了模型的限制，却完全没有考虑内容本身的结构。
文档不是随机 token 的集合，而是有语义、有层次、有上下文依赖的。
当你用固定长度去切一个本来有结构的内容时，很容易出现几种情况：
- 一句话被切成两半
- 一个定义和它的解释被拆开
- 一个流程的前因后果落在不同 chunk 里
这些 chunk 单独拿出来 embedding，看起来都“有点像”，但实际上都不完整。
切分做错时，RAG 会出现哪些典型症状
很多人并不知道自己的切分有问题，只是感觉 RAG 不太好用。这里我总结几个非常典型的症状，你可以对照看看自己有没有遇到过。
最常见的一种情况是：召回的 chunk 看起来都相关，但没有一个真正有用。
你点开看每一条，发现关键词都对，但拼不出完整答案。
还有一种情况是：模型引用了文档，但结论明显不对。
你回头去查原文，发现关键条件刚好被切到了另一个 chunk 里。
更隐蔽的一种，是系统在小样本测试时表现还行，一到真实用户场景就开始翻车。
这是因为真实用户的问题，往往比你测试时想得更复杂，对上下文依赖更强。
这些问题，很少是 embedding 模型的问题，几乎都是切分阶段就已经埋下了雷。
错误切分导致关键信息分离的示意图
一个核心认知：chunk 不是“越小越好”
很多人在意识到切分重要之后，会走向另一个极端：
既然切分有问题，那我就切得更细。
这是一个非常自然的反应，但在 RAG 里，chunk 过小同样是灾难。
chunk 太小，意味着每一段包含的语义信息非常有限。embedding 虽然能抓住关键词相似度，但却丢失了“为什么”“在什么条件下”“有什么限制”这些关键信息。
结果就是：
- 召回数量上来了，噪声也上来了。
- 模型看到了一堆“相关但不完整”的碎片，只能靠自己猜。
这也是为什么你会看到一些 RAG 系统，召回结果看起来很多，但回答质量反而下降了。
真正有用的切分，必须尊重“语义完整性”
在我看来，好的切分策略，核心只有一个原则：
一个 chunk 本身，应该是“可以被人单独读懂的”。
这句话听起来很朴素，但真正做到并不容易。
什么叫“单独读懂”？
不是语法完整，而是语义完整。
读完这一段，你至少能知道它在讲什么、解决什么问题、有哪些前提。
这意味着，切分时你必须开始关心文档结构，而不是只看 token 数。
不同类型文档，切分策略应该完全不同
一个非常常见的错误，是用同一种切分方式处理所有文档。
技术文档、产品说明、客服 FAQ、法律条款，这些内容的结构差异非常大，如果一刀切，效果几乎一定不好。
技术文档往往有明确的标题层级，非常适合按小节切分；
客服 FAQ 通常是一问一答，天然就是 chunk；
流程类文档，最好把一个完整流程放在同一段里；
而规范、条款类内容，则需要保留上下限制条件。
你越是尊重文档本身的表达方式，RAG 的效果越容易提升。
overlap 不是“保险”，用不好反而是噪声源
很多教程都会建议加 overlap，看起来很合理：
前后多留一点上下文，避免信息被切断。
但在真实项目里，overlap 用不好，反而会引入大量冗余。
尤其是在 chunk 已经比较小的情况下，再加大量 overlap，等于在向量库里反复存储相似内容。
结果就是：相似度搜索时，返回一堆几乎一模一样的 chunk。
模型看到这些内容，并不会更清楚，反而更混乱。
我的经验是，overlap 只在“语义边界不清晰”的情况下有意义，而不是作为默认配置。
一个容易被忽略的问题：切分直接影响 rerank 的上限
很多人会把希望寄托在 reranker 上，觉得只要 rerank 足够强，就能弥补前面的不足。
但现实是，rerank 只能在你提供的候选集合里做选择。
如果切分阶段已经把语义切碎了，rerank 再强，也选不出完整答案。
你可以把 rerank 理解成一个“精修工具”，而不是“救命工具”。
切分质量对召回与 rerank 效果的影响示意图
一个实用的切分思路：先人为理解，再让模型理解
在很多项目里，我会建议团队先做一件“看起来很笨”的事：
随机抽几篇文档，手工切一版。
不是为了最终使用，而是为了建立对“什么样的 chunk 是有用的”的直觉。
当你自己能接受把某一段单独交给别人阅读时，它大概率也适合作为 RAG 的最小知识单元。
等这个感觉建立起来，再去用规则或者模型自动化，效果会好很多。
在验证切分策略是否合理时，先通过在线方式快速尝试不同切分方案，对比召回结果和生成效果，往往比一开始就全量入库更省时间。像 LLaMA-Factory online 这类工具，在这个阶段能明显降低试错成本。
如何判断你的切分是不是在“拖后腿”
这里有一个非常实用的小测试方法。
找几个你非常确定答案就在文档里的问题，让 RAG 系统只返回检索结果，不生成答案。
然后你自己去看这些 chunk：
如果你作为人，读完这些内容，依然很难回答问题，那问题基本就不在模型。
这个方法简单粗暴，但几乎百试百灵。
总结：切分不是细节，而是 RAG 的地基
很多团队在做 RAG 时，把 80% 的精力放在模型、参数、架构上，却只花 20% 的精力在切分上。
但现实往往正好相反：切分这种“看起来很基础”的工作，决定了 RAG 能走多远。
当你真正把切分当成一个需要反复打磨的工程问题，而不是一次性配置，你会发现 RAG 的很多“玄学问题”，其实都有迹可循。
在这个过程中，能够让你快速验证切分效果、反复调整策略的工具，比追逐更大的模型更有价值。
