Jev 的三种问法怎么选：choice / score / noul

先说结论

1. Jev 的“提问”不是自然语言提示词，而是三种带类型的 primitive：choice 返回选项和概率分布，score 返回分数和级别说明，noul 返回 0~1 的布尔判断。
2. 选择规则很直白：能用选项枚举就用 choice，能打序用 score，只有是/否判断才用 noul；官方明确建议一个问题只判一件事，复合判断要拆成多个问题再在代码里加权合并。
3. 同一个 state 的多个问题应当放在一次请求里并行评估，官方说明每个问题独立评估、返回按 ID 对应。
4. confidence 是模型自己的把握，不是准确率；工程上应设阈值，低置信度走兜底分支，并记录每次决策的 confidence 日志。
5. 三种 primitive 不适合开放生成、长链推理、需要解释理由的任务；这类任务应换成 LLM 或把任务拆细。

三种 primitive 分别返回什么

根据官方文档 Primitives，TypeSafe 把“提问”定义为小型、带类型的构建块。每个问题针对一个 System One 模型对某个 state 的判断，答案以类型化值返回。三种类型的返回结构如下（官方数据）：

Choice 适合选项之间没有顺序关系的场景，比如把工单路由到某个部门、识别文档类型、检测编程语言。返回的 choice 是选项 key，probabilities 是各选项的概率分布，confidence 是模型对这次选择的把握。官方提醒：当选项列表可能覆盖不全时，要加一个 other 或 none of the above 兜底选项。

Score 适合答案落在某个连续谱上、而且你能描述每个等级含义的场景。比如客户愤怒程度 0~2 分。返回的 score 可以是小数，legend 是级别说明，probabilities 是各等级概率，confidence 是把握。官方示例中 score: 1.4 就说明它不是强制整数，而是可以取中间值的连续量。

Noul 适合是/否判断，返回 noul 字段，取值 0~1，0 表示否，1 表示是，中间值表示模型的不确定程度。官方文档里 Noul 的 criteria 是可选的，用来澄清“是”和“否”具体指什么。

选择规则：能枚举就别打分

官方文档 Primitives 给出的选择逻辑是：先看答案的形状。

• 如果你要的答案是一组已知选项中的一个，而且选项之间没有天然顺序，用 Choice。典型例子是工单部门路由：billing、technical、account。
• 如果答案落在一条谱上，而且你能为每个级别写出清晰定义，用 Score。比如“这条消息的紧急程度：0=冷静，1=着急，2=非常着急”。
• 如果只是一个真/假判断，用 Noul。例如“客户是否要求退款”。

关键规则是官方明确写出的：一个问题只判一件事。原文说 System One 模型是为快速、聚焦的判断而生的，应该问“一个有相关知识的人在一秒内能给出的判断”。例如“这条消息是否表达紧迫性？”是个好问题；而“分析这条消息并决定最佳行动方案”不是，因为它需要慢速推理，是信号告诉你要把任务拆成小问题，再用代码组装答案。

官方还给了具体例子：不要问“给这个创业路演打分”，而要分别问市场空间、技术可行性、差异化程度，然后在代码里按重要性加权合并。这样当优先级变化时，只改权重值，不用重写提示词。

state 怎么组织：内容与问题分离

官方文档 State 明确说明：state 是你要求模型评估的内容，可以是支持消息、一段文本，也可以是应用的当前状态。它和 questions 是分开的：state 里放内容和支撑事实，questions 里放要做的判断。

state 可以是简单字符串，也可以是 JSON 对象或数组。官方建议大多数请求用对象，这样每个字段有描述性名称，关系清晰。例如一个支持工单对象可以包含 ticket（对话）、order（订单信息）、refund_policy（退款政策），这些相关部分放在同一个 state 里，因为判断需要比较这些部分。

需要注意两个官方约束：Jev 只接受文本输入，state 必须是字符串、JSON 对象或文本数组，不支持图片、音频、视频；Jev 主要训练语言是英语，其他语言包括中日韩文可以接受但准确率目前更低（官方未给出具体下降数字）。

官方没有给出 state 的 token 上限或字段数量上限，只说“把相关材料放进去”。所以工程上应该按“给一组专家看什么材料”来组织，而不是塞入无关上下文。

多问题并行：同一 state 一次请求

官方文档 Primitives 和 State 都强调：每个请求只评估一个 state，但可以同时评估多个问题。所有问题共享同一个 state，每个问题独立评估，返回时用你指定的 ID 对应答案。

这意味着如果你要对同一个工单判断“是否要求退款”“该分给哪个部门”“紧急度多高”，不应该发三次请求，而应该放进一次请求的 questions 对象里，三个问题并行评估。官方原话是“Every question in a request sees the same state, is evaluated independently, and returns a typed answer under the ID you chose.” 这样做既降低延迟，又减少 token 消耗。

confidence 怎么接进代码

