上周帮一个团队排查企业知识库问答的“幻觉”问题。场景很典型内部文档库标准 RAG 流程——文档切块、向量化、语义检索、把 Top-5 切片拼进大模型上下文、生成回答。用户问的是“项目验收时发现发票金额和合同不一致应该找哪个部门处理流程是什么”系统返回了一段流畅但漏掉关键信息的回答。我打开检索日志真正包含上报流程的文档排在第十一位根本没进 Top-5。团队第一反应是把 K 从 5 改成 20。结果那条文档进来了回答反而更差——多出来的低相关切片分散了大模型注意力甚至和合同条款产生矛盾。这不是换个 embedding 模型、调一调 K 能解决的问题。Top-K 本质上是一个黑盒决策它只返回一列排序后的切片不告诉你“为什么是这些”“还缺哪部分证据”“哪些候选被拒了、为什么被拒”。最近讨论度很高的 Agentic Retrieval也有人直接叫 Agentic RAG之所以值得关注我认为核心不是“更智能”而是它把检索从一次不可解释的黑盒调用改造成了一条可观察、可调试、可控制的操作路径。这篇文章想聊的就是这个转变它到底替换了什么落地时怎么设计以及哪些场景其实不该用它。1. Top-K 不是“检索”而是一个把决策藏起来的黑盒1.1 Top-K 到底做了什么任何 Top-K 检索背后都是一个打分函数向量余弦相似度、BM25 词项权重或者两者的融合。它把所有切片按分数从高到低排好截断成前 K 个然后交给下游。这个机制对简单事实查询足够好用因为它隐含了一个假设查询意图是单一的相关文档和查询在语义空间里靠得足够近。但真实业务查询很少这么听话。用户问的是“发票金额和合同不一致验收前找谁处理”它包含至少三层意图一是“金额不一致”的判断标准二是“验收前”这个时间约束三是“找哪个部门、走什么流程”的处理路径。这三层信息很可能分散在不同文档里任何单一相似度排序都很难同时把它们顶到最前面。更麻烦的是很多关键流程文档因为措辞和查询长得不太像比如文档里写的是“结算差异”而不是“不一致”会排在很后面直接掉出候选区。1.2 黑盒的代价先说最直接的三个代价。第一你无法判断“召回是否足够”。Top-K 只给出排序结果不给出“这些切片是否覆盖了回答这个问题所需的全部证据”。下游大模型不会主动告诉你“我漏了关键文档”它只会用现有材料编一个听起来合理的答案。这就是知识库问答幻觉的常见来源之一不是模型在乱编而是检索把关键证据丢了模型只能说些“正确的废话”。第二调试手段极其有限。检索结果不对时你能做什么换 embedding 模型、调 K、调相似度阈值、加 metadata 过滤。这些都是在黑盒外面打转因为你无法回答“到底是哪一步把关键证据挡在门外”。你只能做实验然后祈祷整体效果变好。第三业务规则没法精细注入。想表达“草稿合同不能作为依据”“只看最新生效版本”“这个流程只适用于金额超过五万的场景”在纯向量检索里非常难写。metadata 过滤能解决一部分但它表达不了条件关系更没法在检索过程中根据中间结果动态调整。1.3 为什么“把 K 调大”不是出路K 调大召回率确实会提升但代价是精确率下降。更麻烦的是多出来的噪声切片会进大模型上下文挤占 attention甚至和正确切片产生事实冲突。你可以继续调 K但本质上是在用参数调整掩盖架构缺陷。真正的问题不是“K 没调对”而是“用一次全局排序解决所有查询的意图识别和证据组织”这件事本身就不成立。判断一个检索方案是否该换不是看它现在准不准而是看它出问题之后你能不能定位到具体原因。Top-K 在这点上天然吃亏。2. Agentic operations 替换的不是“检索”而是检索的决策方式2.1 一次 agentic 操作长什么样所谓操作就是把原来一次完成的“输入 query → 输出 K 个切片”拆成一组显式步骤。常见实践里这组步骤可以归纳成五个动作拆、查、滤、读、断。拆Decompose把用户问题拆成需要分别检索的子问题。查Search每个子问题选择适合的索引和检索方法返回候选切片。滤Filter用业务规则、metadata、时间范围、版本状态过滤候选。读Read阅读候选切片验证它是否真的回答了子问题。断Decide汇总验证结果决定终止、补搜还是承认找不到。注意“拆、查、滤、读、断”每一步都是离散操作都有输入、输出和判断理由。这和 Top-K 有本质区别Top-K 是“一次排序”而 agentic 操作是“一条流水线”。流水线的每一环都可以单独拆下来看也可以单独换掉。2.2 每个操作都可以被记录、被检查、被单独修改这是可解释性的真正来源。在大模型应用里我们通常没法让模型解释内部推理但我们可以让系统把决策过程变成结构化日志。例如“滤”这一步可以记成这样{ op: filter, sub_query: 发票金额不一致处理流程, input_ids: [doc_112, doc_78, doc_203], output_ids: [doc_78], rejected: { doc_112: draft_version, doc_203: policy_not_effective } }当用户投诉回答错误时你不需要猜只要回放这段日志就能看到“doc_112 因为版本是草稿被过滤掉”这个具体判断。如果 doc_112 其实应该保留你只需要修正这条规则或者改掉 doc_112 的 metadata而不是重新调一遍整个检索系统。单步可修改意味着系统从“调参优化”变成了“代码级维护”。2.3 可解释性来自流程结构而不是模型透明这里要澄清一个常见误解Agentic retrieval 背后的大模型本身仍然是一个黑盒。拆解子问题、验证切片是否相关这些动作都是模型调用我们并不知道模型内部怎么推理。但这不影响整体可解释性。可解释性不要求每一步都透明只要求在流程层面我们能看见“系统做了什么、依据什么、放弃了什么”。这就像你可以调试一个由复杂函数组成的流水线不需要读透每个函数的源码只要每个函数有清晰的输入输出契约和日志你就能定位问题出在哪一环。3. 落地路径怎么把 Top-K 改造成可解释的操作链3.1 先判断问题类型别为所有查询上操作链不是所有查询都值得走 agentic 流程。我建议先做一次问题分类如果查询是单意图、单文档能回答的事实问题一次 Top-K 就够成本低、延迟短。如果查询是多意图、多约束、需要组合多份证据或者回答结果必须能溯源才值得切换到 agentic 检索。一个简单的判断方法把一条 query 交给五个不同的人如果他们回答时需要查看的材料不一样、且需要互相交叉确认那这条 query 就属于复杂检索值得走操作链。3.2 把流程拆成“最小可观察操作”Agentic 检索需要维护的状态并不多我一般只保留四类子问题列表每个子问题都独立可检索。候选集合每个子问题的原始召回结果。证据列表通过验证、可以支撑回答的切片。终止状态成功 / 部分成功 / 失败。每个操作的目标是改变其中一个状态并留下日志。比如“查”改变候选集合“滤”和“读”改变证据列表“断”改变终止状态。如果你发现某个操作既改变状态又不留日志那它就是黑盒残留要补日志。3.3 给每个操作加上日志、断言和回退实际落地时我一般给每个操作配置三样东西日志输入、输出、关键选择理由结构化保存。断言检查输出是否合理比如“子问题不能为空”“召回不能为空”“证据列表不能为空”。断言失败要触发回退而不是继续往下走。回退定义失败后的动作——是改写子问题重新检索还是放宽过滤条件还是承认无法回答。这三点是把“能跑”变成“可维护”的关键。没有断言和回退的操作链只是把一个大黑盒换成了好几个串联起来的小黑盒。3.4 一个最小概念示例下面是一段概念性代码用来展示整体结构不是某个具体框架的完整实现# 概念示例把 Top-K 黑盒检索替换成可观察的操作链路 def decompose(query): sub_queries llm_extract_sub_queries(query) assert len(sub_queries) 0, 子问题为空停止流程 log_op(decompose, {query: query, sub_queries: sub_queries}) return sub_queries def search(sub_query, index, top_k10, metadata_filterNone): candidates vector_search(sub_query, indexindex, top_ktop_k, filtermetadata_filter) log_op(search, {query: sub_query, index: index, returned_ids: [c.id for c in candidates]}) return candidates def filter_candidates(candidates, rules): kept, rejected apply_business_rules(candidates, rules) log_op(filter, {kept_ids: [c.id for c in kept], rejected: {c.id: reason for c, reason in rejected}}) return kept def verify(candidates, sub_query): evidence, failed verify_by_reading(candidates, sub_query) log_op(verify, {sub_query: sub_query, evidence_ids: [e.id for e in evidence], failed_ids: [c.id for c in failed]}) return evidence def run(query): sub_queries decompose(query) evidence_map {} for sub in sub_queries: cands search(sub, indexdefault, top_k10) cands filter_candidates(cands, rulesBUSINESS_RULES) evidence verify(cands, sub) if not evidence: # 回退放宽过滤条件扩大候选池后再试一次 log_op(fallback, {sub_query: sub, reason: no_evidence}) cands search(sub, indexdefault, top_k20, metadata_filterNone) evidence verify(cands, sub) evidence_map[sub] evidence return build_answer_with_evidence(evidence_map)这段代码里search 的 top_k 从 5 调到 10 甚至 20 不是关键——关键是后面跟了 filter 和 verify它们会裁掉噪声只保留能通过验证的证据。K 在这里变成了“候选预算”而不是“输出预算”。这就是它和黑盒 Top-K 的核心区别之一。3.5 关键参数怎么定几个常见参数的经验值具体可以按你的场景调整参数常见初始值说明子问题数量3 到 5太多会成倍增加成本太少会漏意图每步子检索 top_k8 到 10候选放宽靠后面的 filter 和 verify 收敛回退轮数1 到 2超过两轮收益通常低于成本证据通过阈值至少 1 个切片通过 verify关键子问题没有证据通过时应该停止生成这里要强调没有统一的“正确答案”。参数要不要调整取决于你的文档质量、query 分布和业务容忍度。先按保守值跑一批样本观察日志再逐步收紧或放宽。建议先拿 50 到 100 条真实 query 做小样本验证不要一开始就全量上线。小样本阶段重点看两件事日志是否完整回退是否频繁。4. 真正复杂的不是多接几个工具而是状态、上下文与终止条件4.1 状态管理agent 下一步依据什么每次操作之间都要显式决定“保留什么、丢掉什么”。实践里很常见的错误是把整段对话历史或者所有中间检索结果一直堆在上下文里随着轮数增加成本飙升而且注意力被稀释。我一般让系统只保留三类东西子问题列表、已验证的证据列表、待调用操作队列。原始候选切片和中间判定理由进日志不长期留在主上下文。这样每一步的输入都短、目的都明确也更容易排查。4.2 上下文工程给模型看什么是检索系统的核心产出Agentic 操作链最终要做的是构造一个“高质量证据上下文”。这本质上是上下文工程的一部分决定把哪些证据送进最后一步生成、以什么顺序、附带哪些元信息。Top-K 的做法是把排序靠前的切片直接拼接操作链的做法是让每一步都参与选择最终只把验证过的证据交给生成模型。这也是“meta context engineering”这类概念想要解决的问题不是让模型更聪明而是让喂给模型的东西更可控、更可复用。当操作链跑通之后你会发现真正需要长期维护的不是某个模型而是上下文构造规则。4.3 终止条件什么时候该停下来这是 agentic retrieval 最容易被忽略的点。很多实现会一直检索、一直尝试最后要么越查越偏要么强行用不完整的证据生成回答。我会在“断”这一步明确三个结果成功所有子问题都能找到至少一个通过验证的证据可以生成回答。部分成功部分子问题有证据部分没有。生成时必须在对应部分明确标注“未找到充分证据”。失败核心子问题没有任何证据。这时候最有价值的输出是“当前知识库不足以回答这个问题”并附上检索尝试记录。敢于说“不知道”在知识库问答里往往是更专业的表现。强行生成一个看似完整、实则没有证据支撑的回答才是真正的风险。4.4 成本和延迟预算Agentic 检索的每一步都可能调用大模型多轮下来 token 消耗和延迟会成倍增长。我的建议是先给流程设硬上限——最多几轮、最多多少 token、单次检索最长时间。同时可以用较小的模型做拆解和路由把复杂验证和最终生成留给更强、更贵的模型。不要一上来就是“全流程大模型”。先跑通再衡量每一步值不值得用更贵的模型。5. 边界哪些场景其实不该用 agentic retrieval5.1 适合的场景复杂业务问答问题包含多个约束答案需要跨文档组合证据。需要审计和溯源的场景客服、合规、医疗、金融等领域回答出错要能回放“系统依据什么得出结论”。领域规则强的场景法律条款、产品规格、审批流程需要按业务规则排除无效版本或草稿。5.2 不适合的场景单意图事实查询例如“某个版本发布时间”“某个接口返回什么字段”一次 Top-K 足够。高并发低延迟接口拖一条多轮操作链上线上延迟和成本都不可控。数据质量很差、元数据混乱的库操作链救不了脏数据。检索前先做数据治理否则 filter 规则无从谈起。延迟要求小于一秒的交互场景需要单独设计异步任务或离线预计算方案。5.3 一个务实的中等方案如果不想全量替换可以先做两阶段先用 Top-K 快速检索加一个轻量评估步骤判断“当前召回是否足够回答这个问题”。如果足够直接生成如果不够再触发 agentic 操作链。这样大部分简单查询保持低延迟复杂查询才走完整流程。下面这个对比表可以帮你判断现有系统处在哪个阶段维度Top-K 黑盒检索Agentic 操作链检索决策方式一次相似度排序取前 K 个多步操作每步产生显式判断可观测性只有召回列表每一步有结构化日志和裁决理由调试方式换模型、调 K、调阈值定位故障步骤修复该步骤业务规则依赖 metadata 过滤表达粗糙可作为独立过滤/验证操作失败模式静默召回错误下游无法察觉通过验证步骤显式发现召回不足成本与延迟低单次向量查询高多轮模型调用和检索适用场景简单事实问答、高吞吐检索复杂问题、多条件约束、需要溯源6. 从黑盒变成白盒本质是可靠性问题6.1 调试范式变化Top-K 时代检索出问题你只能换模型、调 K、加过滤然后祈祷整体指标变好。Agentic 操作时代你可以按“路径 → 输入 → 检索 → 验证 → 终止”的顺序逐层排查先看路径翻开日志确认拆出来的子问题是什么每个子问题去哪个索引查了过滤掉了什么。再看输入子问题本身是否准确表达了用户意图上下文有没有在步骤之间丢失。再看检索召回是不是为空是不是查错了索引metadata 过滤是否把关键证据挡在门外。再看验证和终止验证器是否误杀了有效证据终止条件是不是在证据不足时仍强行输出。每一步都有明确方向而不是盲调。这就是白盒化的价值。6.2 操作序列可以沉淀成团队资产一套验证有效的“拆查滤读断”流程不只是代码更是一种领域知识。新人可以通过操作日志理解业务逻辑运营可以提出修改过滤规则的诉求技术可以把某条操作链固化为模板供不同业务复用。这个价值会随着时间累积而调参经验不会。6.3 长期趋势检索和推理正在融合当检索不再是一次排序而是一连串决策时它已经不只是“找材料”而是在做“问题分析和证据组织”。这也是 Agentic RAG 讨论度越来越高的原因。未来真正重要的已经不是“哪个模型更强”而是“如何设计一个可观察、可控制、可迭代的知识获取流程”。回到开头那个发票金额不一致的案例。如果用 agentic 操作链重写“拆”会先析出“验收规则”“财务政策”“上报流程”三个子问题“查”会在对应索引里分别检索“滤”会排除草稿和未生效版本“读”会确认切片是否真的提到了金额偏差处理“断”会发现流程文档缺失——系统要么补一次检索要么明确告诉你知识库里没有这个流程。更重要的是每一步都留了日志。查出问题时你不需要猜只需要回放。这大概就是“可解释的 agentic operations”真正的价值它不一定让知识库问答变得更聪明但它让系统变得可靠、可维护、可追溯。长期使用的系统最稀缺的从来不是单次效果而是出问题时你能快速定位到那一环。