RAG 系统进化论（一）：纵览 RAG 的发展历程

董员外
0 阅读16分钟

RAG 系统进化论（一）：纵览 RAG 的发展历程

从“能查到”到“可运营”，RAG 是如何一步步演进的？

本文导读： RAG 并不是一套突然出现的复杂架构，而是在解决真实问题的过程中逐步演进的。本文将纵览 Naive RAG、Advanced RAG、Modular RAG、纠错、图检索、多模态、智能体、评测与运营等阶段，说明每次升级引入了什么技术，又解决了上一阶段的哪些不足。

01-01-rag-evolution-cover.png 做一个可以演示的 RAG（Retrieval-Augmented Generation，检索增强生成）并不难。

准备几份文档，把它们切成小块，生成向量，保存到向量数据库；用户提问时检索几个相似片段，再交给大模型生成答案。

十几行代码，就能得到一个看起来不错的知识库问答系统。

真正困难的是接下来的问题：

  • 为什么文档里明明有答案，系统却没有找到？
  • 为什么找到了相似内容，模型还是回答错了？
  • 为什么产品型号、错误码和专有名词经常检索不到？
  • 为什么简单问题很快，复杂问题却需要多次查询？
  • 为什么知识库没有答案时，模型仍然可以说得很确定？
  • 为什么 Demo上效果很好，换成真实数据后问题不断？

RAG 后来出现的大量技术，基本都在回答这些问题。

为什么要写这个系列？

学习 RAG 最容易遇到的困难，不是某个 API 不会使用，而是不知道各种技术之间是什么关系。

刚刚理解向量检索，就会看到 BM25、Hybrid Search和 RRF；继续往下，又会遇到 Reranker、Query Rewrite、GraphRAG、Self-RAG和 Agentic RAG。

  • BM25（关键词相关性排序算法）
  • Hybrid Search（混合检索）
  • RRF（Reciprocal Rank Fusion，倒数排名融合）
  • Reranker（重排序模型）
  • Query Rewrite（查询改写）
  • GraphRAG（基于知识图谱的 RAG）
  • Self-RAG（自反思式 RAG）
  • Agentic RAG（智能体式 RAG）。

如果只是按照名词逐个学习，很容易得到一张越来越长的技术清单，却仍然不知道：

为什么需要这项技术，它究竟解决了上一阶段的什么问题？

很多资料会直接给出一套复杂架构，但很少解释系统为什么会从最简单的检索生成，一步步发展到路由、纠错、图检索、智能体（Agent）、评测和运营。

这个系列想换一种方式。

我们不按照框架 API 组织内容，也不把每个技术名词单独写成一篇文章，而是沿着 RAG 的主要发展阶段往前走。每一篇只讨论四件事：

  1. 当前阶段遇到了什么问题；
  2. 为此引入了哪些技术；
  3. 这些技术解决了什么；
  4. 它们又留下了哪些问题。

文章中的代码只使用少量 TypeScript 风格伪代码，用来解释数据怎样流动。真正的主线始终是 RAG 的能力变化。

RAG 到底解决了什么问题？

大模型在训练过程中，会把语言规律和一部分世界知识保存在模型参数中。这些知识让模型拥有强大的通用能力，但也带来几个天然限制：

  • 模型不知道企业制度、内部文档和个人资料；
  • 训练结束后出现的新知识不会自动进入模型；
  • 更新一条事实不能简单地修改某个模型参数；
  • 模型可能在缺少知识时生成听起来合理的错误答案；
  • 很难说明某个结论究竟来自哪份资料。

一种做法是把所有资料直接放进大模型的上下文，但随着知识量增加，很快就会遇到 Token（模型处理文本的基本计量单位）成本、无关信息干扰、权限隔离和内容更新等问题。

RAG 的思路是：不要让模型记住全部知识，而是在回答问题时，先从外部知识库中找到相关证据。

普通生成：
问题 → 大模型 → 答案

RAG：
问题 → 检索证据 → 将证据加入上下文 → 大模型 → 答案

01-02-how-rag-works.png

RAG 这个名字中的三个词，刚好对应三个动作：

  • Retrieval（检索）：从知识库中找到与问题相关的证据；
  • Augmented（增强）：把检索结果加入模型上下文；
  • Generation（生成）：让模型根据问题和证据组织答案。

用最简单的伪代码表示就是：

// 先根据用户问题，从外部知识库中检索相关证据
const evidence = await retrieve(question);

