RAG 效果差，80% 的问题和模型无关

村亢 · 6 天前

<h2 id="当你开始怀疑模型的时候问题往往已经被带偏了">当你开始怀疑模型的时候，问题往往已经被带偏了</h2>
如果你真的在项目里落地过 RAG（Retrieval-Augmented Generation），你大概率经历过下面这个过程。
一开始，你很有信心。 
Embedding 模型选了主流的， 
向量库也搭好了， 
Prompt 看起来也挺专业。
但一测效果，你开始皱眉。
<ul>
<li>有些问题明明“库里有”，模型却答不出来</li>
<li>有些答案看起来很像“胡说”，但你又说不清楚错在哪</li>
<li>换了个更大的模型，好像也没好多少</li>
</ul>
这时候，一个非常自然的念头就会冒出来：
<blockquote>
“是不是模型不够强？”
</blockquote>
于是你开始换模型、调参数、加上下文长度， 
但效果依然不稳定。
很多 RAG 项目，就是在这一步，被彻底带偏方向的。
因为在绝大多数真实项目中： 
RAG 效果差，问题真的很少出在模型上。
<h2 id="一个必须先认清的事实rag-是检索系统不是模型能力放大器">一个必须先认清的事实：RAG 是“检索系统”，不是“模型能力放大器”</h2>
这是理解 RAG 失败原因的第一步。
很多人潜意识里，会把 RAG 理解成这样一件事：
<blockquote>
“模型本来不会的问题，只要把知识塞进去，它就会了。”
</blockquote>
但 RAG 的本质其实更接近于：
<blockquote>
一个以自然语言为接口的检索系统。
</blockquote>
模型在 RAG 里做的事情，非常有限：
<ul>
<li>理解用户问题</li>
<li>利用给定上下文生成答案</li>
</ul>
而真正决定 RAG 上限的，是： 
你到底给模型检索到了什么。
如果检索阶段出了问题， 
模型再强，也只能在“错误或无关的信息”上发挥。
<h2 id="第一个常见误判把答不好当成模型不会">第一个常见误判：把“答不好”当成“模型不会”</h2>
这是 RAG 实战中最容易出现、也最容易误导判断的一点。
很多时候，模型不是不会答， 
而是根本没看到该看的内容。
你可以做一个非常简单的自检： 
在生成之前，把检索到的内容单独打印出来，自己读一遍。
你会非常频繁地发现：
<ul>
<li>检索结果本身就不相关</li>
<li>只命中了关键词，没命中语义</li>
<li>真正关键的信息被挤在很后面</li>
</ul>
在这种情况下，模型答不好，是完全正常的。
<h2 id="切分chunking是-rag-翻车的第一大源头">切分（Chunking），是 RAG 翻车的第一大源头</h2>
如果让我在 RAG 里只选一个“最容易被低估，但杀伤力最大”的环节，那一定是： 
文档切分。
很多人切文档时，脑子里只有一个目标： 
“切小一点，方便检索。”
于是你会看到：
<ul>
<li>固定长度切分</li>
<li>不管语义直接截断</li>
<li>表格、列表被打散</li>
<li>上下文依赖完全丢失</li>
</ul>
这样做的直接后果是： 
检索出来的 chunk，本身就无法独立表达有效信息。
模型看到的，不是“知识片段”， 
而是“信息残骸”。
<h2 id="一个非常常见的场景答案就在库里但永远检索不到">一个非常常见的场景：答案就在库里，但永远检索不到</h2>
这是很多 RAG 项目里最让人崩溃的时刻。
你明明知道： 
“这个问题，文档里绝对有。”
但检索就是命不中。
原因往往不是 embedding 不行，而是：
<ul>
<li>问题和文档的表达方式差异太大</li>
<li>文档是“说明式”，问题是“场景式”</li>
<li>切分后，关键信息被拆散了</li>
</ul>
Embedding 模型不是魔法，它无法在信息本身已经被破坏的情况下，自动帮你“拼回语义”。
<h2 id="topk-并不是越大越好">TopK 并不是“越大越好”</h2>
这是另一个非常典型的工程误区。
很多人发现 RAG 效果差，第一反应是： 
“那我多给模型一点上下文。”
于是 TopK 从 3 → 5 → 10 → 20。
结果往往是：
<ul>
<li>上下文越来越长</li>
<li>噪声越来越多</li>
<li>模型开始抓不住重点</li>
</ul>
因为模型并不会自动帮你判断“哪段最重要”。
在很多场景下： 
TopK 变大，只是在稀释真正有用的信息。

