意图识别使用什么模型，意图识别树如何组织？
未标记
考查重点：分层意图与叶子执行路由。按业务域—任务—可执行意图组织树，叶子映处理器；规则/小模型/LLM按类别规模与歧义选，缺参澄清
本题目录
参考答案
核心回答
意图识别先定义业务意图、所需槽位和无法判断时的处理方式，再选择规则、分类小模型或LLM。意图树按“业务域 → 任务类型 → 可执行意图”分层，叶节点映射受控处理器；不是把业务所有名词排成一棵树，也不是让模型随意生成函数名。
从大模型切到小模型时，不只看响应快，还要比较每类召回、混淆、高风险误路由、长尾表达和未知意图拒识，再结合成本与维护能力判断。
模型怎么选
规则适合明确命令、固定格式与高精度入口；分类小模型适合意图集合相对稳定、标注数据充足、低延迟高频请求；LLM更适合自然表达多样、上下文省略和新场景，但成本、输出稳定性及边界也需要评估。
可以用高精度规则处理确定请求，小模型覆盖常见意图，LLM辅助复杂长尾或澄清。并不是层次越多越好；小规模意图集直接分类可能更简单。模型自报置信度未经校准，不能直接等同真实正确概率。
意图树怎样建立
从真实需求、服务能力与错误成本出发整理意图，写出每个叶子的定义、正反例和必需槽位。上层划分尽量有明确业务意义，例如订单域下区分订单查询、申请退款、取消订单；“查能不能取消”和“取消”必须区分。
节点维护稳定ID、定义、候选子节点、示例与回退策略；叶节点关联服务端注册的处理器、参数Schema和执行条件。模型只输出允许的意图及槽位，实际身份与权限来自可信运行时。
先在上层选少量候选，再在候选分支细分，可以减少每次比较范围；但上层错判会层层传播。因此允许跨分支候选、回到上层或进入未知意图，不能一旦选错域就再无恢复机会。
多轮、多意图与模糊请求
当前话语要结合相关会话状态，例如“那这单呢”需要知道所指订单；用户改口应更新槽位，而不是继续使用旧对象。多个独立意图可以拆分并行，有依赖则按顺序编排；不能强行塞成唯一叶子。
“帮我处理订单”缺少具体动作时，可给有限的候选或补问关键条件；若明确是查询但缺少订单ID，可先从已有上下文补齐。槽位收集是任务状态管理的一部分，不应靠反复猜测。
如何迭代
建立分层标注集，覆盖同义表达、近似意图、否定、纠正、多意图和分布外请求。除了总体准确率，还看各层路由、叶子召回、混淆矩阵、拒识、最终任务成功及延迟。
大模型换小模型时使用同一数据和业务口径对照，记录哪些类别变差；必要时保留选择性回退。技术亮点是将分类结构、执行契约与可恢复路由分开，避免一棵树成为不可纠错的决策漏斗。
RagentJava Workflow
基于 Ragent核心回答
Ragent 这条链使用 LLM 对候选叶子节点打分，意图树负责组织业务分类和执行所需的配置。树从 Redis 加载，缓存缺失时查询数据库并重建；识别时展开树，把当前模式允许的叶子节点及其路径、描述、示例一次性放进提示词，而不是从根节点开始逐层调用分类模型。
这里选择可配置的 Workflow 模式说明：仓库部署配置的 ragent.engine.type 默认为 agent，两条入口不能混为同一流程。Workflow 的意图候选包含知识检索类 KB 和系统交互类 SYSTEM；另一条 Agent 入口的知识工具只识别 KB，不会把系统应答混进知识库选择。
实际调用什么模型
意图分类器通过统一的 LLMService.chat() 同步调用模型，构造系统提示词和用户问题，并设置较低的 temperature、top_p，关闭思考模式。它没有在分类器中写死一个专用分类模型，而是由 RoutingLLMService、ModelSelector 根据默认 standard 档位选择模型，再调用对应供应商的适配客户端。
固定版本的配置中，standard 的首个候选是 qwen3.8，对应百炼的模型名 qwen3.8-27b；后续登记了 qwen-plus、deepseek-flash 和本地 qwen3 等回退候选。实际使用的模型由启用状态和路由结果决定。模型配置与路由服务共同决定这条调用链。
供应商客户端适配请求与返回，例如百炼客户端复用基于 OkHttp 的聊天请求实现，并处理供应商的思考开关。
意图树怎样保存与加载
数据库节点用 intentCode、parentCode 表达父子关系，加载时只取未删除且已启用的节点，先建立节点映射，再连接父子节点，并生成从根到叶的 fullPath。节点有名称、描述、示例问题和层级标识；叶子还可以关联知识库与逻辑集合、检索条数及提示配置。树的层级可以按业务组织，不要求所有分类都固定为同样深度。
例如“业务系统 > OA 系统 > 数据安全”这样的路径，既能帮助维护者区分同名主题，也能连同描述和示例一起进入分类提示词。kind=KB 表示知识检索，kind=SYSTEM 表示问候、助手身份或反馈等系统交互，两者后续处理不同。
每次分类会读取 Redis 中的树；缓存不存在或读取失败时，再从数据库加载并回写缓存。管理端增删改节点后会清理缓存，使后续读取重新加载。这是数据库配置、缓存与请求内候选结构的分工，不能把“树在缓存里”理解为树只存在内存中，也不能把读缓存说成每次都查数据库。实现见树加载与组装和数据库节点重建。
怎样从叶子评分走到检索或应答
流程先结合会话历史改写问题并拆分子问题，再对每个子问题分别做意图识别。分类器提取符合当前模式的叶子候选，将 id、完整路径、描述、示例和类型放进同一份提示词，请模型返回带 id、score 的 JSON 数组。提示词里虽然有判断步骤，但不是服务端沿树每层发起一次模型调用。
收到结果后，代码只接受本次候选集合中的 ID，忽略不存在或当前模式不可用的节点，按分数排序；IntentResolver 再做最低分过滤与候选数量限制。模型调用失败或返回无法解析时，分类器返回空意图。这些分数是模型给出的相关性评分，不是经过校准的正确概率。 候选白名单校验也只限制可选节点，不能证明选中的分类一定正确。具体见候选构造与结果解析。
分类之后，固定流水线先检查是否需要澄清：例如多个系统下都有“数据安全”主题，结合候选路径和歧义判断，可以先让用户选择系统。只有所有子问题都各自仅命中一个 SYSTEM 意图时，才进入系统应答分支；其余请求进入知识检索流程。固定流水线负责这个顺序。
知识意图用于选择检索范围，低分或无有效知识意图时，当前实现可以退回有效知识库的全局检索；分数足够时采用命中范围，并保留补充范围。因此，空意图不等于必然拒答，命中意图也不等于权限校验已经完成。验证这条链应分别看候选分类、检索范围和最终回答，用明确实体、同名主题、未知请求及模型返回非法 ID 等样本定位错误，而不是只统计模型有没有返回一个分类。
对应教程
- 实战项目-电商小二/1-对话系统基础与多轮对话架构：理解业务意图、槽位和多轮状态的连接。
参考资料
国内：WeThinkIn：意图识别与业务路由：依据规则、模型、槽位与注册处理器的分工，说明正文中识别结果如何接入实际业务。
国内：zero2Agent：模糊需求与澄清：借鉴关键缺失条件与候选澄清，说明正文中模糊请求和上下文省略的处理。
国内：zero2Agent：Skill路由评估：依据分层路由指标，区分正文中上层误判、候选遗漏与叶子混淆。
国外：Rasa：Forms：借鉴旧版 Rasa 的必需槽位与完成条件机制，说明正文中多轮参数收集的状态管理。
国外：Rasa：Fallback and Human Handoff：借鉴旧版 Rasa 的拒识与澄清机制，说明正文中不确定请求的回退路径。
国内：阿里云：意图分类节点：采用按意图描述与示例限定分类范围、区分单选多选及未匹配分支的设计，说明项目中候选定义与后续路由的职责；具体树结构和评分流程以
Ragent源码为准。
