6.1 分类：一张选项表走天下

6.1 分类：一张选项表走天下

本节摘要：分类是 Jev 最直白的用法，也是官方基准测试的主战场（宣称比可比 LLM 快至 200 倍、便宜至 400 倍——自报上界）。做法就一句话：一个 Choice，选项即类别，务必带 other。本节讲透分类质量真正的决定因素——选项表：上线前过"三查"（具体性：描述写给阅卷老师；覆盖性：有逃生门且 other 占比受监控；判别性：选项间排他），上线后用 50~100 条人工标注跑混淆矩阵，盯两件事——哪两类互相混、other 是否被滥用。记住本章的锚点：分类的上限不在模型，在你的选项表。

学习目标

阅读完本节，你应当能够：

1. 写出一份通过"三查"的分类请求。
2. 用混淆矩阵定位选项表的结构性问题。
3. 把 other 占比变成选项表的迭代信号。

一、最小可用的分类请求

{
  "topic": {
    "type": "choice",
    "instructions": "将用户反馈归类。判别标准：以用户的主要不满为准，而非提到的话题",
    "criteria": {
      "bug":          "功能不按预期工作、报错、崩溃",
      "ux":           "能用但难用：流程绕、找不到入口、交互反直觉",
      "pricing":      "价格贵、套餐不合理、付费障碍",
      "feature_req":  "希望增加新功能或新内容",
      "other":        "以上皆非，或混杂不清"
    }
  }
}
​

注意 instructions 里写的是判别标准（"以主要不满为准"）而不是任务描述（"请分类"）——遇到"支付页太丑还总报错"这种复合反馈时，这条标准决定它归 bug 还是 ux。

官方基准数字供参考：TypeSafe 宣称 Jev 在分类任务上"比可比 LLM 快至 200 倍、便宜至 400 倍"（workflow 评测上界：193.6 倍 / 444.6 倍，基线为 GPT-6 Astra 与 Fable 5.1 均值，官方自认属"真实收益偏高端"）。你的场景收益多少，用第 9 章方法自测。

二、选项表三查

一查具体性：每个选项的描述是"具体情形"还是"抽象程度词"？（第 3.2 节准则一的完整清单。）

二查覆盖性：有 other 逃生门吗？上线后监控 probabilities["other"] 的占比：

other 高频出现      → 选项表没覆盖真实流量，该细分了
other 几乎不出现    → 覆盖良好；也可顺带检查是否"从不给不确定留出口"
​

三查判别性：任取两个选项，问自己"有没有一条输入会同时满足两者的描述"？有——要么合并，要么补排他性描述：

❌ technical: "产品问题"     app_issue: "应用问题"
✅ technical: "产品自身故障、报错"     app_issue: "用户不会用、操作疑问"
​

💡 选项表是活的：它不是一次设计定型的静态配置，而是"三查 → 上线 → 混淆矩阵 → 修订"循环驱动的活文档。修订选项表 = 改模型，必须重跑回归集（第 9.1 节）。

三、混淆矩阵：分类的体检报告

用 50~100 条人工标注样本，跑一遍请求，把结果汇成矩阵（示例数据）：

读法三步：

1. 看对角线：整体准确率（本例 68/80 ≈ 85%）；
2. 看双高格：bug↔ux 双向混（3+2）——两选项判别性不足，回去补排他描述；
3. 看 other 行/列：真实类被推进 other（说明描述写得太窄），或 other 被当垃圾场（说明选项表缺类别）。

混淆矩阵的完整工程化（含自动化脚本思路）在第 9.1 节回归集一节展开。

四、高频变体

本节要点回顾

1. 做法：一个 Choice + 带逃生门的选项表；instructions 写判别标准。
2. 三查：具体性、覆盖性（监控 other 占比）、判别性（排他描述）。
3. 体检：50~100 条标注跑混淆矩阵——双高格补判别性，other 异常查覆盖。
4. 红线：改选项表 = 改模型，必须重跑回归集。

归堆之上再加一个维度——选项就是下游的处理路径——分类就变成了路由，而且"错误代价"突然变得可计算。下一节见。