中文译本。原文见同目录 README.md

第 8 课：Agentic RAG——更聪明的检索

引言

在前面的课程中，你学到了智能体如何用工具与世界交互。智能体可拥有的最重要工具之一，就是查阅能力——搜索知识库、查询数据库或检索文档。这正是 Retrieval-Augmented Generation（RAG，检索增强生成）的基础。

基础 RAG 遵循简单模式：拿用户问题，搜索相关文档，把文档塞进 LLM 上下文，再生成答案。这对直截了当的查询很有效。但当问题复杂、第一次搜索没返回正确文档、或答案需要综合多个来源时，它就会垮掉。

Agentic RAG 通过让智能体掌控检索过程来解决这个问题。不再是僵硬的 retrieve-then-read 流水线，智能体决定何时搜索、搜什么、结果是否够好、以及何时用不同方法再试。智能体把检索当作战略性使用的工具，而不是始终遵循的固定步骤。

快速回顾：什么是 RAG？

RAG 代表 Retrieval-Augmented Generation（检索增强生成）。想法很简单：LLM 有知识截止日期，不可能什么都知道。所以在回答问题之前，你从外部来源检索相关信息，并放进提示中。

基础 RAG 流水线：

User Question
     |
     v
[Retriever] -- searches --> [Document Store]
     |
     v
Retrieved Documents
     |
     v
[LLM] -- generates answer using question + documents
     |
     v
Answer

为什么 RAG 重要：

  • LLM 有知识截止日期——RAG 提供当前信息
  • LLM 可能幻觉——RAG 用真实文档锚定答案
  • LLM 无法访问私有数据——RAG 把它们接到你的数据库
  • RAG 让你更新知识而无需重训模型

简单类比： RAG 像开卷考试。不只依赖你背下来的东西（LLM 的训练数据），答题前还可以查阅笔记（文档库）。

基础 RAG 的局限

基础 RAG 对答案存在于单一文档中的简单、直接问题很有效。但在若干常见场景中会吃力：

问题 1：查询与文档措辞不匹配

用户提问用的词与文档不同。检索器搜「如何修复慢数据库」，相关文档却讲「查询优化技术」。语义鸿沟导致检索器错过最佳文档。

问题 2：答案跨越多个文档

用户问「公司对国际员工远程办公的政策是什么？」答案需要综合远程办公政策、国际雇佣指南与税务合规文档。基础 RAG 一次检索一小撮文档，并指望其中包含正确的那些。

问题 3：第一次结果不够好

基础 RAG 检索一次就承诺使用它们。若顶部结果平庸或不相关，LLM 就生成平庸或错误的答案。没有机制说「这些结果没用，让我换一种搜索」。

问题 4：问题需要分解

用户问复杂问题，如「比较我们北美与欧洲的 Q3 营收，并解释差异的关键驱动因素。」这需要多个子查询：北美 Q3 营收、欧洲 Q3 营收，以及对贡献因素的分析。基础 RAG 试图用单次搜索回答。

问题 5：没有验证

基础 RAG 没有自检机制。LLM 基于检索到的任何文档生成答案，哪怕这些文档过时、不相关或互相矛盾。没有步骤问「这个答案在证据下是否真的说得通？」

什么让 RAG「有智能体性」（agentic）

Agentic RAG 让 LLM 对检索过程拥有自主权（agency）。不再遵循固定流水线，智能体在每一步做决策：

智能体决定何时搜索

并非每个问题都需要检索。Agentic RAG 系统能识别何时已经知道答案（来自训练数据或当前对话上下文）并完全跳过检索。也能识别何时确定需要外部信息并发起搜索。

智能体重写查询

若初始搜索返回糟糕结果，智能体不会放弃。它分析为何结果差，并尝试不同查询。也许原问题太宽，于是收窄；也许用错了术语，于是改写。

示例：

Original query: "fix slow database"
    Results: generic articles about databases
    Agent thinks: "Too vague. Let me be more specific."
Reformulated: "PostgreSQL query optimization for slow JOIN operations"
    Results: specific optimization techniques
    Agent thinks: "Much better. These are relevant."

智能体交叉对照多个来源

智能体可不依赖单次搜索，而是查询多个来源、比较结果，并综合出更完整的答案。它可能先查内部知识库，再对照公开文档核实，再与近期支持工单交叉对照。

