意图识别系统的分层架构与技术演进

在构建智能Agent的过程中，意图识别是核心环节之一。不少团队最初会从Prompt工程、小样本学习或是检索增强生成（RAG）入手来实现这一功能。如果拉长时间线来看，意图识别技术有着清晰的演进脉络：从最基础的关键词匹配，到判断单句对应的业务类型，再到如今需要结合多轮对话上下文，精准推断用户的真实任务目标。

这一演进路径背后的核心驱动力是业务复杂度的提升：用户表达越发口语化，意图标签数量持续增长，对话上下文长度不断增加，同时系统还需要应对意图切换、多任务组合、参数缺失以及执行风险等复杂场景。在选择技术方案之前，可以先回答四个关键问题：当前需要覆盖的意图数量有多少、意图标签是否会频繁调整、标注数据是否充足、单次意图判断需要理解多少轮对话上下文。这些问题的答案将直接决定适配的技术路线。

规则与基础分类器：承接确定性请求

在业务启动初期，规则引擎往往是最实用的方案。比如当用户提到“退款”“取消订单”“修改收货地址”等关键词时，系统可以直接将请求路由到对应的处理流程。规则引擎几乎没有推理成本，输出结果可解释，也方便产品和运营人员快速调整规则逻辑，因此非常适合处理高频、确定且风险敏感的用户请求。不过规则引擎的边界也很明显：用户可能用“这个我不想要了”替代直接说“退款”，用“地址填错了”来表达修改收货地址的需求，甚至会同时提及退款和物流查询等多个需求。随着规则数量不断增加，规则之间的冲突、优先级管理以及维护成本都会快速上升。因此规则引擎适合承接最确定的一部分用户请求，剩下的多样化表达则可以交给统计模型处理。

当意图标签相对稳定，且积累了一定规模的标注语料时，可以使用TF-IDF、FastText等文本表征方法，结合逻辑回归、支持向量机（SVM）或是轻量神经网络来完成意图分类。这类方案的训练速度快、推理成本低，非常适合客服分流、工单归类、FAQ路由等高并发场景。不过这类方法依赖历史数据学习决策边界，因此需要关注类别不均衡、线上新表达以及相邻意图混淆等问题。即使离线测试的准确率很高，在大促活动、新产品上线或是政策更新后，模型的效果仍可能快速下滑。

随着用户表达复杂度不断提升，CNN、LSTM、BERT等深度学习模型开始展现出优势。预训练语言模型能够理解词序和上下文信息，比如同样是“我要退了”，在商品退款、机票改签和会员服务取消的场景下，模型可以给出不同的语义表征。此时还可以将意图分类与槽位抽取进行联合训练，一次性得到完整的意图和参数信息，比如intent=modify_flight、departure=杭州、destination=北京、date=下周一。这类方案适合意图标签稳定、标注数据充足且线上流量较大的业务，但代价是标注、训练以及版本管理的成本更高；当意图标签调整后，通常需要补充新的数据并重新训练模型。

当业务进入冷启动阶段时，场景会发生变化：此时意图标签已经定义完成，但每个标签仅对应少量标注样本。基于Embedding、原型网络和对比学习的方法更适配这类场景，它们通过向量空间来描述类别之间的关系，让同类语义表达在空间中彼此靠近，不同意图的表征则逐渐分开。当新增意图上线时，只需要准备少量示例样本就可以参与召回，新意图的扩展速度会快很多。

需要注意的是，语义相似并不等同于业务动作一致。比如“怎么取消订单”和“为什么订单被取消”，这两个句子在向量空间中可能非常接近，但对应的后续业务动作却完全不同。因此，基于Embedding的方法更适合用于召回少量候选意图，最终的意图判断则可以由分类器或是大语言模型（LLM）来完成。

意图数量扩容后的两阶段方案：先缩小范围再精准判断

大语言模型（LLM）进一步降低了意图系统的冷启动门槛。我们可以在Prompt中明确写明业务意图的定义、判断边界、正反案例以及输出格式要求，让模型直接返回意图、槽位信息、置信度以及是否需要向用户追问补充信息。LLM对口语化表达、省略句式、情绪表达以及少样本意图的适配能力更强，也更适合意图频繁调整的智能Agent产品。

但当意图数量逐渐增多时，将所有意图的定义和案例都塞进单个Prompt中，会带来上下文冗余、标签混淆、推理成本增加以及维护难度上升等问题。此时系统会自然演进到“先缩小决策范围，再完成精准判断”的两阶段架构。

意图检索增强生成（Intent RAG）的核心价值就在于缩小决策空间：系统先根据当前用户请求召回最相关的意图定义、边界案例以及易混淆的反例，再让LLM在这些候选意图中完成最终判断。原本需要从数十个意图中选择一个，现在只需要对比三到五个候选意图，不仅Prompt的长度更短，意图边界也更加集中清晰。

