RAG for Agent：Agent 什么时候需要查知识库？

导语

员工问：“上海员工今年没休完的年假能转到明年吗？”模型很快给出答案，却引用了三年前的旧政策。问题不在措辞，而在于它没有取得当前组织、地区和年份对应的有效证据。

上一篇讲了 Runtime 如何为当前决策准备上下文。知识库不会自动出现在模型眼前，因此还需要一条“按需取证”的路径。

RAG 是 Retrieval-Augmented Generation，常译为检索增强生成：先从外部知识源找出相关内容，再让模型基于检索结果回答或决定下一步。

对 Agent 来说，检索通常不是固定前置步骤，而是一种工具能力：

当前上下文不足
→ Agent 提出检索
→ 检索系统按权限返回证据
→ Agent 阅读证据并决定回答、继续查或调用其他工具

“先搜再答”只是最简单形态。真正的工程问题是：什么时候搜、搜哪里、怎样证明搜到的是对的，以及知识是否有权被当前用户看到。

---

一、哪些问题需要检索

需要外部事实

模型训练知识不包含你的合同、内部手册、代码仓库和实时订单。若答案依赖这些事实，就需要工具或检索。

事实可能更新

产品价格、API 文档、公司制度和线上状态会变化。即使模型“记得”，也不应把记忆当最新证据。

结论必须有出处

法律、财务、研究和企业决策常要求引用具体来源。检索为结论提供可检查证据。

信息规模超过当前上下文

大量文档不适合整批放入模型窗口。检索先缩小候选范围。

---

二、哪些情况不该机械地查知识库

• 用户只是要求改写刚给出的文字；
• 计算可以由确定性代码完成；
• 答案已经在当前 Tool Result 中；
• 问题需要实时业务状态，应调用业务 API 而非过期文档；
• 知识库没有覆盖该领域，检索只会制造似是而非的片段；
• 用户没有访问对应资料的权限。

RAG 不是 Agent 的固定第一步。检索有延迟、成本和错误，也可能把无关或恶意内容带入上下文。

下面的判断表把“需要外部证据”和“已有更直接的数据路径”分开，适合在设计检索工具触发条件时直接使用。

---

三、知识进入系统之前发生什么

一条可靠的离线链路通常包括：

检索质量在用户提问之前就已经被决定了一半。数据源、切分、元数据、质量检查、索引以及更新删除必须形成可追踪链路，任何一步偷懒都会把脏数据带到最终答案。

数据源

先确认哪些系统是权威来源。个人随手整理的副本不能与正式政策库同权。

解析与切分

按标题、段落、表格或代码结构切分，通常比固定字符数更能保留语义。块过大带来噪声，过小则丢失上下文。不存在适用于所有资料的唯一尺寸，应通过 Eval 调整。

元数据

至少考虑文档 ID、标题、版本、更新时间、来源、章节位置、租户、权限标签和有效状态。

更新与删除

新版本加入索引时，旧版本是否下线？源文档撤权或删除后，索引、缓存和副本是否同步？“能搜到”只是开始，知识生命周期同样重要。

---

四、在线检索不只是向量相似度

一条查询可能经过：

1. 判断是否需要检索；
2. 从任务和上下文构造查询；
3. 用租户、权限、版本和时间做过滤；
4. 关键词检索、向量检索或混合检索；
5. 对候选结果重排；
6. 去重并补充邻近段落；
7. 返回带来源的证据块。

关键词检索擅长精确名称、错误码和 ID；语义检索擅长意思相近但措辞不同的问题；混合方式常能互补，但是否更好要以自己的数据评测。

查询改写可以由模型完成，例如把“这个政策怎么算”补成包含产品、地区和日期的搜索词。但地区和身份必须来自可信上下文，不能由模型臆测。

---

五、两条落地路径：自己搭检索链，或使用托管检索

路径 A：自己实现检索服务

适合数据源多、权限规则复杂、需要自定义排序，或必须部署在现有基础设施内的团队。

