Jev 1.13 jaggedness
TypeSafe AI 官方「模型缺陷清单」页面（docs.typesafe.ai/model-jaggedness/jev-1.13）的来源摘要。该页适用于 jev-1.13，官方标注最后审阅日期 2026-09-17。在一份产品文档里主动列出自身 9 类失败模式相当罕见，也是判断「这个模型能不能用」最有价值的一手材料。原始语料见 processed/jev-原始资料/官方-文档/model-jaggedness__jev-1.13.md。
一句话摘要
官方承认 jev-1.13 虽然快、校准、擅长常识判断，但在字面理解、数值精度、多层间接、无关上下文、对抗内容、常识性结构不变式、文本生成等方面存在系统性缺陷，并逐条给出「应该改用哪种做法」。
关键要点
官方总述：jev-1.13 最擅长系统一（System One）任务；它可能在需要额外一层间接（indirection）的任务上挣扎，理解可以相当字面，在需要数值精度（numeric precision）的任务上挣扎。
一、九类失败模式总表（官方原表）
| # | 失败模式 | 官方建议 |
|---|---|---|
| 1 | 字面理解（Literal reading） | 写出精确的条件与每个可用选项的判据 |
| 2 | 数学与数字（Math and Numbers） | 把算术留在代码里 |
| 3 | 日期与时间比较（Date and time comparison） | 抽取各组成部分；在代码里比较 |
| 4 | 多层间接（Indirection） | 减少跳跃层级；明确指向 state 中相关部分 |
| 5 | 塞满无关细节的大 state | 先过滤；只发问句需要的内容 |
| 6 | 对抗内容（Adversarial content） | 写精确的提示，并在部署前测试边界情况 |
| 7 | 指令与判据自相矛盾 | 让判据与指令对齐 |
| 8 | 常识性结构不变式 | 每个决策只问一种问法；在代码里强制恒等式 |
| 9 | 生成（Generation） | 改用生成模型 |
二、逐条详解（表现 + 官方建议）
1. 字面理解（Literal reading）
- 表现：「它回答的是你写下的问题，而不是你想问的问题。」限定词、否定、隐含条件都按字面读；一则问句会基于
instructions里写出来的词作答，而人可能会读出指令背后的意图。 - 官方建议：在
instructions里陈述精确条件，要具体；把边界情况放进criteria。官方给了一条自查法：「当你看着一个错误答案、发现自己正在解释『我其实想说的是……』时，那句解释就是指令缺失的另一半。」当解释不可避免时，拆成两个字面问句，在代码里组合。
2. 数学与数字（Math and Numbers）
- 总则：「Jev 不是计算器。」官方强烈建议把任何数学逻辑放到代码里；它在语义问题上的表现优于数学问题。
- 数数（Counting）：不可靠——包括数一个词里有多少字符、一个词在段落里出现几次、长列表里有多少项。官方解释其机制：「模型识别的是答案的『形状』，而不是真的在清点，误差随被数对象的规模增长。」
- 官方建议：在代码里数。 若单位是正则或解析器能识别的，计数就属于代码。要「数有多少项满足某条件」，就在代码里遍历候选，每一项问一个问句，再自己把答案加起来（官方给了 Noul 逐项判断 + 阈值求和的可运行示例；阈值示例写成
YES = 0.5并注明「取决于你的用例」）。
- 官方建议：在代码里数。 若单位是正则或解析器能识别的，计数就属于代码。要「数有多少项满足某条件」，就在代码里遍历候选，每一项问一个问句，再自己把答案加起来（官方给了 Noul 逐项判断 + 阈值求和的可运行示例；阈值示例写成
- 数值表示（Numeric representations）：语义表示优于数值表示。例如用十六进制值问颜色，表现不如用英文颜色名；给了 RGB 三元组或 hex 值，它无法可靠判断两个值是否相近。同理，问「高级编程语言」优于问「底层汇编或二进制编码指令」。
- 官方建议：转换放到代码里，传入算好的数或命名好的分桶；把模型留给真正属于判断的部分（比如「这个颜色读起来像警告色吗」）。
- 用 Score 做数学：官方明确请求不要用 Score 的输出（期望值、概率）去推算某个数在两级之间的精确量级；可以用期望值检查是否越过某个阈值，但
jev-1.13的 Score 等级在数值校准上很弱，无法靠「在最近两级间插值」反推准确数值。
3. 日期与时间比较（Date and time comparison）
- 表现：「
jev-1.13把日期当文本读，而不是当作有序数量。」问两个日期谁在先、相距多远、是否落在某窗口内都不可靠；混合格式、相对引用（如「上个月」）以及领域边界（季度、结算窗口、计息期）会让它更糟。 - 官方建议：拆分工作——抽取是判断，交给模型；算术不是，留在代码。 日期的每一部分都是小的闭集：12 个月、31 个可能的日子、有界范围的年份；据此把抽取变成在枚举选项上的 Choice，而不是自由解析，并且留一个显式的「未述明」选项，让缺失部分被报告而不是被猜。代码负责把各部分组装成真正的日期，并接管其后的排序、时长、偏移、星期几。
- 官方指引：
date extraction cookbook有完整版本，含相对日期与置信度门控。
4. 多层间接（Indirection）
- 表现：带双重否定或复杂间接的指令，答案可靠性更低；问「某个属性的属性」、或需要多次推理跳跃的问题，都会损失准确率。
- 官方建议：尽可能直白地写指令；可能时按名字指出 state 中的相关部分。
5. 塞满无关细节的大 state（Large state full of irrelevant detail）
- 表现：准确率随 state 中与决策无关的内容增长而下降。无关细节充当干扰项（distractor），而且大 state 让「输入里哪一部分导致了错误答案」更难定位。
- 官方建议：先在代码里检索与过滤，只发问句需要的字段；无法在 state 里过滤时，可以用一个 Noul 做相关性过滤。官方给出
classifying RAG passages cookbook作为完整示例。 - 官方附注：
jev-1.13上下文窗口有上限，具体词元限额见 Models 页（每请求 64k 词元，state + 最长问句 ≤ 32k）。
6. 对抗内容（Adversarial content）
- 表现：「state 是数据，而
jev-1.13默认不把它当敌意内容对待。」为对抗性操控模型而写的内容——注入的指令、故意误导的表述、或「为自己的归类辩护」的文本——都能推动答案。官方声明期望未来改进这一点。 - 官方建议：在
criteria里写明确；在部署给大量用户之前彻底测试你的集成。
7. 指令与判据自相矛盾（Contradictory instructions and criteria）
- 表现：当
instructions与criteria要求的是不同的事时，模型可能会困惑。官方举例：一个 Noul 里true映射到「否」、false映射到「是」，表现会更差。 - 官方建议：把
criteria当作指令的延伸；用清晰精确的语言把两者对齐。目标是写一个普通人容易读懂的指令。
8. 常识性结构不变式（Common-sense structural invariants）
- 表现：官方强调
jev-1.13极度一致（extremely consistent）——语义相似的输入应期待量化上相似的输出；但很多「人以为必然成立」的结构不变式，模型并不保证。官方给了两个具体数字例：-
同一张工单「I’m not happy with the fit. What are my options here?」，问「客户是否要求退款？」：
Noul noulChoice yesChoice noChoice confidence0.22 0.01 0.99 0.97 即是非题问出 0.22，同一个问题改成二选一选择题，选「是」的概率只有 0.01。官方指出：可比的数字只有
noul与probabilities["yes"]，「而如何用 Choice 的输出与置信度去解释 Noul 问题（或反过来），并不明显」。 -
同一个问题与它的否定——「客户是不是要求退款以外的东西？」——作为两个 Noul 问同一张工单（“I was charged twice for the same order. Can someone look into this?”）：
refundnot_refundSum 0.72 0.47 1.19 两个概率之和是 1.19，本该接近 1。官方解释：「
P(noul)与1 - P(not noul)可能不可直接比较，原因很多。」
-
- 官方建议：不要依赖想象中的结构不变性；问题怎么问，就写成你想要的直接意思。不要把在 Noul 上调好的阈值搬到 Choice 上；也不要用算术恒等式去要求模型在多个独立问句之间自洽。官方给了机制解释：「一个跨选项的 Choice 与『每个选项各来一个 Noul』回答的是不同的问题：Choice 是相对的，解决『哪一个』；而每个 Noul 是绝对的，可以对所有选项都取低值。」
skill suggestion cookbook在同一份候选短名单上同时用了两者——Choice 用来选技能，Noul 用来判断「到底要不要推荐」。
9. 生成（Generation）
- 表现：
jev-1.13不是为生成文本训练的。你可以通过串联多次选择强迫它生成，但效果不好而且非常慢。 - 官方建议：抽取场景下，先用正则或生成模型产生候选，再让
jev-1.13从候选中挑出正确的那一个；当答案空间有界时，把抽取改写成在选项上的 Choice，而不是直接索要那个值。「如果真需要生成文本……那有别的模型干这个。」
三、官方在页尾重申的四条红线
官方以 Info 框再次提醒，避免以下做法：
- 问模型「代码能精确算出来」的东西；
- 把好几个判断藏在同一个问句里；
- 系统二（System Two）类任务：更多层间接；
- 在
state里给超出问句需要的上下文——「Jev 会受上下文腐坏（Context Rot）影响，state 里无关的材料会让你损失准确率。」
官方同时邀请用户通过 Discord 提交新发现的失败模式。
重要引用
“
jev-1.13answers the question you wrote, not the one you meant.”
jev-1.13回答的是你写下的问题，不是你想问的问题。
“Jev is not a calculator. We strongly recommend implementing any mathematical logic in code.”
Jev 不是计算器。我们强烈建议把任何数学逻辑放到代码里实现。
“
jev-1.13reads dates as text, not as ordered quantities.”
jev-1.13把日期当文本读，而不当作有序数量。
“State is data, and
jev-1.13does not treat it as hostile by default.”state 是数据，而
jev-1.13默认不把它当作敌意内容。
“Don’t carry a threshold tuned on a Noul over to a Choice, and don’t hold the model to arithmetic identities between separate questions.”
不要把在 Noul 上调好的阈值搬到 Choice 上，也不要用算术恒等式去要求模型在两个独立问句之间自洽。
“A Choice over options and one Noul per option answer different questions: the Choice is relative, settling which option, while each Noul is absolute and can be low for all of them.”
一个跨选项的 Choice 与「每个选项各来一个 Noul」回答的是不同的问题：Choice 是相对的，解决的是「哪一个」；而每个 Noul 是绝对的，可以对所有选项都取低值。
“Jev suffers from context rot, so unrelated material in the
statecosts you accuracy.”Jev 会受上下文腐坏影响，所以
state里无关的材料会让你损失准确率。