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

当你开始怀疑模型的时候，问题往往已经被带偏了

如果你真的在项目里落地过 RAG（Retrieval-Augmented Generation），你大概率经历过下面这个过程。

一开始，你很有信心。
Embedding 模型选了主流的，
向量库也搭好了，
Prompt 看起来也挺专业。

但一测效果，你开始皱眉。

• 有些问题明明“库里有”，模型却答不出来
• 有些答案看起来很像“胡说”，但你又说不清楚错在哪
• 换了个更大的模型，好像也没好多少

这时候，一个非常自然的念头就会冒出来：

“是不是模型不够强？”

于是你开始换模型、调参数、加上下文长度，
但效果依然不稳定。

很多 RAG 项目，就是在这一步，被彻底带偏方向的。

因为在绝大多数真实项目中：
RAG 效果差，问题真的很少出在模型上。

一个必须先认清的事实：RAG 是“检索系统”，不是“模型能力放大器”

这是理解 RAG 失败原因的第一步。

很多人潜意识里，会把 RAG 理解成这样一件事：

“模型本来不会的问题，只要把知识塞进去，它就会了。”

但 RAG 的本质其实更接近于：

一个以自然语言为接口的检索系统。

模型在 RAG 里做的事情，非常有限：

• 理解用户问题
• 利用给定上下文生成答案

而真正决定 RAG 上限的，是：
你到底给模型检索到了什么。

如果检索阶段出了问题，
模型再强，也只能在“错误或无关的信息”上发挥。

第一个常见误判：把“答不好”当成“模型不会”

这是 RAG 实战中最容易出现、也最容易误导判断的一点。

很多时候，模型不是不会答，
而是根本没看到该看的内容。

你可以做一个非常简单的自检：
在生成之前，把检索到的内容单独打印出来，自己读一遍。

你会非常频繁地发现：

• 检索结果本身就不相关
• 只命中了关键词，没命中语义
• 真正关键的信息被挤在很后面

在这种情况下，模型答不好，是完全正常的。

切分（Chunking），是 RAG 翻车的第一大源头

如果让我在 RAG 里只选一个“最容易被低估，但杀伤力最大”的环节，那一定是：
文档切分。

很多人切文档时，脑子里只有一个目标：
“切小一点，方便检索。”

于是你会看到：

• 固定长度切分
• 不管语义直接截断
• 表格、列表被打散
• 上下文依赖完全丢失

这样做的直接后果是：
检索出来的 chunk，本身就无法独立表达有效信息。

模型看到的，不是“知识片段”，
而是“信息残骸”。

一个非常常见的场景：答案就在库里，但永远检索不到

这是很多 RAG 项目里最让人崩溃的时刻。

你明明知道：
“这个问题，文档里绝对有。”

但检索就是命不中。

原因往往不是 embedding 不行，而是：

• 问题和文档的表达方式差异太大
• 文档是“说明式”，问题是“场景式”
• 切分后，关键信息被拆散了

Embedding 模型不是魔法，它无法在信息本身已经被破坏的情况下，自动帮你“拼回语义”。

TopK 并不是“越大越好”

这是另一个非常典型的工程误区。

很多人发现 RAG 效果差，第一反应是：
“那我多给模型一点上下文。”

于是 TopK 从 3 → 5 → 10 → 20。

结果往往是：

• 上下文越来越长
• 噪声越来越多
• 模型开始抓不住重点

因为模型并不会自动帮你判断“哪段最重要”。

在很多场景下：
TopK 变大，只是在稀释真正有用的信息。

TopK 增大导致信息密度下降示意图

检索“命中”≠ 检索“可用”

这是一个非常关键、但经常被混为一谈的概念。

很多系统在调试 RAG 时，只看一个指标：
有没有命中相关文档。

但真正重要的，是：
命中的内容，能不能直接支撑答案生成。

比如：

• 命中了背景介绍，但缺少结论
• 命中了定义，但缺少条件
• 命中了局部描述，但缺少上下文

对模型来说，这些信息是“不完整的线索”，
而不是“可用的依据”。

