← 全部文章
Agent 与 AI··约 7 分钟·

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

RAG 不是所有问题都先做向量搜索，而是让 Agent 在需要外部、私有或最新知识时，按权限检索证据并基于证据行动。

RAG for Agent：Agent 什么时候需要查知识库？
文章目录
  1. 导语
  2. 一、哪些问题需要检索
  3. 需要外部事实
  4. 事实可能更新
  5. 结论必须有出处
  6. 信息规模超过当前上下文
  7. 二、哪些情况不该机械地查知识库
  8. 三、知识进入系统之前发生什么
  9. 数据源
  10. 解析与切分
  11. 元数据
  12. 更新与删除
  13. 四、在线检索不只是向量相似度
  14. 五、两条落地路径：自己搭检索链，或使用托管检索
  15. 路径 A：自己实现检索服务
  16. 路径 B：使用 OpenAI File Search 等托管能力
  17. 怎么选
  18. 六、检索结果应该怎样返回给 Agent
  19. 七、权限过滤必须发生在检索端
  20. 八、Agent 何时继续搜，何时停止
  21. 九、怎样评价 RAG 是否真的有效
  22. 检索层
  23. 证据层
  24. 回答或行动层
  25. 十、前端与后端视角
  26. 前端
  27. 后端
  28. 十一、费曼式重建：回答休假政策
  29. 十二、常见误区
  30. 十三、本篇总结
  31. 参考资料

导语

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

上一篇讲了 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 还应明确：

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

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

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

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

正确边界是：

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

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

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

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

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

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

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

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

RAG Eval 至少分三层。

检索层

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

证据层

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

回答或行动层

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

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

十、前端与后端视角

前端

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

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

下一篇开始进入开发者最关心的应用形态：Code Agent 如何安全地读代码、改代码、跑测试？

参考资料