# 3.4 智能体中的 RAG 系统设计

上一节解决的是“向量放在哪里”和“向量库能做什么”，这一节解决的是“什么时候取出来、怎样交给模型、以及取不到时怎么办”。检索增强生成（RAG）在智能体系统中的角色与独立应用大不相同，但在讨论 Agent 特化之前，本章先把最小闭环补完整。

> 💡 本节会先在本章内给出一个可落地的最小闭环；如果你还想展开阅读分块、重排序、混合检索等通用优化技术，可把《上下文工程指南》第五章当作延伸材料。

## 3.4.1 一个最小可用的 RAG 闭环

无论系统是否“agentic”，一个能工作的 RAG 至少要有下面五个环节：

| 环节    | 最小要求                                      | 常见失败模式                 |
| ----- | ----------------------------------------- | ---------------------- |
| 索引    | 将原始资料切成可检索单元，并保留 `source_id`、时间戳、权限范围等元数据 | 切块过大、丢失来源、无法过滤权限       |
| 检索    | 把用户问题转换为查询，召回 Top-K 候选，并在必要时做过滤或重排        | 找不到关键 chunk、召回了无权限内容   |
| 生成    | 只基于检索证据组织回答，而不是把检索结果原样堆给模型                | 回答脱离证据、上下文窗口被噪声占满      |
| 引用或拒答 | 回答里附上证据来源；证据不足时明确拒答、澄清或继续检索               | 模型“猜一个”看似流畅但不可溯源       |
| 观测    | 记录 query、召回的 chunk ID、最终答案和引用，便于回放与评测     | 线上出了问题却无法区分是检索失败还是生成失败 |

最小闭环并不要求你一开始就上复杂的 reranker、query planner 或多路检索，但至少要满足两个底线：**答案必须能回溯到证据**，以及**证据不足时系统必须有保守策略**。否则它不是一个可维护的 RAG，只是“把检索结果拼进 Prompt”的临时技巧。

可以把这条链路压缩成下面的伪代码：

```
chunks = retriever.search(query, top_k=5, filters=scope)
if chunks is empty or evidence_is_insufficient(chunks):
    return ask_for_clarification_or_abstain()

prompt = build_grounded_prompt(query=query, evidence=chunks)
answer = llm.generate(prompt)
return {
    "answer": answer,
    "citations": [chunk.source_id for chunk in chunks]
}
```

有了这条基础链路，后面再讨论 Agent 的动态检索、记忆融合和评测，才有统一语境。

## 3.4.2 智能体 RAG 与独立 RAG 的关键区别

**独立 RAG**：用户提问 → 检索 → 生成 → 回答（线性流程）

**智能体 RAG**：

* 智能体在多步推理中动态决定**何时、是否、从哪里**检索
* 检索结果可能触发**连续多次**的检索（而非单次）
* 检索与**工具调用、信息融合、决策制定**紧密耦合

这意味着智能体 RAG 不是单纯的上下文增强，而是**认知流程的有机部分**。

换句话说，普通 RAG 解决的是“拿材料来回答”，而 Agent RAG 还要解决“何时去拿、拿完是否继续行动、以及不同来源之间如何协同”。

## 3.4.3 最小可复现智能体 RAG 评测脚手架

一旦最小闭环跑通，下一步不是继续堆技巧，而是先把评测脚手架搭起来。建议构建 **最小可运行评估栈**，包括：

1. **数据集设计**：包含 `query_id`、问题、标准答案和 `required_source_ids`，支持追溯“检索失败” vs “生成失败”。
2. **日志收集**：记录检索到的 chunk ID、生成的答案和引用的证据，完整保存执行轨迹。
3. **指标评估**：
   * **context\_precision**：所需 chunk 是否被检索到（确定性指标）
   * **answer\_faithfulness**：回答是否基于检索内容（用 LLM-as-a-judge 评分）
4. **回归门槛**：CI/CD 拦截 `context_precision` 下降、`answer_faithfulness` 未保持或提升。

> RAG 评测方法的详细设计（数据集构建、评估框架、自动化回归）请参考第 7 章（Ch7.2 评估方法）。

## 3.4.4 智能体中的动态检索决策

在 Agent 中，最大的进步是从\*\*“总是检索”**到**“按需智能检索”\*\*的转变。

