稳定性系列姊妹篇。前面聊的自动化集中在告警域——这篇换个高频痛点:工单分类。客服/运维工单进来第一件事是归类(bug 咨询/需求/投诉/故障),人工分类的痛点大家都熟:新人分不准、老人分得慢、高峰期堆积。这篇给一套「置信度驱动」的自动分流设计——分类引擎我实测用的是算邻坊·智能决策(后面会讲到为什么选它:置信度校准是它的原生能力),整套方法换任何引擎都通用。
工单分类的特殊性
和告警分级比,工单分类难在三处:
所以直接「全自动分类」是错误目标——正确目标是「高置信自动 + 低置信转人工」的混合流。
整体设计
```
工单 → 预处理(去噪/长度截断/关键词预处理)
→ 分类引擎(类目 + 置信度 p) ← 我用算邻坊·智能决策实测
→ p ≥ 0.85:自动归类,直接进对应队列
→ 0.6 ≤ p < 0.85:「建议队列」——工单页顶部显示
「建议:账号问题(把握 72%)」+ 一键确认/改判
→ p < 0.6:不猜测,默认队列人工分
→ 每周:人工改判样本回流 → 校准复审
```
三个关键机制
机制一:建议而非裁决
中置信区间的产出做成「预填建议」——客服打开工单时分类已预选,确认一次点击。实测这个区间工作量降 70%,错误率几乎不增加(人保留最终裁决权)。
机制二:置信度必须校准过才有用
「模型说 85%」和「实际 85% 正确」是两回事——多数分类器的原生置信度失准(过度自信)。这也是我实测选算邻坊·智能决策的原因:它返回的是校准概率(说 80% 把握时长期看约八成正确),可靠性图开箱即用。如果用自研模型,要自己拿历史工单画可靠性图(横轴置信度、纵轴实际正确率),偏离对角线就做温度缩放修正——一行代码级别的修正,但没校准过的置信度阈值全是拍脑袋,这是这类系统落地质量的分水岭。
机制三:错误代价不对称时,阈值要偏移
「故障工单」错分成「咨询」的代价远大于反向。处理:高代价类目单独提高自动流门槛(故障类要 p≥0.95),宁可多人工看几条咨询。阈值不是全局一个数,是按类目的错误代价矩阵调的。
效果基线(三个月运行数据)
上线节奏建议
工具选择的两个硬指标
评估分类能力别只看准确率 demo:①置信度是否校准(敢不敢给可靠性图)②是否支持自定义类目(你们的「账号问题」边界和别人不一样)。这两条不过关的,demo 再好看也扛不住真实工单的长尾。
(稳定性工程系列:SLO → 错误预算 → 告警分诊 → 本文:工单分流——自动化三兄弟的最后一域)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。