A-RAG：2026 年，知识库升级了

2026 年了，知识库早就不新鲜了。但是用户对于知识库的要求从“能搜到、能回答”，升级成“答得准、可引用、可复盘”。过去两年的很多系统，把文档切成块、做向量检索、拼进上下文，再让大模型输出答案。效果看起来不错，但一旦进入真实业务，问题会集中暴露在三点：噪声证据混进来后容易强行编答案；引用往往停留在“给个文档链接”，无法精确定位支撑句；成本和延迟波动大，难以解释为什么某个问题突然要读很多段。2026 年的知识库需要完整的工程系统升级：证据链可追溯，决策过程可记录，失败原因可定位。Agentic RAG（智能体式检索增强生成）是这一阶段最关键的方向之一，因为它把“检索”从固定流水线升级成可决策行为，使“准确与可引用”有了更稳定的实现路径。

从“检索一次”到“会查资料”

RAG 的核心并不复杂：先检索外部文档，再让模型基于检索结果生成答案。问题在于传统实现常被简化成一次 top-k：向量库返回若干段文本，全部塞进提示词，模型在这堆材料上写结论。这个流程在单跳 FAQ 上能跑通，但在复杂问法上会出两个典型故障。其一是“材料不够”，top-k 没覆盖关键条件，模型却仍然给出确定结论。其二是“材料太杂”，候选段落包含相似但不相干的信息，模型把噪声拼成看似合理的回答。两类故障的共同点是：检索被当成一次性动作，模型没有机会像人一样“先看线索、再精读、读不够就再查”。Agentic RAG 的切入点就在这里：把检索拆成多个工具，让模型在多轮过程中决定怎么找、找多少、什么时候停。

Agentic RAG 的“agent”并不等同于复杂编排，而是：把知识库检索能力做成可调用的工具，并允许模型根据当前证据状态继续搜索或结束回答。A-RAG 这类研究提出的分层工具很典型：关键词搜索用于精确定位术语、编号、条款；语义搜索用于处理口语化表达；精读接口用于按需读取某个 chunk 的完整文本。这个分层结构把“便宜的线索”和“昂贵的精读”分开，模型先用少量 token 看 snippet，再决定是否值得花更多 token 读原文，从而降低无效上下文带来的幻觉风险，并天然支持更精确的引用定位。

BM25、向量检索与重排：底座决定上限

Agentic RAG 不是用来替代检索底座的。相反，底座越扎实，agent 的上限越高。文档知识库常见的检索底座有两类：BM25/倒排与向量检索。BM25 的直觉是“词命中 + 统计学权重”，擅长编号、术语、人名、条款号这类精确字符串；向量检索用语义相似度找近邻，擅长同义改写、口语提问、概念性表达。两者组合成 hybrid 检索，能够同时覆盖“精确定位”和“语义泛化”。在万级文档规模下，hybrid 通常不是锦上添花，而是稳定性的基本盘。

检索之后还需要重排（rerank）。原因很直接：召回阶段宁可多、不能漏；生成阶段需要少而准。召回 top-100 到 top-300 后，用更强的相关性模型对候选段落进行精排，再挑出 top-8 到 top-12 进入后续阅读或证据抽取，能显著降低噪声比例。重排是“准确率分水岭”，也是“可引用”的前提之一：只有候选足够准，引用才不会变成“看起来引用了但实际上不支持”。

Agentic RAG 与这些组件的关系是互补的：hybrid + rerank 提供干净候选集，agent 决定是否需要多轮检索与精读。没有强底座的 agent 往往会出现另一种浪费：在噪声候选里不断迭代，步数更多，证据质量却不提升。成熟的工程实践通常不会把 agent 当成底座，而是把它当成“复杂问题的增量能力”。

可引用不是“给链接”，而是“把结论钉在原文上”

“可引用”听起来像展示功能，实际是可信系统的核心约束。可引用的关键不在于把文档 URL 附到答案后面，而在于把每个关键结论与原文证据片段建立一一对应。工程上通常会把段落进一步压缩成 evidence spans：从候选 chunk 中抽取支撑结论的句子或短跨句片段，并保留 doc_id、section 路径、chunk_id、offset 范围。生成时只允许基于这些 spans 下结论，答案中的引用标记直接指向 spans。这样做同时解决三个问题：减少上下文 token；降低模型自由发挥空间；支持审计时的精确复核。

Agentic RAG 在这里的价值很明显。传统 RAG 往往一次性塞入大量段落，证据与结论的对应关系模糊；Agentic RAG 更像“先找线索再精读”，精读接口天然以 chunk_id 为单位读取原文，便于把证据片段稳定地落在可定位的范围里。再配合 evidence spans 抽取，引用可以精确到句子级，而不是文档级。

证据门控：让系统知道“现在不该回答”

知识库系统最难处理的不是“能不能答”，而是“该不该答”。证据不足时强答，风险远高于拒答。证据门控（Evidence Gate）是一种工程化的自我保护机制：在生成之前对证据质量做判定，低于阈值就触发补救动作，补救无效则拒答或请求更多信息。门控信号可以来自 rerank 分数、证据覆盖度、关键条件命中情况，也可以来自一个轻量 evaluator 模型对“当前证据是否支持回答”的判断。CRAG 这类纠错思路强调的正是这一点：先评估检索质量，再决定改写 query、扩大检索、或终止回答。

Agentic RAG 与证据门控是天然搭配。门控负责告诉系统“证据不够”，agent 负责执行“再去找证据”。多步检索不是默认常态，而是在门控触发时才启动，成本因此可控。最终输出要么是“有证据链的答案”，要么是“证据不足的拒答”，两者都可解释。

何时需要 Agentic，何时不需要

Agentic RAG 的优势主要体现在两类问题上。其一是对比、变更、跨文档条件这类复杂问题，需要多轮定位与拼接证据链；其二是证据敏感问题，答案需要进入决策流程或对外交付，必须把结论与原文绑定并可复核。相反，简单 FAQ 或结构非常固定的问题，强底座的 single-pass RAG 往往更经济、更稳定。把所有问题都拉进多步循环，容易带来不可预测的延迟与成本，并引入新的随机性来源。更合理的形态是“默认短链路，复杂问题触发 agent”，并在每次触发时配置硬预算：最大步数、最大读块数、最大 token、重复读取去重。

总之

“知识库 2.0”是系统目标从“回答”升级为“证据驱动的回答”。BM25/倒排与向量检索提供稳定召回，重排把噪声压下去，evidence spans 把结论钉在原文上，证据门控让系统知道何时该停。Agentic RAG 把这一切串成可决策的过程：先看线索、再精读、证据不足就继续查，证据充分才输出结论。最终交付的不只是答案，而是一条可追溯的证据链和一段可复盘的检索轨迹。对客户而言，这比“能聊”更重要；对系统而言，这才是从演示走向可规模化落地的分界线。