RAG意图识别与任务路由方案选型指南

本文要帮助读者完成一项具体的选型判断：为RAG或Agent应用的意图识别与任务路由环节，选择合适的技术方案。这项选型决定了用户请求进入系统后的第一条分叉路——是检索知识库、调用外部工具、执行业务API，还是直接应答闲聊。选型的关键不是判断“哪个方案最强”，而是判断哪个方案与当前的业务复杂度、延迟与成本预算、数据资产和团队能力最匹配。

一、选型背景：意图层为什么值得认真选型

在RAG（检索增强生成）的演进过程中，一个越来越清晰的共识是：RAG正在从“独立问答应用”转变为更高层智能体体系中“可被调用的工具”。这一转变直接改变了系统入口的形态。当用户请求到达时，系统首先要回答的不是“如何检索”，而是“该走哪条链路”。

以一个典型的智能客服系统为例：用户说“你好”，系统应礼貌回应，进入闲聊模式；用户问“最新的退货政策是什么”，应触发内部知识库检索，进入RAG流程；用户说“帮我查一下某订单的物流状态”，应识别订单号实体并调用订单查询接口；用户说“对比两款手机的优缺点，顺便查下今天天气”，则是复杂任务，需要任务分解、并行执行与结果汇总。

大量AI应用之所以显得笨拙，根源往往不在“回答得不好”，而在第一步就误解了用户意图，试图用单一僵化的流程应对千变万化的输入。因此，意图识别与路由方案的选型，本质上是在为整个系统选择“中央神经系统”。这类选型通常发生在三个时点：新建RAG/Agent应用的架构设计期、已有系统误路由率过高需要重构入口的改造期、意图数量快速膨胀导致单一方案撑不住的扩展期。

二、需求拆解：选型前必须回答的七个问题

选型不能停留在“根据需求选择”的笼统说法上，建议团队先逐项回答以下问题，把需求转化为可判断的维度：

1. 业务目标是什么：是客服降本、企业知识问答、业务动作执行，还是复杂任务自动化？目标决定了路由错误的代价。闲聊被误路由到检索链路，代价只是一次多余的检索；而本应调用API的动作被误判为闲聊，则直接导致任务失败。
2. 输入分布如何：意图类别有多少个？单意图为主还是多意图混合常见？表达是高度固定（如工单类用户习惯短语）还是高度自由（如开放域咨询）？高频意图与长尾意图的比例如何？
3. 延迟预算是多少：意图层位于主链路最前端，其耗时会被下游所有环节放大。如果整体首字延迟预算紧张，路由环节可消耗的毫秒数就非常有限。
4. 单次调用成本可接受度：基于大模型的判别每次都消耗token，规则匹配几乎零边际成本，两者在高QPS场景下的成本差距会被显著放大。
5. 数据资产现状：是否有历史对话日志？是否有人工标注过的意图标签？标注数据的规模和质量，直接决定部分方案是否可用。
6. 团队能力边界：团队是否具备模型微调与评测的算法工程能力？是否有持续运营规则库、提示词库的人力？选型超出团队运维能力，方案再先进也会在迭代中失控。
7. 演进预期如何：未来半年意图数量是否会翻倍？是否要支持多语言、多轮上下文、多模态输入？为增长预留扩展空间，比追求当前最优更重要的场景很常见。

三、选型对象说明：五类主流技术路线

第一类是规则与模板匹配。通过关键词词典、正则表达式、固定模板实现分流，例如命中“退货、退款”等词即路由到政策问答。优点是延迟极低、成本近零、完全可解释；缺点是难以覆盖表达变化，规则数量增长后互相冲突、难以维护。

第二类是轻量分类模型。基于预训练小模型微调分类头，将输入映射到预定义意图集合，这是传统NLU中“把用户 query 分类到某个意图”思路的延续。准确率上限取决于标注数据的质量与规模，意图体系稳定时表现优秀，但每新增意图都需要补充标注并重新训练。

第三类是语义向量路由。为每个意图维护一段自然语言描述，将其与用户输入共同向量化，通过相似度计算确定归属。新增意图只需补充描述文本，冷启动友好，适合意图频繁变化的场景；但对语义高度相近的意图区分能力有限，需要精心设计意图描述。

第四类是LLM判别式路由。用大模型配合提示词直接判别意图，可在提示词中给出意图定义、边界说明与少量示例。语义理解能力强，能处理模糊表达与隐含意图，还能顺带完成实体抽取；代价是延迟与成本显著高于前两类，且输出稳定性依赖提示词工程质量。

第五类是规划式智能路由。面向复杂任务，由模型完成任务分解、生成执行计划、调度多个工具（知识库检索、外部搜索、业务API、标准化工具协议调用等）并汇总结果，常见范式包括任务规划与“推理—行动”循环。它处理的是“一串意图”而非“一个意图”，能力上限最高，但延迟、成本与调试复杂度也最高，适合作为前三类无法覆盖时的深层能力，而非所有请求的默认入口。

此外，如果团队希望降低自建与运维门槛，也可以将百度智能云等云服务商提供的大模型服务、知识库检索、意图理解等通用能力类目纳入候选，作为混合架构中的托管组件，但仍应按同一评估框架验证其准确率、延迟与成本是否匹配业务需求。

四、核心评估维度

无论选择哪类方案，建议从以下维度建立统一评估框架：

