RAG 全链路总览 &「RAG 已死」之争

T2-1模块 2 · RAG 工程化面试权重 高更新于 2026-08
前置T0-4
关联题目Q2-01Q2-02

这篇学完你能回答什么

  • 「完整讲一遍 RAG 链路，每一步在解决什么问题？」——一面几乎必问的开场题。
  • 「模型都支持百万上下文了，为什么还要 RAG？」
  • 「一个 RAG 系统效果差，你怎么定位是哪一环的锅？」

从一个真实场景讲起

老板扔给你一个需求：「把公司这三年的产品文档、售后工单、内部规范做成一个能问答的机器人。」

你的第一反应可能是：把文档全塞进 prompt 里？三年文档几千万字，塞不下，也塞不起——就算模型支持百万 token，每问一句话都过一遍全量文档，成本和延迟都会失控。

第二反应：微调一个模型把知识「学进去」？但文档下周就会更新，总不能每周训一次；而且模型学完也说不清「这句话是从哪份文件来的」，出了错没法追溯。

RAG（Retrieval-Augmented Generation，检索增强生成）就是第三条路，思路朴素得像开卷考试：别让模型背书，让它查书。 用户提问时，先从知识库里捞出最相关的几段，连同问题一起交给模型，让它照着材料回答。

两条老路都堵死了，才有第三条
老板要把三年产品文档、售后工单、内部规范做成问答机器人

  1. 老板扔来的需求

    三年产品文档、售后工单、内部规范

  2. 第一反应 · 全塞进 prompt

    三年文档几千万字，塞不下也塞不起

  3. 就算塞得下断点

    每问一句都过一遍全量，成本和延迟失控

  4. 换第三条路 · RAG

    先捞出最相关的几段，连问题一起交给模型

全量灌进上下文三年几千万字塞不下，也塞不起
微调把知识学进去文档下周就更新总不能每周训一次
微调答错了想追问依据说不清从哪份文件来
三条路里 RAG 赢在朴素：不改模型，只在提问时把最相关的几段塞进上下文。代价是离线那半条链路一点都省不掉 —— 书得先整理好、索引得先建好。

核心概念：一句话定义

RAG = 检索（Retrieval）+ 增强（Augmented）+ 生成（Generation）。用一次外部检索，把「模型不知道的知识」临时装进上下文，再让模型基于这些材料作答。

它解决三个模型的先天缺陷：不知道你的私有数据、知识有截止日期、胡说八道无从追溯。

别让模型背书，让它查书
同样是「让模型知道你的私有知识」，写进权重和临时装进上下文差在哪
闭卷 · 全背在脑子里

张口就来，不用翻材料

教材下周改版就得重背；也说不清哪一页学的

对应
微调 · 把知识学进权重

Fine-tuning

文档下周就会更新，总不能每周训一次；出了错也说不清这句是从哪份文件来的

每周重训无从追溯
开卷 · 现翻现答

先翻到相关那几页，照着材料答

材料翻对了，人照样可能抄串行

对应
RAG · 检索增强生成

Retrieval-Augmented Generation

用一次外部检索，把「模型不知道的知识」临时装进上下文，再让它基于这些材料作答

私有数据知识截止日期引用溯源
查书这条路专治模型的三个先天缺陷：不知道你的私有数据、知识有截止日期、胡说八道无从追溯。前两个它能解，第三个只能靠引用溯源一直盯着。

原理拆解：完整链路

只说四个词，等于说自己没建过
离线建索引只做一次，在线查询每次都走 —— 十环各解决一个问题
离线 · 建索引（PDF / Word / 网页 / 工单，只做一次，更新时增量做）
① 解析抽文字、表格、标题层级
② 分块 Chunking切成可检索的语义单元
③ 向量化 Embedding每块变成一个向量
知识库落成
原文 + 元数据一起存④ 入库建索引向量索引 + 倒排索引
在线 · 查询（每次提问都走一遍）
⑤ 查询理解改写、扩展、路由
⑥ 检索召回向量 + BM25 双路，求召得全
⑦ 融合与重排Rerank：从召得全到排得准
组装与作答
⑧ 上下文组装拼 prompt、控预算、带出处
⑨ 生成基于材料作答 + 引用溯源
闭环
⑩ 评测与迭代badcase 回归集
做砸了的症状 —— 这张表本身就是排障框架
环节做砸了的症状
① 解析表格变乱码、扫描件抽不出字
② 分块答案被切成两半，永远召不回
③ 向量化领域词理解不了，相似度失真
④ 索引数据一涨延迟飙升
⑤ 查询理解口语化问法搜不到
⑥ 召回正确答案根本没进候选
⑦ 重排答案在第 18 位，被截断丢掉
⑧ 组装塞太多反而变笨（context rot，见 T1-3）
⑨ 生成有材料也胡说、引用对不上
⑩ 评测全靠拍脑袋调参

