Jev 工单分类：原理、输入输出与最省 token 的玩法

Jev 不是 ChatGPT 那种「写字的 AI」。它是一个判卷老师：你把工单（一份材料）递给它，再把一张你预先印好的答题卡（几个分类选项）也递给它，它不写一个字的作文，只在答题卡上涂概率：

因为不写字、只涂卡，「编造一个不存在的选项」「输出一段没法解析的话」这类错误在构造上就不存在——答题卡是你印的，它只能在你的选项里涂。

术语：Jev 是 TypeSafe AI 的 System One 模型，RLCD 训练，70–500ms 出结果，输入 $0.042/M token、输出免费

「校准」是关键卖点：普通 LLM 你问「有几分把握」，它八成回答 99%。Jev 的训练目标（RLCD）就是让置信度和真实命中率对齐——这意味着置信度第一次变成了可用的生产参数，而不只是心理安慰。

① state（材料）：工单的证据文本——故障现象描述、错误代码、已换过的备件、机型。直接贴原文，不需要清洗措辞，错别字、行话、中英夹杂都行（下文实测）。

② questions（答题卡）：你定义的分类体系，三种题型——

{
  "state": "客户报修天吊DR，开机自检报错…（工单证据）",
  "model": "jev-latest",
  "questions": {
    "failure_mode": {
      "type": "choice",
      "instructions": "判断最可能的故障子系统",
      "criteria": {
        "detector": "平板探测器坏点/伪影/校准失败/图像异常",
        "hv_generator": "高压发生器/高压油箱打火/曝光错误",
        "tube": "球管漏油/真空下降/阳极噪声",
        "software": "软件报错/升级引起/回滚后恢复",
        "mechanical": "机械/运动轴/限位/刹车",
        "other": "以上都不符合或证据不足"
      }
    },
    "needs_escalation": { "type": "noul", "instructions": "需升级研发" },
    "severity": { "type": "score", "criteria": ["可继续用","受限","无法出图","停机"] }
  }
}

{
  "answers": {
    "failure_mode": {
      "choice": "detector", "confidence": 0.69,
      "probabilities": { "detector": 0.77, "software": 0.23, … }
    },
    "needs_escalation": { "noul": 0.29 },
    "severity": { "score": 1.6, "confidence": 0.78, … }
  },
  "usage": { "input_tokens": 402, "output_tokens": 70 }
}

三个问题一次调用全部返回——问题是并行评估的，多加问题几乎不加时间。这不是「问三遍 API」，是「一张答题卡涂三道题」。

用 X 光机售后工单风格的输入实测（结果均为 API 真实返回）：

「球馆漏油」这关最说明问题：字面是错的，它靠「漏油」+语境推出了球管。50 个工程师 50 种写法的实体归一化问题，语义模型直接吃掉。

成本量级感受：10000 条 × 2000 token = 2000 万 token ≈ $0.84。全量重跑一遍不到 6 块钱——迭代分类体系不用心疼。

• ① 分类体系（最重要的 80%）：按故障子系统分 6–10 类 + other 兜底，每类一句「判定证据」。准则含糊 → 概率摊平。自检：抽 20 条盲分，犹豫 ≥2 秒或可放两类 = 准则没写清。
• ② 别名表写进准则：帕累托 Top 20 现象里的黑话/错字变体（平板=检测器=detector）直接写进对应选项描述。
• ③ 100 条脱敏样本 + ground truth：去客户名/序列号。没有标签就没有评估——准确率和校准度都无从验证。
• ④ 置信度门控阈值：低于 0.5 进人工复核队列；「升级研发」等高代价动作 ≥0.85 才执行。Jev 给人工复核排序，不是替代人工。

import json, urllib.request, os

key = os.environ["TYPESAFE_API_KEY"]          # 或从 ~/.hermes/.env 读

def classify(order_text: str) -> dict:
    body = {
        "state": order_text,                   # 脱敏后的工单证据
        "model": "jev-latest",
        "questions": {
            "failure_mode": {
                "type": "choice",
                "instructions": "判断最可能的故障子系统",
                "criteria": CRITERIA,          # 你定义的分类体系
            },
            "needs_escalation": {
                "type": "noul",
                "instructions": "安全问题或重复维修未解决，需升级研发",
            },
        },
    }
    req = urllib.request.Request(
        "https://api.typesafe.ai/v1/systemone",
        data=json.dumps(body).encode(),
        headers={"Authorization": f"Bearer {key}",
                 "Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=60) as r:
        return json.load(r)

result = classify("客户报修天吊DR，探测器校准失败……")
print(result["answers"]["failure_mode"]["choice"])        # detector
print(result["answers"]["failure_mode"]["confidence"])    # 0.69

429/529 时指数退避重试；端点只有一个，没有别的 API 面

CREATE TABLE jev_classifications (
    order_id        TEXT,        -- 工单号
    failure_mode    TEXT,        -- choice 结果（选项 id）
    probabilities   JSONB,       -- 全选项概率分布（整存！）
    confidence      REAL,        -- 置信度
    needs_escalation REAL,       -- noul 概率
    severity_score  REAL,        -- score 分
    input_tokens    INT,
    created_at      TIMESTAMPTZ DEFAULT now()
);

• probabilities 整存 JSONB——别只存最终选项。故障树门概率、Top-2 概率比、校准度评估，全靠这份分布。
• 每天一条校准 SQL：按 confidence 分桶，算每桶实际命中率。说 80% 把握的那批真有 80% 命中 → 校准可信 → 门控阈值才有意义。
• 复盘进分类体系：other 占比 >10% = 缺类信号；某类挤爆 = 该拆；高置信错的样本 = 准则有误导，优先修。

• 跑帕累托 SQL：SELECT 故障现象, COUNT(*) GROUP BY 1 ORDER BY 2 DESC → Top 20
• 归并 6–10 大类 + other，别名写进准则（数据侧，你来）
• 导 100 条脱敏样本 + 标签 → A/B benchmark（工具侧，我来）
• 指标：Top-1 准确率 + 置信度校准度，通过后进 FTA 管线

详细 playbook 见知识库《Jev工单分类-实施流程与成功关键》