八个步骤，你可以把整个过程想成"秘书处帮领导准备一份答复材料"：
| 步骤 | 系统在做什么 | 生活化类比 |
|---|---|---|
| ❶ 接收问题 | 用户输入的问题被系统收到 | 领导交办："帮我弄清楚XX这件事，给我一份答复" |
| ❷ 嵌入理解 | 先把问题"整理"得更好查——改写含糊的措辞、补上同义说法、把一个复杂问题拆成几个小问题——然后再转换成一串数字（向量），方便计算机"理解语义"并拿去跟数据库比对 | 秘书先把交办的问题理明白——含糊的地方问清楚、换成档案系统里的规范说法，才好去调文件 |
| ❸ 检索 | 拿这串数字去数据库里找最相关的几段文字。真实系统里这一步是个"先宽后窄的漏斗"：先用两条路一起找（按意思找的向量搜索 + 按字面找的关键词搜索），再按条件筛掉不该出现的（比如你没权限看的、太旧的），最后用一个更仔细的模型把剩下的候选重新排一遍序（叫"重排"），只留下最切题的几段 | 秘书去档案室调卷：几个渠道同时找，剔掉自己无权调阅的密级文件和已作废的旧版本，再逐份细读，只留下真正答得上问题的那几页 |
| ❹ 增强（组装 Prompt） | 把"找到的资料"+"你的原始问题"+"系统的行为指令"拼成一段完整的文字，准备交给模型。"增强"这个名字来自 RAG 的全称 Retrieval-Augmented Generation（检索增强生成）——用查到的资料去增强你的原始问题，指的就是这一步 | 秘书把调出的资料页、领导的原始问题、还有"照材料写、别自由发挥"的要求，一起装进一个工作夹 |
| ❺ 生成 | 大语言模型读这个文件夹，逐字写出答案 | 处里的笔杆子接过工作夹，照着里面的材料起草答复稿 |
| ❻ 守门（护栏） | 系统检查这段回答有没有问题（比如泄露不该说的内容、格式不对、明显瞎编）——这道检查机制在业界的标准叫法是"护栏"（Guardrails）。更讲究的系统还会让模型自己"对照查到的资料，把答案再核一遍"，发现出入就改（这个自查动作叫 reflection，反思修正） | 起草人先自己对照原始文件把稿子核一遍，处长再把关审定，才准上报 |
| ❼ 回应引用 | 把答案连同"这句话是根据哪份文档、哪一段"的引用一起返回给你 | 呈报领导的答复上注明"依据某文件第某条"，领导随时可以调原件核对 |
| ❽ 记录 | 系统把这轮问答记下来——通常存两份：日志（持久档案，给之后排查问题、审计、统计用）和对话历史（留给你下一个问题当背景的上下文，两份记录用途不同、存放位置也常不同） | 办公室登记备案：谁交办的、什么时候办的、调了哪些文件、答复了什么；同时把这次问答归入这位领导的往来卷宗，下次交办时随手可翻 |
一个提醒：通常说的"RAG"，只是这张表的中段。 论文和教程里定义的 RAG，核心就是 ❸ 检索 → ❹ 增强 → ❺ 生成这三步——恰好对应 RAG 全称的三个词（Retrieval 检索、Augmented 增强、Generation 生成）；❷ 转向量是检索的前置动作，一般也算进去。其余几步不属于 RAG 本身：❶ 和 ❼ 是任何在线服务都有的"一收一发"，❽ 是运维记账，❻ 是生产系统的加固措施。所以当别人说"我们上了 RAG"，指的往往只是中间那一段；这张表描述的，是把 RAG 放进真实生产系统后跑起来的完整流程。
这八步分别由哪些"部门"承担：
| 部门 | 负责的步骤 | 是什么 |
|---|---|---|
| 前端 | ❶ 收下你的问题、❼ 把答复呈现给你 | 你打字提问、看到答案的那个聊天窗口 |
| 编排／后端 | 指挥全部八步的先后与放行；亲自动手做 ❹ 组装和 ❻ 的规则检查 | 一个看不见的协调程序——自己不"回答问题"，但决定去哪拿资料、怎么组装、生成完要不要卡下来审查。第三章会展开一条重要规则：全系统只有它是"主动发起方" |
| 模型 | ❷ 把文字转成向量（嵌入服务）、❺ 生成答案（LLM服务） | 真正做"理解语义"和"写答案"的AI。两种服务各有两种部署形态：云端调用（即 MaaS，Model-as-a-Service 模型即服务——模型跑在供应商云上，通过网络调用，不用自己买机器）或自托管（自己架机器跑，数据不出公司边界）。选哪种形态是第五章合规讨论的关键决策 |
| 数据 | ❸ 检索去查的地方 | 向量数据库（存资料转成的向量，通常也存着原文明文备份，查到向量就能调出原文）+ 文档／对象存储（最原始的PDF、Word文件本身存放的地方） |
| 支撑 | ❽ 记录中"日志"那一份的去处（另一份"对话历史"由后端保管，留给下一轮用） | 日志／可观测性系统——每次"谁问了什么、查了什么、答了什么"都留一份持久副本，供排查与审计。第五章会讲到：这是合规上最容易被忽略的角落 |
离线索引：八步之外的日常准备——检索去查的资料是哪来的？
上面八步讲的都是"领导交办之后"发生的事，但有个前提被跳过了：❸ 检索去查的那个向量数据库，里面的向量是谁、什么时候放进去的？答案是一条独立于八步之外、平时就在运转的准备流水线，叫离线索引（"离线"的意思是：不发生在回答问题的现场，而是提前做好）：
文档 → 解析（把PDF、Word等格式读成纯文字）→ 切块（把长文档切成一段一段，比如每段几百字，因为模型一次读不了太长也不好精准定位）→ 嵌入（把每一小段转成数字向量）→ 存进向量数据库。
这一步就像档案室平时就把所有文件立卷、编目、按主题归档，之后要用才能随调随到——如果不先做这一步，每次领导交办都要现场把全公司文件重新翻一遍，会慢到无法忍受。它也不是"做一次就完"：文档有新增和修订、检索策略要调整，都会触发索引更新或重建——下面的回环 D 会讲到是什么在驱动这件事。
这八步是一条直线吗？四个回环
单看一次顺利的问答，八步确实是从头走到尾的一条直线（前一步的产出是后一步的原料，顺序不能乱）。但真实系统会在这条主干上挂几条"回头路"，遇到特定情况就往回走：
- 回环 A · 再查一轮：模型在生成答案前发现"查到的资料不够回答这个问题"，于是换个问法回到❷❸再检索一轮，可能反复几次，直到资料够用。关键在于：查几轮不是程序预先写死的，而是模型自己临场判断的——这正是后面第四章要讲的"代理式"工作方式。
- 回环 B · 守门驳回：❻检查不通过时，系统按预先定好的规则退回❺重新生成一次，或退回❸重新检索。和回环 A 不同，这里"什么情况退、退到哪、最多退几次"都是工程师事先写死的规则，模型没有决定权。
- 回环 C · 多轮对话：模型本身是没有记忆的——一轮问答结束，它什么都不会"记住"。你之所以能接着追问"那第二种呢"，是因为 ❽ 每轮都会把问题和答复存进对话历史（注意是 ❽ 存的两份记录里的这一份，不是日志）；你发新问题时，❹ 组装的工作夹里除了新问题和新查到的资料，还会把这份历史一并附上，模型当场重读一遍，才知道"第二种"指的是什么。一句话概括这个环：上一轮的输出，会变成下一轮输入的一部分。
- 回环 D · 日志反哺：❽积累的日志会定期交给评估体系分析（哪类问题答得差、是检索找错了还是生成写错了），工程师根据结论调整切块方式、检索策略，再重建离线索引。这个环以天或周为周期转动，环上做决定的是人，不是系统。
延伸说明：RAG 的"代际"划分
RAG 自诞生以来一直在演进，行业习惯把它分成三代。
第一代叫朴素 RAG（Naive RAG）：八步一条直线走到底，每一步都只做最简单的版本。第二代叫高级 RAG（Advanced RAG）：骨架不变，但每一步做得更精细——❷ 加入改写和拆解，❸ 变成先宽后窄的漏斗，❻ 补上反思修正，再配上回环 B 这类按规则触发的重试。本章描述的"真实系统"就属于这一代。第三代叫代理式 RAG（Agentic RAG），第四章会专门展开。
三代之间的分界线，不在于有没有回环，而在于循环由谁决定。前两代的循环规则由工程师预先写在代码里，系统只是照章执行；代理式 RAG 则把"要不要再查、怎么查"交给模型在运行中自行判断，回环 A 就属于这种情形。至于回环 B、C、D，在前两代系统里，它们的决定权同样握在规则和人手里：B 由预设规则触发（规则内部可以请模型充当"打分员"，比如让模型给检索结果的质量打分，但打分之后走哪条路仍由规则决定），C 按固定方式附带历史，D 由工程师驱动，所以它们的存在不改变代际判断。反过来，一旦把某个环的决定权真的交到模型手里——比如让模型自行判断答案是否有依据、要不要重查重写（业界确有这类做法，如 Self-RAG）——按同一标准，这个环也就代理化了。归结起来：三代用的组件是一样的，变的是指挥权在谁手里。