Choice、Score 与 Noul

如何选择基础单元

当答案是一个具名选项时，请使用 Choice，例如队列、技能、类别标签或下一个链接。TypeSafe 显示的问题是“以下哪个选项？”。返回内容包括选择结果、概率和置信度。Criteria 是最多包含 255 个选项的映射。如果有数百个 Wikipedia 链接，就无法全部塞进一个 Choice；Wikiracing 演示会先评分，再从候选短名单中选择。

当答案是简短有序等级上的程度时使用 Score，例如平静 / 沮丧 / 非常沮丧，或 1-5 级严重程度。返回值包括 score、legend、probabilities 和 confidence。Criteria 是包含 2 到 10 个等级的有序数组。不要将插值后的分数当作精确量值。Jev 1.13 的等级不适合还原两个档位之间的具体数值；期望值只应作为阈值检查。

问题可用是或否回答时，请使用 Noul，例如：“这是真的吗？”它返回 0 到 1 的 noul。判定标准可以选择性说明真和假的含义。这里没有置信度字段。接近 0.5 的 Noul 表示不确定，而不是中等强度。不要假设 Noul 等同于只有两个选项的 Choice，也不要把为其中一种调好的阈值直接用于另一种。TypeSafe 的 jaggedness 页面针对同一张工单，并列展示了 0.22 的退款 Noul 和 0.01 的“是”Choice。

并行问题与 ID

同一请求中的问题共用 state，彼此独立并行运行，增加问题几乎不会改变延迟。同一个映射中可以混用 Choice、Score 和 Noul。键由你定义，例如 urgency、department、frustration。对应答案会在相同键下返回。键不会发送给底层模型，也不参与推理。

在循环中生成键时，这条 ID 规则很重要。jaggedness 页面的计数示例会为列表中的每一项提出一个 Noul（item_0, item_1, …），再由 Python 对答案求和。Jev 从不会把这些名称视为 tokens。日志中的名称应保持稳定，才能将重试记录关联回原始映射。

每种基础单元响应共有的返回元数据包括 requestId、timestamp、latency 和 metadata。使用 requestId 关联追踪记录。timestamp 和 latency 只是传输事实，不应作为重新提问的理由。metadata 是附加在核心载荷上的可选内容。请先比较三个基础单元，再将这些共享字段理解为类型化答案外层的封装。

实际使用限制

255 个 Choice 选项是硬性上限，并非建议值。Wikiracing 通过先用 Score 生成候选短名单、再执行 Choice 来突破此限制。如果分类体系有 400 个标签，就需要采用相同的两阶段结构，或构建 Choice 层级。不要指望 API 会接受 256 个。

Score 的 2 到 10 个等级适用于人类可以直接念出的简短量表。100 分制质量量表选错了基础单元；应拆分为原子级 Score，再在代码中相加。1.4 这类位于等级之间的分数属于正常结果，但不应据此还原具体金额。

Noul 没有置信度字段，因此门控依据是 noul 值以及额外添加的第二个问题。常见组合是：用 Noul 判断“这是否属于处理范围”，仅在 noul 较高时才用 Choice 判断“应归入哪个类别”。jaggedness 的不变量记录提醒你，不要把这两个数值视为同一种统计量。

针对同一工单混用全部三种基础单元，是常规结构而非高级技巧。用 Noul 判断紧急程度，用 Choice 判断部门，用 Score 判断挫败程度，随后交给代码处理。这与快速入门 curl 示例中的映射相同。本页的对比旨在帮助你先选定类型，再编写 JSON。

共享封装字段不是第四种基础单元。requestId、timestamp、latency 和 metadata 会随每个答案一同返回，便于追踪调用。产品事实应放在 state 中。如果你正把政策塞进 metadata，应将其移入 Jev 实际读取的对象。

编写 Criteria 时，应确保新同事明天也能读懂。Choice 的选项名称和 Score 的等级名称都是问题的一部分。含糊的标签会让模型在生产环境中按字面误读。

Noul 是专有名称。即使请求的其余部分使用英文叙述，也应保留该拼写。