AI 学习小记:大模型总爱瞎编?你需要认识 RAG

一、什么是 RAG？

如果你需要把 AI 落地到实际应用中，那你一定躲不过这个词：

RAG（Retrieval-Augmented Generation，检索增强生成）

▸ 举例说明

我们先通过一个简单的小案例来了解 RAG 是什么：

假设我们买了一张票，现在想要退掉，但你不知道能不能退，也不知道是能全额退还是部分退。

这时候你问 claude、GPT 等这些大模型，它可能会告诉你，你可以全额退。

当你真正退了之后，你发现实际上并不是全额退，平台扣掉了你 30% 手续费。这时候你才反应过来，大模型说的也不全是真的，模型是有幻觉的。

那么有没有什么办法可以减少模型的幻觉呢？

让我们先回到上一步。

你在问大模型之前，你意外获得了一个平台规则的文档，你把文档里"退款"相关的内容和你的问题一起发给大模型。

这时候大模型会告诉你，你今天退款只能退还 70% 的金额，这个回答明显更接近实际情况。

这就是 RAG，它的核心思路非常简单：用户提问后，不让 AI 直接回答，而是先去查找相关资料，再基于这些资料生成答案。

整个过程可以理解为：

用户提问 → 知识库检索 → 找到相关资料 → 把资料提供给 LLM → 生成答案

▸ RAG 的工作流程

在这个过程中，RAG 的工作流程分为两个阶段：

【第一阶段】数据分块处理（建立索引）

【第二阶段】查询操作

当用户提出查询时，比如"我的保险单是否涵盖这种药物 X 的费用？"，你的大型语言模型会将这个查询转换为一个嵌入向量，我们将其称为 QUERY_EMBEDDING。
你的向量数据库会检索出那些嵌入向量与 QUERY_EMBEDDING 最为相似的数据块。

▸ 衡量检索质量

在上面两个阶段里，检索质量是非常关键的。

那怎么去衡量 RAG 的信息检索质量？通常使用两个经典指标：

上下文精度：你搜到的所有资料里，有多少是有用的？

比如你搜"怎么做红烧肉"，搜索结果里 10 篇文章有 6 篇是真的教做红烧肉的，那精度就是 60%，另外 4 篇是其他不相关内容。

上下文召回率：所有真正有用的资料里，你搜到了多少？

还是拿红烧肉举例，假设有 20 篇高质量的红烧肉教程，你的搜索结果只覆盖了其中 6 篇，那召回率就是 30%，剩下的 14 篇没被搜到，就被"漏掉"了。

简单概括就是：精度是看"搜出来的东西准不准"，召回是看"该搜到的东西全不全"。

回到一开始的小案例，有人可能会问：直接把整个文档发给大模型就好了，为什么要再引入 RAG？

这里从三个方面回答这个问题：

省 token、省时间
如果你的文档很小，那直接丢给大模型就是最好的选择。
但是如果你的文档很大，直接丢给大模型就不划算了——每次回复它都需要先去读取文件内容，再去回答你的问题，这个过程会导致计算效率低下，非常浪费 token，也浪费时间。
简化内容，提高大模型性能
我们知道很多大模型的上下文会有一定长度限制，当你的上下文内容很多的时候，你会发现大模型的注意力越来越分散，很容易已读乱回。
特别是你频繁带一个大文件去对话大模型，聊到后面，发现对话质量会严重下降。
如果附件的文件过大，大模型可能只能读完前半部分，一旦要查询的内容是在后半部分，它就无法成功检索到有效内容，这时候带文件查询的意义也就不大了。
所以 RAG 有个很大的优势就是，可以帮助大模型减少噪声。在检索的时候，一般是检索前 5 条相关内容（也视情况而定），只向大模型提供关键信息。
更适合企业级 / 大数据应用
前面也提过，如果文件内容过多或者过大，RAG 的优势就会表现得非常明显。
特别是在企业的落地场景中，很多时候是要先查内部资料，再去做回答，质量才会更高更稳定。出于数据安全考虑，也很难把所有文件都丢给大模型去消化。

虽然说了很多 RAG 的优势，但也不是所有情况都要用 RAG——比如文件内容较少，可以直接丢给大模型处理。

RAG 最适合的场景，本质上都有一个共同点：答案已经存在，只是分散在各种资料里，需要先"找出来"，再"组织成回答"。

总体来说，只要一个问题的正确答案不依赖模型"创造"，而依赖"从已有资料中查找"，那么 RAG 就非常适用。