智能体自我纠正

生成答案后，智能体对照检索到的证据检查。答案是否真的由文档推出？有无矛盾？是否缺少关键信息？若答案站不住，智能体回去检索更多信息。

Agentic RAG 循环

Agentic RAG 的核心是循环，而不是流水线。智能体迭代检索、评估与精炼，直到有满意答案或穷尽选项。

        User Query
            |
            v
    [1. Query Planning]
     "What do I need to find?"
            |
            v
    [2. Retrieve]
     Search knowledge base(s)
            |
            v
    [3. Evaluate Results]
     "Are these results good enough?"
           / \
         No   Yes
         |      \
         v       v
    [4. Refine]  [5. Generate Answer]
     Reformulate     |
     query and       v
     go back to  [6. Verify Answer]
     step 2      "Does this answer check out?"
                    / \
                  No   Yes
                  |      \
                  v       v
             Go back    Return Answer
             to step 1   to User

Basic RAG vs. Agentic RAG

Watch both pipelines process the same query side by side. Agentic RAG iterates and self-corrects.

Basic RAG — one-shot pipeline
Agentic RAG — iterative with self-correction
Click "Step Through" or "Auto-play" to begin the comparison.

让我们逐步详细走一遍。

步骤 1：查询规划（Query planning）

智能体分析用户问题并决定检索策略。对简单问题，可能只需一次搜索。对复杂问题，智能体把问题分解为子查询。

示例：

用户问：「我们上线新客服聊天机器人后，客户满意度分数如何变化？」

智能体规划：

  1. 找聊天机器人上线前的客户满意度分数
  2. 找聊天机器人上线日期
  3. 找上线后的客户满意度分数
  4. 找连接二者的任何分析或报告

步骤 2：检索（Retrieve）

智能体执行规划好的搜索。可能涉及查询向量数据库、调用搜索 API、查找结构化数据，或其任意组合。

步骤 3：评估结果（Evaluate results）

这正是 Agentic RAG 与基础 RAG 分道扬镳之处。智能体审视检索到的文档并做判断：

  • 相关性（Relevance）： 这些文档是否真正回应我的问题？
  • 完备性（Completeness）： 我是否有所需全部信息？
  • 新鲜度（Freshness）： 这些文档是否够新？
  • 一致性（Consistency）： 各来源是否彼此一致？

步骤 4：精炼（Refine，如需要）

若结果不够好，智能体精炼方法：

  • 改写查询： 用不同关键词，更具体或更宽泛
  • 换来源： 从通用知识库切到专业库
  • 进一步分解： 把问题拆成更小的子问题
  • 扩大搜索： 寻找可能导向答案的相关概念

步骤 5：生成答案（Generate answer）

一旦智能体有足够证据，就基于检索文档生成答案。答案应引用出处，便于用户核实。

步骤 6：验证答案（Verify answer）

智能体做最终检查：

  • 答案是否与任一检索文档矛盾？
  • 答案中的所有主张是否有证据支持？
  • 是否有缺口或含糊措辞暗示还需要更多检索？

若验证失败，智能体循环回去收集更多信息。

Agentic RAG 的关键能力

自主查询规划（Autonomous query planning）

智能体自动把复杂问题拆成子查询，无需预定义模板或规则。它用对问题的理解来决定需要哪些信息。

基础 RAG： 把用户原问题原样发给检索器。 Agentic RAG： 分析问题，识别信息需求，并规划多次定向搜索。

自适应来源选择（Adaptive source selection）

智能体可按问题选择查询哪些知识来源。公司政策问题去政策库；客户问题去 CRM；近期事件问题去网络。

问题类型 来源选择
公司政策 内部政策数据库
客户信息 CRM 系统
技术文档 工程 wiki
近期事件 网络搜索
产品规格 产品目录
历史数据 数据仓库

上下文感知的查询扩展（Context-Aware query expansion）

智能体利用对话上下文与先前检索到的信息改进后续查询。若第一次搜索返回了关于「Project Alpha」的信息，智能体可能在后续查询中加入「Project Alpha」以找到相关文档。

多跳推理（Multi-Hop Reasoning）

有些问题需要检索链。第一次查询的答案决定下一步搜什么。

示例：

Question: "Who manages the team that built our recommendation engine?"

