RAG 真正让人头疼的地方，从来不是“搭不起来”

有时候是召回的内容看起来“擦边”有时候是答案明明就在文档里模型却像没看到还有时候模型引用了一堆内容但就是没真正解决用户的问题。很多人第一反应是换 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 理解成一个“精修工具”而不是“救命工具”。