代理检索与充分上下文：当RAG信息不足时
标准RAG往往过早给出答案。而代理式检索机制则会持续搜索、筛选来源、评估证据，直至获取足够的信息背景。
来源: When RAG Doesn’t Know Enough: Why Agentic Retrieval Needs Sufficient Context
向量搜索并非导致大多数RAG系统失效的根本原因。更棘手的问题在于模型在缺乏足够证据的情况下仍会给出回应。这并非完全找不到任何内容：系统通常会提取一些内容，这些片段看似与主题相关，回复也流畅且自信。但由于所需事实分散在多份文档、系统、表格、工单、手册、日志或图表关系中，因此回复仍然是不完整的。
典型的处理方式是仅进行一次遍历：
User question → embed query → retrieve top-k chunks → send to LLM → generate answer
简单的问题这样处理没问题，但企业级问题很少如此。策略规则存在于一个文档中，其例外情况则另存于另一个文档。工单用于描述事件，发布说明用于解释行为变化，数据库记录保存当前状态，图结构中的边展示依赖关系，PDF表格呈现实际数据，而过往对话记录则记载用户已尝试过的操作。如果只获取少量相似内容，模型就会过早给出回复。RAG并未消亡，它需要能够识别出自身信息不足的情况。
过早的回答
许多RAG系统会悄无声息地出错。它们从不说明证据不足，而是给出一个流畅、有条理且看似合理的答案，但实际上却是错误的。
想象一下，有内部支持人员被问及为何在工作空间迁移后Acme的导出功能出现了故障。一个简单的流程只会找到一个导出故障排查页面，并称是权限不足导致的。这或许有部分道理。但完整的解决方案需要参考Acme的迁移记录、关于导出权限变更的发布说明、上周的工单、内部事件报告、该账户的功能开关，以及列出相关导出服务的依赖关系图。单一份文档根本无法承载所有这些信息，因此信息检索的处理方式必须更接近于人工处理。
充分上下文的意义
足够的上下文意味着手头的证据足以支撑一个确定的答案。关联度较低的片段、过高的相似度得分或仅返回的五份文档均不可取。在生成答案之前，系统应确认自己掌握了相关策略、例外情况、当前状态、权威记录、实体间的关联关系，以及足以解释问题根源而非仅表面症状的信息，同时还需有引用结果的途径。如果缺少任何要素，系统就应该重新搜索。这就是从传统RAG向智能检索的转变。
从top-k检索到证据查找
标准RAG将检索视为一个独立步骤：检索一次即可给出答案。而智能检索则将其视为一个工作流程：
Retrieve once → answer
Plan → retrieve → inspect → judge evidence → retrieve again → answer
模型并无义务必须从最先出现的信息中回答问题。它更像是一名研究分析师，会进行搜索、打开文档、对比内容、梳理关联关系，在上下文足够充分时才会进行验证并给出答案。
为何智能体能提升处理效率
聊天机器人只是回答问题，而智能体则会做出决策：选择工具、调用API、更新记录、提交工单、推荐行动方案、请求批准或依次执行多个步骤。不完整的上下文会随之影响后续处理流程：
Incomplete retrieval → wrong diagnosis → wrong tool call → wrong business action
检索代理不应仅仅上报类似的文档。它应当能够说明自己找到了相关策略、例外情况、实时账户状态以及相关事件，并且这些证据足以解决该问题。这才是不同的架构。
代理检索的发展方向
近期在RAG和知识图谱方面的研究表明，未来的检索系统应当由代理控制、具备图谱意识、根据证据进行评分，并且有记忆功能作为支撑。并非每个系统都需要庞大的知识图谱，但检索层需要比简单的查询嵌入和返回前k个结果更强的智能性。有几个重要的发展方向。
跨语料库检索
企业知识并非存储在某个结构化的向量数据库中，而是分散在 Google Drive、Confluence、Notion、Slack、Jira、GitHub、数据仓库、支持工单、仪表板、内部 API、产品文档以及 PDF 手册中。一个优秀的系统必须能够判断首先该在何处查找。检索规划器可以将问题分类为政策相关、产品行为、客户特定问题、故障事件、财务指标或技术依赖关系，然后据此进行路由处理。全面搜索成本高昂，而在错误的地方搜索则更为糟糕。
将检索作为工具
一种实用的方法是将检索呈现为一组可控的工具，而非固定的结果：
search(query)
find(term, document)
open(document_id)
summarize(document_id_or_section)
这与人类的调查过程类似：先进行搜索，打开有希望的结果，查看相关内容，优化查询条件并比对证据。推理模型驱动这一流程，但仅限于一定的工具集范围内，从而在保持灵活性的同时避免无限制的访问。
知识图谱遍历
向量搜索能够找到语义上相似的文本，而许多实际问题则涉及实体之间的关系。这项服务会影响哪些客户？哪些产品依赖于该API？该地区适用哪项政策？是哪次部署导致了此次故障？这些都是需要结合上下文来解答的问题，而非单纯基于相似性的问题。知识图谱可以直接将这些实体相互关联：
Customer → Workspace → Feature Flag → Service → Incident → Release Note
智能体可以跟随这些链接，而不必指望在顶部结果中出现合适的片段。这更像是基于导航而非检索的方式。在关系至关重要的场景中使用它，而仅因它听起来很高级就舍弃则不可取。
证据充分性评分
检索完成后，系统应判断现有证据是否足够。它能否直接回答问题？是否存在实体、日期或来源的缺失？各来源之间是否存在矛盾？信息来源是否具有真正的权威性？答案能否被引用？当证据不足时，系统会继续搜索：
Evidence score: weak
Reason: found general export docs, but no customer-specific workspace state
Next action: query account configuration source
这种循环机制可以避免过早给出答案，同时便于调试，因为你可以清楚地看到智能体为何会再次进行搜索。
上下文图与智能体记忆
RAG通常用于处理外部知识，但智能体也需要记忆：用户之前询问过什么、已经搜索过什么、哪些证据被采纳、做出了什么决定以及还有哪些假设尚未解决。单纯的对话缓冲区是不够的。更好的设计是将记忆与实体和决策关联起来，这样推理过程本身就能成为记忆：
User asked about Acme export failure → agent searched export docs →
found migration-related incident → checked Acme workspace state →
concluded permission-path mismatch
下次出现类似问题时，代理无需从头开始处理，这对于长时间运行的代理而言非常重要。
多模态且具备文档理解能力的RAG
许多企业知识并非纯文本形式，它们存在于PDF、表格、截图、图表、公式、扫描件、曲线图、幻灯片和表格中。普通的文本分割方式会破坏这些文档的结构：表格会变成杂乱无章的文本，公式会脱离原有上下文，图表则会被简化为OCR识别结果，各部分内容也会与解释它们的标题分离。具备文档理解能力的处理流程能够理解文本、表格、图表、布局、标题层级、说明文字、表单字段以及视觉元素与文字内容之间的关联。金融、医疗、制造、法律、保险以及技术文档领域最依赖这类技术。
工具与上下文资源限制
工具也会消耗上下文资源。一旦加载了数十种检索、图谱、数据库和搜索工具，它们的结构规范就会与相关证据产生冲突：
Tool definitions + retrieved evidence + conversation history + room for the answer
= one finite context window
因此，代理式RAG需要一个具备预算意识的运行时系统，它能决定展示哪些工具、包含多少片段、是否需要对工具输出进行总结，以及最重要的，何时停止。其目标是获取足够的信息，而非无止境地获取。
生产环境架构
总体而言，用于代理式检索的生产系统更类似于控制平面，而非流水线：
User Question
↓
Intent + Risk Classifier
↓
Retrieval Planner
↓
Source Router
├── Enterprise Search
├── Vector Search
├── Keyword Search
├── Knowledge Graph
├── Structured Data
├── Document Parser
└── Agent Memory
↓
Evidence Inspector
↓
Sufficiency Gate
├── If insufficient → refine query / follow graph / open document
└── If sufficient → generate answer
↓
Answer with Evidence Trace
实际操作要点更简单：在RAG获得足够证据之前不要让它给出答案。
Acme案例的全过程
当被问及工作空间迁移后导出失败的原因时，传统的RAG会调取导出故障排除指南和迁移常见问题解答，然后回复称导出失败很可能是由于权限不足所致。而代理系统则会进行如下调查：
- 在支持文档中搜索导出失败的相关信息。
- 在版本说明中查找工作空间迁移带来的变更。
- 打开客户的账户配置。
- 检查功能标志的状态。
- 查询故障历史记录。
- 沿着依赖关系图从导出服务追踪到权限服务。
- 判断现有证据是否足够。
- 结合来源信息撰写答案。
最终答案是：Acme已被迁移到新的工作空间模型，但导出服务仍在使用旧的权限路径进行检测。虽然工作空间标志已启用，但导出策略始终未升级，因此解决办法是为该工作空间模型更新相应策略。改变结果的并非更强大的模型，而是更完善的证据收集方式。
应首先构建什么
在已有RAG系统的基础上，无需重新构建所有内容。请按以下步骤操作：
- 添加充分性检查。在生成内容之前，先判断所获取的证据是否足以回答当前问题；如果不够，要么再次进行信息检索，要么向用户提出更明确的疑问。
- 添加源路由功能。每次都搜索所有源节点会浪费大量精力。首先对查询进行分类：政策相关问题归类到政策文档中，客户问题则连同账户状态一起存入工单，技术故障相关内容存入文档、日志和服务结构图中，而指标相关问题则交由语义层处理。
- 添加诸如
search、open、find、summarize、follow_entity_relation和query_structured_record之类的检索工具，从而使检索过程具备迭代性。 - 添加图遍历功能，因为某些答案取决于所有权、依赖关系、传承关系、因果关系、层级结构、多跳链接或政策例外情况。
- 保留文档结构。对于PDF、报告、幻灯片、表格和图表，应使用能够识别文档结构的解析方式来存储信息，而非简单地进行分块处理。
- 需保留证据轨迹，记录所搜索的来源、打开的文档、采纳的事实、发现的缺失以及系统判定已收集足够信息的理由。正是这样的记录为代理式RAG赢得了信任。
无需过度设计的部分
设计可能会过于复杂，且并非每种技术都适用于所有场景。简单的常见问题搜索可能不需要知识图谱，纯文本文档无需多模态解析，一次性问答不需要长期图结构记忆，而完全内部化的领域则无需外部搜索。关键是要判断该问题需要何种类型的证据。对于单一清晰的文档，普通的RAG即可满足需求；而当答案涉及多种来源、关联关系、历史记忆及当前状态时，代理式检索才显得其复杂性有必要。
转变
当前RAG领域的发展并非要取代向量搜索，而是为信息检索增添更多控制手段。向量搜索依然重要，关键词搜索也同样重要。当存在数据关联时知识图谱就发挥作用，当有明确结构时文档解析就必不可少，而当智能体需要持续工作则内存十分关键。实际应用任务就是将这些技术结合起来。下一代系统将不再呈现如今这样的形态：
Vector DB → top-k chunks → LLM
还有类似这样的内容：
Planner → source routing → retrieval tools → graph traversal → evidence scoring → answer
RAG不仅在获取到不良数据块时才会出错，当它获取到部分有用但并不完整的数据块并过早给出答案时也会出错。对于简单问题，top-k方法或许仍能适用。但对于企业级应用、研究场景、支持服务、运维任务以及需要处理大量文档的智能体而言，检索机制需要更完善的循环机制：
plan the search → route to the right sources → inspect evidence →
follow relationships → check sufficiency → retrieve again if needed →
answer only when grounded
这就是从标准RAG向智能检索代理的转变。并非因为RAG已经过时，而是实际应用中的智能代理需要能够识别出自己掌握的信息不足的情况。
相关阅读
- RAG、微调还是智能代理：如何选择合适的层次及构建顺序 —— 对检索、微调与智能代理三种技术的实际对比，涵盖了成本、延迟、故障模式、实用原则，以及一个展示构建顺序的人力资源助理案例。