为什么换更大的模型，RAG 也不一定会变好

这是很多团队花了最多钱、却收获最少的一步。

当 RAG 效果差时，换模型往往是性价比最低的优化路径。

原因很简单：

• 模型只能基于已有上下文发挥
• 它不能凭空补全缺失的信息
• 更大的模型，只会更“自信地胡说”

在检索质量不高的情况下，
模型能力提升，很可能只会放大错误输出的流畅度。

Rerank：很多 RAG 项目“救回来”的关键一步

在真实工程中，Rerank 往往是 RAG 效果的分水岭。

初始向量检索，解决的是“快”和“召回”；
Rerank，解决的是“相关性排序”。

很多时候，你的库里其实有正确答案，
只是它排在第 7、第 8 个位置，
模型根本没机会看到。

加入 rerank 后，
你会突然发现：
模型“好像变聪明了”。

但实际上，是你终于把对的内容，放到了它面前。

一个最小可用的 RAG 排查流程（非常实用）

当 RAG 效果不理想时，我非常建议你按下面这个顺序排查，而不是直接怪模型。

第一步：
固定模型，不动生成参数

第二步：
单独检查检索结果是否可读、可用

第三步：
检查切分方式是否破坏语义

第四步：
减少 TopK，看效果是否反而变好

第五步：
再考虑 rerank 或 query rewrite

这是一个非常“反直觉”，但成功率极高的流程。

RAG 排查流程图

一个简单的调试技巧：把模型当“人”用一次

这是我个人非常常用的一个方法。

在调试 RAG 时，你可以做一件很简单的事：

把检索结果直接贴给一个人，让他回答问题。

如果这个人都觉得：
“信息不够”“看不懂”“缺关键条件”，
那模型答不好，真的不是模型的问题。

Query 本身，也可能是 RAG 的隐形短板

很多人会忽略：
用户问题，并不一定适合直接拿去做检索。

尤其是在真实应用中，用户问题往往：

• 口语化
• 信息不完整
• 带有上下文依赖

在这种情况下，
简单地用原始问题做 embedding，很容易偏离真正的检索目标。

这也是为什么 query rewrite 在很多项目里是“隐形刚需”。

一个很容易被忽略的问题：RAG 的评估方式本身可能是错的

很多团队在评估 RAG 时，只看最终答案。

但这样做，会把所有问题都归因到“模型输出”。

更合理的评估方式，应该拆成三层：

• 检索是否命中正确 chunk
• 提供的上下文是否足以支撑答案
• 模型是否合理使用了上下文

如果第一层就失败了，后面再讨论模型，毫无意义。

RAG 分层评估结构图

为什么 RAG 的工程成本，远高于你的第一印象

这是一个你在教程里几乎看不到的事实。

RAG 看起来很简单：
“检索 + 生成”。

但在真实项目中，它涉及：

• 文档治理
• 数据版本管理
• 检索质量监控
• 切分策略演进
• 评估体系搭建

模型，反而是其中最稳定的一环。

一个现实建议：先把 RAG 当“检索系统”做好

如果你只记住这一篇里的一句话，那应该是这句：

RAG 成功与否，80% 决定于检索系统，而不是模型能力。

当你真的把检索质量、数据结构、切分策略打磨好之后，
你会发现：
哪怕用一个不那么大的模型，效果也会明显提升。
在验证 RAG 架构和数据组织是否合理时，先用 LLaMA-Factory online 快速对比不同检索策略下的生成效果，比一开始就深度绑定某个模型方案更容易定位问题。

总结：RAG 效果差，通常不是模型“不行”，而是你没把该给的东西给它

写到最后，其实结论已经非常明确了。

模型在 RAG 里，并不是主角。
它更像是一个“阅读理解能力很强的执行者”。

如果你给它的是：

• 破碎的内容
• 无关的信息
• 排序混乱的上下文

那它能给你的，也只能是一个看起来很像答案的东西。
真正成熟的 RAG 实战，不是不断换模型，而是反复打磨：你到底在让模型读什么。