Jev 1.13 官方“参差不齐”页：能力边界与第三方实测对照

先说结论

1. TypeSafe 为 jev-1.13 单开了一页 Model jaggedness，逐条列出 9 类已知失败模式，并给出替代做法。官方定性是“good at common-sense judgment but it is not perfect”，不是全盘否定，而是一份按任务拆解的边界清单。
2. Models 页显示当前版本 ID 是 jev-1.13.0，jev-latest 和 jev-preview 当前都指向它；响应里的 model 字段会回报实际版本，因此 jaggedness 页只对 jev-1.13 这一个版本有效。
3. 第三方 60 例工具调用风险基准（社区二手）显示：清晰题 100%、模糊题 71.4%、对抗题 91.7%，总体 91.7%。分层差异与官方说的“字面阅读、间接推理、对抗内容要小心”方向一致，但两者任务不同，不能直接比较数字。
4. 工程上应做自己的分层评测，把难题单独切出来看，而不是只看总体准确率；同时把算术、日期比较、计数等任务移到代码里。
5. 官方页面署明适用于 jev-1.13，版本升级后可能修复部分问题，必须查看当前版本对应的 jaggedness 页面。

证据与过程

一、这页是什么：官方按任务拆解的 9 类边界

官方在 Model jaggedness（jev-1.13） 页面开头就说：“Jev isn’t perfect. Here are some jagged edges we are aware of with jev-1.13. Many of these will be fixed in later versions.” 这句是官方原话，可以理解为：这是一个版本化的已知问题清单，而不是对模型整体能力的否定。

页面随后把失败模式分成 9 类。逐条看，官方给的并不是“模型很弱”这种笼统结论，而是具体任务场景和推荐做法。以下是官方分类与替代方案（官方数据，按页面顺序）：

1. 字面阅读（Literal reading）：模型回答的是你写出来的问题，而不是你心里想问的问题。限制范围词、否定、隐含条件都会被按字面理解。官方建议把精确条件写进 criteria，把边界情形放进选项；如果发现自己事后解释“我其实是想说……”，那段解释就应该补进指令。
2. 数学与数字（Math and Numbers）：官方明确说“Jev is not a calculator”，强烈建议把数学逻辑放在代码里。其中计数不可靠，官方原话是 jev-1.13 does not count reliably，错误会随计数对象规模增大而变大。
3. 日期和时间比较（Date and time comparison）：官方说模型把日期当文本，而不是有序数量。比较先后、计算间隔、判断是否落在窗口内都不可靠；混合格式、相对日期、季度/结算期等边界会更差。
4. 间接推理（Indirection）：模型在需要额外跳数时才容易出错。官方建议减少 hop，直接指向相关 state。
5. 大段无关状态（Large state full of irrelevant detail）：状态里无关细节太多会干扰判断。建议先过滤，只送该问题需要的状态。
6. 对抗内容（Adversarial content）：建议写精确提示，并在部署前测试边缘样本。
7. 互相矛盾的指令与标准（Contradictory instructions and criteria）：先把指令和 criteria 对齐。
8. 常识结构不变量（Common-sense structural invariants）：每个决策只问一种方式，身份约束放在代码里。
9. 生成任务（Generation）：官方建议改用生成式模型。

官方对总体能力还有一句关键判断：jev-1.13 does the best on System One tasks。也就是说，它最擅长的是快判断、单步决策这类任务；一旦任务需要数值精度、多层间接理解或自由生成，边界就比较明显。

官方在“Math and Numbers”一节给出了一个计数示例。代码块如下，来自官方文档，展示的是“逐个判断、代码加总”的推荐模式：

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # 阈值按业务自己定

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

这个例子的核心不是“如何数水果”，而是说明官方推荐的一种工程用法：不要让模型直接给出总数，而是把大任务拆成多个原子判断，再用代码汇总。这正好呼应了官方在计数问题上的态度：如果正则或解析器能做的计数，就不该让模型做。

二、与 Models 页、Primitives/System One 的口径对齐

Models 页 给出了版本和调用口径。当前模型是 Jev 1.13，版本 ID 为 jev-1.13.0（官方数据）。所有模型都由同一个端点 POST /v1/systemone 服务，请求里的 model 字段决定调用哪一个。别名表中，jev-latest 和 jev-preview 当前都指向 jev-1.13.0。官方特别提醒：别名会随新版本发布而移动，所以响应里的 model 字段会回报实际处理的版本 ID，便于日志记录。

这一点和 jaggedness 页直接相关：如果开发者使用 jev-latest，某天版本升级后，之前针对 jev-1.13 的边界判断可能不再成立。因此官方建议在调过置信度阈值或做过版本适配后，固定具体版本 ID，而不是一直用别名。

价格、速率和上下文长度在 Models 页也有官方数据：价格为每 Btok $42 / 每 Mtok $0.042，输出 token 免费；速率限制为 250,000 tokens/s、1,200 requests/min；上下文长度为每请求 64k tokens，其中 state 加最长单题的预算是 32k tokens；输入仅支持文本，不支持图片、音频、视频。语言支持方面，官方说英语是主要训练语言、当前准确率最好，其他语言包括 CJK 脚本“handled but not equally well”，上线前需要自测。