System One 模型的 confidence 是 校准过的信心，官方概念页 System One 说明：模型概率针对结果做了优化，以反映不确定性。但校准是针对群体预测而言的，不保证单个答案一定正确。所以 confidence 不代表“这次一定对”，只能当作模型对自己判断的把握程度。

工程上接 confidence 的正确姿势是：

1. 不要把它当准确率。confidence 0.9 不等于 90% 准确，它只是模型认为这次很有把握。
2. 设阈值分流。低于阈值的走人工审核或调用推理模型兜底；高于阈值的直接进代码逻辑。
3. 记录日志。把每次决策的 question ID、confidence、最终结果都记下来，方便后续分析阈值是否合理。

官方文档没有给出置信度阈值的推荐值。阈值应该根据业务风险自己标定。一个非官方社区基准 jev-benchmark（第三方实测，非官方）在 60 个手标注样本上发现：jev-latest 在 confidence 0.9–1.0 区间内的准确率为 98.0%（50 个样本），而所有错误答案的 confidence 都没有出现过 1.000。但该样本量很小，且是特定任务，不能当作通用结论。这个基准本身也提醒“一个只在简单样本上计算的校准数字没有意义”。

下面给出一个可直接用的 JSON 请求样例（结构基于官方文档描述，字段名以 API 参考为准）：

{
  "state": {
    "ticket": {
      "subject": "重复扣款",
      "messages": [
        {"from": "customer", "text": "我被重复扣款了，请退款。"},
        {"from": "support", "text": "我们正在查询扣款情况。"}
      ]
    },
    "order": {
      "id": "A-104",
      "charges": [
        {"amount_usd": 49, "status": "captured"},
        {"amount_usd": 49, "status": "captured"}
      ]
    },
    "refund_policy": "重复扣款符合退款条件。"
  },
  "questions": {
    "refund_requested": {
      "type": "noul",
      "instructions": "Does the customer request a refund?"
    },
    "department": {
      "type": "choice",
      "instructions": "Which department should handle this ticket?",
      "criteria": {
        "billing": "Billing issue",
        "technical": "Technical issue",
        "account": "Account issue",
        "other": "None of the above"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": ["low", "medium", "high", "critical"]
    }
  }
}

对应的阈值分流伪代码：

# 伪代码：阈值分流，低置信度走人工兜底
# 阈值 0.8 是示例值，不是官方推荐；需按业务风险自行标定
result = client.system_one(state=state, questions=questions)

for qid, answer in result.answers.items():
    confidence = answer.confidence
    if confidence < 0.8:
        log_low_confidence(qid, confidence, state)
        escalate_to_human(qid)
    else:
        apply_answer(qid, answer)

自己的判断：什么任务不适合这三种 primitive

综合官方文档 System One 和 Primitives 的说明，以下任务不适合直接使用 choice / score / noul：

1. 开放生成：写邮件、写代码、写摘要、生成对话回复。System One 模型不生成自由文本，它只返回类型化答案。
2. 需要长链推理：多步规划、因果分析、复杂决策树。官方明确说“Analyze this message and determine the best course of action”不是好问题，应该拆成多个快判断再组合。
3. 需要解释理由：模型不输出推理过程或解释，你只有答案和概率，没有“为什么”。如果业务上必须拿到理由，要么放弃这个模型，要么自己根据 state 重建解释。
4. 多模态输入：图片、音频、视频目前不支持，只接受文本。
5. 复合判断过于复杂：如果拆解后需要几十个 primitive，而每个 primitive 的语义又难以清晰定义，那么拆解成本可能超过收益，不如直接调用推理型 LLM。

反过来，这三种 primitive 最适合的场景是：规则明确、答案空间固定、需要结构化输出直接进代码、对延迟和成本敏感、可以接受低置信度兜底的高频决策节点。比如 CRM 自动分单、客服意图识别、风控规则前置筛选、文档自动分类。

这次没核实的

• confidence 阈值的官方推荐值：官方文档只说明要“决定何时行动、何时升级”，未给出具体阈值数字。上文代码中的 0.8 是示例，不是官方建议。
• Score 返回里 legend 的具体结构：Primitives 页面只列出字段名，详细说明在子页面，本文未展开核实。
• state 的 token 或字段数量上限：官方文档未提供，只说明 state 是文本/JSON/数组，且 CJK 语言准确率更低但未给出具体幅度。
• 来源4 的 60 例基准结论：该基准是社区第三方测试（非官方），其 91.7% 准确率、置信度分桶数据只适用于它自己的工具调用风险分类任务，样本量 n=60，不能泛化为 Jev 的通用表现。引用时请谨慎。

参考来源

• 官方文档：Primitives（Choice / Score / Noul） — 一手来源
• 官方文档：State — 一手来源
• 官方文档：System One — 一手来源
• 第三方 60 例基准（置信度校准结论） — 社区二手，非官方实测