第一步不要先选向量数据库，而是选一个真实问题和权威数据源。实现最小链路：解析与切分、元数据和权限、关键词或向量召回、可选重排、结构化证据返回。Agent 只通过一个边界清楚的检索工具访问它。

可见产物应包括索引版本、每个证据块的来源与权限、查询和过滤条件、召回顺序、空结果与截断状态。常见失败是只保存向量和正文，更新政策后无法删除旧块，也无法解释为什么某条证据被召回。

验证不要只问“答案看起来对吗”。准备带正确文档 ID 的查询集，分别测正确证据能否召回、无权证据是否彻底不可见、空结果是否被正确处理，再评最终回答是否忠实引用。

路径 B：使用 OpenAI File Search 等托管能力

适合数据规模和权限模型较简单，希望先验证产品价值的团队。托管 File Search 可以负责文件上传、向量存储和检索调用，减少自建解析、Embedding 与查询基础设施的工作。

但文件归属、访问范围、版本替换、删除同步和最终引用仍由应用负责。

先用一小组可审查文档建立独立知识库，为每个租户或权限范围设计明确边界，要求工具结果保留文件与片段引用。随后用第十二篇的 Eval 比较检索相关性、回答忠实度、零结果和权限样本。

若产品需要复杂 ACL、关键词与向量混合排序、跨数据源联邦查询或自定义删除时效，托管能力未必覆盖全部需求。此时可以保留托管服务做简单知识库，把高要求场景迁回自建检索服务，而不是用 Prompt 弥补权限缺口。

怎么选

情况	起步建议
小规模文档问答，权限边界简单	托管 File Search
多租户、细粒度 ACL、复杂版本规则	自建检索服务
需要精确错误码、文件名和语义互补	自建混合检索，或先验证平台是否支持
还不知道用户是否真的需要知识库	用托管能力做小实验，先跑 Eval

---

六、检索结果应该怎样返回给 Agent

不要只返回一段拼接文本。至少保留结构：

type EvidenceChunk = {
  chunkId: string;
  documentId: string;
  title: string;
  text: string;
  sourceUrl?: string;
  section?: string;
  version?: string;
  updatedAt?: string;
  score?: number;
};

模型需要文本来理解，也需要来源和版本来判断冲突、生成引用。score 是检索系统的排序信号，不等于“事实为真”的概率，不应直接向用户宣称 92% 可信。

Tool Result 还应明确：

• 是否没有结果；
• 是否因权限过滤掉部分候选；
• 是否截断，还有没有下一页；
• 使用了哪个索引或数据版本；
• 请求和检索耗时。

“空结果”不能被模型理解成“事实不存在”，它只表示在当前范围与查询下没有找到。

因此工具最好返回结构化证据包，而不是把若干片段拼成一堵文本墙。证据包应同时携带来源、时间、权限和检索条件，让 Agent 能明确选择回答、继续搜索或拒绝。

---

七、权限过滤必须发生在检索端

错误做法是先检索全公司文档，把结果发给模型，再让 Prompt 要求它“不要泄露无权内容”。此时数据已经越过安全边界。

正确边界是：

可信用户与租户身份
→ 检索服务生成权限过滤条件
→ 只返回当前身份可读的文档块
→ 模型基于允许的证据工作

文档级权限有时还不够。同一文档中若部分段落敏感，需要更细的分块权限或在数据源侧提供安全视图。

缓存也必须带权限维度，避免把管理员查询结果复用给普通用户。

---

八、Agent 何时继续搜，何时停止

一次检索可能不够。Agent 可以根据观察选择：

• 证据已直接覆盖问题，开始回答；
• 结果冲突，搜索权威来源或更新版本；
• 查询过宽，加入实体和时间限定；
• 只有二手引用，继续寻找原始文档；
• 没有结果，换关键词、换数据源或向用户澄清；
• 达到搜索次数或成本上限，明确报告不足。