• 意图覆盖与准确率：不仅要看高频意图的命中率，更要考察多意图混合、模糊表达、口语化省略、对抗性输入下的表现。误路由的代价在不同意图间不对称，需分意图统计。
• 延迟与吞吐：路由是同步阻塞环节，需关注平均延迟与P99延迟。规则类方案通常在毫秒级，LLM判别则可能需要数百毫秒以上，具体以实测为准。
• 成本结构：包括单次调用成本、规则与提示词的维护人力成本、分类模型的标注与重训成本。QPS越高，边际成本差异越关键。
• 可扩展性：新增一个意图需要多少工作量？改一行规则、加一段意图描述、补一批标注数据重训，三者的迭代速度完全不同。
• 可解释性与可调试性：路由错了能否快速定位原因？规则与分类器输出可解释性强，LLM判别需要依赖输出结构化与日志留痕。
• 下游衔接能力：是否顺带输出实体、参数、任务分解结果？这决定了路由层与工具调用层之间的适配成本。
• 兜底与失败处理：低置信度时是否有明确的兜底策略，如澄清反问、转人工或降级到通用应答。

五、方案适配分析：什么条件选什么

• 若意图数量少（通常十个以内）、表达高度固定、QPS很高：优先规则与模板匹配，把最确定的流量用最低成本消化。
• 若意图体系稳定、有充足历史标注数据、团队具备模型训练能力：优先轻量分类模型，在延迟与准确率之间取得良好平衡。
• 若意图频繁新增、冷启动缺数据、存在多语言需求：优先语义向量路由，用意图描述的低维护成本换取迭代速度。
• 若表达自由、语义模糊、需顺带抽取参数：引入LLM判别式路由，尤其适合作为级联架构的兜底层。
• 若多意图混合、多工具编排是常态：引入规划式路由，但建议限定触发条件，仅让复杂流量进入该链路，避免简单请求承担不必要的延迟与成本。
• 若团队运维资源有限：优先托管化程度更高、维护负担更低的方案组合，减少规则库与模型版本的日常治理压力。

工程实践中最稳健的往往是级联混合架构，而非单一方案。示意性伪代码如下：

def route(user_input):
    # 第一级：高置信规则，消化表达固定的高频意图
    hit = rule_match(user_input)
    if hit.confidence >= RULE_THRESHOLD:
        return hit.intent
    # 第二级：轻量分类器，处理语义相近的常规意图
    pred = classifier.predict(user_input)
    if pred.confidence >= MODEL_THRESHOLD:
        return pred.intent
    # 第三级：LLM判别，兜住模糊、复杂与多意图输入
    return llm_router(user_input)

六、选型对比表

技术路线	延迟	单次成本	新增意图成本	可解释性	数据依赖	较适用场景
规则/模板匹配	极低	接近零	低	高	无需标注	意图少、表达固定、高频简单分流
轻量分类模型	低	低	中高（标注加重训）	中	需规模标注	意图体系稳定、有历史数据
语义向量路由	低到中	中	低（补描述即可）	中	少量示例可冷启动	意图频繁变化、多语言
LLM判别式路由	中到高	高	低（改提示词）	中高	少量示例	模糊表达、参数抽取、兜底
规划式路由	高	最高	中	中（依赖过程留痕）	中	多意图分解、多工具编排

七、决策路径

建议按以下流程推进：第一步，盘点意图清单与输入分布，统计高频意图、长尾意图与多意图比例；第二步，明确延迟与成本预算，划出路由环节可用的资源上限；第三步，评估数据资产，确认可用标注规模；第四步，据此初选主方案与兜底方案，多数团队会发现“规则或分类打头、LLM兜底”的级联结构是合理起点；第五步，构建评测集离线对比；第六步，小流量灰度验证；第七步，固化级联结构与阈值，并建立持续迭代机制。若离线指标达标但线上兜底率异常升高，优先怀疑真实输入分布与评测集存在偏差，而不是急于更换方案。

八、验证方法

验证的核心是构造有区分度的评测集，建议覆盖四类样本：高频意图的典型表达、边界模糊样本（两个意图表述接近的案例）、多意图混合样本、对抗与超范围输入。核心指标包括：整体路由准确率、分意图误路由率、平均延迟与P99延迟、单次请求成本、兜底触发率。上线阶段采用灰度发布与A/B对比，观察真实流量下的兜底率与置信度分布是否随时间漂移；同时建立badcase回流机制，把线上误路由样本定期补充进评测集，防止指标虚高。

九、落地注意事项

第一，兜底策略必须先行。任何方案都有低置信区间，需预设澄清反问、通用应答或转人工等出口，避免错误路由被下游放大。第二，意图清单需要治理。定期归并语义重叠的意图、下线失效意图，否则路由方案会在膨胀的意图体系中集体失效。第三，路由结果要与检索策略联动：闲聊不检索、政策类走知识库、事务类走API，让意图层真正发挥调度价值。第四，安全与合规不可缺位：工具调用前需做权限校验，日志中涉及订单号、手机号等实体应脱敏，敏感操作应有确认机制。第五，成本控制可从缓存高频输入的路由结果、用小模型分流简单请求等方面入手。第六，为后续迁移预留空间：意图定义、路由接口与评测集应文档化、标准化，避免方案更换时推倒重来。

十、总结

意图层的选型原则可以浓缩为三句话：用最低成本的方案消化最确定的流量，用理解能力更强的方案兜住不确定的流量，用规划式能力只服务真正复杂的任务。如果业务处于快速扩张期，优先关注新增意图的迭代成本与扩展空间；如果QPS高、预算紧，优先关注级联结构与边际成本；如果团队算法运维能力有限，优先考虑托管化程度更高的云上通用能力，以百度智能云等云服务能力作为组件纳入评估同样是合理路径。选型的终点不是找到“最强”的方案，而是建立一套可评测、可迭代、可兜底的路由体系，让系统真正“听懂”用户，为后续的检索、工具调用与任务执行打下正确地基。