1.3.1 为什么不能把 RAG 简单理解成“检索 + Prompt”？

很多人第一次接触 RAG 时，会很自然地把它理解成：

“先搜一下，再把搜到的内容塞进 Prompt。”

这个理解不能说完全错，但它太简单了，简单到会掩盖真正决定效果的关键环节。

这个说法为什么看起来有道理

因为从表面流程上看，RAG 确实像两步：

1. 检索外部资料
2. 把资料交给模型回答

如果只是做一个最小 Demo，这种理解已经足够让系统跑起来。

但一旦数据变多、问题变复杂、用户真实使用起来，你就会发现，真正影响效果的部分远不止这两步。

RAG 中间其实还隔着很多关键环节

在“检索”和“Prompt”之间，通常至少还有这些问题：

• 数据有没有清洗好
• 文档切块是否合理
• Metadata 是否完整
• 检索策略是否适合当前问题
• 候选结果有没有重排
• 上下文是否做了去重和压缩
• 生成约束是不是足够清晰

这些环节任何一个做得差，最终都可能表现成：

• 检索到了但答偏
• 检索结果很多但没用
• 明明有资料却没回答出来
• 回答看起来流畅，但其实不忠于材料

所以真正的 RAG，更准确地说是：

一条围绕外部知识组织、筛选、约束和生成的完整链路。

如果效果不好，应该先从哪几层往前查

把 RAG 理解成“检索 + Prompt”还有一个直接后果：一旦系统答不好，大家就很容易只盯着 Prompt 改。

更稳的排查顺序通常是这样：

第 1 层：先看有没有召回到正确材料

先确认：

• 正确答案对应的资料是否真的在候选集合里
• 如果不在，是数据问题、切块问题还是检索问题

如果这一步就失败了，后面再改 Prompt 基本没有意义。

第 2 层：再看候选里噪声是不是太多

有些系统不是没找到，而是找到了一堆有点相关但没用的东西。

这时更该查的是：

• Metadata 是否完整
• 过滤条件是否缺失
• Top K 是否过大
• 是否需要重排

第 3 层：再看上下文是不是组织错了

就算候选集合里有正确材料，如果：

• 关键证据排得太后
• 相邻 chunk 没拼起来
• 重复内容过多
• 中间塞了很多噪声

模型仍然可能用不好这些内容。

第 4 层：最后才看生成约束和 Prompt

Prompt 当然重要，但它更像最后一公里。

真正应该在这层解决的，通常是：

• 要不要强制只基于材料回答
• 要不要要求引用来源
• 资料不足时怎么表达
• 回答格式怎么约束

也就是说，Prompt 更擅长解决“怎么用材料”，不擅长解决“系统有没有把正确材料准备好”。

为什么只盯 Prompt 往往不够

当回答效果不好时，最容易下意识去改 Prompt。

但很多时候，Prompt 只是最后一层表达问题，真正的问题其实在更前面，比如：

• 没召回到真正相关的内容
• 召回结果里噪声太多
• 关键证据排得太靠后
• 上下文拼接方式不合理

如果这些问题不解决，Prompt 再怎么调，也很难稳定救回来。

为什么只盯检索也不够

反过来也一样。

有时候检索本身并不差，问题出在：

• 结果没有被合理筛选
• 模型读到的信息顺序不对
• 关键信息埋在中间
• 回答规则不明确

这时你会看到一种典型现象：系统“找到了资料”，但模型“没把资料用对”。

更准确的理解方式

把 RAG 理解成“检索 + Prompt”，适合入门时快速建立直觉。

但如果你真的想把它看清楚，更好的理解方式是：

RAG = 数据准备 + 索引设计 + 查询理解 + 检索 + 排序 + 上下文构造 + 生成约束

一个更有操作性的理解

如果你把 RAG 只理解成“检索 + Prompt”，你会很容易陷入下面这种工作方式：

• 效果不好 -> 改 Prompt
• 还不好 -> 再改 Prompt
• 再不好 -> 换模型

但更成熟的工作方式通常是：

• 先看数据质量
• 再看切块和元数据
• 再看检索和过滤
• 再看重排和上下文构造
• 最后才调生成约束

这两种方式的差别很大。前者是在最后一层反复打补丁，后者是在整条链路上定位真正的瓶颈。

换句话说，RAG 不是两个点，而是一整条链路。

一个更务实的判断标准

如果一个系统只是：

• 检索几段文本
• 直接拼到提示词里
• 让模型自由回答

那它可以算 RAG 的最简形态，但还远远谈不上成熟。

真正稳定的 RAG，通常不是把资料“塞进去”这么简单，而是要确保：

• 塞进去的是对的材料
• 这些材料顺序合理
• 噪声足够少
• 模型知道应该怎样使用这些材料