> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/agentic_ai_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/03_memory/3.4_rag_advanced.md).

# 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)