Jev 1.13 的锯齿

Jev 并不完美。以下是我们在 jev-1.13 上已知的一些锯齿边缘。其中许多会在后续版本中修复。

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

#失败模式的详细说明

#字面理解

jev-1.13 回答的是你写下的问题，而不是你想问的那个问题。限定词、否定词与隐含条件都按字面理解。问题会依据 instruction 中写下的字面措辞来回答，而人则可能读出 instructions 背后的意图。

改为： 在 instructions 中写明确切条件。要具体。把边界情况放进 criteria。当你看着一个错误答案，并开始解释你真正想表达的意思时，那段解释就是这条 instruction 缺失的另一半。在解释不可避免的地方，把它拆成两个字面问题，再在代码中合并结果。

#数学与数字

Jev 不是计算器。我们强烈建议把任何数学逻辑都在代码中实现。Jev 在语义问题上的表现会优于数学问题。

#计数

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

在提出计数问题之前，先问一问这个计数为什么需要模型。如果计数单位是正则表达式或解析器能够找到的东西，那么这个计数就该放在代码里，模型帮不上忙。

改为： 在代码中计数。当你想统计符合某些 criteria 的条目数时，在代码中遍历候选对象，为每一项提出一个问题，然后自己把答案加起来。

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 的输出（例如期望值与概率）来计算某个数字在 criteria 的两个等级之间的确切大小。你可以用期望值检查它是否越过某个特定阈值，但 jev-1.13 的 score 等级在数值校准方面较弱。它无法通过在最接近的两个等级之间做插值来帮你还原出确切的数字。

#日期与时间比较

jev-1.13 把日期当作文本来读取，而不是当作有大小顺序的量。询问两个日期哪个在前、相隔多久，或某个日期是否落在某个时间窗内，都是不可靠的。格式混杂、相对指代，以及季度、结算窗口、计息期这类领域边界，都会让情况更糟。

改为： 把工作拆开。抽取属于判断，所以交给模型。算术不属于判断，所以留在代码中。

日期的每个组成部分都是一个小的封闭集合：十二个月、三十一种可能的日、一个有界的年份范围。这把抽取从自由形式的解析变成了对枚举选项的 Choice，也让你有地方放置一个显式的「未说明」选项，从而让缺失的部分被报告出来而不是被猜测。代码把这些部分组装成真正的日期，并负责其后的所有事情，包括排序、时长、偏移与星期几。

日期抽取实践手册中有完整的示例版本，包括相对日期与置信度门控。

#间接性

带有双重否定或复杂间接性的 instructions，回答的可靠性会下降。关于「某个属性的属性」的问题，或需要多跳推理的问题，都会牺牲准确性。

改为： 尽可能直接地撰写 instructions。在可能的情况下，用名称指明状态中相关的部分。

#充满无关细节的大状态

当状态中与决策无关的内容增多时，准确性会下降。无关细节会起干扰作用，而庞大的状态会让你更难判断是输入的哪一部分产生了错误答案。

改为： 先在代码中检索与过滤，只发送问题需要的字段。当无法在状态中过滤时，你可以用 Noul 来筛选相关性。对 RAG 段落进行分类实践手册中有一个完整示例。

#对抗性内容

状态是数据，jev-1.13 默认不会把它当作有敌意的内容。为对抗性地操纵模型而撰写的内容，无论是注入的 instruction、刻意误导的表述框架，还是为自身分类辩护的文本，都可能改变答案。我们预期未来会在这一点上有所改进。

改为： 在 criteria 中写清楚。在向大量用户部署之前，彻底测试你的集成。

#自相矛盾的 instructions 与 criteria

当 instructions 与 criteria 要求的是不同的东西时，jev-1.13 可能会困惑。清晰措辞能带来最佳表现。例如，一个把 true 映射为否、把 false 映射为是的 Noul，表现会更差。目标是写出普通人容易读懂、容易理解的 instructions。

改为： 把 criteria 视为 instruction 的延伸。用清晰、精确的语言让两者保持一致。

#常识性结构不变量

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，而不是直接索要那个值本身。如果你确实需要生成文本……那有其他模型可以做这件事。