Models 页还直接链接到 jaggedness 页，并写明：“See Jev 1.13 jaggedness for how accuracy shifts as the state grows.” 这说明官方自己就把“状态增大后准确率变化”当作一个已知变量，和 jaggedness 页里的“Large state full of irrelevant detail”一致。

Primitives (Questions) 页则强调 System One 模型适合快速、聚焦的判断。它把问题拆成 Choice、Score、Noul 三种小型判断，并建议把宽泛任务拆成多个原子问题，再在代码里组合。这个口径与 jaggedness 页完全一致：模型负责那一秒能做出的判断，计算、计数、日期比较、身份约束等则留给代码。

关于校准，官方 System One 概念页把校准放在群体层面讨论，不保证单条正确。这一句在本次写作中我依据的是任务线索，而非逐字核对后的原文，具体见“这次没核实的”。

三、第三方 60 例基准：分层准确率与校准结果

第三方测试来自 Web of Mike 的 60 例基准报告（社区二手，非官方）。它的任务不是官方 jaggedness 页里列的那些演示，而是另一个具体场景：把 agent 工具调用分类为 readonly、destructive、privileged、exfiltration 四类。

测试集共有 60 个手标样本：34 个清晰、14 个模糊、12 个对抗。结果如下（社区二手数据）：

校准方面，社区的观察是：所有错误答案都没有出现在置信度恰好为 1.000 的样本里；jev-latest 的 ECE 为 0.0712，jev-preview 为 0.0505。但作者自己也警告，never 1.000 and wrong 不等于 never high-confidence and wrong。在一次提交运行中，有一条置信度 0.97/0.98 的样本被判错。

这组数字不能直接去比官方 jaggedness 页，因为任务不同、样本不同、口径不同。但方向上是一致的：清晰、常识型判断表现很好；模糊、需要额外判断的样本明显掉到 71.4%；对抗样本虽然这一轮不差，但官方仍建议部署前专门测试边缘样本。也就是说，官方“字面阅读、间接推理、对抗内容需谨慎”的自述，与第三方在模糊层看到的分层下降，至少是同向的。

四、自己的判断：上线前做分层评测，不要只盯总体

这是我的工程判断，不是官方数据，也不是第三方数据。

如果只看 91.7% 的总体准确率，可能会误判模型在自己的生产任务上足够好。但模糊层只有 71.4%，说明一旦任务分布偏向模糊或需要多跳判断的样本，总体指标就会被高估。更合理的做法是：

1. 固定版本号：不要直接用 jev-latest，至少把 jev-1.13.0 或当前具体版本写死，避免版本漂移改变行为。
2. 按难度和任务类型切层：至少分清晰/模糊/对抗，再按长状态、英文/中文、是否包含计数或日期、单跳/多跳等维度切层。
3. 每层单独报告准确率和置信度分布：不仅看准确率，还要看低置信度样本占比，以及高置信度样本里有没有错。
4. 给低置信度留后路：对低于阈值的请求走人工审核、降级或拒绝执行，尤其是在 destructive、privileged、exfiltration 这类高风险动作上。
5. 把非判断任务移出模型：算术、日期比较、计数、显式身份约束等操作放在代码里，模型只做语义判断。
6. 用官方 9 类失败模式逐条构造边界样本：这比随机评估更能暴露问题。

一个基本的分层评测清单可以长这样（自己推算的示意，不是标准答案）：

eval_layers:
  - name: clear
    expected: "hard constraint on accuracy, usually near 100%"
  - name: ambiguous
    expected: "lower than clear; measure confidence spread"
  - name: adversarial
    expected: "test edge cases before deploy"
  - name: long_state
    expected: "compare accuracy vs state length"
  - name: numeric_date
    expected: "prefer code-based components"
  - name: non_english
    expected: "self-test before relying on CJK workloads"

五、风险提示

官方 jaggedness 页明确写有 Applies to jev-1.13，最后审阅时间是 2026-09-17。这意味着版本升级后，这些边界可能被修复，也可能出现新的边界。任何照搬这份清单的做法都必须先确认当前版本号。

第三方基准只有 60 例，作者自己也说样本量小，单次运行的准确率不应被当成稳定值。它的校准结论也只能覆盖该任务集，不代表所有任务都会出现“1.000 置信度一定正确”。另外，官方 Models 页提到速率限制可能动态调整，容量相关的数字不宜当作长期承诺。

这次没核实的

• System One 概念页关于“校准是群体层面、不保证单条正确”的完整原文，本篇未能逐字核对，只按任务线索引用链接并给出概括。
• 官方 jaggedness 页在“Date and time comparison”之后的部分，本次来源正文被截断，未能完整读到第 5、6、7、8、9 类后面的详细示例。
• 第三方基准原始结果文件（themsquared/jev-benchmark）未逐一复核，数据来自 Web of Mike 的报告，属于社区二手。
• 除 jev-1.13 外，是否有其他版本的 jaggedness 页面、以及当前 jev-latest 是否仍指向 jev-1.13.0，未能实时核实。

参考来源

1. TypeSafe AI: Model jaggedness — Jev 1.13（一手）
2. TypeSafe AI: Models（一手）
3. TypeSafe AI: Primitives (Questions)（一手）
4. TypeSafe AI: System One（一手，本次未能逐字核对）
5. Web of Mike: I Benchmarked Jev on Agent Tool-Call Risk（社区二手）