核心技术总结
一、核心脉络
RAG 的演进历程并非简单的版本升级，而是每一次迭代都在解决前一代无法控制的检索不确定性。路径可概括为：从"查得到"（Naive RAG）→ "查得准"（Advanced RAG）→ "查得全、能推理"（Graph RAG）。
二、Naive RAG（基础 RAG）
工作流程：切文档 → 向量化 → 相似度召回（Top-K） → 将片段塞给大模型生成答案。
一、基础 RAG 的核心痛点
基础 RAG 流程仅包含「文档加载→分割→向量化→检索→拼接上下文→生成」，存在以下关键问题：
检索层面：仅依赖单一向量检索，易漏检、误检；无法处理语义歧义、多意图问题；
上下文层面：分割粒度不合理（过粗 / 过细），导致上下文缺失或噪声；多轮对话中历史信息未有效融入检索；
生成层面：检索结果与问题的关联性弱，LLM 易忽略关键信息或生成 “幻觉”；无法处理复杂推理型问题（如多步骤分析、跨文档关联）。
解决问题：大模型本身不知道公司内部文档、合同、制度。通过检索可以临时看到私有知识，实现从 0 到 1。
典型翻车点（原文案例）：
- 问题模糊：用户问"报销应该怎么走"，不同部门、不同费用的流程不一样，检索容易抓到看起来像但实际不对的段落。
- 文档不一致：同一个概念在不同文档里叫法不同，如"差旅""出差费用""差旅补贴""交通补贴"，向量相似度可能召回到相近但不对的内容。
核心结论：Naive RAG 解决的是"没有知识"的问题，但解决不了"查不准"的问题。
三、Advanced RAG（进阶 RAG）
本质：不是在 Naive RAG 之外换一个完全不同的东西，而是在检索链路的前、中、后做工程增强。像给实习生配流程、配工具、配审核，而不是让他直接做高级业务。
三大核心增强：
1. 检索前：查询改写
用户问题不清楚时，先把问题改得更可检索。原文案例：
- 用户问："合同风险有哪些？"
- 改写为：① 违约责任条款风险点 ② 付款条件与发票条款风险点 ③ 解除条款与争议解决风险点
- 分别检索，提高召回覆盖率
2. 检索中：混合检索
只用向量检索（语义相似度，但事实可能不对）不够，只靠关键词检索（BM 25，但容易漏掉同意表达）也不够。企业常用方案：向量检索 + BM 25 关键词检索，把两边的优势叠加起来。
3. 检索后：重排序（Rerank）
这是 Advanced RAG 的分水岭环节。先召回 50-100 条，再用更精细的模型打分器做重排，把真正相关的排到前面。原文指出：在实际问答系统中，Rerank 往往是提升最明显也是最容易被忽视的环节。
核心结论：Advanced RAG 的核心价值是通过一整套检索工程，把"查不准"变成"可控"的问题。是目前企业最常见的方案。
四、Graph RAG（图谱 RAG）
触发条件：当问题需要通读多文档归纳、跨文档推理时，Advanced RAG 遇到天花板。原文案例："请总结这 100 份合同里共同的风险点"——这不只是找一段话能解决的事，而是需要把大量信息组织起来，建立关联。
核心变革：
- Naive/Advanced RAG 把文档切成 chunk
- Graph RAG 抽取实体与实体之间的关联，构建一张可走的网（知识图谱）
图谱元素：
- 点（实体）：公司、项目、条款、责任主体、时间、金额、产品模块
- 线（关系）：隶属、依赖、因果、引用、约束、冲突、触发条件
可解决的复杂问题（原文案例）：
- "A 条款适用于哪些业务线？"
- "A 条款和 B 条款冲突时以谁为准？"
- "某个风险过去在哪些合同里出现过？对应的责任方是谁？"
- "从制度→审批单→财务凭证，这条链路在哪个环节最容易出错？"
系统不再做简单的向量召回，而是通过沿着关系追溯以及组合更接近结构化的理解与推理。
代价：系统变得更贵、更慢、建设成本更高——需要进行数据抽取、清洗、对齐、维护。
五、三代对比总结
| 维度 | Naive RAG | Advanced RAG | Graph RAG |
|---|---|---|---|
| 定位 | 从 0 到 1，解决有没有 | 从有到准，解决稳不稳 | 从准到全，解决会不会 |
| 核心手段 | 向量化+相似度召回 | 查询改写+混合检索+重排序 | 实体关系抽取+知识图谱+路径推理 |
| 解决痛点 | 模型不知道私有知识 | 检索结果不准、不稳定 | 碎片化、看不全、跨文档难关联 |
| 典型翻车 | 模糊问题抓错段落 | 多文档归纳推理卡住 | 建设成本高、维护复杂 |
| 适用场景 | 简单问答、单文档查询 | 企业常见知识库问答 | 复杂推理、风险审计、合规分析 |
三者关系：不是谁淘汰谁，而是一个工具箱——问题的类型决定你该用哪个工具。简单问题用 Naive RAG（成本最低），需要精度用 Advanced RAG（最常用），复杂推理用 Graph RAG（能力最强但成本最高）。
面试题
基础题
- 请分别说明 Naive RAG、Advanced RAG、Graph RAG 的核心定位是什么？面试官追问时如何回答才能显得有深度？
## 1. Naive RAG 深度回答
Naive RAG 是 RAG 的**基线范式**，核心是通过**向量检索**把外部知识注入 LLM，解决幻觉和知识更新问题。
但它本质是**语义匹配**，不理解文本结构，不处理查询意图，所以在**复杂查询、长文档、多跳问题**上能力很弱。
**关键词：**
基线、语义匹配、简单场景、不可商用。
---
## 2. Advanced RAG 深度回答
Advanced RAG 是**工业界主流可落地的 RAG 架构**。
它从**全链路优化**检索与生成：
- **查询前：** 改写 / 扩展 / 多轮上下文理解
- **检索中：** 混合检索（向量 + 关键词）、分层检索、多路召回
- **检索后：** Rerank、上下文压缩、去噪
它解决的是**检索精度不足、噪声干扰、复杂问题理解弱**，让 RAG 真正具备**生产级稳定性**。
**关键词：**
全链路优化、检索增强、高精度、可落地、工业标准。
---
## 3. Graph RAG 深度回答
Graph RAG 是**面向深度知识理解的下一代 RAG**。
它不依赖语义匹配，而是把文本抽象成**实体、关系、属性**构成的**知识图谱**。
它的核心优势是：
- 能做**多跳推理**
- 能挖掘**隐式知识**
- 能处理**长文本 / 多文档关联**
- 更接近人类的 “逻辑思考”
适合**复杂知识库、行业文档、深度总结、研究型问答**。
- Naive RAG 最常见的翻车点有几个？请用原文例子说明。
检索层面：仅依赖单一向量检索，易漏检、误检；无法处理语义歧义、多意图问题；
上下文层面：分割粒度不合理（过粗 / 过细），导致上下文缺失或噪声；多轮对话中历史信息未有效融入检索；
生成层面：检索结果与问题的关联性弱，LLM 易忽略关键信息或生成 “幻觉”；无法处理复杂推理型问题（如多步骤分析、跨文档关联）。
- Advanced RAG 在检索链路中做了哪三个环节的优化？每个环节解决什么问题？
1. Advanced RAG 在检索链路的三大优化：
2. Query 优化 → 解决查询不准、模糊、歧义问题
3. 检索增强（多路 / 混合召回） → 解决召回不全、漏检问题
4. Re-ranking 重排序 → 解决检索精度低、误召回、噪声多问题
进阶题
- 为什么说 Rerank 是 Advanced RAG 的"分水岭"？在实际系统中 Rerank 如何与向量检索配合？
1. **向量检索只能做 “粗召回”，无法保证相关性**
- 向量检索靠余弦相似度，快但不准
- 相似度高 ≠ 对问题有用
→ 会出现**语义相似但答案无关**的误召回
2. **Rerank 模型是 “细粒度相关性判断”**
- Rerank 模型（Cross-Encoder）直接输入 **Query + Document** 做语义匹配
- 真正理解**问题和文本之间的真实关联**
→ 精度远高于向量检索
3. **有无 Rerank，决定了 RAG 是否具备商用价值**
- Naive RAG：无 Rerank → 不稳定、易错、幻觉多
- Advanced RAG：有 Rerank → 精度大幅提升、噪声过滤、鲁棒性强
**一句话总结：**
**Rerank 让 RAG 从 “语义匹配” 升级为 “意图理解”，是区分初级与工业级 RAG 的关键标志。**
---
## 二、实际系统中，Rerank 如何与向量检索配合？
### 标准工业级架构：**先向量召回，再 Rerank 精排**
流程如下：
1. **向量检索（粗召回）**
- 从海量库中快速召回 **top20~top50** 条
- 目标：**快、全**，不遗漏相关内容
2. **Rerank 重排（精排）**
- 对召回的 20~50 条做精细排序
- 目标：**准、精**，选出最相关 top3~top5
3. **最终送入 LLM**
- 只把最精准的片段给模型
- 降低噪声、减少幻觉、提升回答质量
- 混合检索（向量检索+BM 25）为什么要同时使用两种方式？各自解决了什么问题？
因为单一检索都有致命缺陷：
只用向量检索：
专业术语、型号、ID、关键词匹配不到
容易召回语义相似但不相关的内容
精确性不足
只用 BM 25：
模糊查询、口语化查询完全搜不到
不懂同义、不懂意图
鲁棒性极差
四、最经典的一句话总结（深度满分）
BM 25 解决 “字面精确匹配”，向量检索解决 “语义意图匹配”。
混合检索让系统既懂文字，又懂意思，实现 “高召回 + 高精度”。
工业界标准混合策略（你必须会说）
流程：
- 向量检索召回 top20~50
- BM25 检索召回 top20~50
- 合并候选集
- Rerank 模型精排
- 取 top3~5 给 LLM
- 为什么这样做？
- 向量：保证语义不丢失
- BM25：保证关键词不丢失
- Rerank：保证最终最精准```
Graph RAG 中的"点"和"线"分别代表什么？请用"合同风险管理"场景举例构建一个简单的图谱。
### 深入思考题
8. 从"控制检索的不确定性"这个角度，解释三代 RAG 各自达到了什么程度的控制？
- Graph RAG 的成本代价具体体现在哪些方面？在实际落地中，有哪些方法可以降低成本？
## 1. **构建成本极高（最痛）**
必须把所有文档**抽取实体、关系、属性**，构建知识图谱。
- 需要 LLM 做大量**三元组抽取**
- 文档越多、越长，抽取调用次数爆炸
- 多文档更新时，需要**全量 / 增量重新抽取**
→ **Token 成本、时间成本都远高于普通 RAG**
## 2. **存储与维护成本高**
- 要用图数据库（Neo4j、NebulaGraph），比向量库更重
- 实体去重、实体链接、冲突处理**人工 / 算法成本高**
- 结构复杂后，查询、更新、维护难度上升
## 3. **推理（检索）成本高**
普通 RAG：一次向量检索
Graph RAG：
- 图遍历
- 路径查找
- 多跳关联
- 社区挖掘
→ **计算更重、耗时更长、并发能力弱**
## 4. **门槛与迭代成本高**
- 需要懂图谱、图结构、图查询（Cypher）
- 抽取质量不好时，效果会**雪崩式下跌**
- 调参与优化比普通 RAG 复杂得多
- 如果业务场景是"客服问答"，同时存在简单 FAQ 和多文档推理两种需求，应该如何设计 RAG 架构？需要同时部署三种 RAG 吗？还是可以用一种方案覆盖？
不需要三种 RAG，一套 “混合增强 RAG” 架构就能同时覆盖：
简单 FAQ → 走 BM25 + 向量检索 + Rerank（快、准、稳）
多文档复杂推理 → 走 轻量级 Graph 子图 + 深度检索（强推理）
Graph RAG 不作为全量系统，只作为 “增强模块” 嵌入 Advanced RAG。
二、为什么不用三套？（深度解释）
Naive RAG：精度不够，客服场景不能用
Advanced RAG：能解决 90% 简单问题
Graph RAG：只用来解决 10% 复杂推理问题
三套全上 = 成本爆炸、维护爆炸、架构冗余
真实业务 = 一套架构，动态路由
三、客服场景终极 RAG 架构设计（满分）
整体架构：路由式双层 RAG
第一层：Query 路由（核心大脑）
先判断用户问题类型：
简单问题（FAQ、单轮、明确关键词）
复杂问题（多文档、多跳、为什么 / 分析类）
判断方法：
规则：是否包含专业术语、长问句、多条件
轻量 LLM 分类：这是简单问题还是复杂问题？
第二层：简单 FAQ 问题 → Advanced RAG 处理
流程：
BM25 关键词精确匹配（FAQ 必中）
向量检索语义匹配
Rerank 精排
直接给 LLM 生成回答
特点：快、成本极低、准确率极高
第三层：复杂多文档问题 → Graph 增强 RAG
流程：
从文档中抽取局部子图（实体 + 关系）
在子图上做多跳推理
把推理路径返回给 LLM
生成深度答案
特点：只在需要时启动，成本可控
四、这套架构的优势
一套系统覆盖所有场景
简单问题速度 < 500ms
复杂问题准确率拉满
成本只有全量 Graph RAG 的 1/10
可维护性极强
五、面试官 30 秒黄金回答（直接背）
客服场景同时存在简单 FAQ 和复杂推理需求，不需要部署三套 RAG，最优方案是路由式混合增强 RAG 架构：
Query 路由层：自动区分简单问题与复杂问题
简单 FAQ：用 Advanced RAG（向量 + BM25+Rerank），保证速度与精度
复杂多文档推理：启用轻量级 Graph 增强模块，做子图推理
Graph 不作为全量系统，仅作为增强能力嵌入
这种架构一套系统覆盖全场景，兼顾速度、成本、效果、可维护性，是客服场景工业级标准方案。
六、最有深度的总结（面试官最爱）
RAG 架构的核心不是堆砌技术，而是按需分配算力。
简单问题用简单方案，复杂问题用增强方案。
一套架构，动态增强，才是工程落地的最高境界。