停止条件不应只是“模型觉得够了”。Runtime 可以限制检索次数、Token 和延迟；任务完成条件可以要求关键结论必须有来源，或高风险问题必须包含权威文档。

---

九、怎样评价 RAG 是否真的有效

RAG Eval 至少分三层。

检索层

正确证据是否出现在前若干结果中？可以使用 Recall@k、MRR 等指标，但要先有经过标注的相关文档。

证据层

返回块是否足够支持结论，是否来自正确版本和有权限的来源？相关不等于足以回答。

回答或行动层

最终结论是否忠实于证据，引用是否对应，证据不足时是否承认不足？如果 Agent 还要调用其他工具，也要评检索结果是否帮助它选择了正确动作。

三层评测回答的是三个不同问题：有没有找对、证据够不够、Agent 有没有忠实使用。只优化其中一层，无法证明 RAG 真的改善了任务结果。

离线测试用固定索引快照，线上再监测零结果率、点击或引用打开率、延迟、权限拒绝和用户纠正。不要只看向量相似度。

---

十、前端与后端视角

前端

把引用和结论关联起来，允许用户展开原文、标题、版本和更新时间。若来源无权打开，至少给出合适解释；更理想的是在检索阶段就避免这种不一致。

用户还可以选择搜索范围、移除错误资料或反馈“引用不支持结论”，这些事件能回流 Eval。

后端

维护数据接入、解析、索引、权限、删除同步、查询、重排、缓存和审计。文档版本、Embedding 模型、切分策略与重排器都应版本化，因为它们会改变检索结果。

---

十一、费曼式重建：回答休假政策

用户问：“上海员工今年未休年假能转到明年吗？”

可靠过程是：

1. 应用从登录态确认组织与用户可访问范围；
2. Agent 判断问题依赖内部且可能更新的政策，提出知识检索；
3. 查询包含“上海、年假、结转、当前有效版本”；
4. 检索服务先应用权限和有效状态过滤，再混合召回与重排；
5. Tool Result 返回政策段落、章节、版本、更新时间和链接；
6. 若新旧文件冲突，Agent 优先查询权威现行版本，而不是自行平均；
7. 最终回答只陈述证据支持的规则，并附可打开的引用；
8. 若政策没有覆盖特殊员工类型，明确提示需要 HR 确认。

这才是“基于知识回答”，不是模型看到几个相似句子后自由发挥。

本文简化了表格解析、多模态文档、知识图谱和跨语言检索。是否需要这些能力，应由数据与 Eval 结果驱动。

---

十二、常见误区

• 所有请求都先做向量搜索；
• 把整份长文档直接塞进上下文；
• 只存文本，不存来源、版本和权限元数据；
• 先检索敏感数据，再要求模型不要泄露；
• 把相似度分数解释为事实可信度；
• 检索为空时让模型凭记忆补答案；
• 更新新文档却不处理旧索引和缓存；
• 只评最终文风，不评正确证据是否被召回。

---

十三、本篇总结

RAG for Agent 是一条受控的取证链：在需要外部知识时，Agent 提出检索；检索系统按身份、版本和范围返回证据；Agent 基于证据回答或继续行动。

关键点是：

1. 并非每个问题都需要 RAG；
2. 数据接入、切分、元数据、更新和删除决定知识底座质量；
3. 检索要组合查询、权限过滤、召回、重排与可追溯结果；
4. 空结果和相似度都有明确边界；
5. 检索质量、证据质量和最终结果要分层评测。

到这里，课程已经完成 Agent 通用运行内核：循环、工具、状态、Memory、Planning、权限、HITL、可观测性、Eval、Context 与 RAG。

---

参考资料

• OpenAI：Retrieval https://developers.openai.com/api/docs/guides/retrieval
• OpenAI：File Search https://developers.openai.com/api/docs/guides/tools-file-search
• OpenAI API：Vector store files https://developers.openai.com/api/reference/resources/vector_stores/subresources/files
• LangSmith：Evaluate a RAG application https://docs.langchain.com/langsmith/evaluate-rag-tutorial