8.0
热点
AI SCORE
技术实践2026-09-23 10:33
Jev 1.13实测：工单分类精度达100%，对比规则引擎和本地LLM
dev.to · AI#Jev#AI决策#对比评测
Editor brief · 编辑速览
开发者在70张合成工单上测试Jev 1.13，分类准确率1.0，优先级0.9857，风险0.9571，与已有规则基线和Ollama分类器对比，评估同一分类法下三种范式的差异。
Jev 1.13 在我的留出集中将所有类别分类都正确了：类别准确率为 1.0000。同一个实验测得的优先级准确率为 0.9857，风险准确率为 0.9571。这些是 70 张合成工单上的结果，并不能证明 Jev 在生产环境中更优。
我决定测试 Jev，是因为在 ops-triage-ai 中我已有两个参考点：一个是确定性规则基线，另一个是使用本地 Ollama 的分类器。问题是这个第三范式——类型化概率决策模型——是否会在同一分类体系下产生不同的结果。
我没有将 Jev 作为自由形式的对话使用，然后再解释其 prose 输出。而是通过 typesafe/jev-1.13 将决策发送至 OpenRouter Decisions API，采用类型化响应和概率分布。实验期间全部 73 个 API 响应均解析为 typesafe/jev-1.13-20260917。
适配器实现了 TriageClassifier 接口，但与 Ollama 分类器和 HybridPolicy 保持独立。我使用 Bun 原生 fetch，未添加任何依赖。Jev 未集成到应用流程中，也未取代本地模型。
我使用了与历史留出基准测试相同的分类体系和相同的 70 个合成标签。所有开发调用均发生在冻结之前。在 commit 4c41e0b 中，我冻结了配置和评估，然后运行留出集一次以获取正式结果。
这一分离很关键：最终集未用于模型调优，也未在相同集合上测量调优效果。样本量虽小且为合成数据，但协议明确了冻结内容和产生这些数字的运行。
Jev 在 66/70 的情况下将类别、优先级和风险三元组完全正确（0.9429）。历史基准测试未为确定性分类器或 Ollama 发出独立的精确元组准确率。因此我无法将 66/70 与单字段指标或混合路径的精确元组进行比较——它们衡量的是不同维度。
在 Jev 的 70 次独立调用中，平均延迟为 569.4 ms，p50 为 545.5 ms，p95 为 712.2 ms，最大值为 1,142.2 ms。报告记录了 90,229 个输入 token，总报告成本为 0.003789618 美元，API 或 schema 失败次数为零。
该成本为本次 OpenRouter 运行的报告金额。历史 Ollama 基准测试未发出成本或独立延迟数据。其公布的 6-7 秒描述的是完整混合路径，而非与独立 Jev 调用的等效比较。
Jev 保留了概率分布、连续置信度以及 top-1/top-2 边界。这为评估决策提供了更多信息，但并不能保证决策本身是正确的——一个 HIGH 风险错误分类也有 0.86 的置信度。
在这个观测数据集上，探索性校准分析报告的 Brier 分数为：类别 0.0005、优先级 0.0386、风险 0.0800；top-1 ECE 分别为 0.0054、0.0329 和 0.0226。这些是 70 张合成工单的统计数据，每个范围内的样本很少。它们并不能证明概率已针对真实工单进行了校准。
当要求全部三个置信度值都达到 0.80 的阈值时，70 张工单中有 54 张仍被覆盖，且所有被覆盖案例的观测三元组均正确。在 0.90 时，70 张中有 51 张仍被覆盖，同样实现了 100% 的观测精确准确率。
这不能定义生产环境阈值。分母很小，样本是合成数据，该结果也不能建立超出此集合的校准或性能。这是一个假设，需要用代表性数据和单独定义的审查标准来测试。
我会保持当前决策：确定性基线和 Ollama 保留在现有评估和混合策略中；Jev 留在基准测试/评估阶段。在任何集成之前，我会扩展和多样化标记数据，重复冻结评估以衡量方差，并定义人工审查和严重程度错误如何纳入验收标准。
有用的结果不是"Jev 赢了"。第三种范式在一次可复现的运行中产生了不同的可测量信号，并具有明确的限制——这些是指导下一次评估的材料，而不是证明生产替换合理的依据。
Repository: ops-triage-ai on GitHub
Jev 1.13 冻结提交的留出报告：jev-1.13-held-out-4c41e0b.md
运行 JSON 产物：jev-1.13-held-out-4c41e0b.json