RAG 程序进化论：纵览 RAG 的发展历程

使用者痛点汇总

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

这些痛点是推动 RAG 不断演进的根本原因，也是这篇文章结构设计的出发点。

为什么要写这个系列？

关系。老实说，

刚开始接触向量检索时你会看到 BM25、Hybrid Search 和 RRF；继续往下你会遇到 Reranker、Query Rewrite、GraphRAG、Self-RAG 和 Agentic RAG。

如果只是按名词堆砌，很容易得到一张长长的技术清单。却不清楚：

• 为什么需要这项技术，它到底解决了什么痛点？

本系列以“阶段+痛点+技术+效果”四大维度展开，让你快速定位每一次升级背后的业务价值。

RAG 到底解决了什么问题？

大中把语言规律和部分世界知识嵌入参数，但面临以下天然限制：

• 公司制度与内部文档缺失；新知识无法实时更新，单条事实难以单独修改；缺乏证据时易生成听起来合理但错误的答案；难以追踪答案来源，

主要痛点：模型无法随时获取最新公司知识，也无法证明其回答来自何处。

普通生成：问题 → 大模型 → 答案 RAG这方面，问题 → 检索证据 → 将证据加入上下文 → 大模型 → 答案

RAG 的三大动作：

• Retrieval: 寻找相关证据。不过，
• Augmented: 把检索结果注入上下文。
• Generation: 基于证据组织答案。

RAG 为什么会不断演进？

Dora 曾说：把大模型比作开卷考试。即使带上书，也可能答错，说到程序需要决定，

• “去哪里查?”)
• “用什么方式查?”)
• “怎样判断找到的是正确证据?”)
• “资料不足时是否继续查?”)
• 关系?”)
• “什么时候停止并拒绝回答?”)

Coding & Retrieval are just first steps.

主要发展阶段概览

传统信息检索 – “只会找到文件”

• -倒排索引 -TF-IDF -BM25 -分词器与文本分析器 -Retriever + Reader -稠密向量检索

第一阶段这方面。Naive Rag – 基础闭环

Load ➜ Split ➜ Embed ➜ Store ➜ Retrieve ➜ Augment ➜ Generate

从主要目标来看，让模型能读取私有知识而不重新训练。但 Naïve Rag 存在多处盲区：