// 再把问题和证据一起交给大模型，让模型基于证据生成答案
const answer = await generate(question, evidence);

因此，RAG 的重点不只是“生成”，而是通过检索得到能够支撑答案的证据。

如果检索阶段没有找到正确内容，后面的模型再强，也只能根据错误或残缺的上下文回答。

RAG 为什么会不断演进？

RAG 经常被比喻成让大模型参加一场开卷考试。

但开卷考试不是把书带进考场就一定能答对。系统还需要解决：

去哪里查？
用什么方式查？
怎样判断找到的是正确证据？
资料不足时是否应该继续查？
不同证据之间是什么关系？
什么时候应该停止并拒绝回答？

RAG 的发展过程，本质上就是不断提高寻找证据、组织证据、验证证据和运营系统的能力。

下面这些阶段不是严格的时间年表，也不是互相替代的产品版本。它们更像一张能力演进地图：当简单方案无法解决真实问题时，系统才增加新的能力。

RAG 的主要发展阶段

01-03-rag-evolution-stages.png

为了便于展示，图中合并了关系密切的阶段；下面会按照完整的能力路线分别说明。

RAG 之前：传统信息检索

在大模型出现之前，搜索引擎已经在解决“怎样从大量文档中找到相关内容”。

这一时期的重要技术包括：

  • 倒排索引；
  • TF-IDF（Term Frequency-Inverse Document Frequency，词频-逆文档频率）；
  • BM25；
  • 分词器与文本分析器；
  • Retriever + Reader（检索器加阅读器）；
  • 稠密向量检索。

对于中文搜索，Elasticsearch（分布式搜索与分析引擎）、IK（中文分词器）和 BM25 就属于这套传统检索能力：

中文文档
→ IK 分词
→ Elasticsearch 建立倒排索引
→ BM25 计算关键词相关性

传统检索解决了“找到文档”，但通常不会像大模型一样理解多份资料并组织自然语言答案。

RAG 的出现，把检索系统和生成模型连接了起来：

检索系统负责寻找证据； 生成模型负责理解证据并组织答案。

第一阶段：Naive RAG（基础 RAG）——让模型能够使用外部知识

Naive RAG 建立了检索增强生成的最小闭环：

Load → Split → Embed → Store → Retrieve 
→ Augment → Generate

它使用文档加载、文本切块、Embedding（将文本转换为向量表示）、向量数据库和 Top-K（相似度最高的前 K 条结果）检索，把少量相关片段放进 Prompt（提示词），再交给大模型回答。

它解决的核心问题是：

不重新训练模型，也能让模型读取私有知识和新知识。

但 Naive RAG 通常把“语义相似”近似当成“能够回答问题”。真实数据中，两者并不总是一回事。

切块可能破坏完整语义；向量检索不擅长精确编号；固定 Top-K 会带入无关内容；知识库没有答案时，系统仍然会返回几个最相似的片段。

于是，下一阶段开始系统优化证据质量。

第二阶段：Advanced RAG（进阶式 RAG）——让检索更加准确

Advanced RAG 不再只关注向量数据库，而是优化检索前、检索中和检索后的完整过程。

检索前

通过结构化切块、语义切块、Parent-Child Retrieval（父子块检索）、Metadata（元数据）和查询改写，让文档与问题更适合检索。

检索中

使用 BM25、Dense Retrieval（稠密向量检索）、Metadata Filter（元数据过滤）和 Hybrid Search，同时利用精确关键词与语义相似度。

在中文业务知识库中，常见的组合是：

关键词分支：Elasticsearch + IK + BM25
语义分支：Embedding + Vector Search（向量检索）
结果融合：RRF
检索后

使用 MMR（Maximal Marginal Relevance，最大边际相关性）、Reranker、去重和 Context Compression（上下文压缩），把更有可能支持答案的内容放到前面，并减少重复、无关上下文。

Advanced RAG 解决的是：

不仅要找到相似内容，还要尽可能找到真正能够回答问题的证据。

但随着步骤增加，另一个问题出现了：无论用户问什么，所有问题仍然经过同一条流水线。

第三阶段：Modular RAG（模块化 RAG）——让不同问题选择不同流程

简单知识问答可以搜索向量库，订单查询可能需要调用业务 API，统计问题更适合查询 SQL（结构化查询语言），时效性问题可能需要外部搜索。

