客服消息越积越多时,先按问题类型分到合适队列,能减少重复分拣。这篇用 8 条虚构工单,让本机 OpenJev 给出类别,再由固定规则生成一个待确认的队列建议。脚本只打印结果,不连接客服系统、不创建工单,也不替客服做最终决定。

你需要准备

准备 本次使用 用途
Apple 芯片 Mac M1 Max、64GB 统一内存、macOS 27.0.1 本次在 CPU 上运行小型分类模型
OpenJev 0.5.0,Verdict 1.4 后端 根据工单文字返回一个预先定义的类别
Python 3.12.13 运行附带的本地练习脚本
模型文件 151M 参数;本次下载约 606 MB 权重 第一次启动需要下载;还要预留 Python 依赖空间
练习资料 8 条虚构工单与本地脚本 不含真实订单、顾客资料或联系方式

OpenJev 是独立开源项目提供的结构化判断服务,按选项返回分类结果;本地运行不调用付费推理 API,但会占用你的电脑、网络和磁盘。它本身不会替你创建或分派工单。查看 OpenJev 官方说明。本次测试使用其中较小的 Verdict 1.4 模型,不是常见的 DiffusionGemma 后端。本机仓库报告版本为 0.5.0;上游变更记录列有 0.6.0,本次没有测试新版。查看变更记录

模型卡的公开评测使用 Banking77 和 CLINC150 等数据集;这些分数不代表中文客服工单的效果。查看模型卡

先选一种分流方式

做法 适合什么情况
固定规则加人工分拣 工单量不大,类别和接手人已经很清楚
客服平台自带分流 已经使用客服平台;先核对平台的规则、人工接手和回退方式,本文没有测试具体平台
本机模型给队列建议 想用虚构样本先检查分类流程;本文的结果只显示建议,不自动分派

先把分流规则写清楚

先确定业务里的队列名称,以及哪些情况始终需要人工看。示例分类和队列如下:

工单类别 建议队列 例子
订单 订单客服 订单状态、发货或物流
付款 资金与发票人工复核 付款、扣款、退款、发票
商品 商品售后 使用问题、质量、缺件和配件
技术 技术支持 登录、验证码、网页或系统故障
其他 人工分诊 信息不完整,或不属于以上类别

退款、重复扣款、投诉、赔偿、产品安全疑问等情况在示例里直接转人工。低置信度或无法识别的类别也进入人工分诊。示例阈值 0.55 只是为了演示回退规则:OpenJev 会移除 Verdict 的“证据不足”选项,再把剩余类别概率重新归一化,所以返回的置信度不能单独代表是否该自动处理。OpenJev 官方说明了这个差异。脚本里的关键词也只是教学用的少量规则,不能直接作为真实客服系统的完整风险策略。

启动本机 OpenJev

先安装 Python,再按 OpenJev 官方仓库下载代码和依赖。本次使用 Verdict 后端,模型权重约 606 MB;首次启动会从模型发布页下载,访问代码仓库和模型站点的网络、磁盘空间以你的环境为准。

git clone https://github.com/razorback16/openjev
cd openjev
git checkout dcd20947b5ddad5be4a8f5aed6aa6dd245653823
uv venv --python 3.12
source .venv/bin/activate
uv pip install -e '.[verdict]'
OPENJEV_BACKEND=verdict OPENJEV_DEVICE=cpu OPENJEV_HOST=127.0.0.1 OPENJEV_PORT=19176 python -m openjev

最后一行只绑定本机回环地址,不对局域网开放。

保持这个终端运行,再把工单分类练习包解压到一个文件夹。进入该文件夹后先运行本地规则自检,再向本机服务发送 8 条虚构工单:

python3 run_demo.py --self-check
python3 run_demo.py

--self-check 不调用模型,只检查队列映射、低置信度和人工复核规则。第二条命令请求 127.0.0.1:19176 的 OpenJev /v1/systemone 接口;每条结果会列出模型类别、置信度和建议队列,并保存到 evidence/results.json。脚本不会访问互联网、客服平台或真实业务系统。

我们试了什么

本机 OpenJev 0.5.0 / Verdict 1.4 对 8 条虚构中文工单逐条做了单次判断。这组小样本只用来找错和演示流程,不能当成准确率或上线评估。 下表列出模型类别、把握度和按示例规则计算的队列;每个建议仍需人检查后再决定是否分派。

<!-- s180-result-table -->
样本 预设类别 模型类别 把握度 建议队列
T01 订单 订单 0.588 订单客服
T02 付款 订单 0.196 人工复核
T03 商品 订单 0.114 人工分诊
T04 技术 技术 0.281 人工分诊
T05 商品 其他 0.158 人工分诊
T06 付款 订单 0.183 人工分诊
T07 商品 订单 0.076 人工分诊
T08 其他 订单 0.244 人工分诊

按这 8 条固定样本核对,模型类别与预设标签相同的有 2 条。T01 是唯一超过示例阈值 0.55 的结果;T02 虽分类错了,但“重复扣款”关键词把它送进人工复核,其余 6 条低把握结果进入人工分诊。这个结果说明示例流程能把部分不确定项留给人看,不能据此认为模型适合真实工单分派。可在练习包的 evidence/ 中查看逐条输出和本次运行环境。

接入真实工单前

先用经过批准、去掉不必要个人信息的样本,整理固定的测试题和期望队列。逐条核对错分、漏分、低置信度和高风险内容;少量样本通过,不代表真实业务表现稳定。Verdict 1.4 每条问题输入上限为 512 tokens,过长内容可能被截断而没有报错;附件和长对话要先确认保留了哪些关键信息。关键词规则要由业务负责人维护,并设置人工接手路径。

把任何客户信息送进模型前,还要核对公司的数据处理授权、服务部署位置、日志与保留设置。私有部署不等于自动满足数据保护要求。可以先看企业数据安全教程,再参考AI 客服流程边界。

如果你要把工单摘要交给客服复核,可继续看AI 客服落地教程;如果要整理明确的销售需求,可看销售线索整理教程。