Hop 1: Search for "recommendation engine team"
  -> Found: "The recommendation engine was built by the ML Platform team"

Hop 2: Search for "ML Platform team manager"
  -> Found: "The ML Platform team is managed by Sarah Chen"

Answer: "Sarah Chen manages the ML Platform team, which built
         the recommendation engine."

自我纠正机制

Agentic RAG 最有价值的方面之一，是识别并从错误中恢复的能力。

重新查询（Re-Querying）

当智能体检测到初始结果不足时，它根据第一轮学到的内容制定新查询。这不是随机重试——而是有信息依据的精炼。

Initial query: "deployment process"
Results: Too many general documents about various deployment processes
Agent analysis: "I need to be more specific about which service"
Refined query: "deployment process for the payment microservice"
Results: Specific runbook for the payment service deployment

诊断工具

智能体可用诊断工具评估检索质量：

  • 相关性打分： 按与问题的相关程度给每篇检索文档评分
  • 覆盖检查： 验证问题各方面是否都被覆盖
  • 矛盾检测： 不同来源不一致时打标
  • 置信度估计： 基于证据评估对答案有多自信

人工回退（Human fallback）

当智能体多次尝试后仍找不到满意答案时，它升级给人类而不是瞎猜。这是关键安全机制。

Agent: "I searched our knowledge base for information about
the 2024 data migration project but could not find sufficient
documentation. I found references to it in three documents,
but none contained the specific timeline you asked about.
I recommend checking with the Data Engineering team directly."

何时用基础 RAG vs. Agentic RAG

并非每个用例都需要完整的 agentic 方案。选择指南如下：

在以下情况使用基础 RAG：

  • 问题简单直接（「我们的退货政策是什么？」）
  • 答案通常存在于单一文档
  • 延迟关键（Agentic RAG 增加多次 LLM 调用）
  • 成本是主要约束
  • 知识库小且组织良好
  • 准确度要求适中

在以下情况使用 Agentic RAG：

  • 问题复杂且开放（「分析我们的客户流失趋势」）
  • 答案需要综合多个文档
  • 用户期望研究级深度
  • 知识库大、多样或组织混乱
  • 准确度关键且错误答案代价高
  • 问题常需澄清或分解

成本与延迟对比

方面 基础 RAG Agentic RAG
每次查询的 LLM 调用 1 3–10+
每次查询的检索调用 1 2–5+
典型延迟 1–3 秒 5–30 秒
Token 成本 低 高 3–10 倍
简单问题的答案质量 好 类似（杀鸡用牛刀）
复杂问题的答案质量 差到一般 好到优秀

ELI5：图书管理员 vs. 研究助理

基础 RAG 像向图书管理员问一个问题。你走到柜台说：「有关于恐龙的书吗？」图书管理员查目录，找到一本书交给你。如果这本书答不了你的具体问题——抱歉，你只能拿到这个。

Agentic RAG 像雇一个研究助理。你说：「我需要理解恐龙为何灭绝。」研究助理去图书馆，抽出几本书，读过之后发现一本过时了，放回去，找到更新论文，交叉对照两种理论，检查引用，带着有据可查的摘要回来。若图书馆信息不够，就查在线数据库。若发现冲突信息，会注明分歧并解释双方观点。

图书管理员给你一本书。研究助理给你一个答案。

在 Google Cloud 上做 Agentic RAG

Google Cloud 提供若干用于实现 Agentic RAG 的构建块：

Vertex AI RAG Engine

Vertex AI RAG Engine 为 RAG 流水线提供托管基础设施。它处理文档摄入、分块、嵌入与检索，让你能专注于 agentic 逻辑。

关键特性：

  • 带自动索引的托管向量搜索
  • 多种数据源连接器（Cloud Storage、Google Drive、网页 URL）
  • 可配置的分块与嵌入策略
  • 与 Vertex AI 模型端点集成

Vertex AI Agent Engine

Vertex AI Agent Engine 让你构建把 RAG 当作工具之一的智能体。智能体可决定何时搜索、查询哪些数据源，以及如何组合结果。

构建循环

Google Cloud 上实用的 Agentic RAG 实现可能像这样：

User Query
    |
    v
[Vertex AI Agent Engine]
    |-- Plans retrieval strategy
    |-- Calls RAG Engine (possibly multiple times)
    |-- Evaluates results
    |-- Reformulates if needed
    |-- Generates grounded answer
    |
    v
