AI

RAG 进阶：从 naive 到 Agentic（2026）

写在前面

2024 年的 RAG “Hello World” 是这样的：把 PDF 切一切塞进向量库，查询时检索 top-K 喂给 LLM。当年够用，2026 年不够了——这套 naive 流程在生产里召回差、容易幻觉、答非所问。

这篇讲 RAG 怎么从 naive 进化到 production-grade：chunking、混合检索、reranking、GraphRAG，再到 2026 的 SOTA——Adaptive / Agentic RAG。地基是上一篇《向量检索入门：embedding、ANN 与向量库选型》讲的向量检索；这篇讲怎么把它用对。

这是 AI 分类的第二篇（第一篇是《Claude Code 使用指南》）。它和数据库分类的向量检索篇互为表里：那篇是"存储/检索原语"，这篇是"之上的应用范式"。

一、naive RAG 长什么样，为什么不够

经典三步：

1
2

离线:  文档 → 切块 → embedding → 存向量库
在线:  查询 → embedding → 向量检索 top-K → 拼进 prompt → LLM 生成答案

它的问题一针一线都在：

  • 切得粗：固定大小切块会截断语义、切碎表格和代码，检索到的块缺上下文；
  • 召回差：纯向量检索对精确词、专有名词、代码、数字反而不如关键词——“ERROR_0x80070005” 这种，向量相似没用，字面匹配才准；
  • 幻觉：LLM 拿到不相关的上下文也硬编一通，没有"这个检索结果到底支不支持回答"的判断；
  • 一律重型：不管查询是"公司成立于哪年"还是"你好"，都跑同一套检索+生成，浪费。

下面每一节都是在修其中一个洞。

二、chunking：第一道关

切块决定了"检索能召回什么"。固定大小（比如每 500 字符）是最朴素也最差的：

  • 块太大 → 一个块塞了多个主题，检索时相似度被稀释，召回不准；
  • 块太小 → 上下文断裂，“它指代什么"丢了，LLM 拿到片段也看不懂。

进阶做法：

  • 语义切块：按句子/段落的语义边界切（用模型判断"这里是不是话题转折点”），而不是按字符数；
  • 层次切块（parent-child）：检索用小子块（精准命中），但喂给 LLM 时返回它所属的大父块（保留完整上下文）。这是生产里最常用的一招；
  • 带元数据：每个块附上标题、章节、来源、时间——检索时能按元数据过滤（“只在 2025 年的文档里找”）。

chunk 大小是 recall（怕漏）vs 噪声（怕混）的权衡，没有标准答案，要按你的文档和评估指标调。

三、混合检索（Hybrid Search）：向量 + 关键词

纯向量检索有个盲区：它擅长"意思像"，不擅长"字面就是"。代码、错误码、人名、型号、精确数字——这些你要的是字面匹配，向量相似反而会把"长得像的错误码"排前面。

于是混合检索：同时跑两路——

1
2
3
4

查询 ──┬── BM25 / 倒排（关键词路）──→ 召回 A
       └── 向量检索（语义路）  ──→ 召回 B
                                          ↓
                          RRF（Reciprocal Rank Fusion）融合排序

BM25 是《数据库系列（三）：索引原理》里倒排索引那套传统检索；向量检索是上一篇讲的语义检索。两路各自召回 top-K，再用 RRF（倒数排名融合） 把两个排名合成一个——取两者之长。这是 production RAG 的标配，纯向量检索在 2026 已经很少单独用了。

pgvector + PG 的全文检索、或者 Elasticsearch，都能在一个库里同时跑这两路。

四、reranking：检索分两阶段

为什么检索要分两阶段？因为"快+全"和"准"没法用一个模型兼顾：

  • 召回阶段（要快、要全）：用 bi-encoder——查询和文档分别独立编码成向量，靠 ANN 飞速从百万文档里捞回 top-50。糙但快。
  • 重排阶段（要准）：用 cross-encoder——把"查询 + 文档"作为一对一起喂进模型，输出一个精确的相关性分数。准但慢，所以只对召回的小集合（top-50）跑，重排出 top-5。
1
2

