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