RAG架构进化论

RAG 架构进化论

8 种架构不是选择题，而是一条进化路径

📌 导读

“RAG 已死”——上周 Hacker News 上这篇文章引发激烈争论，290+ 点赞，近 200 条评论。作者认为上下文窗口足够大，Agent 可用精确搜索替代向量检索，RAG 该扔了。但高赞反驳直指核心：代码库与企业级百万文档是两个量级，精确匹配与语义理解是两种能力。

                    真正的问题不是“选哪个架构”，而是你的检索系统需要多少智能。
                

✦ 核心观点

RAG 没有死，它只是在进化。
从简单的技术方案，变成复杂的系统工程问题。

🧩 8 种架构 · 进化路径

从无脑执行到自主决策，从文本块到实体关系图谱

阶段一基础管道

Naive RAG

文档切块 → 向量化 → 检索 → 生成。流水线作业，不会质疑检索结果。

阶段二加入质量控制

Corrective RAG

内置质检员：相关则用，不相关则扔，模糊则精炼。本地不足时自动外搜。

Self RAG

模型自主判断 4 件事：是否需要检索、文档是否相关、答案是否被支持、是否有用。

阶段三多视角 + 结构

Multi-head RAG

同一问题多视角理解，并行检索，融合结果。解决不同角度需要不同文档的问题。

Graph RAG

引入知识图谱，理解实体关系。精准遍历而非向量碰运气，比如查询“某公司领导层”。

阶段四加入真正智能

Agentic RAG

有规划、能选择、会迭代的智能体。复杂问题分解为子任务，检索→推理→再检索。

Adaptive RAG

根据问题类型动态调整策略：事实问题直接答，多跳问题迭代检索，开放问题多查询扩展。

FRAG

SalesForce Research 工业级最佳实践：高质量 embedding + 重排序 + 上下文压缩 + 引用生成 + 质量验证。

⚠️ “RAG 已死”论的三个盲区

—— 正如 Hacker News 上所说：“RAG 不是一种架构，是一个原则。”

🔍 选型指南 · 问自己四个问题

①

知识库多大？ 千级文件 vs 百万级文档，量级决定架构起点。

②

问题多复杂？ 事实查询 vs 多跳推理 vs 开放性生成，复杂度决定智能层级。

③

容错空间多小？ 检索错误能否承受？决定是否需要质检与验证模块。

④

预算多少？ 推理成本与架构复杂度直接相关，量力而行。

💡 三条实践建议

先跑通 Naive RAG，再逐步加量

太多团队一上来就想搞 Graph + Agentic + 多模态，半年过去还在调数据。先跑通端到端，收集反馈，再针对性升级。

建立自己的评测体系

准备 10–20 个真实业务场景问题，每个新架构上线前盲评打分。这比任何公开 benchmark 都有用。

关注检索质量，不只是生成质量

检索是 RAG 的天花板，生成只是在天花板下装修。检索阶段拿了错误文档，后面再怎么优化 prompt 也是白搭。

“这 8 种架构不是菜单，是进化地图。理解方向，选好起点，然后沿着路径逐步升级。”

—— LM x Factors

RAG 没有死，它只是在进化。
从简单的技术方案变成了复杂的系统工程问题。
选好起点，逐步升级，让检索系统匹配你需要的智能。

由 CuteNote.app 颜值笔记生成