AI 电子伴侣

创建时间: 2026-08-01最后更新: 2026-08-04作者: yangbo

1. 从一个答错的问题开始

假设公司在今年调整了请假制度：年假可以拆成半天使用，连续请假三天以上需要直属负责人审批。员工把问题交给通用大模型：

NOTE

我请三天年假，需要谁审批？

模型可能回答得很流畅，但它没有看过公司的最新制度。它只能根据训练时见过的相似内容猜测，答案有时正确，有时会把别的公司规定拼进来。更麻烦的是，语气越肯定，使用者越容易相信。

我们当然可以把整份员工手册放进 Prompt。手册只有两页时，这个办法能用；等资料变成几百份 PDF、产品文档和内部公告后，每次都把全部内容发给模型，不但超过上下文窗口，调用成本和响应时间也会迅速增加。

RAG 要解决的正是这个问题：回答之前，先从外部资料中找到与问题有关的内容，再让模型依据这些内容回答。

2. RAG 是什么

RAG 是 Retrieval-Augmented Generation 的缩写，中文通常翻译为检索增强生成。这个名字看起来有些抽象，我们可以把它拆成两件事。

检索负责找资料。用户询问三天年假时，系统从员工手册里找出请假时长和审批规则，而不是把整本手册交给模型。

生成负责组织答案。模型拿到用户问题和检索结果后，用自然语言回答，并说明答案来自哪份制度。如果资料没有覆盖这个问题，模型应当明确告诉用户现有资料不足。

最小的 RAG 可以写成下面这条调用链路：

rag-minimal.txt

1用户问题
2  -> 检索相关资料
3  -> 把资料放进模型上下文
4  -> 模型基于资料生成答案

这里有一个容易说错的地方。RAG 没有把新知识写进模型参数，也没有让模型真正产生永久记忆。模型在这一轮请求中只是临时看到了检索结果；下一轮如果不再提供这些资料，它仍然不知道公司的请假制度。

因此，与其说 RAG 让模型记住了资料，不如说它让模型在回答前拿到了合适的参考材料。

3. 直接问模型与 RAG 的差别

不用 RAG 时，问题会直接进入模型。模型只能依赖训练数据、当前对话和 Prompt 中已有的信息。用了 RAG 以后，中间多出一个外部知识检索过程。

这两种处理方式的区别不只在于是否使用向量数据库。真正的分界点是：模型回答时，有没有得到一份针对当前问题选择出来的外部上下文。

公司制度问答适合使用 RAG，是因为制度属于私有、经常更新、不能依靠模型猜测的知识。AI 伴侣的长期记忆也有类似特点：用户的偏好、边界和共同经历不在模型训练数据里，需要在每次对话时按需找回来。

不过，两种场景的数据特点不同。公司制度相对稳定，重点是文档版本和引用来源；个人记忆持续增长，除了语义相关性，还要考虑时间、重要度、用户确认和隐私权限。后面做项目升级时，我们会单独处理这些差异。

4. RAG 不等于向量数据库

很多教程从 Embedding 和向量数据库开始讲，久而久之，读者容易把 RAG 理解为：

code.ts

1RAG = 向量数据库 + 大模型

这并不准确。向量检索只是常见的检索方式之一。真实系统还可能从这些地方取资料：

用 SQL 查询订单状态、用户套餐或精确日期；
用全文搜索查找产品编号、错误码和专有名词；
调用 CRM、搜索引擎或公司内部 API；
同时使用关键词检索和向量检索，再合并候选结果；
让 Agent 根据问题决定调用哪一种检索工具。

例如用户问“订单 A-1024 什么时候发货”，订单号是精确标识。直接按订单号查数据库，比把问题转成向量再做相似度检索可靠得多。用户问“有没有适合出差时申请报销的规定”，表达方式和制度原文可能完全不同，语义检索会更合适。

所以面试中被问到“RAG 是否必须使用向量数据库”时，答案应当是：不必须。RAG 关心的是在生成前引入外部检索结果，具体检索方式由数据和问题决定。

5. 一套系统中的两类工作

一个能够使用的 RAG 系统，至少包含知识准备和在线问答两类工作。

知识准备发生在用户提问之前。系统需要读取原始文档、清理无关内容、切成合适的小块、补充来源和权限信息，再建立可以查询的索引。

