Choice / Score / Noul：三种决策原语怎么选、怎么写

Jev 的请求结构高度一致：state（要判断的内容）+ model（模型名）+ questions（问题字典）。三种问题类型就是三张不同的「答题卡」。本文的请求/响应示例逐字来自官方文档（2026-09-20 快照），可以放心对着写。

Choice：从固定选项里选一个

什么时候用：答案是无序的封闭集合——哪个团队处理这张工单、哪个产品类目、这段代码是什么语言。

请求里每个 Choice 问题有三个字段：type: "choice"、instructions（要回答的问题）、criteria（选项字典：键是选项名，值是描述）。

{
  "state": "My running shoes arrived in the wrong size. Can I swap them for a size 10?",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "returns": "Exchanges, refunds, wrong or damaged items",
        "shipping": "Delivery status, delays, lost packages",
        "billing": "Charges, invoices, payment problems"
      }
    }
  }
}

响应（答案按你起的 id 归位）：

{
  "model": "jev-latest",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": {
        "shipping": 0.0,
        "returns": 1.0,
        "billing": 0.0
      }
    }
  },
  "usage": { "input_tokens": 330, "output_tokens": 34 }
}

三个返回值各管一件事：choice 是概率最高的选项；probabilities 是全部选项的分布（和为 1）；confidence 由分布形状算出——概率摊在多个选项上就走低。置信度低不是噪声，是信号：概率分布里排第二的选项往往对应真实存在的歧义，你的代码可以据此「给另一个团队抄送一份」。

Score：在有序量表上定位

什么时候用：答案是程度问题——bug 严重程度、客户情绪、相关性。量表以数组给出（至少 2 档、最多 10 档），数组顺序就是档位编号（从 0 起）。

{
  "state": "The export button crashes the settings page in Safari. It works in Chrome, but a few of our customers only use Safari.",
  "questions": {
    "bug_severity": {
      "type": "score",
      "instructions": "How severe is the reported issue?",
      "criteria": [
        "Cosmetic; no impact to functionality",
        "Broken or degraded feature, but workaround exists",
        "Blocking issue; no workaround exists"
      ]
    }
  }
}

与 Choice 最大的不同：返回的 score 是连续位置，可以落在两档之间（比如 1.4 =「比『有变通方案的功能受损』更重，但还够不上『完全阻断』」）。做阈值判断时应该读各档概率与分数的组合，而不是把分数当整数用。

Noul：某条件是否为真

什么时候用：是非判断驱动行为的场景——这条内容要不要拦、该 passage 能不能支撑回答、用户是不是在要求人工。返回一个 0–1 的「是」概率，典型动作是过滤、拦截、触发规则（官方 Confidence-gated routing 模式里的风险分级就是这个用法）。

与前两者一样通过 questions 传入，是封闭问题——具体请求字段以官方 Noul 文档为准，本站暂不展示代码示例以免转述失真。

契约设计的三个高频错误

1. 选项描述不互斥。「退货政策」和「退货进度」都可能出现「退款」字样，模型只能摊概率。官方给的结构化写法是给每个选项加 what（管什么）/ not_for（不管什么）/ examples（示例）——字段名完全由你自定义，模型会看到。
2. 没有兜底选项。清单覆盖不了所有输入时，模型被迫硬选。加一个 other: "以上都不符合"，配合低置信度分流，才是完整契约。
3. 一次一问。官方明确建议把代码可能需要的所有问题放进同一个请求并行求值：加问题的边际延迟很小，代码忽略不需要的答案即可（token 费用照付，但省下的是整轮请求的延迟与限流额度）。

概率 → 代码：一个最小决策骨架

answer = response.answers["department"]

if answer.confidence < 0.3:
    route_to_human(ticket)                      # 分布太散，人工兜底
else:
    assign(ticket, team=answer.choice)          # 主选项直接路由
    for team, p in answer.probabilities.items():
        if team != answer.choice and p > 0.25:
            notify(ticket, team=team)           # 第二名概率可观 → 抄送

这只是骨架，阈值必须用你自己的样本校准——完整流程见客服分流实战。想先跑通第一个请求，从中文上手教程开始；三种原语在整个架构里的位置见Jev 是什么。