智能工单系统的建设——从人工分派到 AI 自动分类与路由一、工单处理的瓶颈不在数量在分配效率企业服务的工单系统有一个容易被忽视的成本结构处理工单本身不是最花时间的环节分类和分配才是。一份工单从用户提交到到达正确处理人手中间要经过客服筛选、组长审核、业务分组分配通常需要 2~3 次转派。一旦分类错误工单会在不同团队之间反复流转有时一周后才到达正确的处理人。我们团队在接入智能工单系统之前工单的首次分配准确率只有 64%意味着超过三分之一的工单至少要经历一次转派。转派不仅增加等待时间还会因为信息传递衰减导致重复沟通——第二个接手的人需要重新阅读整个工单历史。智能工单系统的核心价值不是替代人工处理而是用 AI 做分类和路由让工单第一次就到达正确的人手里。这个目标的实现依赖三个能力工单内容的语义理解、分类模型对业务术语的覆盖和路由规则的正确映射。二、智能工单系统的整体架构工单进入系统后首先经过预处理提取关键字段标题、描述、附件摘要、用户身份、历史工单记录。文本特征提取层将这些信息转化为分类模型的输入同时识别业务关键词如退款、发货、账户异常和情感倾向是否带有紧急或投诉情绪。LLM 分类是系统的核心它输出三个维度一级分类业务大类如支付问题、账户问题、订单问题、二级分类问题子类如支付失败、重复扣款、退款未到账和优先级紧急/高/中/低。分类之后再经过处理人路由引擎将工单映射到具体处理人或处理组。三、分类模型的训练与持续优化与通用文本分类不同工单分类面临两个特殊挑战一是业务术语专业性强例如支付行业中的卡组织拒付、二清、备付金通用 LLM 可能不理解二是分类边界模糊——支付失败和支付超时的区别需要上下文判断。我们的方案是基础分类 领域微调 规则兜底。基础分类使用 LLM 的 Few-shot 推理Prompt 中包含分类标签定义和典型案例。领域微调是针对公司的业务术语和工单分类体系用历史工单数据做 SFT 微调提升模型对专业术语的理解。规则兜底处理两类极端情况明确的规则型工单如忘记密码直接分类到账户问题和高频已知模式在过去 30 天内出现过 50 次以上的问题类型。Service public class TicketClassifier { private final LlmService llmService; private final RuleEngine ruleEngine; private final HistoryMatcher historyMatcher; public ClassificationResult classify(Ticket ticket) { // 优先尝试规则匹配快速且准确 RuleMatchResult ruleResult ruleEngine.match(ticket); if (ruleResult ! null ruleResult.getConfidence() 0.95) { return ClassificationResult.fromRule(ticket.getId(), ruleResult); } // 尝试历史相似工单匹配 ListTicketHistory similarTickets historyMatcher.findSimilar(ticket, 3); // 构建 Few-shot Prompt注入分类体系和历史案例 ClassificationPrompt prompt ClassificationPrompt.builder() .ticketInfo(ticket) .categoryDefinitions(getCategoryDefinitions()) .similarExamples(similarTickets) .build(); try { ClassificationOutput output llmService.classify(prompt); if (output null || output.getPrimaryCategory() null) { throw new ClassificationException(LLM 分类返回为空); } ClassificationResult result ClassificationResult.fromLlm( ticket.getId(), output, similarTickets ); // 如果 LLM 置信度低降级为人工分配 if (result.getConfidence() 0.6) { return ClassificationResult.delegate(ticket.getId(), LLM 分类置信度过低: result.getConfidence()); } return result; } catch (Exception e) { // LLM 调用失败时降级为规则匹配规则也失败则委托人工 log.error(工单分类失败, ticketId{}, error{}, ticket.getId(), e.getMessage()); if (ruleResult ! null) { return ClassificationResult.fromRule(ticket.getId(), ruleResult); } return ClassificationResult.delegate(ticket.getId(), 分类服务异常委托人工处理: e.getMessage()); } } }四、路由引擎从分类到处理人的多层映射分类解决了这是什么问题路由解决谁来解决。路由需要处理多层映射关系大类到处理组、子类到具体处理人、优先级到 SLA 时限。更复杂的是排班和负载均衡——不能把所有工单都分给同一个人。路由引擎的设计采用权重匹配机制每个处理人有一个能力标签集合如 [支付, 退款, 国际]每个工单分类也有标签。匹配计算考虑了标签吻合度、当前负载、历史处理效率和技能匹配度。负载高或处理效率低的处理人权重自动下调确保工单均匀分布。排班信息集成也需要考虑。如果主处理人不在岗需要自动路由到备选处理人。这要求路由引擎能实时访问排班系统或值班表。五、效果度量的关键指标智能工单系统的效果度量要比准确率复杂。建议观测以下指标首次分配准确率定义是所有分类结果的准确率还是只看高置信分类建议两个维度都观测因为高置信分类占比本身也是一个重要指标——占比越高说明系统自动化程度越高。工单处理时长中位数不仅看平均中位数更能反映真实体验。首次分配准确率提升后由于减少转派处理时长应明显下降。人工校正比例统计工单分配后被人工修改的比例这个指标比分类准确率更贴近业务真实反馈。如果某个处理人频繁修改分配结果意味着该人的业务领域定义可能和训练数据不一致需要重新对齐。当前我们系统的首次分配准确率已从 64% 提升到 87%工单处理时长中位数从 4.2 小时降至 1.8 小时。提升最大的不是 AI 本身而是因为正确分配减少了转派和重复沟通。
