RAG工作原理深度拆解：检索如何让大模型保持诚实

RAG 已成为应用 AI 中最重要的模式之一，也是被谈论得最模糊的模式之一。下面我来解释 RAG 到底是什么、它的流水线是如何端到端工作的，以及它在哪里会悄然失效。

RAG 要解决什么问题

大语言模型的知识在训练时就已固定。它不知道你的内部文档、上周的数据或用户刚刚上传的某份银行对账单。更糟的是，当你向它询问超出其知识范围的问题时，它很少会说"我不知道"——它会用一段流畅、看似合理但往往错误的答案来填补空白。

给模型注入新知识有两条路。一条是微调——成本高、速度慢，而且对于频繁变化的事实来说是个糟糕的选择。另一条是在提问时检索相关信息，将其作为上下文交给模型。第二条路就是 RAG，对于需要事实性、经常变化或私有的数据，它几乎总是胜出。

流水线：分步解析

RAG 有两个阶段：离线索引阶段和在线查询阶段。

索引（提前一次性完成）：

• 将文档切分成段落——每个段落几百个 token。切得太大，检索就会变得嘈杂；切得太小，又会丢失上下文。这个边界的处理比人们想象的更重要。
• 将每个段落嵌入为向量——一个捕捉其含义的数字列表，使得主题相似的段落在向量空间中彼此靠近。
• 将这些向量存入向量数据库。

查询（每次用户提问时执行）：

• 使用相同的模型将问题嵌入为向量，然后检索向量最接近问题的 top-k 个段落。这是语义搜索——匹配的是含义，而不是关键词。
• 增强提示词：将检索到的段落与用户的问题拼接在一起，并附上类似"仅使用以下上下文作答"的指令。
• 生成答案。此时模型是在真实检索到的文本上作答，而不是依赖它冻结的记忆——你还可以要求它注明每个结论来自哪个段落。

这就是 RAG 的全部思路：先检索，再生成。模型不再是一个记忆库，而变成了一个对你提供的实事进行推理的推理引擎。

为什么 RAG 在事实层面优于微调

微调教给模型的是新行为——一种语调、一种格式、一项技能。用它来教事实是一种笨拙的方式，因为事实会变化，而重新训练代价高昂。RAG 将两者清晰分离：模型负责语言和推理，你的知识库负责真相。更新一份文档，系统的答案就会立即更新——无需任何训练过程。

在我构建的各个 AI 系统中，这是一个我依赖的架构，因为它把 LLM 从一个不可靠的神谕变成了一个真正能放到用户面前使用的东西。

RAG 不是魔法，大多数失败都是检索失败，不是生成失败

• 糟糕的分块：将一个事实拆分到两个段落中，导致任何一个都无法完整被检索出来。
• 检索漏召：正确的段落存在，但没有排进 top-k，模型根本看不到它，只好回头猜测。
• 上下文塞填：塞入二十个勉强相关的段落会把真正有用的那个淹没，并让模型产生困惑。

教训是：在一个 RAG 系统中，你的大部分工程努力应该放在检索质量上，而不是提示词的措辞上。

在真实系统中看到它

RAG 最令人信服的形态，是模型根本不被允许直接陈述事实。在我写的《让 LLM 对银行对账单产生信任》中——一个用自然语言回答财务文档问题的平台——LLM 的唯一工作是根据严格的 schema 生成 SQL 查询。数据库产生数字，模型从不编造一个。这就是 RAG 逻辑上的极致演绎：检索不仅是上下文，它本身就是护栏。

如果你只记住一件事：不要让 LLM 去记忆。在恰当的时刻给它正确的信息，让它做它真正擅长的事——对眼前的内容进行推理。