Jev 1.13 能力短板

jev-1.13 速度快、经过校准，并且在常识判断上表现出色，但它并非完美。jev-1.13 在 System One 任务上表现最佳。它可能在需要额外间接层级的任务上遇到困难，并且倾向于字面理解。它在需要数值精度的任务上表现不佳。

失败模式的详细说明

字面阅读

jev-1.13 会按字面回答你写出的问题，而不是你心中所想。范围限定词、否定词以及隐含条件都会被照字面理解。问题的回答会基于 instructions 中写出的字面词，而人可能会读出 instructions 背后的意图。

替代做法： 在 instructions 中明确写出精确条件。要具体。把边界情况放入 criteria。当你看到错误答案，并发现自己要解释真正意图时，那个解释就是缺失的那一半 instruction。如果解读无法避免，就把它拆成两个字面问题，然后在代码中合并。

数学与数字

Jev 不是计算器。我们强烈建议把任何数学逻辑放在代码里实现。Jev 在语义类问题上会比在数学类问题上表现更好。

计数

jev-1.13 无法可靠地计数。这包括：单词中的字符数、段落中某个词的出现次数，以及长列表中条目的数量。模型识别的是答案的形态，而不是逐个清点，错误也会随着计数对象规模的增大而增多。

在提出计数问题之前，先想想为什么这个计数需要交给模型。如果计数单位是普通正则或解析器可以找到的，那么计数应当交给代码，模型也就无从插手。

替代做法： 在代码中计数。当你想统计符合某些条件的条目时，先在代码里遍历候选对象，对每个对象单独问一个问题，然后自己把答案加起来。

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # up to you on what you want the threshold to be, depends on your usecase.

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)))

数值表示

jev-1.13 在语义表示上的表现优于在纯数值表示上的表现。例如，使用 hex 值描述颜色的题目，会比使用英文颜色名的题目表现更差。给定 RGB 三元组或 hex 值，它无法可靠地判断两个值是否接近。

类似地，关于高层编程语言的问题，会比关于底层汇编或二进制编码指令的问题表现更好。

替代做法： 在代码中完成换算，然后传入计算好的数字或命名好的分桶。把模型留给真正需要判断的部分，例如颜色读起来像不像警告。

用 score 做数学

请勿使用 score 输出（例如期望值和概率）来计算某个 criterion 两个档位之间数值的精确大小。你可以用期望值来判断它是否通过某个阈值，但 jev-1.13 的 score 档位在数值校准上偏弱。它无法通过在最近的两个档位之间插值来帮你还原出精确数字。

日期与时间比较

jev-1.13 把日期当作文本读取，而不是有序量。询问两个日期哪个更早、它们相距多远，或者某个日期是否落在某个区间内，结果都不可靠。在混合格式、相对引用，以及季度、交割窗口、应计期间等业务边界下，表现会更差。

替代做法： 把工作拆开。提取是判断，交由模型处理；算术不是，所以放在代码里。

日期的每个组成都是一个小的封闭集合：十二个月、三十一天、有限范围的年份。这样一来，提取就被转换成一个针对枚举选项的 Choice，而不是自由形式的解析；同时也为显式放置一个"未提及"选项留出了空间，让缺失的部分被报告出来而不是被猜测。代码再把各个组成部分组装成真正的日期，并接管后续所有步骤，包括排序、时长、偏移和星期。

date extraction cookbook 提供了完整示例，包括相对日期与置信度分流。

间接引用

包含双重否定或复杂间接引用的 instructions，回答的可靠性较低。关于"属性之属性"的问题，或者需要多跳推理的问题，都会带来准确率的损失。

替代做法： 尽可能直接地编写 instructions。如果可能，按名称指明 state 中相关的部分。

状态过大且充满无关细节

随着 state 中无关内容增多，准确率会下降。无关细节会充当干扰项，状态越大，也越难看出输入中哪一部分导致了错误答案。

替代做法： 先在代码中检索并过滤，只发送问题真正需要的字段。当无法在 state 中过滤时，你可以用一个 Noul 来过滤相关性。classifying RAG passages cookbook 提供了一个完整示例。

对抗性内容

state 就是数据，jev-1.13 默认不会把它视作敌对内容。无论是注入的 instruction、刻意误导的框架，还是试图为自身分类辩护的文本，都可能推动答案偏移。我们预期未来会在这方面持续改进。

替代做法： 在 criteria 中写得明确。在面向大量用户部署之前，对集成进行充分测试。

指令与判定标准相互矛盾

当 instructions 和 criteria 要求的内容不一致时，jev-1.13 可能会感到困惑。最优表现来自明确的措辞。例如，一个 Noul 把 true 映射到"否"、把 false 映射到"是"，表现就会更差。目标应是让普通读者都能轻松读懂 instructions。

替代做法： 把 criteria 视作 instruction 的延伸。用清晰且精确的语言让两者保持一致。

选择题选项顺序

在某些情况下，我们观察到 Choice 选项的顺序会影响答案，jev-1.13 会偏向排在更前面的选项。

替代做法： 重新排序选项，再次确认答案是否保持一致。

生成

jev-1.13 并没有训练成用来生成文本。虽然你可以通过串联 Choice 来强行让它生成，但效果不好且速度很慢。对于数据抽取，更好的做法是用正则或生成式模型提取出候选选项，再交给 jev-1.13 选出正确的那一个。

替代做法： 当答案空间有界时，把抽取转化为一个针对这些选项的 Choice，而不是直接询问该值。如果你真的需要生成文本……那是其他模型的工作。

这份文档由 Mintlify（开发者文档平台）构建并托管。