智能工单系统的建设——从人工分派到 AI 自动分类与路由

智能工单系统的建设——从人工分派到 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);
}

// 尝试历史相似工单匹配
List<TicketHistory> 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 本身，而是因为正确分配减少了转派和重复沟通。