• 语义相似并不等同于能回答——切块可能破坏语义完整性。怎么说呢，
• 向量检索对编号类数据不敏感——精确匹配难实现。
• 固定 Top‑K 导致无关内容混入。
• 无答案时仍返回最相似片段。

  第二阶段的观点是，Advanced Rag – 精准检索提高全流程质量

  检索前

  结构化切块 / 语义切块 / Parent‑Child Retrieval / Metadata / Query Rewrite

  检索中

  BM25 + Dense Retrieval + Metadata Filter + Hybrid Search 从中文例子来看。Elasticsearch + IK + BM25 → Embedding + Vector Search → 融合

  检索后

  MMR + Re‑ranker + 去重 + Context Compression Advanced Rag 的真正价值是：“**从** *近似相似* **变成** *真正支持答案*。说起来，” 但流水线统一化也带来了新的瓶颈——所有请求都走同一条方法。

  说到第三阶段，Modular Rag – 路由化流程匹配需求

  简单问答可直接向量库。订单查询需调用业务 API，统计分析适合 SQL 查询。模块拆分这方面，Router / Conditional Routing / Multi‑source Retrieval / Parallel Retrieval / Result Fusion / Tool Calling / State & Workflow Orchestration 代码示例这方面。ts const route = classify; const evidence = await retrieveByRoute;const answer = await generate;

  痛点这方面。

  • 动态路由仍可能返回错误或不完整证据，需要进一步验证。老实说，

  从第四阶段来看，Corrective / Self‑rag – 自动检查与纠错

  从关键技术来看，

  文档相关性判断 | Evidence Sufficiency | Query Rewrite | Re‑search | External Search fallback | Answer Grounding | No‑answer Detection | Self‑Reflection

  说到逻辑示例。

  text Retrieve -> Check relevance -> If not relevant => Rewrite & Re‑search If insufficient => Continue searching or refuse If sufficient => Generate & Validate answer

  从痛点来看，

  • 验证步骤增加延迟和成本；
  • 多轮循环可能累积错误；老实说，
  • 单块文本虽正确。但缺乏跨实体关系，

  至于第五阶段。Graph rag – 理解跨文档关系

  从文本抽取实体/关系建立图谱，再做图遍历/社区发现/摘要。

  组合示例的观点是，

  text Vector search → Text retrieval Graph search → Entity relation & multi‑hop paths

  从痛点来看。

  • 图谱维护成本高；
  • 对简单事实问答无比较大的优势。

  从第六阶段来看，Multimodal rag – 文本之外的数据支持

  OCR | Layout-aware Parsing | Table Extraction | Image Captioning | Multimodal Embedding | text Page screenshot retrieval -> Vision Language Model -> Region-level citation

  再看痛点。

  • 多模态解析成本高；
  • 决策先查哪种数据源更复杂。

  从第七阶段来看。Agentic rag – 自主多步推理

  Planner + Tool Selection + Multi-step Retrieval + Memory + Checkpointing + Human-in--loop + Budget Control 等，实现开放式任务自组织。

  至于流程示例，

  text Understand goal -> Plan -> Select tool -> Get evidence -> Update plan ...

  痛点这方面。

  • 行为不可预测；

    * 成本和延迟显著上升。

  再看第八阶段，评测与可观测性 — 用数据验证改进

  指标类别	示例指标
  检索	Recall@K,Precision@K,MRR,nDCG
  生成	Correctness,Faithfulness。Answer Relevance
  引用	Citation Accuracy
  拒答	No-answer Accuracy

  再看可观测性要素，

  Trace ↔ Span ↔ Dataset ↔ Experiment ↔ User Feedback ↔ Failure Taxonomy ↔ Latency/Tokens/Costs.

  工具如 LangSmith 可帮助记录调用链并管理实验集。

  ---

  第九阶段的观点是，可运营 rag — 长期使用较稳定运行

  从关键环节来看，

  1️⃣ 数据治理 — 增量索引/删除/质量检查/版本管理 2️⃣ 权限安全 — 身份认证・Document ACL・多租户隔离・Prompt Injection 防护 3️⃣ 成本控制 — 缓存・超时・重试・限流·Token 与步骤预算 4️⃣ 发布迭代 — Prompt/model/index version 管理·灰度发布·回滚·线上失败样本反馈至评测集

  至于闭环示意。

  text Data update → Index build → Offline eval → Gradual release → Online monitoring → Collect failures → Update eval set & system

  ---

  小结 —— 更复杂不一定更好

  • 若知识量小，可直接使用 Naïve Rag。
  • 产品型号/错误码多，可先加 BM25 或 Hybrid Search。
  • 跨文档关系明显，则 Graph‐rag 必须考虑。
  • 多步骤、多工具协作需求才适合 Agentic Rag。说起来，

  判断是否升级。应先确认：

  1. 当前程序在哪些痛点失效？
  2. 新技术是否针对这些痛点？老实说，
  3. 引入的新复杂度与成本是否值得？
  4. 是否能改进？

  我们始终遵循“先找痛点，再加技术”的原则。

  ---

  从下一篇预告来看，《从 Naïve Rag 开始》——深入最小闭环细节

  主要说明的观点是。

  1. “检索提高生成”为何把检索放在首位。
  2. Chunk / Embedding / Vector Store / Top-K 各自解决的问题。
  3. 如何把证据有效融入 Prompt。说起来，
  4. Naïve Rag 常见瓶颈及其后续调整方向。

  理解最小闭环后你才能真正看懂混合检索、查询调整等高级方案为何存在还有它们分别解决哪些痛点。