**检索时机决策**（何时调用 RAG）：

* Agent 在**规划阶段**评估：“我的内部知识足以回答这个问题吗？”
* 只在判断需要检索时才调用 RAG 工具，降低延迟和成本
* 对于多步问题，智能体可以在完成某个子任务后再决定是否检索相关信息

**实现示例**（伪代码）：

```
if agent_has_internal_knowledge(question):
    answer = agent.think(question)
else:
    relevant_docs = agent.retrieve(question)
    answer = agent.think_with_context(question, relevant_docs)
```

这类“按需检索”只有在你已经具备上一节的最小闭环与日志能力时才真正可控，否则你只会看到“有时检索，有时不检索”，却无法判断它究竟帮了你还是害了你。

## 3.4.5 记忆系统核心评估指标

有效的 Agent 记忆系统需要在多个维度上进行量化评估：

| 指标           | 定义                  | 计算方式               | 目标值    |
| ------------ | ------------------- | ------------------ | ------ |
| Recall\@K    | 前 K 个检索结果中包含相关文档的比例 | 相关命中数 / 总相关文档数     | > 0.85 |
| Precision\@K | 前 K 个检索结果中相关文档的占比   | 相关命中数 / K          | > 0.70 |
| 幻觉率          | 生成内容中无法溯源到检索结果的事实比例 | 无来源断言数 / 总断言数      | < 0.05 |
| 检索决策准确性      | Agent 选择“检索”的决定是否正确 | 需要检索且检索的 / 需要检索的总数 | > 0.80 |

> 💡 **Agent-特定指标**：对 Agent 系统而言，“检索决策准确性”比单纯的检索精度更重要，因为不必要的检索会拖累响应速度。

## 3.4.6 RAG 与多源记忆系统的融合

传统 RAG 和用户记忆系统往往作为两套独立管道运行：RAG 检索知识库文档，记忆系统检索用户历史。这种松耦合架构存在一个根本问题——**知识与个性化上下文的割裂**。

### 割裂带来的失败模式

考虑一个技术助手场景：用户问“如何部署我的服务”。

* 知识库 RAG 能检索到通用的部署文档（Kubernetes、Docker Compose、Serverless 等多种方案）
* 记忆系统知道“这个用户偏好 Kubernetes，且上周刚完成了集群搭建”

如果两者分离，系统要么给出不够个性化的通用答案，要么只基于记忆回答但缺少最新文档支撑。

### 混合检索的设计思路

新一代框架（如 Supermemory）将两者合并为单次混合查询：一次检索同时返回知识库文档和个性化记忆，让模型在生成时能同时基于“外部知识是什么”和“用户的相关上下文是什么”。

这种设计对 RAG 系统的架构有两个重要启示：

1. **检索源的统一语义层**：来自不同源的内容（文档、聊天记录、文件、代码、邮件）需要经过统一的事实抽取和结构化处理，进入同一个语义空间。否则跨源召回时容易出现上下文不匹配。
2. **目标函数的重新定义**：传统 RAG 优化的是语义相似度（Semantic Similarity），但当记忆参与检索后，系统需要同时优化 **更新正确性**（新事实是否覆盖了旧事实）、**时间正确性**（是否返回了最新状态）和 **噪声抑制**（是否过滤了过期信息）。

### 外部连接器：让记忆超越聊天

记忆不应只来自对话历史。在真实智能体场景中，用户的状态分散在多个外部系统中：

* 文档协作平台（Google Drive、Notion）中的最新工作内容
* 代码仓库（GitHub）中的最近变更
* 邮件中的确认事项和决策

通过实时连接器（Webhooks）同步这些外部源，系统获得的不只是“用户说过什么”，还有“用户最近做了什么”。这种多源融合显著提升了上下文的完整度，是从“聊天记忆”到“全景记忆”的关键一步。

> **架构提示**：混合检索不是简单地将两个检索结果拼接后送入 LLM。有效的实现需要在检索层面完成结果的去重、冲突消解和优先级排序，确保送入上下文窗口的信息既完整又不自相矛盾。

***

**下一节**: [3.5 图记忆与知识图谱](/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/03_memory/3.5_graph_memory.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/03_memory/3.4_rag_advanced.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.