RAG

普通的大语言模型回答问题时，主要依赖两样东西：

1. 模型训练时学到的知识；
2. 当前对话中提供给它的上下文。

但问题是，模型不可能天然知道所有外部信息。

例如你问一个普通 LLM：

“我们公司去年的退款政策是什么？”

如果这份退款政策属于公司内部资料，模型训练时根本没有见过，它自然无法准确回答。

RAG 的作用，就是在模型回答之前增加一个“查资料”的步骤。

整个过程可以简化为：

所以 RAG 最核心的逻辑就是：

先 Retrieval，再 Generation。

也就是：

先检索，再生成。

这是理解 RAG 最关键的问题。

RAG 不是一个像 Photoshop、Redis 或 Docker 一样可以直接指向某一个具体软件的东西。

它更像是一种软件架构方案。

真正落地以后，RAG 往往表现为：

一段后端代码 + 检索系统 + 数据库 + LLM。

例如开发者完全可以写一个 rag.py：

这一整套代码逻辑，就可以称为一个 RAG 系统。

因此，更准确地说：

RAG 本质上是一套由代码实现的“外部资料自动检索 + LLM生成答案”的解决方案。

因为现在很多 AI 产品已经把 RAG 封装好了。

例如某个 AI 产品允许用户：

上传公司文档 → 建立知识库 → 直接向 AI 提问。

对于用户来说，看起来就像：

上传文件 → AI知道文件内容。

但后台实际上可能发生了一系列操作：

所以用户感觉：

“这个 AI 自带知识库功能。”

但从技术角度来说：

产品只是把 RAG 系统封装成了一个功能。

这也是为什么 RAG 有时候看起来像插件，有时候像软件，有时候又像模型能力。

实际上这些只是不同的产品包装方式。

RAG 本身仍然只是一种技术方案。

可以把 LLM 想象成一个非常聪明的人。

而 RAG 是他的资料管理员。

LLM 负责：

理解、推理、组织语言、生成答案。

RAG 负责：

去哪找资料、找哪些资料、把哪些资料交给 LLM。

所以两者的关系可以简单理解成：

例如公司有 10 万份文件。

用户问：

“Router 的 Failover 为什么没有触发？”

LLM 不需要把 10 万份文件全部读一遍。

RAG 可以先从中找到：

• Failover 配置说明；
• Provider Health Check 文档；
• Retry Policy；
• Model Fallback 配置。

然后只把这些资料交给 LLM。

LLM 再根据这些内容进行分析和回答。

这里还有一个很容易混淆的问题。

如果把一个 PDF 上传给 AI，并不意味着一定使用了 RAG。

如果文件比较短，系统完全可以直接把整份文档放进 LLM 的 Context Window 中。

这种方式实际上是：

这更接近 Long Context，长上下文。

而典型的 RAG 是：

因此两者最大的区别是：

Long Context 是“把资料都给模型看”。

RAG 是“先筛选，再把相关资料给模型看”。

当资料规模变成几万、几十万甚至几百万份文件时，不可能每次都把所有内容塞给模型。

这时候 RAG 就非常重要。

另一个常见误区是：

“我把公司资料放进 RAG，是不是相当于训练了模型？”

不是。

RAG 通常不会修改模型参数。

可以把两者理解成：

例如公司产品价格今天是 100 元，下个月改成 120 元。

如果使用 Fine-tuning，每次资料发生变化都重新训练模型显然非常麻烦。

而使用 RAG，只需要修改知识库里的资料。

下一次用户提问时，RAG 就可以检索到最新的信息。

因此对于企业内部知识、产品文档、法律文件、客服资料等不断更新的信息来说，RAG 往往比 Fine-tuning 更合适。

理解 RAG 以后，会发现一个很重要的事实：

RAG 系统真正的核心竞争力，经常不在 Generation，而在 Retrieval。

因为 LLM 最终能不能回答正确，很大程度取决于前面到底找到了什么资料。

假设真正答案在文档 A。

结果 RAG 找出来的却是：

文档 B、文档 C、文档 D。

那么即使后面接的是一个非常强的大模型，它依然可能回答错误。

这也是一句非常值得记住的话：

所以一个成熟的 RAG 系统真正需要优化的是：

• 文档应该怎么切 Chunk；
• 如何建立索引；
• 用户问题应该如何理解；
• 如何进行语义检索；
• 搜索多少候选资料；
• 如何进行 Rerank；
• 最后到底选择哪些资料交给 LLM。

很多现代 RAG 系统甚至会采用：

这也是为什么企业做 RAG 时，检索质量往往和模型质量一样重要。

“RAG 到底是什么？”

可以直接回答：

RAG 不是一个模型，也不是某个固定插件，而是一套让 AI 自动检索外部资料，并把相关资料提供给 LLM 生成答案的软件架构方案。

再简单一点：

RAG，就是 AI 的自动查资料系统。

LLM 是负责思考和回答的人。

RAG 是负责在茫茫资料中，把正确文件递到它桌面上的秘书。

而一个好的 RAG 系统真正要做到的，就是：

在正确的时间，把正确的资料，交给正确的模型。