Modular RAG 把完整流程拆成可以组合的模块：

  • Router（路由器）；
  • Conditional Routing（条件路由）；
  • Multi-source Retrieval（多数据源检索）；
  • Parallel Retrieval（并行检索）；
  • Result Fusion（结果融合）；
  • Tool Calling（工具调用）；
  • State（状态）与工作流编排。

系统可以先判断问题类型，再选择不同的数据源和处理路径：

// 判断当前问题应该进入哪一条处理路径
const route = classify(question);

// 根据路由结果，选择对应的知识库、数据库或业务接口获取证据
const evidence = await retrieveByRoute(route, question);

// 将选定路径返回的证据交给大模型生成最终答案
const answer = await generate(question, evidence);

它解决的是：

不再让所有问题走同一条固定管线。

但是，动态选择了一条路径，并不代表这条路径返回的证据一定正确。系统还需要判断自己是否找错了。

第四阶段：Corrective RAG（纠错式 RAG）与 Self-RAG——让系统检查并纠正错误

这一阶段开始把“检查”加入 RAG。

主要技术包括：

  • 文档相关性判断；
  • 证据充分性判断；
  • Query Rewrite；
  • 重新检索；
  • 外部搜索降级；
  • Answer Grounding（答案证据一致性检查）；
  • No-answer Detection（无答案检测）；
  • Self-Reflection（自我反思）。

基本逻辑是：

检索证据
→ 判断证据是否相关
→ 不相关：改写问题并重新检索
→ 证据不足：继续搜索或拒绝回答
→ 证据充分：生成并检查答案

它解决的是：

不让低质量证据毫无检查地进入生成阶段。

当然，负责评估的模型也可能判断错误，多次循环还会增加延迟和费用。而且，即使每一个文本块都正确，孤立的文本块仍然难以表示复杂的实体关系。

第五阶段：GraphRAG——让系统理解知识之间的关系

向量检索擅长找到语义相似的文本，却不擅长回答这类问题：

  • 某个事件涉及哪些人物和组织？
  • 两家公司通过哪些项目发生联系？
  • 多份报告共同反映了什么趋势？
  • 一个结论需要经过哪几层关系才能得到？

GraphRAG 会从文档中抽取实体和关系，构建知识图谱，再通过图遍历、社区发现、社区摘要以及 Local / Global Search（局部搜索与全局搜索）获取证据。

常见组合是：

向量检索：寻找相关文本
图检索：寻找实体关系和多跳路径

它解决的是跨文档关系、多跳问题和全局总结。

代价是图谱构建、实体消歧和增量更新更加复杂。对于简单事实问答，GraphRAG 也不一定比普通检索更合适。

第六阶段：Multimodal RAG（多模态 RAG）——让知识不再局限于文本

真实文档中的知识并不只存在于段落里。

产品手册包含结构图，财务报告包含表格和曲线，扫描合同依赖页面布局，故障说明可能直接标注在设备图片上。

如果只抽取纯文本，这些信息很可能在进入检索系统之前就已经丢失。

Multimodal RAG 引入：

  • OCR（Optical Character Recognition，光学字符识别）；
  • Layout-aware Parsing（布局感知解析）；
  • Table Extraction（表格抽取）；
  • Image Captioning（图片描述生成）；
  • Multimodal Embedding（多模态向量表示）；
  • 页面截图检索；
  • Vision Language Model（视觉语言模型）；
  • 页面和区域级引用。

它解决的是：

检索并理解表格、图片、扫描件和页面布局中的知识。

但多模态解析、索引和模型推理的成本更高。面对开放式复杂任务，系统还需要自己决定先查什么、再查什么。

第七阶段：Agentic RAG——让系统自主完成多步检索

传统 RAG 的路径通常由开发者提前写好。Agentic RAG 则让模型参与决定：

  • 是否需要检索；
  • 应该使用哪个工具；
  • 是否需要把目标拆成子问题；
  • 当前证据是否足够；
  • 是否需要根据中间结果继续调查；
  • 什么时候应该停止。

因此，它会使用 Planner（任务规划器）、Tool Selection（工具选择）、Multi-step Retrieval（多步检索）、Memory（记忆）、Checkpointer（状态检查点）、Human-in-the-loop（人工介入）、Budget（预算控制）和 Stop Condition（停止条件）。

工作方式从一次检索变成一个循环：

理解目标
→ 制定计划
→ 选择工具
→ 获取证据
→ 更新计划
→ 继续执行或停止
→ 汇总答案