在线问答发生在用户请求到达之后。系统理解问题，限定检索范围，找出候选资料，必要时做重排，然后把经过筛选的上下文交给模型。

如果只写了在线查询接口，却没有考虑资料如何更新和删除，系统很快就会出现旧版本制度仍然被召回的问题。如果只把文档写进向量库，却没有验证用户问题能否命中正确片段，也不能算完成了 RAG。

下一篇会把这两条链路完整展开。现在先记住一个判断方法：

NOTE

建立索引解决“资料怎样准备”，在线查询解决“当前问题应该使用哪些资料”。

6. 三种常见架构

LangChain 当前将常见 RAG 架构分为 2-Step RAG、Agentic RAG 和混合方式。它们使用的知识库可以相同，区别主要在于谁决定何时检索，以及检索之后是否还有额外判断。

2-Step RAG

2-Step RAG 每次都先检索，再生成答案。公司制度、产品文档和客服问答通常适合从这种方式开始，因为执行步骤固定，延迟和成本容易估算，出了问题也方便区分是检索错误还是生成错误。

two-step-rag.txt

1问题 -> 检索 -> 生成

Agentic RAG

Agentic RAG 把检索包装成工具，由 Agent 判断是否调用、调用几次以及是否改写查询。它更灵活，适合研究助手或同时连接多个数据源的场景，但调用路径不再固定，调试和评测也更复杂。

agentic-rag.txt

1问题 -> Agent 判断 -> 选择工具 -> 检索或继续推理 -> 回答

混合方式

混合方式会保留显式流程，同时在局部使用模型判断。例如先固定执行权限过滤和第一次检索，如果结果不足，再让 LangGraph 进入查询改写、补充检索或人工确认节点。

对于刚接触 RAG 的读者，学习顺序应该是 2-Step RAG、受控的 LangGraph 工作流，最后才是 Agentic RAG。先把可预测的流程跑通，再增加自主决策，问题会更容易定位。

LangChain 官方的 Retrieval 文档也把 2-Step RAG 作为简单、延迟可预测的方案，把 Agentic RAG 用于需要动态决定检索方式的任务。

7. 哪些场景不需要 RAG

RAG 很常用，但并不是所有 AI 功能都应该接知识库。

如果任务只是改写一段文字、翻译、提取用户已经提供的字段，所需信息已经在当前输入里，额外检索只会增加延迟。如果答案来自一条确定的业务记录，例如账户余额或订单状态，应当调用受权限保护的业务接口，而不是让向量检索猜答案。

资料规模很小并且每次都必须完整阅读时，也可以直接放入上下文。比如只有一页活动规则，强行切块、向量化和召回，工程复杂度可能大于收益。

可以用三个问题判断是否值得做 RAG：

答案是否依赖模型训练数据之外的信息？
资料是否多到不能每次全部放入上下文？
是否只需要从资料中选择与当前问题相关的一部分？

三个问题大多回答“是”时，RAG 才真正有价值。

8. 回答错误时先查哪里

RAG 系统答错问题，不要第一时间更换大模型。我们可以先把一次请求拆开检查。

如果正确资料根本没有进入候选结果，问题通常出在文档解析、切块、查询表达、Embedding、过滤条件或召回策略。此时继续修改生成 Prompt，模型仍然看不到答案。

如果正确资料已经检索出来，但最终答案遗漏或曲解了内容，再检查上下文排序、Prompt 约束、上下文长度和生成模型。

如果答案正确但引用来源不对，需要检查 chunk 与原文的映射关系，而不是只看回答文本。

这也是面试里判断候选人是否真正做过 RAG 的一个分水岭。只会说“调整 Prompt”和“换更好的模型”，通常没有把检索与生成分开；能够拿出问题、候选文档、分数、最终上下文和回答逐段排查，才是在处理真实系统。

9. 总结

RAG 的核心并不复杂：模型回答前，系统先从外部世界取回当前问题需要的信息。它不会修改模型参数，也不要求一定使用向量数据库。

学习 RAG 时，先把检索和生成分开，再区分知识准备与在线问答。后面的文档切分、Embedding、重排、引用和评测，都是围绕一个目标展开：让正确资料稳定地进入模型上下文，并且在资料不足时允许系统如实回答不知道。