大多数 RAG 与Agent 的检索逻辑，都会直接写在 workflow 的某个节点里，跟推理、记忆管理、工具调用并列。它的表现形式，通常是一段固定代码：要么调 dense retriever，要么调 BM25，要么写一个 if-else 切换。

这种做法在任务单一时跑得起来。但当一个Agent 既要回答事实问题、又要处理多跳推理、还要做科学声明验证时，就会出现一个问题：没有一个机制来判断这次查询应该用哪种检索方式。

一篇来自澳门理工大学一篇主题为Experience-RAG Skill的论文提出了一个思路：把检索策略选择从 Agent 的上层逻辑里抽出来，封装成一个可复用的 skill。

论文地址：https://arxiv.org/pdf/2605.03989

那么，它具体的怎么做的，在生产中，可以给我们什么启发？

01 检索逻辑写在 pipeline 里的三个工程问题

先看当前的常见做法。

一个典型的 RAG 或者Agent，检索相关的代码大概长这样：query 进来，经过 embedding，发给一个 retriever，拿回结果，塞进 context，交给 LLM 生成。如果后来发现 dense 不够用，就加一路 BM25，写一个 if-else 或者做一次 hybrid search。再后来，不同任务需要不同检索方式，就继续加 if-else。

这种做法会出现三个问题。

第一个是不可复用。检索策略的选择逻辑嵌在特定 workflow 的代码里，换一个任务场景就要重新写。一个项目里积累的检索经验，没有办法被另一个项目直接调用。

第二个是不可观测。策略选择发生在一段 if-else 里，没有结构化的记录。系统跑了一段时间之后，你很难回答过去一千次查询里策略选择对了多少次，哪些类型的查询被路由到了错误的检索器。

第三个是不可演进。因为策略逻辑和 workflow 代码耦合在一起，想改进路由规则就要改 pipeline 代码。没有一个独立的机制来积累什么场景用什么策略效果更好这类经验。

这三个问题在任务单一时不明显。因为一个只做事实问答的 Agent，固定用 dense retriever 就够了。但一旦 Agent 面对的任务类型开始多样化：同一个系统既要回答 Milvus 的默认一致性级别是什么这种直接事实问题，又要处理从 A 论文的方法出发结合 B 论文的数据判断 C 场景是否适用这种多跳推理，还要验证论文声称 X 方法在 Y 数据集上优于 Z 这种科学声明，一条写死在pipeline 里的检索链路根本覆盖不了。

02 检索策略选择和普通 tool-use 的区别

很多人会把检索策略选择，等同于ReAct、Toolformer、HuggingGPT这样的tool-use？

但这里面的一个区别在于：工具调用的前置条件是知道用什么，而检索策略解决的，正是用什么、怎么用的问题。

比如，调用一个 API、执行一段代码、查一个数据库，这些工具的输入输出是明确的。但检索策略选择涉及的判断更复杂：当前查询是什么类型？上下文有多长？问题的复杂度如何？文档结构是扁平的还是层次化的？这些信号需要被分析，然后映射到一个检索方式上。

更关键的是，这种映射不是静态的。同一种类型的查询，在不同文档集、不同领域下，最优策略可能不同。这就要求系统能积累经验，记录过去在类似场景下各个检索器的表现如何，哪个策略在什么条件下领先。

普通的 tool-use 不需要这种经验积累机制。你调一个天气 API，不需要记住上次调的时候另一个天气 API 更准。但检索策略选择需要。

03 Experience-RAG Skill 的封装思路

这篇论文把检索策略的制定，拆成了六个模块，组成了一个 skill 层，放在 Agent 和检索器池之间。

统一接口：Agent 只和 skill interface 交互。它不需要知道底层有几个检索器、当前用的是哪一个。调用方看到的就是一个接口：给一个 query，拿回一个结构化的证据包。

场景分析：query 进来后，scene analyzer 会从查询内容、对话历史和任务元数据中提取一组结构化特征，包括任务类型、领域、上下文长度、问题复杂度、查询风格、文档结构。这些特征不是交给 LLM 自由判断，而是被显式提取并记录。

经验记忆：这是这个设计里最有意思的部分。经验记忆存储的不只是这个场景应该用什么策略这个标签，而是一条完整记录：

experience = (scene_features, score_vector, best_strategy, best_margin)

score_vector 记录了各个检索器在这个场景下的实际表现分数，best_margin 记录了最优策略相对次优策略的领先幅度。这种设计意味着系统不只知道用什么，还知道各个选项差多少。当 margin 很小时，说明策略选择的敏感度不高；当 margin 很大时，说明选错策略的代价明显。

策略路由：根据场景特征和经验记忆，选择一个检索策略。当前版本用的是规则路由：direct 类任务走 dense，multi-hop 和 scientific 类任务走 hybrid RRF。

检索器池：承载实际检索的组件。当前版本包含 BM25、Rewrite-BM25、Dense、Hybrid RRF 四种。

结果打包：把检索结果封装成结构化的证据对象返回给 Agent，而不是直接丢一堆文本片段。

整个设计的核心判断是：检索策略选择这件事，复杂到值得被封装成一个独立层，但又稳定到可以被复用为一个 skill。Agent 不需要每次都从头推理我该用什么检索方式，而是调用一个已经积累了经验的 skill。

04 实验：编排在混合负载下的价值

论文在三个公开检索 benchmark 上做了评估：BeIR/nq（事实问答）、BeIR/hotpotqa（多跳推理）、BeIR/scifact（科学声明验证），每个数据集取 120 个查询。