它解决的是开放式、多步骤、跨数据源的研究任务。

与此同时，系统行为会变得更难预测，错误可能在多步执行中累积，延迟和成本也显著提高。

系统越复杂，就越不能只靠几次人工提问判断效果。

第八阶段：评测与可观测性——证明系统真的变好了

RAG 的回答具有一定随机性。修改切块大小、Embedding 模型、召回数量或 Prompt 后，仅凭“感觉好像更准了”无法判断系统是否真正改善。

这一阶段引入两类能力。

评测
  • Recall@K（前 K 条结果的召回率）、Precision@K（前 K 条结果的精确率）、MRR（Mean Reciprocal Rank，平均倒数排名）、nDCG（Normalized Discounted Cumulative Gain，归一化折损累计增益）：评估检索结果；
  • Correctness（正确性）、Faithfulness（忠实度）、Answer Relevance（答案相关性）：评估生成质量；
  • Citation Accuracy（引用准确率）：评估引用是否准确；
  • No-answer Accuracy（拒答准确率）：评估资料不足时能否正确拒答。
可观测性
  • Trace（调用轨迹）与 Span（轨迹中的单次操作）；
  • Dataset（评测数据集）；
  • Experiment（对比实验）；
  • 用户反馈；
  • Failure Taxonomy（失败类型分类）；
  • 延迟、Token 和费用统计。

LangSmith（用于大模型应用追踪与评测的平台）这类工具适合在这个阶段引入，用于记录调用链、管理测试集和比较实验结果。

它解决的是：

从“凭感觉调参”变成“用数据验证改进”。

不过，能够发现问题还不够。一个长期运行的系统，还需要管理知识更新、访问权限、成本和发布风险。

第九阶段：可运营 RAG——让系统可以长期运行

可运营 RAG 不是在最后加一个监控平台，而是让整个系统形成闭环。

它至少包括：

数据治理

增量索引、文档删除、数据质量检查、索引版本和 Embedding 模型迁移。

权限与安全

身份认证、Document ACL（Document Access Control List，文档级访问控制列表）、多租户隔离、敏感信息处理、Prompt Injection（提示词注入）防护和工具权限。

可靠性与成本

缓存、超时、重试、限流、降级以及 Token 和步骤预算。

发布与反馈

Prompt、模型和索引版本管理，质量门禁、灰度发布、回滚，以及将线上失败样本加入评测集。

最终形成下面的循环：

数据更新
→ 构建索引
→ 离线评测
→ 灰度发布
→ 线上观测
→ 收集失败样本
→ 更新评测集和系统

它解决的是：

不只是让 RAG 能够运行，而是让它可以安全、稳定、可控地持续改进。

RAG 的演进主线

回头看这些阶段，会发现它们并不是一组互不相关的热门名词。

每个阶段都在解决上一阶段暴露的问题：

01-04-rag-evolution-complete-stages.png

如果进一步压缩，这条路线可以概括成：

01-05-rag-evolution-capabilities.png

更复杂，不等于更好

RAG 的这些阶段不是一张必须全部完成的升级清单。

如果知识量很小，Naive RAG 可能已经足够；如果业务中有大量产品型号和错误码，可以先增加 BM25；只有确实存在跨文档关系问题时，才需要考虑 GraphRAG；只有任务需要多次调查和工具协作时，Agentic RAG 才有价值。

判断是否需要升级，不应该看技术是否热门，而应该先确认：

  1. 当前系统具体失败在哪里；
  2. 新技术能否解决这个失败；
  3. 增加的复杂度、延迟和费用是否值得；
  4. 改造前后能否通过评测得到验证。

这也是本系列后续文章会一直遵循的原则：

先找到问题，再引入技术。

下一篇：从 Naive RAG 开始

下一篇将从最小的 RAG 闭环开始：

文档加载
→ 文本切块
→ Embedding
→ 向量存储
→ Top-K 检索
→ 上下文增强
→ 生成答案

我们会重点说明：

  • “检索增强生成”的重点为什么是检索；
  • Chunk、Embedding、Vector Store 和 Top-K 分别解决什么问题；
  • 检索到的证据怎样进入 Prompt；
  • 为什么一个能运行的 Naive RAG 很快就会遇到瓶颈。

理解这个最小闭环之后，后面的混合检索、查询优化、重排、路由和纠错，才会知道是在解决什么问题。

avatar
文章
阅读
粉丝