TopK 增大导致信息密度下降示意图
<h2 id="检索命中-检索可用">检索“命中”≠ 检索“可用”</h2>
这是一个非常关键、但经常被混为一谈的概念。
很多系统在调试 RAG 时，只看一个指标： 
有没有命中相关文档。
但真正重要的，是： 
命中的内容，能不能直接支撑答案生成。
比如：
<ul>
<li>命中了背景介绍，但缺少结论</li>
<li>命中了定义，但缺少条件</li>
<li>命中了局部描述，但缺少上下文</li>
</ul>
对模型来说，这些信息是“不完整的线索”， 
而不是“可用的依据”。
<h2 id="为什么换更大的模型rag-也不一定会变好">为什么换更大的模型，RAG 也不一定会变好</h2>
这是很多团队花了最多钱、却收获最少的一步。
当 RAG 效果差时，换模型往往是性价比最低的优化路径。
原因很简单：
<ul>
<li>模型只能基于已有上下文发挥</li>
<li>它不能凭空补全缺失的信息</li>
<li>更大的模型，只会更“自信地胡说”</li>
</ul>
在检索质量不高的情况下， 
模型能力提升，很可能只会放大错误输出的流畅度。
<h2 id="rerank很多-rag-项目救回来的关键一步">Rerank：很多 RAG 项目“救回来”的关键一步</h2>
在真实工程中，Rerank 往往是 RAG 效果的分水岭。
初始向量检索，解决的是“快”和“召回”； 
Rerank，解决的是“相关性排序”。
很多时候，你的库里其实有正确答案， 
只是它排在第 7、第 8 个位置， 
模型根本没机会看到。
加入 rerank 后， 
你会突然发现： 
模型“好像变聪明了”。
但实际上，是你终于把对的内容，放到了它面前。
<h2 id="一个最小可用的-rag-排查流程非常实用">一个最小可用的 RAG 排查流程（非常实用）</h2>
当 RAG 效果不理想时，我非常建议你按下面这个顺序排查，而不是直接怪模型。
第一步： 
固定模型，不动生成参数
第二步： 
单独检查检索结果是否可读、可用
第三步： 
检查切分方式是否破坏语义
第四步： 
减少 TopK，看效果是否反而变好
第五步： 
再考虑 rerank 或 query rewrite
这是一个非常“反直觉”，但成功率极高的流程。

RAG 排查流程图
<h2 id="一个简单的调试技巧把模型当人用一次">一个简单的调试技巧：把模型当“人”用一次</h2>
这是我个人非常常用的一个方法。
在调试 RAG 时，你可以做一件很简单的事：
<blockquote>
把检索结果直接贴给一个人，让他回答问题。
</blockquote>
如果这个人都觉得： 
“信息不够”“看不懂”“缺关键条件”， 
那模型答不好，真的不是模型的问题。
<h2 id="query-本身也可能是-rag-的隐形短板">Query 本身，也可能是 RAG 的隐形短板</h2>
很多人会忽略： 
用户问题，并不一定适合直接拿去做检索。
尤其是在真实应用中，用户问题往往：
<ul>
<li>口语化</li>
<li>信息不完整</li>
<li>带有上下文依赖</li>
</ul>
在这种情况下， 
简单地用原始问题做 embedding，很容易偏离真正的检索目标。
这也是为什么 query rewrite 在很多项目里是“隐形刚需”。
<h2 id="一个很容易被忽略的问题rag-的评估方式本身可能是错的">一个很容易被忽略的问题：RAG 的评估方式本身可能是错的</h2>
很多团队在评估 RAG 时，只看最终答案。
但这样做，会把所有问题都归因到“模型输出”。
更合理的评估方式，应该拆成三层：
<ul>
<li>检索是否命中正确 chunk</li>
<li>提供的上下文是否足以支撑答案</li>
<li>模型是否合理使用了上下文</li>
</ul>
如果第一层就失败了，后面再讨论模型，毫无意义。

RAG 分层评估结构图
<h2 id="为什么-rag-的工程成本远高于你的第一印象">为什么 RAG 的工程成本，远高于你的第一印象</h2>
这是一个你在教程里几乎看不到的事实。
RAG 看起来很简单： 
“检索 + 生成”。
但在真实项目中，它涉及：
<ul>
<li>文档治理</li>
<li>数据版本管理</li>
<li>检索质量监控</li>
<li>切分策略演进</li>
<li>评估体系搭建</li>
</ul>
模型，反而是其中最稳定的一环。
<h2 id="一个现实建议先把-rag-当检索系统做好">一个现实建议：先把 RAG 当“检索系统”做好</h2>
如果你只记住这一篇里的一句话，那应该是这句：
<blockquote>
RAG 成功与否，80% 决定于检索系统，而不是模型能力。
</blockquote>
当你真的把检索质量、数据结构、切分策略打磨好之后， 
你会发现： 
哪怕用一个不那么大的模型，效果也会明显提升。 
在验证 RAG 架构和数据组织是否合理时，先用 LLaMA-Factory online 快速对比不同检索策略下的生成效果，比一开始就深度绑定某个模型方案更容易定位问题。
<h2 id="总结rag-效果差通常不是模型不行而是你没把该给的东西给它">总结：RAG 效果差，通常不是模型“不行”，而是你没把该给的东西给它</h2>
写到最后，其实结论已经非常明确了。
模型在 RAG 里，并不是主角。 
它更像是一个“阅读理解能力很强的执行者”。
如果你给它的是：
<ul>
<li>破碎的内容</li>
<li>无关的信息</li>
<li>排序混乱的上下文</li>
</ul>
那它能给你的，也只能是一个看起来很像答案的东西。 
真正成熟的 RAG 实战，不是不断换模型，而是反复打磨：你到底在让模型读什么。 来源：程序园用户自行投稿发布，如果侵权，请联系站长删除 免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册

RAG 效果差，80% 的问题和模型无关

相关帖子

浏览过的版块

签约作者

RAG 效果差，80% 的问题和模型无关

相关帖子

相关推荐

浏览过的版块

签约作者