稀饭

什么是 RAG：给大模型装一根「外接知识线」

RAG(检索增强生成)概念全解析：大模型的三个死穴、切块/向量化/检索/生成四大步骤、RAG-Fusion/重排序/GraphRAG/Agentic RAG 变体，以及检索比生成更值得优化的那些坑。

  • AI
  • RAG
  • LLM
  • 检索增强生成
  • GraphRAG
  • 向量数据库

在 CS230 课程笔记里， 我把 RAG 列进了给 base model"增强"的三件套之一；在graphify 那篇里又提过 GraphRAG。 但"RAG 到底是什么"这个基础问题，一直没有单独讲清楚。这篇就把它的概念、为什么需要、 核心流程、常见变体和坑，一次讲明白。

一、它是什么：给大模型装一根"外接知识线"

RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。 名字已经把原理说完了：先检索，再生成——在让大模型生成回答之前， 先从外部知识库里检索出相关内容，作为上下文一起交给模型。

一句话定义：

RAG 是一种把"模型内部的参数化知识"和"外部可检索的非参数化知识"结合起来的架构。模型负责理解和生成，外部数据库负责提供它没见过、没记牢、或者不该背下来的事实。

它和"微调（Fine-tuning）"是两种互补的思路：微调是把知识写进模型的参数， 让模型"记住"；RAG 是把知识放在模型外面，用到时"查出来"。 更直白的对比：

微调 Fine-tuningRAG
知识存哪模型参数里外部数据库里
更新成本重新训练，贵、慢换文档，便宜、快
适合改变模型的风格/能力/格式给模型喂新鲜、私有的知识
可解释性黑盒，说不清依据可追溯，能指出引用来源

二、为什么需要它：大模型的三个死穴

为什么要"外接知识"？因为大模型有三个靠自身解决不了的问题：

1. 知识有截止日期

模型的训练数据有个截止时间，之后发生的事它一概不知。2026 年的新闻、你公司刚发的内部文档、 昨天刚上线的产品功能——它都没见过。RAG 把这些新鲜知识放到外部库里，问题就解决了：知识库更新了，模型不用重新训练，回答就跟上了。

2. 知识是"模糊记忆"，不是"精确查阅"

模型对常见知识很熟，但对具体细节会幻觉——一本正经地编造不存在的条款、 错误的引用、虚构的数据。因为它是"按概率生成"而不是"查表"。RAG 让模型去查真实文档，用检索到的原文约束生成，幻觉大幅下降——尤其适合需要精确、可引用的场景（客服、法律、医疗、财务）。

3. 私有知识进不了参数

你的公司文档、客户数据、个人笔记，不可能拿去训练大模型。但 RAG 不需要：知识留在你自己的数据库里，只把相关的片段临时取出来给模型看。数据主权还在你手上。

三、核心流程：四大步骤

一个标准的 RAG 系统由四个环节组成。前半段是离线建库（做一次）， 后半段是在线问答（每次提问都走）：

第 1 步：切块（Chunking）

原始文档太长，不能整个塞进上下文。先把文档切成小块（chunks）—— 按段落、按标题层级、按固定长度都可以。切块策略直接决定后面检索的质量： 太碎会丢失上下文，太大又容易检索到不相关的部分。

第 2 步：向量化 + 建索引（Embedding + Indexing）

把每个 chunk 用 embedding 模型转成一个向量（一串表示语义的数字）， 然后存入向量数据库。这一步是离线做的，把整份文档变成了一张"语义地图"。

第 3 步：检索（Retrieval）

用户提问时，先把问题也转成向量，然后在向量数据库里找语义最相近的 top-k 个 chunk。 相似度通常用余弦相似度计算。这一步决定了模型"能看到什么"，是 RAG 质量的关键。

第 4 步：增强生成（Generation）

把检索到的 chunks 作为上下文，拼进 prompt，交给大模型生成回答—— 并在 prompt 里明确要求"只基于提供的资料回答，不要编造"。这样回答既有了依据，又能被追溯。

把这四步画成一条线：

文档 → 切块 → 向量化 → 向量数据库(离线建库)
                                          ↓
用户提问 → 向量化 → 检索 top-k → 拼进 prompt → 大模型 → 回答(在线问答)

四、进阶变体：从"朴素 RAG"到 RAG 2.0

上面是最基础的 Naive RAG。过去两年 RAG 进化出了很多变体， 挑几个重要的：

RAG-Fusion 与重排序（Rerank）

朴素的向量检索只看"语义相似"，偶尔会漏掉关键词完全匹配但向量不太像的情况。RAG-Fusion 同时跑向量检索 + 关键词检索，再合并结果；Reranker 用更精的模型对检索结果二次排序，把最相关的顶上来。 检索质量提升明显，是性价比最高的升级。

GraphRAG

向量检索本质是"语义相似"，回答"哪些实体之间有什么关系"这种全局问题就吃力。GraphRAG 把知识库建成知识图谱——实体是节点、关系是边， 模型可以沿着图做多跳推理。适合"总结整个语料库"、"找实体间联系"的场景。graphify 那篇讲的就是这类思路。

Agentic RAG

最前沿的方向：不再是"一次检索一次生成"，而是让 Agent 自己决定怎么检索—— 拆解复杂问题、多轮检索、根据中间结果决定下一步查什么、必要时调工具。 这正好接上前面几篇写的MCP（工具接口）和Agent Skills（技能装载）—— 检索可以是 Agent 众多工具中的一个，RAG 也从"一个固定流程"变成"Agent 的一项能力"。

五、一些诚实的提醒

RAG 不是银弹。几个常见的坑：

  • "检索不到"比"模型不会"更常见——很多 RAG 系统效果差，根因不在生成，在检索：切块太差、embedding 不匹配、top-k 太小。先用好检索，再优化生成；
  • 相关性 ≠ 准确性——检索到的不一定是对的。同一份文档里可能自相矛盾，多份文档可能冲突。要做引用溯源和冲突检测，而不是把检索结果当事实；
  • 上下文塞满也会稀释注意力——塞进 20 个 chunk，模型可能被无关内容带偏。少而精，配合重排序，往往比堆量更有效；
  • 评估不容易——"回答好不好"是个主观问题。常用的做法是分两条线看：检索质量（召回率、命中率）和生成质量（忠实度、相关性、正确性），分别评估。

我的收获

  1. RAG 的本质是"给模型装外接知识线"——它把"知识"从模型参数里解放出来，变成可以随时更新、随时替换、可以追溯来源的独立资产。这是它被所有生产系统采用的根本原因。
  2. 先解决"能不能查到"，再谈"答得好不好"——RAG 系统的性能瓶颈几乎总在检索端。切块策略、embedding 选择、重排序，这些"笨功夫"比换更强的大模型提升更大。
  3. RAG 正在被 Agent 化——从固定流程到 Agent 自主决定怎么检索，RAG 越来越不像"一个组件"，而像"一项需要判断的能力"。这和我们一路聊的 Agent 主线完全一致。
  4. 可解释性是被低估的红利——RAG 每次回答都能指出依据来源。在合规要求越来越严的行业里，这个"能给引用"的能力，可能比回答本身的准确度更值钱。

顺着这篇往下走，下一站可以是：怎么选 embedding 模型、怎么设计切块策略、 或者干脆动手搭一个最小的 RAG demo。如果对 GraphRAG 或 Agentic RAG 感兴趣， 站里 graphify 那篇是很好的延伸阅读。