Jev 1.13 的参差之处

Jev 并不完美。以下是我们已知的 jev-1.13 存在的一些参差之处。其中许多问题将在后续版本中修复。

jev-1.13 快速、经过良好校准，并擅长常识性判断，但它并不完美。jev-1.13 在 System One 任务上表现最佳。它在需要多层间接引用的任务上可能表现吃力。它的理解可能相当字面化。它在需要数值精度的任务上表现不佳。

失败模式详解

字面解读

jev-1.13 回答的是你写下的问题，而不是你想问的问题。限定词、否定词和隐含条件都会按字面含义解读。问题会根据 instruction 中写下的文字来回答，而人则可能会读出 instruction 背后的意图。

替代做法：在 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 在语义表示上的表现优于数值表示。例如，使用十六进制值提出的颜色问题，其表现会逊于使用英文名称的问题。给定 RGB 三元组或十六进制值时，它无法可靠地判断两个值是否彼此接近。

同样，关于高级编程语言的问题会比关于低级汇编或二进制编码指令的问题表现更好。

替代做法：在代码中完成转换，传入计算好的数值或一个命名分桶。把真正属于判断的部分留给模型，例如某种颜色是否带有警告意味。

使用 score 做数学运算

请不要使用 score 输出（例如期望值和概率）来计算某个数值在标准两个级别之间的精确大小。你可以用期望值判断是否通过某个特定阈值，但 jev-1.13 的 score 级别在数值校准方面较弱。它无法通过在相邻两个级别之间插值来帮你还原精确数值。

日期与时间比较

jev-1.13 把日期当作文本读取，而不是有先后顺序的量。询问两个日期哪个更早、相距多远，或者某个日期是否落在某个区间内，结果都不可靠。在格式混杂、相对引用以及季度、结算窗口、计提期间等领域边界的情况下，问题会更严重。

替代做法：拆分工作。提取是一种判断，所以交给模型；算术不是，所以放在代码中。

日期的每个组成部分都是一个小型封闭集合：十二个月份、三十一个可能的日期、有界的年份范围。这让提取变成在枚举选项上做 Choice，而不是自由格式的解析，也让你可以放一个明确的"未提及"选项，从而让缺失的部分被报告出来而不是被猜测。代码把各部分组装成真实日期，并负责之后的一切，包括先后顺序、时长、偏移量和星期。

日期提取实战指南包含完整可用的版本，涵盖相对日期和置信度门槛。

间接引用

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

替代做法：尽可能直白地书写 instruction。可能的话，按名称指明 state 中的相关部分。

充满无关细节的大体量状态

随着 state 中与决策无关的内容增多，准确率会下降。无关细节会充当干扰项，而庞大的 state 也让人更难判断输入的哪一部分导致了错误答案。

替代做法：先在代码中检索和过滤，只发送问题所需的字段。当无法在 state 层面过滤时，可以用 Noul 来过滤相关性。分类 RAG 段落实战指南中有一个完整示例。

对抗性内容

State 是数据，jev-1.13 默认不会把它当作有敌意的内容对待。为对抗性地引导模型而编写的内容——无论是注入的指令、刻意误导的表述框架，还是为自身归类辩护的文字——都可能改变答案。我们预计未来会在这方面有所改进。

替代做法：在 criteria 中写明确。在向大量用户部署之前，先彻底测试你的集成。

相互矛盾的 instructions 与 criteria

当 instructions 与 criteria 要求的内容不一致时，jev-1.13 可能会感到困惑。最佳表现来自清晰的措辞。例如，true 对应"否"、false 对应"是"的 Noul 表现会更差。力求让 instruction 便于普通人阅读和理解。

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

常识性的结构不变量

jev-1.13 极为一致，这意味着对于语义相似的输入，你应该预期得到数量上相近的输出。 然而，人们可能想象应当成立的许多结构不变量，模型其实并不保证。

例如，针对工单"这个版型我不满意。我有什么选择？"，把"客户是否在要求退款？"分别作为 Noul 和一个是/否 Choice 来提问：

可比较的数值是 noul 和 probabilities["yes"]，而对于 Noul 问题该如何解读 Choice 的输出与置信度，或者反过来该如何解读，并不直观。

同一个问题及其否定形式"客户是否在要求退款以外的事项？"，作为两个 Noul 用于工单"同一订单我被扣了两次款。能有人查一下吗？"：

有很多原因可能导致 P(noul) 与 1 - P(not noul) 不具备直接可比性。

替代做法：不要依赖预期的结构不变性，并用直截了当表达你意图的方式给问题措辞。不要把在 Noul 上调好的阈值搬到 Choice 上，也不要要求模型在各自独立的问题之间满足算术恒等式。在选项上做一次 Choice 与每个选项各做一次 Noul 回答的是不同的问题：Choice 是相对的，用来确定哪个选项；而每个 Noul 是绝对的，可能对所有选项都偏低。技能推荐实战指南在同一份候选清单上同时使用了两者：用 Choice 选出一个技能，用 Noul 决定是否真的要推荐一个。

文本生成

jev-1.13 没有经过文本生成训练。虽然你可以通过串联 Choice 强行让它生成，但效果不佳且非常慢。对于数据提取，更好的做法是用正则表达式或生成式模型提取可能的选项，再让 jev-1.13 挑出正确的提取结果。

替代做法：当答案空间有界时，把提取变成在选项上做 Choice，而不是直接索要取值。如果你确实需要生成文本……为此还有其他模型。