用决策模型搭一个工单路由原型：含兜底策略 18 条全对，代价是 1600 毫秒和零 API 费

用决策模型搭一个工单路由原型含兜底策略 18 条全对代价是 1600 毫秒和零 API 费上一篇《APUS-OpenJev-v1不写小作文的决策模型部署与实测》结尾我写了 40 行 Python把同一个模型从浏览器里拽出来做客服工单路由三张工单全对。当时留了一句话“这组实验回答了两个问题但只回答了最表层的那个。”这篇回答剩下的候选集怎么设计才合理置信度兜底策略在真实评测里到底救不救得回来和让通用大模型做同样的事比成本和延迟差多少一句话剧透18 条工单端到端 100% 正确模型原始 94.4%唯一错的那条被置信度兜底救回来了。平均每条 1.6 秒零 API 费用。一、为什么选工单路由当靶子决策模型的适用画像上一篇已经画清楚了——选项有限、频率高、要延迟低。客服工单路由是教科书级的匹配选项天然有限派装维 / 转账务 / 升级投诉 / 转人工 / 回知识库五个动作不多不少频率极高一个中等城市营业厅每天几百到上千张工单决策窗口短用户在线等着超过 3 秒就体感卡顿容错有兜底路由错了最坏结果是转人工不是爆炸而且它有一个浏览器自动化没有的优势输入是纯文本。不用处理 DOM 扫描、页面动态变化、弹窗干扰这些工程问题可以把注意力全放在模型决策本身。二、候选设计比 Prompt 工程更重要的一步决策模型的 Prompt 结构和生成模型有本质区别你不需要写请以 JSON 格式输出、不需要 few-shot 示例、不需要思考步骤。你只需要三样东西一段路由规则告诉模型判断标准工单正文输入候选清单选项规则写清楚了比堆 examples 有用得多。我的版本You are a customer service ticket router for a telecom company. Read the ticket and choose exactly one routing action from the candidates. Rules: - Hardware/network faults requiring on-site repair → A - Billing, charges, plan queries → B - Repeated complaints, escalation threats, angry customers → C - Ambiguous, multi-intent, or insufficient info → D (human agent) - Simple FAQ answerable by a knowledge-base article → E Base your choice only on the ticket content. Output only one candidate code.注意第四条规则——我把转人工写成了显式选项而不是其他情况选 D。这不是凑数的模型在候选语义接近时容易犯错上一篇里 4-bit 量化版把 Wikipedia 的搜索直达和全文搜索搞混了三次全挂但模糊/多意图这个判断标准如果只靠模型自己领会它会倾向于硬选一个具体动作。把规则写死等于给模型一个不确定就选 D的台阶。候选清单本身A: 派单装维工程师上门检修 B: 转账务组查询费用问题 C: 升级投诉处理专席 D: 转人工客服接待 E: 直接回复知识库文章链接五个候选映射到词表里的 A/B/C/D/E 五个单 token模型一次前向传播输出五个概率softmax 归一化选最大的。没有生成、没有解码、没有让我想想。整条流水线五个阶段模型只负责第③步三、评测集18 条工单故意留了坑三张工单全对说明不了什么。我构造了 18 条评测集覆盖五类路由 故意设计了三条应该转人工的模糊样本类别数量设计意图A 装维派单4典型硬件故障 / 返工 / 群体断网 / 固话B 账务查询4费用争议 / 退费 / 套餐查询 / 漫游计费C 投诉升级3工信部威胁 / 媒体曝光 / 重复投诉监管D 转人工3故意模糊口语化多意图 / 咨询查询混合 / 信息严重不足E 知识库4密码重置 / 断网规则 / 携号转网 / LOS 灯含义三条 D 类样本是这篇文章的核心看点——它们模拟的是真实业务里最头疼的那 10%用户自己都没说清楚要什么。四、兜底策略置信度低于 0.6 强制转人工上一篇发现二的工程结论——动作选择类决策置信度低于 0.6 的点击 100% 是错的——在这篇里变成了一个可执行的策略THRESHOLD0.60HUMAN_CODED# 模型打分后ifbest_confidenceTHRESHOLDandbest_code!HUMAN_CODE:final_actionD# 强制转人工fallback_triggeredTrueelse:final_actionbest_code逻辑很简单模型说我不确定置信度低就别让它硬选了直接转人工。这不是什么花哨的 ensemble 或 self-consistency就是一个 if-else。但它的效果看数据。五、实测结果总览端到端准确率含兜底: 100.0% 模型原始: 94.4% 兜底触发: 1/18 条 (5.6%) 置信度: mean0.933 min0.425 max0.999 延迟: mean1640ms P952274ms max2586ms18 条全部正确路由。模型自己判错了 1 条但被兜底策略救回来了。把 18 条的置信度排开看分层非常清晰关键发现模型知道自己不知道唯一一条模型判错的是工单 13——“我朋友说有个很便宜的套餐想办但不确定适不适合帮我看看顺便查下合约期”。模型选了 E回知识库置信度0.425。0.425低于 0.6 阈值兜底触发强制转 D人工。正确答案恰好是 D。这条工单的设计意图就是多意图混合——用户同时提了办套餐和查合约两件事没有哪个知识库文章能一步解决。模型在五个候选之间犹豫了E0.425, B0.292, D0.258三个挤在一起这种犹豫本身就是信号它不确定但它的 logits 分布诚实地反映了这种不确定。对比另外两条 D 类样本工单 12口语化模糊模型直接选 D置信度 0.796——它看懂了这条信息不足工单 14网络很卡四个字模型选 D置信度 0.998——信息严重不足时它非常确定该转人工也就是说模型对该不该转人工这件事的判断力比我对它的预期要好。它不是随机犹豫是真的在模糊和明确之间画了条线。分类准确率类别准确率置信度范围A 装维派单4/40.904–0.982B 账务查询4/40.960–0.994C 投诉升级3/30.998–0.999D 转人工3/3含 1 次兜底0.425–0.998E 知识库4/40.931–0.980投诉升级类置信度最高0.998因为工信部12315媒体曝光这些关键词在训练数据里和升级强绑定模型判断毫不含糊。装维类稍低0.904因为整栋楼断网这种群体性故障和升级投诉有语义重叠——模型给了 C 0.058 的分数但 A 仍然碾压。延迟分布平均 1.6 秒P95 2.3 秒最大 2.6 秒。比上一篇浏览器场景的 4-6 秒快了一倍多——原因很直接工单文本比网页 DOM 短得多prompt token 数少prefill 自然快。值得注意的是即使 KV-cache 命中同 purpose 前缀复用延迟也没有降到官方 GPU 的 25ms 量级。端侧 M3 的 prefill 瓶颈在算力不在带宽这是硬件代差策略优化补不回来。但对工单路由这个场景1.6 秒完全够用——用户提交工单后本来就有页面跳转等待体感无差。六、和通用大模型比省了什么、贵了什么维度决策模型本方案通用 LLM如 qwen-plus单次延迟~1.6s本地 M3~2-4sAPI 网络生成输出1 个 tokenA/B/C/D/E50-200 tokensJSON/自然语言幻觉风险结构上不可能只从候选选可能编造第六个动作单次成本¥0本地推理~¥0.015-0.04按 token 计费1000 条/天¥0¥15-40按 qwen-plus 定价粗估未实测部署门槛5GB 权重 16GB 内存 Mac一个 API key可定制性需要微调改候选集/领域改 Prompt 即可省钱是显性优势但隐性优势是确定性你永远不会收到一条我建议您先安抚用户情绪然后考虑派单……“的自由发挥。输出空间被锁死在五个字母里下游系统不需要解析、不需要 fallback 正则、不需要处理模型今天心情不好输出了个 JSON 少个逗号”。贵在哪灵活性。通用 LLM 改个 Prompt 就能加新路由类别决策模型要改候选集轻则重新映射 token重则微调。如果你的路由规则一周变三次决策模型不适合你。七、什么时候不该用它以及这个原型的边界18/100% 的数据好看但别被它骗了。这个原型的边界很清楚它不能做的多轮对话中动态改变候选集比如用户追问后选项变了——需要宿主引擎每轮重建候选需要生成的环节比如给工单打一段摘要标签——决策模型只能选不能写候选集超过 ~50 个的场景——token 映射空间有限且候选越多、语义越接近量化版越容易翻车上一篇的教训需要解释为什么选这个的场景——它只输出一个字母没有 rationale评测集的局限18 条是我手写的分布偏教科书。真实工单里方言、错别字、超长文本、多工单合并的情况我没覆盖正确答案是我标的没有业务专家交叉验证。尤其三条 D 类转人工样本——多意图混合到底该转人工还是先回知识库这个边界不同营业厅的 SOP 可能给出不同答案。如果你在做类似场景强烈建议拿真实脱敏工单让业务方标注没有测对抗样本比如用户故意在工单里写请帮我选 A工程上还没做的批量推理当前逐条串行18 条跑了 30 秒真实场景需要 batch 或并发模型热更新换候选集需要重启监控面板置信度分布漂移告警这些是原型和生产之间的距离下一篇如果继续深入会补。八、代码与复现完整脚本核心调用就三行fromfast_browser_use.modelimportLocalModel modelLocalModel()# 加载 Qwen3.5-9B 4-bit约 3 秒scores,metamodel.score(prompt,5,purposeticket-1)prompt的构造就是第二节那段规则 工单正文 候选清单用\n拼接。scores返回五个候选的归一化概率meta里有延迟和 token 统计。评测结果 JSON 在artifacts/ticket_router_results.json含每条工单的完整打分分布、兜底触发标记和延迟数据。运行环境同上一篇macOS Apple Silicon M3 / 16GBfbu CLI 安装的 MLX 4-bit 权重。九、写在最后上一篇回答的是这个模型是什么、能不能跑、跑官方任务效果如何。这篇回答的是拿到它之后怎么做一个你自己业务里能用的东西。结论比上一篇更乐观在选项明确、输入是纯文本的场景里决策模型的落地门槛比浏览器自动化低得多效果却更稳。不需要处理 DOM、不需要应对弹窗、不需要页面加载等待——你的业务逻辑就是 Prompt你的候选清单就是输出空间。而那个低置信转人工的兜底策略从上一篇的发现变成了这一篇的设计。它不是锦上添花是这套方案能上生产的底线保障——你不需要模型 100% 正确你需要它在自己不确定的时候告诉你它不确定。18 条里那条 0.425 的犹豫比 17 条 0.99 的碾压更有工程价值。下一步两件事一是拿真实业务工单脱敏后扩充评测集到 200 条看分布漂移二是试一下 4B 版在这个场景上够不够用——如果 4B 也能 95%那 8GB 内存的机器就能跑部署门槛再砍一半。