尧图网页设计 
文章目录多层意图识别架构1. 用户输入规范化洗数据1.1. 混合规范化策略工程落地案例2. 意图识别2.1 第一层规则与关键词匹配2.2 第二层向量相似度匹配2.3 第三层LLM 兜底层次意图 也叫 粗筛精排2.3.1 低置信度澄清机制2.3.2 回滚策略3. 数据飞轮4. 补充需要掌握的知识点4.1. 意图正交化设计4.2. 任务规划层总览Plan机制说明4.2.1 任务规划层实战案例跨域联动 - 真实场景案例多层意图识别架构采用输入规范化 三层漏斗 澄清兜底 数据飞轮的级联架构核心思想是“用最低成本处理最高频问题逐级兜底长尾复杂请求”。1. 用户输入规范化洗数据用户的输入往往是口语化、碎片化甚至包含“黑话”的。如果不做预处理直接丢给意图识别会导致规则匹配失败、向量召回偏离。核心动作指代消解与补全将“那个”、“最划算”、“第二个”等代词或省略句还原为具体的业务实体如将“那个”替换为上一轮提到的“机票”。术语与黑话标准化将同义词、行业黑话如“抓手”、“三宝”、“RAG”统一映射为标准业务术语。口语去噪剔除“你好”、“请问”、“那个”等无意义的语气词和垫词。工程价值把“人话”变成“机器能懂的结构化表达”大幅提升下游规则层和向量层的命中率。1.1. 混合规范化策略工程落地案例为了兼顾响应速度与 Token 成本规范化不能全量依赖 LLM而是采用“规则先行 检索映射 LLM 兜底”的混合策略规则匹配去掉无意义词汇、时间和数值表转化、第一层降噪音 - 规则与正则处理对于口语去噪、简单的错别字修正、相对时间转换等完全不需要动用大模型。 - 去掉高频无意义词汇啊、那个、帮我看看等。 - 时间/数值标准化通过代码逻辑将“上个月”转为具体的 2026-07-01 ~ 2026-07-31将“一百块”转为数字 100第二层规范术语 - 词汇表通过查词汇表将规范术语和黑话避免LLM去猜。 - 实现方式系统维护一个业务词汇表存在 MySQL 或向量库中。当用户输入“抓手”、“RAG”、“售罄”时先通过精确匹配或向量检索命中词汇表直接将其替换为标准术语如“库存量0”。 - 优势业务黑话的解释权必须掌握在系统手里LLM 很容易产生幻觉而查表的结果是 100% 确定且可控的。第三层LLM 兜底只有当遇到强依赖上下文的复杂问题时才会调用 LLM。 - 指代消解“那个最划算的帮我订了” - LLM 结合对话历史推断出“那个”指的是“机票”“最划算”指的是“价格最低”。 - 省略句补全“肺结核呢” - LLM 结合上一轮“e生保可以投保哪些疾病”补全为“肺结核可以投保 e生保吗”。 - 主观判断量化“更有性价比的” - LLM 结合用户画像或商品属性将其转化为具体的筛选条件如“同品牌下价格低 20%”。2. 意图识别总结三层规则匹配 ➡️ 向量匹配 ➡️ LLM 层次意图兜底2.1 第一层规则与关键词匹配通过正则、关键词、模板匹配处理表述固定、意图明确的高频指令如转人工“签到”“查物流”。延迟 5ms零算力成本可拦截约10%~30%流量2.2 第二层向量相似度匹配将用户输入与预设的标准问法库做 Embedding 相似度计算命中阈值则直接返回答案阀值通常 0.85~0.9。标准问法来源提前录入高频问题 离线测评高分问题可拦截约30%~50%流量支持持续沉淀新发现的有效问法奇怪问题扩充知识库提高拦截率。命中条件双重校验相似度阈值Top-1 得分 ≥ 0.85建议范围 0.85~0.90分差Top-1 与 Top-2 的差值 ≥ 0.1建议范围 0.05~0.1两个条件同时满足才命中否则透传给下一层。例如用户问这个怎么退“Top-1 退货服务0.88Top-2 物流查询0.86分差仅 0.02模型很纠结”此时放弃匹配透传给 LLM 兜底避免误判。分差大 → 高置信直接命中分差小 → 不确定往下透传。2.3 第三层LLM 兜底层次意图 也叫 粗筛精排问题功能模块多时全部塞给 LLM 会降低判断力、增加 Token 消耗和响应延迟。方案采用类似决策树的多级下钻结构——粗筛先识别一级意图售前 / 售后 / 闲聊 …精排根据一级结果动态加载对应子模块的 Prompt 和工具列表再做细粒度意图识别售前 ├── 物品介绍 └── 型号推荐 售后 ├── 退货服务 └── 物流查询 闲聊收益每次调用只传入相关模块信息Token 少、速度快、准确率高。层数控制在 2~3 层避免调用链过长拖慢响应。2.3.1 低置信度澄清机制当 LLM 输出置信度低于阈值时不直接执行而是返回带选项的澄清列表如[查物流][申请退款]。用户点击后直接命中第一层规则兼顾安全与体验。大模型返回的置信度不准要依赖下一步说到的 回滚策略。2.3.2 回滚策略多轮对话中用户反复纠正、多次触发澄清时设置最大重试次数建议2~3 次超过后降级到转人工避免用户体验恶化。3. 数据飞轮进入 LLM 兜底的请求正向/反向两类都记录记录到**“长尾问题日志”通过人工审核排除闲聊和超范围问题后有效问法沉淀回第二层向量库形成线上兜底 → 人工标注 → 知识库扩充 → 拦截率提升**的持续优化闭环。4. 补充需要掌握的知识点4.1. 意图正交化设计场景如果两个意图很像怎么办模型无法决策?假设同时定义了“商品推荐”和“商品比较”两个意图。当用户问“iPhone 16 和小米 15 哪个值得买”此时模型就会困惑是走商品推荐还是商品比较。解决方案合并意图参数分流不要试图让模型去猜“意图”而是把选择权下放给“参数”。合并意图将“商品推荐”和“商品比较”合并为一个更大的意图比如叫 product_decision商品决策。参数区分在这个意图下定义一个参数 action_type。如果用户只说“推荐个手机”只给了一个手机型号action_type 自动填为 recommend 商品推荐。如果用户说了两个手机给了多个手机型号action_type 自动填为 compare 商品比较。代码层实现参数区分的方式以上的参数区分直接在代码层做后处理检测到用户输入中包含 2 个以上商品实体强制将意图路由为“商品比较”。4.2. 任务规划层总览Plan机制说明例如当用户一句话包含多个目标如“查订单并退款”时单纯的意图识别不够用。策略识别出多意图后不直接执行而是触发Plan规划模式生成执行计划。依赖分析判断意图间是否有先后顺序如先“查订单”拿到订单号再“退款”。交互优化如果不需要并发实际场景一般都是顺序执行依赖上一步返回参数可以采用“完成一个问一个”的策略“订单已查到现在帮您退款吗”既降低了并发复杂度又提升了交互确认感。4.2.1 任务规划层实战案例跨域联动 - 真实场景案例背景用户复杂问题常涉及多个功能模块联动意图识别层仅做粗粒度领域路由最小单元为功能模块不具体到接口具体执行链路由任务规划层动态编排。案例用户“帮我查一下最近的订单然后把那个没发货的退了。”执行需要先查询订单然后执行退款用户核心意图是退款【售后管理】、查询订单【订单管理】只是前置依赖。第一层意图识别层领域路由输入“帮我查一下最近的订单然后把那个没发货的退了。”分析用户核心诉求是“退款”售后管理“查询订单订单管理”是为获取退款所需 order_id 而产生的前置数据依赖。输出{主意图:售后管理, 前置依赖领域:[订单管理], // 仅表示需要跨域取数不视为独立用户意图 raw_query:帮我查一下最近的订单然后把那个没发货的退了。}第二层任务规划层工具编排 槽位提取输入主意图售后管理 依赖领域订单管理 原始文本。职责识别出 order_id缺失必须调用订单查询工具补全按依赖关系生成DAG有向无环图执行计划并负责从原文提取工具所需的参数槽位。输出执行计划[{step:1,tool:order_query,params:{time_range:最近,status:未发货}},{step:2,tool:refund_apply,params:{order_id:$step_1.result.id}}] 《对话系统多层意图识别架构设计：三层漏斗 + 任务规划实战》
文章目录多层意图识别架构1. 用户输入规范化洗数据1.1. 混合规范化策略工程落地案例2. 意图识别2.1 第一层规则与关键词匹配2.2 第二层向量相似度匹配2.3 第三层LLM 兜底层次意图 也叫 粗筛精排2.3.1 低置信度澄清机制2.3.2 回滚策略3. 数据飞轮4. 补充需要掌握的知识点4.1. 意图正交化设计4.2. 任务规划层总览Plan机制说明4.2.1 任务规划层实战案例跨域联动 - 真实场景案例多层意图识别架构采用输入规范化 三层漏斗 澄清兜底 数据飞轮的级联架构核心思想是“用最低成本处理最高频问题逐级兜底长尾复杂请求”。1. 用户输入规范化洗数据用户的输入往往是口语化、碎片化甚至包含“黑话”的。如果不做预处理直接丢给意图识别会导致规则匹配失败、向量召回偏离。核心动作指代消解与补全将“那个”、“最划算”、“第二个”等代词或省略句还原为具体的业务实体如将“那个”替换为上一轮提到的“机票”。术语与黑话标准化将同义词、行业黑话如“抓手”、“三宝”、“RAG”统一映射为标准业务术语。口语去噪剔除“你好”、“请问”、“那个”等无意义的语气词和垫词。工程价值把“人话”变成“机器能懂的结构化表达”大幅提升下游规则层和向量层的命中率。1.1. 混合规范化策略工程落地案例为了兼顾响应速度与 Token 成本规范化不能全量依赖 LLM而是采用“规则先行 检索映射 LLM 兜底”的混合策略规则匹配去掉无意义词汇、时间和数值表转化、第一层降噪音 - 规则与正则处理对于口语去噪、简单的错别字修正、相对时间转换等完全不需要动用大模型。 - 去掉高频无意义词汇啊、那个、帮我看看等。 - 时间/数值标准化通过代码逻辑将“上个月”转为具体的 2026-07-01 ~ 2026-07-31将“一百块”转为数字 100第二层规范术语 - 词汇表通过查词汇表将规范术语和黑话避免LLM去猜。 - 实现方式系统维护一个业务词汇表存在 MySQL 或向量库中。当用户输入“抓手”、“RAG”、“售罄”时先通过精确匹配或向量检索命中词汇表直接将其替换为标准术语如“库存量0”。 - 优势业务黑话的解释权必须掌握在系统手里LLM 很容易产生幻觉而查表的结果是 100% 确定且可控的。第三层LLM 兜底只有当遇到强依赖上下文的复杂问题时才会调用 LLM。 - 指代消解“那个最划算的帮我订了” - LLM 结合对话历史推断出“那个”指的是“机票”“最划算”指的是“价格最低”。 - 省略句补全“肺结核呢” - LLM 结合上一轮“e生保可以投保哪些疾病”补全为“肺结核可以投保 e生保吗”。 - 主观判断量化“更有性价比的” - LLM 结合用户画像或商品属性将其转化为具体的筛选条件如“同品牌下价格低 20%”。2. 意图识别总结三层规则匹配 ➡️ 向量匹配 ➡️ LLM 层次意图兜底2.1 第一层规则与关键词匹配通过正则、关键词、模板匹配处理表述固定、意图明确的高频指令如转人工“签到”“查物流”。延迟 5ms零算力成本可拦截约10%~30%流量2.2 第二层向量相似度匹配将用户输入与预设的标准问法库做 Embedding 相似度计算命中阈值则直接返回答案阀值通常 0.85~0.9。标准问法来源提前录入高频问题 离线测评高分问题可拦截约30%~50%流量支持持续沉淀新发现的有效问法奇怪问题扩充知识库提高拦截率。命中条件双重校验相似度阈值Top-1 得分 ≥ 0.85建议范围 0.85~0.90分差Top-1 与 Top-2 的差值 ≥ 0.1建议范围 0.05~0.1两个条件同时满足才命中否则透传给下一层。例如用户问这个怎么退“Top-1 退货服务0.88Top-2 物流查询0.86分差仅 0.02模型很纠结”此时放弃匹配透传给 LLM 兜底避免误判。分差大 → 高置信直接命中分差小 → 不确定往下透传。2.3 第三层LLM 兜底层次意图 也叫 粗筛精排问题功能模块多时全部塞给 LLM 会降低判断力、增加 Token 消耗和响应延迟。方案采用类似决策树的多级下钻结构——粗筛先识别一级意图售前 / 售后 / 闲聊 …精排根据一级结果动态加载对应子模块的 Prompt 和工具列表再做细粒度意图识别售前 ├── 物品介绍 └── 型号推荐 售后 ├── 退货服务 └── 物流查询 闲聊收益每次调用只传入相关模块信息Token 少、速度快、准确率高。层数控制在 2~3 层避免调用链过长拖慢响应。2.3.1 低置信度澄清机制当 LLM 输出置信度低于阈值时不直接执行而是返回带选项的澄清列表如[查物流][申请退款]。用户点击后直接命中第一层规则兼顾安全与体验。大模型返回的置信度不准要依赖下一步说到的 回滚策略。2.3.2 回滚策略多轮对话中用户反复纠正、多次触发澄清时设置最大重试次数建议2~3 次超过后降级到转人工避免用户体验恶化。3. 数据飞轮进入 LLM 兜底的请求正向/反向两类都记录记录到**“长尾问题日志”通过人工审核排除闲聊和超范围问题后有效问法沉淀回第二层向量库形成线上兜底 → 人工标注 → 知识库扩充 → 拦截率提升**的持续优化闭环。4. 补充需要掌握的知识点4.1. 意图正交化设计场景如果两个意图很像怎么办模型无法决策?假设同时定义了“商品推荐”和“商品比较”两个意图。当用户问“iPhone 16 和小米 15 哪个值得买”此时模型就会困惑是走商品推荐还是商品比较。解决方案合并意图参数分流不要试图让模型去猜“意图”而是把选择权下放给“参数”。合并意图将“商品推荐”和“商品比较”合并为一个更大的意图比如叫 product_decision商品决策。参数区分在这个意图下定义一个参数 action_type。如果用户只说“推荐个手机”只给了一个手机型号action_type 自动填为 recommend 商品推荐。如果用户说了两个手机给了多个手机型号action_type 自动填为 compare 商品比较。代码层实现参数区分的方式以上的参数区分直接在代码层做后处理检测到用户输入中包含 2 个以上商品实体强制将意图路由为“商品比较”。4.2. 任务规划层总览Plan机制说明例如当用户一句话包含多个目标如“查订单并退款”时单纯的意图识别不够用。策略识别出多意图后不直接执行而是触发Plan规划模式生成执行计划。依赖分析判断意图间是否有先后顺序如先“查订单”拿到订单号再“退款”。交互优化如果不需要并发实际场景一般都是顺序执行依赖上一步返回参数可以采用“完成一个问一个”的策略“订单已查到现在帮您退款吗”既降低了并发复杂度又提升了交互确认感。4.2.1 任务规划层实战案例跨域联动 - 真实场景案例背景用户复杂问题常涉及多个功能模块联动意图识别层仅做粗粒度领域路由最小单元为功能模块不具体到接口具体执行链路由任务规划层动态编排。案例用户“帮我查一下最近的订单然后把那个没发货的退了。”执行需要先查询订单然后执行退款用户核心意图是退款【售后管理】、查询订单【订单管理】只是前置依赖。第一层意图识别层领域路由输入“帮我查一下最近的订单然后把那个没发货的退了。”分析用户核心诉求是“退款”售后管理“查询订单订单管理”是为获取退款所需 order_id 而产生的前置数据依赖。输出{主意图:售后管理, 前置依赖领域:[订单管理], // 仅表示需要跨域取数不视为独立用户意图 raw_query:帮我查一下最近的订单然后把那个没发货的退了。}第二层任务规划层工具编排 槽位提取输入主意图售后管理 依赖领域订单管理 原始文本。职责识别出 order_id缺失必须调用订单查询工具补全按依赖关系生成DAG有向无环图执行计划并负责从原文提取工具所需的参数槽位。输出执行计划[{step:1,tool:order_query,params:{time_range:最近,status:未发货}},{step:2,tool:refund_apply,params:{order_id:$step_1.result.id}}]