Verified Answer with Citations

实用实现模式

模式 1：查询分解（Query decomposition）

检索前把复杂查询拆成更简单的子查询。

User: "Compare our engineering team's velocity this quarter
       with last quarter and identify bottlenecks"

Agent decomposes into:
  1. "Engineering team velocity metrics Q3 2025"
  2. "Engineering team velocity metrics Q2 2025"
  3. "Engineering bottlenecks Q3 2025"
  4. "Sprint retrospective findings Q3 2025"

Each sub-query retrieves independently, then the agent
synthesizes a comparative analysis.

模式 2：带验证的检索（Retrieval with verification）

生成答案后，对照源文档验证每个主张。

Generated answer: "Revenue increased 15% in Q3..."
Verification step:
  - Claim: "Revenue increased 15%"
  - Source document states: "Revenue grew 15.2% year-over-year"
  - Verdict: Supported (minor rounding)

Generated answer: "...driven primarily by the APAC region"
Verification step:
  - Claim: "driven primarily by APAC"
  - Source documents: No mention of APAC as primary driver
  - Verdict: Not supported - needs re-retrieval

模式 3：迭代加深（Iterative deepening）

从宽搜索开始，根据发现逐步收窄。

Round 1: Broad search for "customer complaints Q3"
  -> Found: Common themes include shipping delays, product quality

Round 2: Focused search for "shipping delay root cause Q3"
  -> Found: Warehouse staffing issues in September

Round 3: Specific search for "warehouse staffing September impact"
  -> Found: 40% increase in fulfillment time due to understaffing

Agent now has a complete chain from symptoms to root cause.

模式 4：来源三角验证（Source triangulation）

查询多个独立来源并寻找一致意见。

Question: "What is the expected release date for Project Phoenix?"

Source 1 (Project tracker): "Target: March 15"
Source 2 (Team standup notes): "Aiming for mid-March release"
Source 3 (Executive update): "Phoenix launching March 15-20 window"

Agent: "Multiple sources converge on a mid-March release,
specifically targeting March 15-20."

常见陷阱

陷阱 1：无限检索循环

智能体不断搜索，因为永远不认为结果「够好」。务必设定最大检索迭代次数（通常 3–5），达到上限时让智能体给出带置信度说明的最佳答案。

陷阱 2：过度检索（Over-Retrieval）

智能体检索太多文档，淹没上下文窗口。限制每步检索的文档数与总上下文大小。优先相关性而非数量。

陷阱 3：忽略检索到的上下文

智能体检索了文档，却基于训练数据生成答案，而不是检索信息。使用强 grounding 指令，要求智能体基于检索文档作答并显式引用。

陷阱 4：缺失信息时没有回退

知识库没有所需信息时，智能体仍试图回答。训练智能体识别缺口，并说「在可用来源中找不到关于 X 的信息」，而不是幻觉一个答案。

动手练习

为技术文档用例构建 Agentic RAG 系统：

  1. 准备： 选一组技术文档（你自己的项目文档，或公开文档集如 Google Cloud docs）。

  2. 基础 RAG 基线： 实现简单的 retrieve-then-read 流水线。用复杂度不同的五个问题测试。

  3. 加入 agentic 能力： 至少实现下列两项：

    • 复杂问题的查询分解
    • 带重新查询的结果评估
    • 多来源检索
    • 对照来源的答案验证

  4. 对比： 用同一组五个问题跑两个系统。记录 Agentic 版本在何处产出更好答案，何处增加了不必要开销。

关键要点

  • 基础 RAG 遵循固定的 retrieve-then-read 流水线。Agentic RAG 让智能体掌控检索，决定何时搜索、搜什么，以及结果是否充分。
  • Agentic RAG 循环——规划、检索、评估、精炼、作答、验证——用迭代精炼取代单次通过。
  • 关键能力包括自主查询规划、自适应来源选择、上下文感知扩展与多跳推理。
  • 通过重新查询、诊断检查与人工回退进行自我纠正，防止系统死盯糟糕结果。
  • 速度重要的简单查询用基础 RAG；准确度比延迟更重要的复杂研究问题用 Agentic RAG。
  • 对检索迭代与上下文大小设清晰上限，避免无限循环与成本失控。

延伸阅读

下一课： 评估与测试智能体