当检索策略变成if-else：Agent与RAG面临的工程困境

在当前的RAG与Agent开发中，检索逻辑通常被直接嵌入工作流的某个节点，与推理、记忆管理、工具调用并列。常见的实现方式是一段固定代码：要么调用dense retriever，要么调用BM25，要么通过if-else语句在不同检索方式间切换。这种做法在任务单一的场景下确实能够正常运行，但当Agent需要同时处理事实问答、多跳推理、科学声明验证等多种任务类型时，问题便显现出来：系统缺乏一种机制来判断当前查询应该使用哪种检索方式。

检索策略选择与普通工具调用的本质区别

这种if-else式的检索策略实现方式存在三个显著的工程问题。首先是不可复用：检索策略的选择逻辑嵌入在特定工作流的代码中，换一个任务场景就需要重新编写，一个项目积累的检索经验无法被另一个项目直接调用。其次是不可观测：策略选择发生在一段if-else代码中，缺乏结构化记录，系统运行一段时间后很难回答过去一千次查询中策略选择对了多少次，哪些类型的查询被错误路由。第三是不可演进：由于策略逻辑与工作流代码耦合，想改进路由规则就需要修改整个pipeline，缺乏独立的机制来积累“什么场景用什么策略效果更好”的经验。

检索技能封装的核心设计

有人可能会将检索策略选择等同于ReAct、Toolformer、HuggingGPT等框架中的工具调用。但两者存在本质区别：工具调用的前置条件是已知使用哪个工具，而检索策略选择解决的正是“用什么工具、怎么用”的问题。例如调用API、执行代码、查询数据库等工具的输入输出是明确的。但检索策略选择涉及更复杂的判断：当前查询是什么类型？上下文有多长？问题的复杂度如何？文档结构是扁平的还是层次化的？更关键的是，这种映射并非静态的。同一种类型的查询在不同文档集、不同领域下，最优策略可能完全不同，这就要求系统能够积累经验，记录过去在类似场景下各检索器的表现。

实验结果与工程启示

澳门理工大学的研究论文提出了将检索策略封装为可复用技能的设计思路。该方案将检索策略的制定拆分为六个模块，形成一个独立的技能层，位于Agent和检索器池之间。统一接口层让Agent只需与技能接口交互，无需了解底层有几个检索器。场景分析模块从查询内容、对话历史和任务元数据中提取结构化特征，包括任务类型、领域、上下文长度、问题复杂度等。经验记忆模块存储的不仅是场景与策略的映射，还包括各检索器在该场景下的实际表现分数以及最优策略相对次优策略的领先幅度，这种设计使系统不仅知道用什么策略，还了解各选项之间的差距。

底层基础设施的支撑价值

论文在三个公开检索基准数据集上的评估结果显示，该方案在混合负载任务下展现出明显优势。当三种不同类型的任务同时存在时，任何单一固定策略都会在某些任务上丢分，而编排层有效避免了这种损失。有趣的是，简单的规则路由表现甚至优于训练出的分类器和回归器，这是因为学习路由需要足够的训练数据，在经验记忆规模有限时容易过拟合或欠拟合。不过规则路由也有其局限性，当任务类型持续增加、场景特征变得更细粒度时，手写规则的维护成本会快速上升。经验记忆的设计正是为未来支持学习路由升级留出空间，合理的路径可能是冷启动用规则路由，经验积累到一定规模后再引入学习路由。

如有侵权，请联系删除。