当你开始怀疑模型的时候，问题往往已经被带偏了
如果你真的在项目里落地过 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 实战，不是不断换模型，而是反复打磨：你到底在让模型读什么。
