Jev 1.13 的粗糙边缘

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

失败模式详解

字面化解读

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

**替代做法：**在 instructions 中写出确切的条件。要具体。把边界情况放进判定标准中。当你看到一个错误答案，并发现自己在解释你真正的意思时，那段解释就是指令中缺失的另一半。在无法避免解读的地方，把它拆成两个字面化的问题，然后在代码中组合结果。

数学与数字

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，而不是自由格式的解析，也让你有地方放置显式的“未说明”选项，从而让缺失的部分被如实报告而不是被猜测。代码把这些部分组装成真正的日期，并接管之后的一切，包括排序、时长、偏移和星期几。

日期提取实战指南提供了完整的实现版本，包括相对日期和置信度门控。

间接引用

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

**替代做法：**尽可能直接地编写指令。可能的话，按名称指明状态中相关的部分。

充满无关细节的大型状态

随着状态中与决策无关的内容增多，准确性会下降。无关细节会起到干扰作用，而大型状态让人更难判断是输入的哪一部分导致了错误答案。

**替代做法：**先在代码中检索和过滤，只发送问题需要的字段。当无法在状态中过滤时，可以使用 Noul 来筛选相关性。RAG 段落分类实战指南提供了完整示例。

对抗性内容

状态是数据，jev-1.13 默认不会把它视为恶意的。以对抗方式引导模型的内容——无论是注入的指令、刻意误导的表述框架，还是为自己所属分类辩护的文本——都可能改变答案。我们预计未来会在这方面改进。

**替代做法：**在判定标准中写明确。在部署给大量用户之前，充分测试你的集成。

相互矛盾的指令与判定标准

当 instructions 和 criteria 要求的东西不一致时，jev-1.13 可能会困惑。最佳表现来自清晰的措辞。例如，一个 true 映射到“否”、false 映射到“是”的 Noul，表现会更差。指令要做到让普通人容易阅读和理解。

**替代做法：**把判定标准视为指令的延伸。用清晰、精确的语言让两者保持一致。

常识性结构不变量

jev-1.13 极为一致，也就是说，对于语义相似的输入，应当预期得到数值上相似的输出。然而，许多人们以为会成立的常识性结构不变量，模型并不能保证。

例如，对于工单“我不满意这个合身度。我这里有哪些选择？”，分别用 Noul 和是/否 Choice 询问“客户是否在要求退款？”：

可以对比的数字是 noul 和 probabilities["yes"]，但无论是用 Choice 的输出和置信度来解读 Noul 问题，还是反过来，都不那么直观。

同一问题及其否定形式——“客户是否在要求退款以外的其他东西？”——作为两个 Noul 应用到工单“同一笔订单收了我两次钱。能有人查一下吗？”上：

P(noul) 与 1 - P(not noul) 无法直接比较的原因有很多。

**替代做法：**不要依赖想象中的结构不变性，把问题措辞成直接表达你想要的意思。不要把在 Noul 上调好的阈值照搬到 Choice 上，也不要要求模型在多个独立问题之间满足算术恒等式。对多个选项做一个 Choice 与每个选项各做一个 Noul 回答的是不同的问题：Choice 是相对的，解决的是选哪一个选项；而每个 Noul 是绝对的，可能对所有选项都低。技能推荐实战指南在同一个候选列表上同时使用了两者：用 Choice 挑选技能，用 Noul 决定到底要不要推荐。

生成

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

**替代做法：**当答案空间有界时，把提取变成对选项的 Choice，而不是直接索要值本身。如果你真的需要生成文本……还有别的模型可以做这件事。