文档索引

在以下地址获取完整的文档索引：https://docs.typesafe.ai/llms.txt 使用此文件可以在进一步探索之前发现所有可用页面。

Jev 1.13 的不稳定性

Jev 并不完美。以下是我们已知的关于 jev-1.13 的一些粗糙边缘（jagged edges）。其中许多将在后续版本中修复。

jev-1.13 速度快、经过校准，擅长常识判断，但它并不完美。jev-1.13 在 系统一 任务上表现最佳。它在需要额外间接引用层级的任务上可能会遇到困难。它的理解可能非常字面。它在需要数值精度的任务上会感到吃力。

详细失败模式

字面解读

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 三元组或十六进制值时，它无法可靠地判断两个值是否在数值上接近。

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

替代方案： 在代码中进行转换，并传入计算后的数字或命名桶。保留模型用于真正需要判断的部分，例如判断颜色是否读取为警告。

使用分数的数学

请不要使用分数输出（例如期望值和概率）来计算标准两个级别之间数字的确切幅度。你可以使用期望值来检查它是否通过特定阈值，但 jev-1.13 的分数级别在数值校准方面较弱。它无法通过最近两个级别之间的插值来帮助你重建确切的数字。

日期和时间比较

jev-1.13 将日期读取为文本，而不是有序量。询问两个日期中哪个在前、它们相隔多远、或者一个是否落在某个窗口内是不可靠的。混合格式、相对引用和领域边界（如季度、结算窗口和应计期间）会使情况变得更糟。

替代方案： 拆分工作。提取是一个判断，所以交给模型。算术不是，所以保留在代码中。

日期的每个部分都是一个小的封闭集：十二个月、三十一个可能的日期、有界的年份范围。这将提取转变为对枚举选项的 Choice，而不是自由格式解析，并为你提供放置显式 "未说明" 选项的位置，以便报告缺失的部分而不是猜测。代码将各个部分组装成真实日期，并承担之后的一切，包括排序、持续时间、偏移量和星期几。

日期提取 cookbook 包含完整的版本，包括相对日期和置信度门控。

间接性

包含双重否定或复杂间接引用的指令回答得不太可靠。关于属性的属性或需要多次推理跃迁的问题会降低准确性。

建议： 尽可能直接地撰写指令。在可能的情况下，通过名称明确标识状态的相关部分。

充满无关细节的大型状态

当状态中包含与决策无关的内容时，准确性会下降。无关细节会起到干扰作用，而大型状态使得难以分辨输入的哪一部分导致了错误答案。

替代方案： 先在代码中检索和过滤，仅发送问题所需的字段。当无法在状态中过滤时，可以使用 Noul 过滤相关性。分类 RAG 段落 cookbook 包含一个完整示例。

对抗性内容

状态是数据，jev-1.13 默认不将其视为具有敌意。旨在对抗性引导模型的内容（无论是注入的指令、故意误导的框架，还是论证自身分类的文本）都可能改变答案。我们期望在未来改进这一点。

建议： 明确指定判断标准。在向大量用户部署之前，请对集成进行彻底测试。

矛盾的指令和标准

当 instructions 和 criteria 要求不同的内容时，jev-1.13 可能会感到困惑。最佳性能来自清晰的措辞。例如，true 映射到否而 false 映射到是的 Noul 表现较差。旨在编写普通人易于阅读和理解的指令。

替代方案： 将标准视为指令的延伸。使用清晰和精确的语言对齐两者。

常识性结构不变量

jev-1.13 具有极高的一致性，这意味着对于语义相似的输入，你应该预期得到定量相似的输出。然而，存在许多你可能认为成立的结构性不变量（invariants），但模型并不保证这些不变量成立。

例如，针对工单 "我对合身度不满意。我有哪些选择？"，分别作为 Noul 和是/否 Choice 提出的 "客户是在要求退款吗？" 问题：

可比较的数字是 noul 和 probabilities["yes"]，但对于 Noul 问题的 Choice 输出和置信度，或者反之，如何解读并不明显。

针对工单 "我对同一笔订单被收取了两次费用。有人能看看吗？"，相同的问题及其否定形式 "客户是否在要求退款以外的其他事项？"，作为两个 Nouls：

P(noul) 和 1 - P(not noul) 可能不可直接比较的原因有很多。

建议： 不要依赖预期的结构不变量，并确保问题的措辞直接表达你的意图。不要将在 Noul 上调整过的阈值直接应用到 Choice 上，也不要要求模型在不同问题之间保持算术恒等式。针对选项的 Choice 与针对每个选项的 Noul 回答的是不同的问题：Choice 是相对的，用于确定 哪个 选项被选中；而每个 Noul 是绝对的，可能所有选项的值都很低。skill 建议 cookbook 在同一候选列表中同时使用了两者：使用 Choice 来挑选 skill，使用 Noul 来决定是否提供任何建议。

生成

jev-1.13 并非用于生成文本。虽然你可以通过串联选择来强制它生成，但效果不佳且速度极慢。对于数据提取，最好使用正则表达式或生成式模型提取候选项，然后让 jev-1.13 选择正确的提取结果。

建议： 当答案空间有限时，将对值的提取转化为对选项的 Choice，而不是直接询问值本身。如果你确实需要生成文本……有其他模型更适合此用途。