🧠 RAG / 知识库2026-06-30
一文看懂三种 RAG 架构：Classic RAG、Graph RAG 与 Agentic RAG
原文链接一文看懂三种 RAG 架构：Classic RAG、Graph RAG 与 Agentic RAG
原文链接：https://mp.weixin.qq.com/s/UNAD6ZS5p0eofHdSwaZvvg 作者：兔兔AGI（技术极简主义） 发布时间：2026年5月16日
一句话总结
三个动词记住三种架构：
| 架构 | 核心动词 | 核心能力 |
|---|---|---|
| Classic RAG | retrieves（检索） | 找相似文本片段 |
| Graph RAG | connects（连接） | 沿关系路径遍历 |
| Agentic RAG | reasons（推理） | 决定下一步该查什么 |
选择原则：看问题形状，不看架构名字。
Classic RAG：先把相似内容找出来
核心流程
- 文档切片（chunk）
- 每个 chunk 转 embedding
- embedding 存入向量数据库
- 用户提问 → 问题转 embedding
- 向量库检索 top K 相似片段
- 问题 + 检索片段 → 大模型
- 大模型生成答案
适合场景
FAQ 问答、政策查询、产品手册、客服知识库、员工制度、内部文档检索助手。
优势与局限
- ✅ 简单、快、成本低、工具链成熟、行为可预测
- ❌ 本质是找"相似文本"，答案在段落里表现好，但跨文档/跨实体/跨关系就卡住
比如"A 的经理的经理是谁"——答案藏在组织关系链里，Classic RAG 找不到稳定沿着关系一步步走到答案的路径。
Graph RAG：不只找文本，还要找关系
核心理念
在文本检索之外增加一层关系结构（知识图谱），不只问"哪些文本相似"，还问"这些实体之间什么关系"。
知识图谱的实体和关系
- 实体：人、产品、零件、团队、部门、供应商、客户、系统模块
- 关系：汇报给、使用、来自、负责、购买了
适合场景
影响分析、依赖分析、组织关系查询、审批链查询、供应链分析、因果链解释。
典型案例
"哪些产品会受到半导体短缺影响？"
- Classic RAG 能找到"半导体短缺"相关段落，但串不起「供应商 → 芯片 → 电路板 → 产品」这条链
- Graph RAG 可以沿图谱路径走下去，找到受影响的产品范围
优势与代价
- ✅ 能沿关系路径查找和解释
- ❌ 建图和维护成本高（实体识别要准、关系要持续更新、只能遍历已建模的节点和边）
Agentic RAG：让系统决定下一步该查什么
核心理念
不再是固定检索一次就回答，而是 Agent 根据问题目标，自己判断下一步该查什么、用什么工具、证据够不够、要不要重新规划。
典型案例
"为什么我们的产品销量下降了？"
Agentic RAG 可能会：
- 拆解问题：哪个产品/地区/时间段？
- 查销售数据库，确认下降趋势
- 查价格历史，看是否有调价
- 查营销活动记录
- 查客服工单，看是否集中投诉
- 查库存系统，看是否缺货
- 证据不足 → 继续选新工具或数据源
- 综合多个来源，给出原因假设和证据链
可调用的工具
向量数据库、知识图谱、SQL、Web API、表格读取器、工单系统、日志系统、BI 报表。
适合场景
复杂问题分析、业务异常归因、跨系统调查、多数据源综合判断、技术排障、竞品分析、投资研究、运营复盘。
代价
- 更多次 LLM 调用，每次规划/工具选择/结果判断都消耗 token
- 延迟更难预测
- 更难调试：要查 Agent 为什么选这个工具、为什么跳过那个数据源
怎么选：看问题形状
| 判断维度 | 选 Classic RAG | 选 Graph RAG | 选 Agentic RAG |
|---|---|---|---|
| 答案在段落里 | ✅ | — | — |
| 答案跨文档/跨实体 | — | ✅ | — |
| 查询路径不可预知 | — | — | ✅ |
| 高频、明确、低成本 | ✅ | — | — |
| 关系链/依赖链问题 | — | ✅ | — |
| 开放式、多步骤调查 | — | — | ✅ |
工程实践建议
- 先用 Classic RAG 解决 80% 的高频明确问题
- 遇到关系链和依赖链问题，引入 Graph RAG
- 遇到开放式、多步骤、跨系统调查，交给 Agentic RAG
先简单方案解决 80%，再为真正复杂的问题增加复杂度。不要为了追新概念而上复杂架构。
三个终极检查问题
遇到任何新的 RAG 方案，问三个问题：
- 它到底在检索什么？
- 它到底在连接什么？
- 它到底在推理什么？