推荐语
别再让 if-else 限制你的智能体！澳门理工大学新研究将检索策略封装为可复用的“技能”，解决了复杂任务下的检索难题。核心内容：1. 当前固定检索策略在复杂任务中的三大工程瓶颈2. 检索策略选择与普通工具调用的本质区别3. “检索技能”封装的核心思路与生产实践启发
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
大多数 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 里的三个字段：
collection: doc_store├── general_emb : FloatVector(dim=768) ├── domain_emb : FloatVector(dim=384) ├── bm25_sparse : SparseVector ├── doc_id : Int64 (primary key)├── text : VarChar├── task_type : VarChar └── domain : VarChar
三种向量，同一份文档，一次写入。不存在系统间的同步窗口。
更关键的是，每个向量字段的索引是独立构建的。general_emb 可以建 HNSW 优先召回质量，domain_emb 可以建 IVF 优先吞吐，bm25_sparse 建 Sparse Inverted Index。索引类型的选择和向量字段绑定，而不是和 collection 绑定。这意味着你可以为每种检索模式选择最合适的索引策略，而不是用一种索引类型硬扛所有场景。08
编排层切换策略时，到底改的是什么
建立在Milvus丰富的检索能力基础上，编排层判断这次查询是 direct 类任务、应该用通用 dense 检索时，发出的请求是：策略 A：直接事实问答，走通用 embedding
result = client.search( collection_name='doc_store', anns_field=‘general_emb’, data=[query_general_emb], limit=10,)
判断这次是科学验证类任务、应该用领域 embedding 时：策略 B：领域验证，走领域微调 embedding
result = client.search( collection_name='doc_store', anns_field=‘domain_emb’, data=[query_domain_emb], limit=10,)
判断这次是多跳推理、需要 hybrid 时，用 HybridSearch 在一次请求里同时查多个向量字段并融合：策略 C：多跳推理，同时走 dense + sparse，融合排序
result = client.hybrid_search( collection_name='doc_store', reqs=[ AnnRequest('general_emb', 10, query_general_emb), AnnRequest('bm25_sparse', 10, query_sparse), ], ranker=WeightedRanker(0.7, 0.3), limit=10,)
三种策略，同一个 collection，切换的只是 AnnRequest 里的目标字段名。不需要切换连接、不需要跨系统协调、不需要确认另一套索引是否更新完毕。而且，每个 AnnRequest 可以独立携带自己的过滤条件、groupBy 设置和 topK 值。这意味着编排层在组合策略时有很大的灵活度，比如 dense 路用 task_type 过滤，sparse 路不过滤，两路结果各取 10 条再融合排前 5。这些组合逻辑都在一次请求内完成。09
对经验记忆的意义
回到 Experience-RAG Skill 的经验积累场景。编排层需要对比同一个 query 在不同策略下的表现来更新 score vector。在多向量字段架构下，因为所有策略都作用于同一份文档数据和同一套一致性保证，不同策略的 score 之间是严格可比的。dense 在这个场景下 nDCG 比 sparse 高 0.12 这个判断，不会被数据同步延迟或索引状态不一致干扰。这是经验记忆质量的基础。如果 score vector 本身不可信，后面所有的路由决策，无论是规则路由还是未来的学习路由，都建立在噪声之上。写在最后
这篇论文的思路不是所有 RAG Agent 都需要的。如果你的 Agent 只处理一种任务类型，比如只做知识库问答或者只做代码搜索，固定一种检索策略通常已经足够。引入编排层反而增加了一层间接性和维护成本。
- Agent 面对的任务类型是异构的。同一个系统里既有事实查询、又有多跳推理、又有验证类任务。不同任务类型对检索器的偏好不同，固定策略在混合负载下一定会在某些任务上丢分。
- 检索策略的选择需要积累经验。不是写一次 if-else 就能覆盖所有情况，而是需要根据历史表现持续调整。如果规则每隔几周就要人工改一次，说明这件事已经值得系统化。
- 多个项目或多个 Agent 之间需要复用检索经验。一个项目里摸索出来的科学论文验证类查询用 hybrid 效果更好，应该能被另一个项目直接复用，而不是重新发现。
- 任务类型单一且稳定。一条检索链路已经够用，加编排层是过度设计。
- 数据规模很小、查询量很低。经验记忆积累不起来，规则路由和硬编码 if-else 没有实质区别。
- 检索质量的瓶颈不在策略选择，而在检索器本身。如果 dense retriever 的 embedding 质量不够，换成 hybrid 也救不了。这时候应该先解决 embedding 和数据质量问题。
所以，决策框架可以简化成一个判断：你的 Agent 是不是已经到了在不同任务上需要不同检索方式、而且这种需求在持续增长的阶段。如果是，检索策略选择就值得从 pipeline 代码里抽出来，变成一个独立的、可复用的、能积累经验的 skill。如果不是，一段写得清楚的 if-else 可能反而更好维护。
粤ICP备14082021号
免费POC，
零成本试错