这类两阶段架构需要分别对召回层和判断层进行评估：如果目标意图没有进入召回的Top-K列表，后续的LLM很难再进行补救；如果目标意图已经被召回，但最终判断却选择了错误的意图，那么问题更可能出在意图边界定义、案例质量或是判断提示词上。将两个环节拆开评估，可以快速定位系统误差的来源。

同时，意图库也需要覆盖真实的线上用户表达分布。除了标准的意图定义之外，还应该收录口语化表达、易混淆的相邻意图、反例、业务前置条件以及历史误判案例。通过LLM批量生成的同义句可以补充长尾表达，但线上真实的用户请求仍然是更新意图库的最重要数据来源。

多轮对话场景：识别的是状态而非单句话

当业务场景进入多轮对话后，对话上下文会成为影响意图识别的核心变量。比如用户说“换成明天吧”，仅看这一句话无法判断他是想要修改机票、酒店预订还是会议日程。此时系统需要将历史对话整理为结构化的会话状态，包括当前活跃任务、已确认的槽位信息、待补充的槽位、上一步工具执行结果以及最近一次的用户修正内容，再结合最新的用户输入完成意图判断。

此时的意图识别目标可以设计为一次会话状态更新：

{
  "active_intent": "modify_flight",
  "intent_transition": "continue",
  "slot_updates": {
    "departure_date": "明天"
  },
  "missing_slots": [],
  "next_action": "confirm_change"
}

模型需要判断当前活跃意图是延续、切换、取消还是完成，同时识别用户修正了哪些槽位参数。这样智能Agent就可以围绕会话流程状态理解用户需求，减少旧意图残留对新任务的干扰。

当场景进一步扩展到复杂智能Agent时，用户的单句话可能还包含多个意图。比如用户说“查一下余额，超过一万就转五千到储蓄卡”，这里包含余额查询、条件判断和转账三个任务，且三个动作之间存在明确的依赖关系。此时单标签分类的方式会丢失完整的任务结构，更合适的输出形式是命令序列或是可执行的任务流程图。

到了这个阶段，意图识别已经逐渐扩展为语义解析、任务拆解和任务规划的综合能力：模型不仅需要理解用户的最终目标，还要确定动作执行顺序、参数依赖关系以及需要向用户确认的高风险步骤。

在实际生产环境中，通常会采用级联架构，让不同的技术方法各自处理其擅长的流量场景：规则引擎承接确定性命令和安全拦截请求，轻量分类器覆盖稳定且高频的意图场景，Embedding方法负责候选意图召回，LLM处理模糊表达、多轮会话状态和长尾请求，RAG模块动态提供业务定义与案例信息，任务规划器负责多任务拆解。每一层架构都需要保留拒识、追问以及人工升级的通道。

这种级联架构还有一个重要优势：系统可以根据请求的难度分配计算成本。简单请求走短链路快速处理，复杂请求再升级到更强的模型进行处理。每一层架构都可以单独进行监控、替换和回滚，当新增意图时也只需要调整对应的相关分支即可。

在意图识别完成后，还需要单独处理权限与执行安全问题：意图层负责回答“用户想要做什么”，权限层负责判断“用户是否有权限执行该操作”，执行层负责确认“该动作是否应该立即执行”。比如查询天气的请求可以直接执行，但删除数据、转账以及发送外部消息的操作通常需要进行身份校验或是二次确认。将这三个层次分开设计，可以避免模型将“意图理解成功”误判为“授权完成”。

因此，一个完整的意图系统需要提供四类处理出口：直接执行、向用户追问、拒识请求以及二次确认。当缺少必要的参数信息时向用户追问，当置信度不足时拒识请求，高风险动作进入二次确认流程，只有当所有条件充分且权限验证通过后，才调用对应的业务工具执行操作。

在评估意图系统时，也需要超越整体准确率（Accuracy）这一单一指标：在类别不均衡的场景下，更适合观察Macro-F1值；对于易混淆的相邻意图，需要维护混淆矩阵来分析错误类型；对于Embedding召回层，需要关注Recall@K指标；槽位抽取任务需要关注字段级别的F1值；在多轮对话场景中，需要关注意图切换和状态更新的准确率；在生产环境中，还需要观察拒识率、追问率、工具调用成功率、端到端任务完成率、系统延迟以及单次请求的成本等指标。

一个成熟的智能意图系统，需要能够判断何时直接执行操作、何时升级到更强的模型进行处理、何时停下来向用户追问补充信息。系统的能力越强，对不确定性的管理也应该越精细。

整个意图识别技术的演进脉络，可以归结为系统分工的不断清晰化：规则引擎负责处理确定性请求，轻量分类器负责承接高频稳定的流量，Embedding方法负责缩小候选意图空间，LLM负责处理复杂语义理解，RAG模块负责提供动态的业务知识，多轮会话状态管理负责维护上下文连续性，任务规划器负责将复合用户目标转换为可执行的任务步骤。优秀的意图识别系统，往往依靠这套分层分工架构能够随着业务复杂度的提升持续迭代升级。