一、项目背景

我们当时服务的是某大型家电企业的客服与运维中心。他们每天通过热线、在线客服、微信公众号、自有 APP 等多个入口涌入工单，峰值时段单日工单量在数千条量级。原有的处置流程高度依赖人工：值班组长先把工单读一遍，凭经验判断该转给哪个业务组——是"安装报修""账号异常""发票售后"还是"渠道投诉"，再手动指派给具体坐席；遇到跨业务工单，还要在群里来回踢皮球。

我们事后复盘，这种模式有三个痛点特别突出。第一，分派慢且错派率高，组长每天大量时间花在"读工单—判断归属"上，高峰期工单在队列里平均停留超过半小时才被认领。第二，处置经验散落在老坐席脑子里，新坐席上手至少要带两周，一个资深坐席离职就意味着一批隐性知识流失。第三，同一类问题反复出现，但因为没人沉淀标准处置方案，每次都从头想一遍，重复工单占比居高不下。

我们当时决定用大模型重构这条链路：让模型读懂工单语义自动分派，并把每一条成功处置过的工单，沉淀成可被检索复用的知识条目。底层我们采用的是自研的 AI 私有化部署底座，配合统一的 AI 网关做多模型接入与智能路由编排，推理框架走 vLLM 这类连续批处理方案，知识库用 Milvus 做向量近邻检索。

二、落地场景

落地后，整条工单链路变成了"自动分派 + 智能推荐 + 知识回流"的闭环。

第一步是语义分派。工单进入系统后，网关先把请求归一化，路由层根据实时成本与延迟，把分类任务优先交给一个轻量级的 7B 级别模型做意图识别与业务组归类，复杂语义再回退到更大的模型精排。分派结果不是简单打一个标签，而是给出"业务组 + 置信度 + 关键证据片段"，直接落到工单队列并推送提醒。

第二步是处置推荐。坐席打开工单时，系统会基于 RAG 知识库做一次检索重排，把历史上相似工单的标准处置方案、FAQ 话术、相关产品手册片段推到工作台侧边，坐席可以直接采纳或微调。

第三步是知识回流。一条工单被标记"已解决"后，我们跑一条异步流水线：先抽取处置过程中的关键信息（故障现象、根因、解决方案、所需物料），去重后切片向量化写入知识库。这样处置经验就不再是某个人的私产，而是平台资产。

三、关键技术挑战与解决思路

挑战一：工单语义理解不止是分类，还要识别"跨业务"。 很多工单一句话里同时涉及"安装""发票""投诉"，单纯用关键词或传统文本分类器，准确率只能到七成左右，且对口语化、错别字多的工单很敏感。我们的解决思路是放弃关键词匹配，改为让模型做"意图槽位抽取 + 多标签打分"。我们在网关编排层设计了"小模型粗分 → 大模型精排"的两段式：先用 7B 模型快速给出候选业务组，再用更大的模型对边界样本做语义重判。Prompt 里我们明确给出业务组的职责边界定义，并要求模型输出判断依据，便于人工复核与迭代。

挑战二：分派策略必须与 SLA 和负载联动，不能只看语义。 只把工单丢给"最对口的组"是不够的——如果那个组已经爆队列，工单照样超时。我们在分派模块后面接了一层策略引擎：综合各组当前在忙坐席数、未处理工单堆积量、该工单的 SLA 剩余时间，对模型给出的"主选组 + 备选组"做加权打分，必要时溢出到次优组。这里模型负责"判对不对口"，策略引擎负责"现在该不该派过去"，两者解耦。

挑战三：处置知识抽取容易"抽不准"也"抽太碎"。 一开始我们用一个通用抽取 Prompt，结果要么把无关的寒暄也抽进来，要么把"根因"和"解决方案"混成一段，检索时无法精准命中。我们改为结构化抽取，要求模型严格输出 JSON 字段（symptom / root_cause / solution / material / apply_scope），并对 solution 做长度与动作性校验。抽取结果写库前先过一道去重：用向量相似度 + 关键字段哈希双重判重，避免同一方案反复入库污染检索召回。

挑战四：知识库需要持续保质，否则越用越偏。 我们设计了"被采纳率"作为知识条目的健康度指标：推荐给坐席后被实际采纳的条目权重提升，长期零采纳的条目自动降权并进入人工复核池。配合 AI 网关的计量层，我们还能看到哪类工单的推荐采纳率偏低，反向驱动抽取模板优化。

四、效果数据

项目在某企业客服中心灰度运行约三个月后，我们拉取了上线前后的对比数据。以下均为脱敏示意值，仅用于说明趋势。

除此之外，新坐席独立上岗的培训周期从约两周缩短到约 5 天，组长用于"读工单分派"的事务性时间下降明显，可以把精力放在疑难工单与服务质量监控上。

五、可复用经验总结

这一仗下来，有几点经验可以复用到其他"工单 / 派单 / 处置"类场景。

其一，分派一定要靠语义而非关键词。关键词和正则能在规则清晰的窄场景跑得动，但一旦工单口语化、跨业务、带错别字，模型做意图抽取 + 多标签打分的鲁棒性优势就出来了。把"分类"升级成"判对口 + 给依据"，还顺带解决了可解释与可复核的问题。

其二，模型判口路与运行期派单策略要解耦。语义归语义，负载和 SLA 归负载和 SLA。让模型只回答"该给谁"，让策略引擎回答"现在给不给"，职责清晰，后续调参也互不干扰。

其三，处置经验必须回流，而且要结构化和去重地回流。知识沉淀不是把聊天记录往库里一扔，而是要抽到"现象—根因—方案—物料"的结构，再去重入库，否则检索越用越脏。

其四，给知识库一个健康度指标。我们用"被采纳率"做权重，相当于让一线坐席用脚投票，系统能自我纠偏，不至于知识库建好就长草。

案例片段（已脱敏）： 工单自动分派的意图识别 Prompt 与网关路由配置（节选）： ```text

工单意图分类 Prompt（system 片段）

你是工单分派助手。候选业务组及职责边界： - 安装报修组：涉及上门安装、调试、硬件故障 - 账号安全组：登录异常、密码、账号冻结、信息泄露 - 发票售后组：开票、换货、退货退款、保修政策 - 渠道投诉组：经销商/门店纠纷、服务态度、超时履约 请对工单做多标签打分，输出 JSON： {"groups":[{"name":"...","score":0-1,"evidence":"原句依据"}],"need_human_review":bool}

AI 网关路由策略（精简）

route:  - match: { intent: "fast_classify" }    target: model-7b-fast        # 轻量模型粗分  - match: { confidence: "<0.6" }    target: model-32b-reason     # 低置信回退大模型精排    fallback: rule-based-review  # 仍失败转人工 ```

一条实际工单的分派日志（脱敏）：log [2025-03-18 14:22:03] ticket=TK-88213 src=wechat  classify: groups=[{账号安全组:0.91},{发票售后组:0.12}]  router: model-7b-fast => confidence=0.91 (skip re-rank)  sla: remaining=4h12m group_load=low  action: ASSIGN -> 账号安全组 / seat=S-117  latency: 1.8s