最忌讳只说「切块、向量化、检索、生成」四个词。要讲成两条线：离线建索引只做一次、文档更新时增量做；在线查询每次提问都走一遍。分不分得开这两条线，直接决定面试官把你归到「建过系统」还是「调过 API」。

效果不好怎么定位？标准动作是先切开检索和生成 —— 把正确文档手工塞进 prompt，模型能答对就是检索的锅，还是答错就是生成 / prompt 的锅。这一刀下去，问题范围立刻缩小一半（详见 T2-8）。

链路上每一环都可能是效果瓶颈，所以真正的能力不在于会搭，而在于出问题时知道该拆哪一环 —— 这也是「讲一遍链路」这道开场题真正在考的。

面试让你「讲一遍 RAG」，最忌讳只说「切块、向量化、检索、生成」四个词。要讲成两条线——离线建索引和在线查询：

原文示意
【离线·建索引】只做一次，文档更新时增量做
  原始文档(PDF/Word/网页/工单)
      ↓ ① 解析：抽文字、表格、标题层级          → T2-2
      ↓ ② 分块 Chunking：切成可检索的语义单元    → T2-2
      ↓ ③ 向量化 Embedding：每块变成一个向量     → T2-3
      ↓ ④ 入库建索引：向量库 + 原文 + 元数据     → T2-4
      ▼
   知识库（向量索引 + 倒排索引）

【在线·查询】每次提问都走一遍
  用户问题
      ↓ ⑤ 查询理解：改写、扩展、路由            → T2-7
      ↓ ⑥ 检索召回：向量 + BM25 双路            → T2-5
      ↓ ⑦ 融合与重排 Rerank：从"召得全"到"排得准" → T2-5 / T2-6
      ↓ ⑧ 上下文组装：拼 prompt、控预算、带出处
      ↓ ⑨ 生成：LLM 基于材料作答 + 引用溯源
      ▼
    答案（附引用）
      ↓ ⑩ 评测与迭代：badcase 回归集             → T2-8

每一步在解决什么问题（面试答题时按这个节奏走，比罗列名词专业得多）：

步骤 要解决的问题 做砸了的症状
① 解析 把非结构化文件变成干净文本 表格变乱码、扫描件抽不出字
② 分块 让每块语义完整又粒度合适 答案被切成两半，永远召不回
③ 向量化 让语义可计算 领域词理解不了，相似度失真
④ 索引 让千万级检索在毫秒内完成 数据一涨延迟飙升
⑤ 查询理解 用户提问和文档表述对不上 口语化问法搜不到
⑥ 召回 尽可能不漏（recall） 正确答案根本没进候选
⑦ 重排 把最相关的顶到前面（precision） 答案在第 18 位，被截断丢掉
⑧ 组装 在有限预算里给模型最优材料 塞太多反而变笨（context rot，见 T1-3）
⑨ 生成 忠实于材料、不编造 有材料也胡说、引用对不上
⑩ 评测 知道哪一环拖后腿 全靠拍脑袋调参

这张表本身就是排障框架：面试官问「效果不好怎么定位」，标准动作是先切开检索和生成——把正确文档手工塞进 prompt，模型能答对，就是检索的锅；还是答错，就是生成/prompt 的锅。这一刀切下去，问题范围立刻缩小一半（详见 T2-8）。

工程实践（截至 2026-08）

RAG 的四代形态，这是 2026 年面试的必备坐标系：

形态 特征 适用
Naive RAG 检索一次 → 生成，固定管线 小型 FAQ、原型验证
Advanced RAG 加语义分块、混合检索、Rerank、查询改写 当前生产主流基线
Agentic RAG 由 Agent 决定检不检、检哪、够不够、要不要再检一轮 多跳推理、复杂问答（T2-9）
GraphRAG 抽实体关系建图，支持跨文档推理与全局洞察 实体密集、关系复杂的领域（T2-9）

一句话记住选型直觉：Advanced RAG 做基座，Agentic 作调度层，GraphRAG 按需加挂——具体决策树见 T2-10。

几个新手常踩的认知坑：

  • RAG 不等于向量检索。 向量检索只是召回手段之一；BM25、SQL、图查询、Web 搜索都可以是 RAG 的检索源。把 RAG 等同于「向量数据库」是典型的半吊子回答。
  • RAG 不是消灭幻觉，是给幻觉套缰绳。 材料给对了模型照样可能编，所以要有引用溯源和忠实度评测（T2-8）。
  • 60% 的 RAG 项目死在从 demo 到生产的路上，死因高度集中在检索层设计和评测缺位，而不是模型不够强。
