Agentic RAG设计指南：何时检索、选哪些数据与溯源全解析

传统RAG（检索增强生成）像一条流水线：用户提问→检索文档→生成回答。但现实中的问题往往更复杂——有些问题不需要检索，有些需要跨多个数据源，还有些答案必须可追溯到原始出处。于是，Agentic RAG 应运而生：让AI智能体自主决定何时检索、检索什么、以及如何标注来源。

最近Reddit上有一个引发广泛讨论的帖子（原帖链接），提出了三个核心设计问题：何时使用RAG、检索哪些数据、如何追溯每个答案的来源。本文结合社区讨论与工程实践，拆解这三个问题的解决思路。

一、何时使用RAG：让智能体学会“按需检索”

Agentic RAG的第一个决策点是触发条件。如果每次提问都检索，不仅浪费算力，还可能引入无关噪声；如果从不检索，模型又会编造事实。Reddit讨论中，多位开发者建议采用路由机制：用一个小型分类器或LLM判断问题类型。

常见策略包括：

• 规则+语义路由：对“今天天气”“最新新闻”等时效性问题强制检索，对数学计算、代码语法等纯逻辑问题跳过检索。
• 置信度阈值：让基础模型先尝试回答，若自身置信度低于阈值（如通过logprob或自洽性采样评估），再触发检索。
• 工具调用范式：将检索器封装为工具，由智能体在推理链中自主决定是否调用。LangChain的create_react_agent和LlamaIndex的RouterQueryEngine都支持这种模式。

原帖作者提到，他们用“检索必要性评分”来训练一个轻量级分类器，准确率可达85%以上。

置信度评估是路由机制中的关键环节。LLM的logprob（对数概率）反映了模型对每个生成token的确定程度，可以取回答序列的平均logprob作为整体置信度的代理指标；自洽性采样（self-consistency）则是对同一问题多次采样，观察答案的一致性程度——若多次采样结果分歧较大，说明模型对该问题把握不足。这两种信号都可以作为触发检索的阈值判断依据。需要注意的是，logprob阈值需要针对具体模型和任务分布进行校准，不同模型输出的概率分布尺度差异较大，直接套用固定阈值往往效果不佳。实践中建议先用标注数据绘制置信度-准确率曲线，再选取兼顾召回率与精确率的最佳切分点。

二、选哪些数据：多源检索与重排序

确定需要检索后，下一个问题是检索什么。Agentic RAG不应只依赖单一向量库，而应支持多源异构数据（文档、数据库、API、网页）的按需选择。

2.1 数据源路由

智能体可以根据问题领域选择数据源：技术问题查代码库，产品问题查帮助文档，实时问题查搜索API。Reddit用户u/rag_enthusiast分享了一个实用技巧：为每个数据源维护一个嵌入中心向量，计算问题与各中心向量的相似度，选Top-2数据源进行检索。

2.2 检索策略组合

单一检索方式容易漏召。建议组合：

• 稠密检索（向量相似度）捕捉语义匹配；
• 稀疏检索（BM25）保证关键词精确命中；
• 元数据过滤（时间、作者、文档类型）缩小范围。

检索后，用交叉编码器（cross-encoder）重排序，取Top-K结果。社区经验是：先宽后精——每源先召回20条，重排序后保留3-5条。

交叉编码器（cross-encoder）重排序与常见的双编码器（bi-encoder）有本质区别。双编码器将查询和文档分别编码为向量后计算余弦相似度，速度极快但丢失了查询与文档之间的细粒度交互信息；交叉编码器则将查询和文档拼接后一起输入Transformer，让注意力机制充分建模两者间的词级关联，因此排序精度显著更高，但计算成本也大得多——每个查询-文档对都需要一次独立的前向推理。这正是“先宽后精”策略的工程逻辑：用低成本的双编码器或BM25做大规模粗召回，再用交叉编码器对少量候选精排，在效果与延迟之间取得平衡。常见的交叉编码器模型包括BGE-Reranker系列和Cohere Rerank等。

2.3 上下文压缩

检索到的片段可能冗余。用LLM做上下文压缩（如LangChain的ContextualCompressionRetriever），只保留与问题直接相关的句子，可显著提升生成质量并降低token消耗。

三、如何溯源：让每个答案都可追溯

溯源是Agentic RAG的信任基石。Reddit讨论中，最受认可的做法是引用标注+验证链。

3.1 生成时强制引用

在提示词中要求模型在每句话后标注来源ID，例如[doc_123]。更严格的做法是使用结构化输出（如JSON），让模型返回{answer, citations: [{text, source_id}]}。OpenAI的Function Calling和Instructor库都能实现。

3.2 检索链记录

智能体应记录完整的检索轨迹：用了哪个查询、检索了哪些数据源、返回了哪些文档、重排序分数如何。这些元数据不仅用于调试，也可在最终答案中展示“推理依据”。

3.3 事后验证

生成后，用一个小模型或规则检查每个引用是否真的支持对应陈述（NLI任务）。Reddit用户u/traceable_ai提到，他们用DeBERTa做蕴含判断，过滤掉不支持的引用，准确率提升约12%。

NLI（自然语言推理） 是判断两个文本片段之间逻辑关系的任务，标准标签包括蕴含（entailment）、矛盾（contradiction）和中立（neutral）。在引用验证场景中，可将“引用文档片段”作为前提（premise）、“答案中的陈述”作为假设（hypothesis），若模型判定为蕴含，则说明该引用确实支持对应陈述；若判定为矛盾或中立，则该引用应被过滤或标记为不可靠。DeBERTa等预训练模型在NLI基准（如MNLI）上表现优异，且推理延迟远低于让大模型自行判断。相比让生成模型“自我检查”，独立的NLI模型作为验证器能有效避免同一模型的自洽偏见，形成真正的交叉校验。

四、工程落地建议

综合社区讨论，一个可落地的Agentic RAG架构包含四层：

1. 路由层：判断是否检索、选哪些数据源；
2. 检索层：多路召回+重排序+压缩；
3. 生成层：带引用的结构化生成；
4. 验证层：引用校验与轨迹记录。

框架选择上，LangGraph适合编排有状态的多步智能体，LlamaIndex的AgentRunner内置了工具调用和溯源支持。如果追求轻量，可以用smolagents或直接基于OpenAI Assistants API搭建。

原帖作者最后总结：“Agentic RAG不是取代传统RAG，而是在其上加一层决策智能。最关键的不是模型多强，而是检索决策和溯源机制的设计。”

LangGraph与LlamaIndex AgentRunner代表了两种不同的编排哲学。LangGraph以图结构组织智能体流程，节点代表处理步骤、边代表状态转移条件，天然适合表达“路由→检索→生成→验证”这类带分支和循环的多步工作流，且支持检查点机制实现中断恢复。LlamaIndex AgentRunner则更偏向工具调用范式，将检索器、查询引擎等封装为智能体可调用的工具，由LLM在推理过程中自主决定调用顺序，开发门槛更低但流程可控性相对较弱。选型时可参考：流程固定、需要严格审计轨迹的场景优先选LangGraph；探索性强、工具组合灵活的场景可考虑AgentRunner。两者也可混合使用——用LangGraph编排外层状态机，内部节点调用LlamaIndex的检索组件。