客服消息越积越多时,先按问题类型分到合适队列,能减少重复分拣。这篇用 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 客服流程边界。