Advanced 做基座，另外两代按需加挂
2026 年面试的必备坐标系：先说清自己停在哪一代，再谈优化
RAG 的四代形态
形态特征适用
Naive RAG检索一次 → 生成，固定管线小型 FAQ、原型验证
Advanced RAG加语义分块、混合检索、Rerank、查询改写当前生产主流基线
Agentic RAG由 Agent 决定检不检、检哪、够不够、要不要再检一轮多跳推理、复杂问答（T2-9）
GraphRAG抽实体关系建图，支持跨文档推理与全局洞察实体密集、关系复杂的领域（T2-9）
选型直觉与认知坑
选型直觉
Advanced RAG 做基座，Agentic 作调度层，GraphRAG 按需加挂 —— 决策树见 T2-10
坑一
RAG 不等于向量检索：BM25、SQL、图查询、Web 搜索都能当检索源；等同于「向量数据库」是半吊子回答
坑二
不是消灭幻觉，是给幻觉套缰绳 —— 材料给对了模型照样编，所以要有引用溯源与忠实度评测（T2-8）
坑三
60% 的 RAG 项目死在从 demo 到生产的路上，死因集中在检索层设计和评测缺位，不是模型不够强
「RAG 已死」
答互补不是替代，理由四条：成本与延迟、长输入失焦 context rot、GB~TB 规模、权限时效过滤与溯源
加分收尾：长上下文真正改变的不是「要不要 RAG」，而是 RAG 的参数 —— 窗口变大后可以放宽 chunk 粒度、多送几个候选、少做激进压缩。它让 RAG 更好用，不是让它消失。

「RAG 已死」之争：怎么答才不掉坑

每隔半年就有人喊一次「长上下文杀死 RAG」。面试官抛这个问题，考的不是立场，是你的工程判断力。标准答案是：互补，不是替代。 理由分四条：

  1. 成本与延迟：每次都灌百万 token，费用和首字延迟都是数量级差距；RAG 只送最相关的几千 token。
  2. 效果：输入越长模型越容易失焦（context rot），有实验显示模型在超过某个长度后准确率会「塌方」式下跌，不是线性变差。喂得多 ≠ 答得准。
  3. 规模：企业知识库动辄 GB 到 TB 级，任何上下文窗口都装不下。
  4. 可控性：RAG 能做权限过滤、时效过滤、引用溯源——这些是 toB 场景的硬需求，长上下文给不了。

加分收尾：长上下文真正改变的不是「要不要 RAG」，而是 RAG 的参数——窗口变大后可以放宽 chunk 粒度、多送几个候选、少做激进压缩。它让 RAG 更好用，而不是让它消失。

面试视角

链路背得再熟，也不如一句归因
追问路径：讲一遍链路 → 哪步最影响效果 → 长上下文还要 RAG 吗 → 你踩过什么坑
  1. 先分两条线离线建索引 / 在线查询，分开讲
  2. 每步带一句这一环在解决什么问题
  3. 主动点归因检索和生成要分开定位
  4. 用四代形态收尾说清自己的项目落在哪一层
只读过：这些答法一听就露
  • 只说「切块、向量化、检索、生成」—— 名词罗列，看不出建过系统
  • 把 RAG 说成向量数据库 —— 忘了 BM25、SQL、图查询也是检索源
  • 「上了 RAG 就没有幻觉了」—— 材料给对了模型照样编
  • 「长上下文迟早取代 RAG」—— 只有立场，成本、规模、可控性一条不提
  • 问「效果差怎么办」，答「换个更强的模型」—— 没有拆环节的动作
真做过：这些动作装不出来
  • 离线 / 在线两条线分开讲，每步跟一句「解决什么问题」
  • 主动说检索源不止向量：BM25、SQL、图查询、Web 搜索都算
  • 提引用溯源与忠实度评测（T2-8）—— 知道幻觉只是被套上缰绳
  • 答「互补不是替代」，再补一句：变的是 RAG 的参数不是存废
  • 第一动作是把正确文档手工塞进 prompt，先切开检索和生成
面试官顺着这条线一路问到「你踩过什么坑」，考的从来不是链路本身。能说出自己的项目停在四代形态的哪一层、当初为什么停在那里，比背完十个环节有用得多。配套题：Q2-01、Q2-02、Q2-17。

典型追问路径：讲一遍链路（Q2-01）→ 哪一步最影响效果、为什么 → 长上下文时代 RAG 还有必要吗（Q2-02）→ 你的项目里这条链路是怎么落的、踩过什么坑。

答题结构建议：先分离线/在线两条线（体现你建过系统而不是只调过 API）→ 每步带一句「解决什么问题」→ 主动点出「检索和生成要分开归因」→ 用四代形态定位自己的项目在哪一层。

配套题目：Q2-01、Q2-02、Q2-17。

小结与延伸

一句话总结：RAG 是给模型开卷考试——离线把书整理好、建好索引，在线快速翻到相关那几页递给它。链路上每一环都可能是效果瓶颈，所以真正的 RAG 能力不在于会搭，而在于出问题时知道该拆哪一环。

下一篇 T2-2 从链路第一环开始：文档怎么解析、怎么切块。

继续深入

本篇归属第 2 章「RAG 工程化」，去做这一章的题。