百万文档 ──bi-encoder + ANN──→ top-50 ──cross-encoder rerank──→ top-5 ──→ LLM
            (快，召回)                    (慢，精排)

典型 reranker：开源的 bge-reranker、Cohere Rerank。这一步对最终答案质量提升极大——召回里混进的不相关块，rerank 基本能剔掉。

五、GraphRAG：知识图谱加持

向量检索本质是"片段相似"。但有些问题是关系型的：

  • “A 公司的 CEO 之前在哪些公司任职？” —— 答案散在多份文档里，要靠"人→公司→职位"的关系串起来；
  • “X 和 Y 的区别？” —— 要把两个实体的属性拉出来对比。

这种多跳推理，纯向量检索（找相似片段）做不好。GraphRAG 的思路：离线时先把文档抽成知识图谱（实体 + 关系），检索时结合图遍历 + 向量——向量找入口实体，图遍历顺着关系找答案。

Neo4j 是这块的代表（把图数据库和向量检索结合）。GraphRAG 适合关系密集、需要跨文档推理的领域（医药、法律、尽调）；普通 FAQ 类 RAG 用不上，别为了用而用。

六、Adaptive / Agentic RAG：2026 的 SOTA

前面四节都是"管线固定、查询来了无脑跑一遍"的 RAG。2026 的前沿是把 RAG 变聪明——让系统自己决定怎么检索：

  • Adaptive RAG（查询路由）：加一个分类器，先判断查询复杂度，再路由到不同管线——

    • 简单事实查询 → 直接向量检索一次就答；
    • 复杂推理查询 → 多步检索 / 上 GraphRAG；
    • 闲聊 / 不需要检索的 → 跳过检索直接答。

    别对所有查询都跑重型管线，省算力、降延迟。

  • Self-RAG（自我反思）：LLM 在过程中自问三件事——“这个问题需要检索吗？““检索回来的相关吗？““我的回答有依据吗？"——不相关就重检索，没依据就拒答。自带质量门。

  • Agentic RAG：把 RAG 包成一个 Agent——能多次检索、能调工具（计算器、SQL、API）、能迭代优化答案，而不是一次性检索+生成。这是当前最前沿的形态，也是"让 agent 帮你干活"那个大方向里的具体一例。

这一节的演进方向很清楚：从固定管线到按需路由到自我反思到自主 Agent。复杂度和能力都在涨，但不是每个应用都需要 Agentic——多数企业 RAG 到 chunking + 混合检索 + rerank 就够好了。

七、生产化：评估与监控

RAG 上线后最头疼的是”怎么知道它好不好"。靠人肉看答案不靠谱，要有指标：

  • 评估（离线）：用 RAGAS 这类框架打分——faithfulness（回答有没有依据，不幻觉）、answer relevance（答没答到点上）、context precision/recall（检索回来的东西有没有用）。改一处 chunking 或换一个 reranker，跑评估看分数升降。
  • 监控（在线）：检索召回率、端到端延迟、幻觉率、用户反馈（👍👎）。出问题能定位是检索层还是生成层——这和《后端架构实战（七）：可观测性》的链路追踪是同一思路：给每次 RAG 调用一个 traceId，把检索、rerank、生成分段打 span。
  • 增量更新：文档变了，别全量重建索引——按文档版本增量 re-embedding。

小结

  • naive RAG（切块→向量→生成）是起点，生产里召回差、易幻觉。
  • 进阶三件套：chunking（语义/层次切块）+ 混合检索（BM25 + 向量 + RRF）+ reranking（bi-encoder 召回、cross-encoder 精排）。这是 production RAG 的标配。
  • GraphRAG：补"关系型/多跳推理"的洞，关系密集领域才用。
  • 2026 SOTA：Adaptive RAG（查询路由）→ Self-RAG（自我反思）→ Agentic RAG（自主 Agent）。方向是让 RAG 从固定管线变聪明。
  • 生产化：评估（RAGAS）+ 监控（traceId 贯穿检索/rerank/生成）+ 增量更新。

一句话：2026 的 RAG，“塞进向量库"只是地基；真正的功夫在 chunking、混合检索、rerank 和评估上。 地基（向量检索）上一篇讲过了，这篇是盖在上面的楼。

参考资料