先看固定策略的表现：

Experience-RAG Skill 的 nDCG @10 是 0.8924,MRR @10 是 0.9006。

这组数字不是为了证明检索器更强，更多在于论证编排本身产生了增益。在逐数据集层面，Experience-RAG Skill 在每个数据集上并没有超过该数据集上的最优固定策略，它只是在每个数据集上都选了对的那个。它的优势体现在混合负载上：当三种不同类型的任务同时存在时，任何一种固定策略都会在某些任务类型上丢分，而编排层避免了这种损失。

和现代 baseline 的对比也值得看。Adaptive-RAG 的 nDCG @10 是 0.8934，比 Experience-RAG Skill 的 0.8924 略高。HyDE 是 0.8326,LongRAG-style 是 0.7095,RAPTOR-style 是 0.6841。

这组对比的意义在于：Experience-RAG Skill 和 Adaptive-RAG 的差距很小，只有 0.001，但两者的设计思路不同。Adaptive-RAG 侧重根据问题复杂度选策略，Experience-RAG Skill 侧重把策略选择封装成可复用的 Agent skill，强调接口统一和经验积累。在检索性能接近的前提下，后者的工程价值在于系统边界更清晰。

需要明确的是，这个实验有几个局限。每个数据集只用了 120 个查询和采样语料，不是全量评估。论文自己也承认，当前版本更适合作为 short paper 或 preprint，而不是完整的系统论文。把这些数字当成方向性参考是合理的，但不宜直接外推到生产规模。

05 规则路由为什么比学习路由更好

论文里有一个反直觉的结果：简单的规则路由（nDCG @10 = 0.8924）比训练出来的分类器（0.8778）和回归器（0.8627）都好。

这个结果在当前阶段是可以解释的。

学习路由需要足够的训练数据，也就是经验记忆里要积累足够多的场景、策略、效果记录。当经验记忆规模有限时，学习路由容易过拟合或欠拟合。规则路由虽然粗糙，但它的映射关系是确定的，不会在小样本下产生不稳定的行为。

从工程角度看，规则路由还有两个现实优势：可解释和可调试。当检索结果不符合预期时，你可以直接查看这个查询被分到了哪个类型、对应了哪条规则，修复链路清晰。学习路由的决策过程更不透明，出了问题不容易定位。

但这不意味着规则路由是终局。它的上限取决于规则覆盖的场景数量和规则之间的区分度。当任务类型持续增加、场景特征变得更细粒度时，手写规则的维护成本会快速上升。这正是经验记忆的设计留了余地的地方，score_vector 和 margin 的记录，本身就是为了未来支持学习路由的升级。

合理的路径可能是：冷启动用规则路由，经验积累到一定规模后，再尝试用学习路由替换或辅助规则路由。论文当前的结果说明的是现在还不到那个规模，而不是学习路由不可行。

06 检索器池背后需要什么基础设施

编排层的设计再清晰，最后还是要落到一个问题上：底层检索器层用什么搞定？

论文里的检索器池包含 BM25、Dense、Hybrid RRF 三类检索模式。编排层切换策略时，只是改一个路由标签。但对底层基础设施来说，这意味着同一批文档要同时支持多种检索方式的独立运行和按需融合。

事实上，很多 RAG 系统在初期建设，需要多种检索时，走的都是分体架构：dense embedding 存向量数据库，BM25 存 Elasticsearch，如果还要试不同 embedding 模型（比如通用 embedding 和领域 embedding），就再开一个 collection 或一个库。

这种架构的问题性能只是其次，更大的问题出在同步。同一份文档写进两三套系统，索引更新节奏不一定一致，删除和更新操作要多方协调。编排层说这次用 dense，它从向量库拿结果；说这次用 hybrid，它要同时从向量库和搜索引擎拿结果再融合。切换策略的成本不只是改一个参数，而是要确认多套系统的数据状态一致。

对 Experience-RAG Skill 来说，这个同步成本还有一个更隐蔽的影响：经验记忆的准确性。编排层需要记录这个场景下 dense 得了多少分、hybrid 得了多少分来积累经验。如果两套系统的索引更新不同步，同一个 query 在不同系统里看到的文档集不一样，score vector 的对比就不公平，经验记忆会被噪声污染。

更不用说，在企业场景里，这往往意味着一个数据被多次存储、企业需要维护多套系统，整体的硬件与人力投入开销过大。

市场需要的，是一个能在一个系统中解决以上所有检索细分需求的基础设施。

07 Milvus 应付复杂检索需求有什么优势

Milvus 解决这个问题的方式，不是支持 BM25 这么简单，而是一个更底层的设计：一个 collection 可以同时支持多个向量字段，每个字段类型独立、索引独立、搜索独立。

从 Milvus 2.4 开始，proxy.maxVectorFieldNum 参数控制单个 collection 里的向量字段上限，默认值是 4。也就是说，一个 collection 在不改配置的情况下，就可以放 4 个不同的向量字段。

这 4 个字段可以是完全不同的类型。Milvus 当前支持 6 种向量类型：FloatVector、BinaryVector、Float16Vector、BFloat16Vector、SparseVector、Int8Vector。它们可以在同一个 collection 里混用。

对检索器池来说，这意味着什么？

假设编排层需要在三种检索模式之间切换：通用 embedding 的 dense 检索、领域微调 embedding 的 dense 检索、BM25 的稀疏检索。在分体架构下，这是三套系统或至少三个 collection。在 Milvus 的多向量字段设计下，这是同一个 collection 里的三个字段：