Jev 模型三原语：判断题、选择题、打分题

Jev 模型的一切能力都可以归结为三种题型原语：判断、选择、打分。TypeSafe AI 围绕这三者设计了模型；一旦你掌握了”问题到原语”的映射，大部分接入决策就自己有了答案。这篇给出每种题型的请求写法和响应形态、边界条件和错误用法、怎么在三者之间做选择、成本与延迟的权衡，以及它们在真实管线里如何组合。所有示例都走 OpenRouter 的 OpenAI 兼容端点。

TL;DR： 判断题返回 yes/no/unclear；选择题返回你枚举的选项之一；打分题返回你定义量表上的数字。每个响应都带 confidence 和 rationale。选择标准就一条：答案空间和你的决策匹配的题型。工作流需要多个决策时，把原语串起来用。

三种题型对比

一条经验法则覆盖大多数情况：答案是是不是，用判断题；是哪一个，用选择题；是有多少，用打分题。

原语一：判断题

判断题是有边界的 yes/no，带一个逃生通道——当输入信息不足时，unclear 是正经答案。

# Confirm the exact model slug on the OpenRouter model page
curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev-1.13",
    "messages": [
      {
        "role": "user",
        "content": "Judgment question: is this refund request covered by the 30-day policy? Request: \"...\""
      }
    ]
  }'

标准的 chat completions 请求；判断语义通过把 content 写成判断问句来传达。

响应——示例数据（example fixture），正式字段名以官方文档为准：

{
  "answer": "yes",
  "confidence": 0.97,
  "rationale": "The purchase date is within 30 days and the item is unopened."
}

判断题适合审核标记、政策检查、重复检测，以及一切”要么放行要么不放行”的闸口。

判断题的适用边界。 判断题在业务层面是真正二元时效果最好。如果你发现自己想区分三种状态——“是”、“否”和”升级人工”——通常应该改成三选项的选择题，而不是判断题。如果你需要的是真值的程度而不是二元闸口，打分题更合适。

生产环境中如何处理 unclear。 始终为 unclear 写明确的分支。常见错误是把 unclear 当 “no” 静默拒绝。更好的默认做法是把它加入人工审核队列，同时附上 rationale 字段内容。threshold 模式详见置信度与回退指南。

原语二：选择题

选择题要求你枚举选项。这个约束恰恰是特性：答案保证是选项之一，你的 switch 语句可以放心写。

import json, os, requests

prompt = (
    "Choice question: which team should own this email? "
    "Options: sales, billing, support. Email: \"...\""
)
resp = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
    json={
        # Confirm the exact model slug on the OpenRouter model page
        "model": "typesafe/jev-1.13",
        "messages": [{"role": "user", "content": prompt}],
    },
    timeout=30,
)
route = json.loads(resp.json()["choices"][0]["message"]["content"])

选项在问题文本里枚举；上线前到 OpenRouter 模型页确认确切的 model slug。

响应——示例数据（example fixture），正式字段名以官方文档为准：

{
  "answer": "billing",
  "confidence": 0.94,
  "rationale": "The email disputes a charge amount rather than asking about a product feature."
}

选择题适合工单分流、意图分类，以及一切”从这个列表里挑一个”的决策。三团队邮件分流的完整落地见 email routing case。

选项标签的设计很重要。 语义重叠的标签——例如”退货”和”退款”作为并列选项——会压低置信度，也让 rationale 难以操作。优先使用互斥且穷举的标签。如果无法保证互斥，加一个”其他”选项兜底，路由到人工处理。

选择题与判断题的区别。 判断题是两选项选择题的特殊形式，但 Jev API 对它们的处理不同：判断题始终提供 unclear 作为第三条路径；而两选项选择题在两个标签之间强制给出明确答案。需要”信息不足”逃生通道时用判断题；需要在两个明确标签之间必须选一个时用两选项选择题。

原语三：打分题

打分题返回你定义量表上的数字，并回带量表本身，避免任何歧义。

import json, os, requests

prompt = "Scoring question (1-10): how well does this FAQ entry answer the user question? Entry: \"...\""
resp = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
    json={
        # Confirm the exact model slug on the OpenRouter model page
        "model": "typesafe/jev-1.13",
        "messages": [{"role": "user", "content": prompt}],
    },
    timeout=30,
)
score = json.loads(resp.json()["choices"][0]["message"]["content"])

量表写在问题措辞里；多次调用保持量表一致，分数才有可比性。

响应——示例数据（example fixture），正式字段名以官方文档为准：

{
  "answer": 8,
  "scale": [1, 10],
  "confidence": 0.86,
  "rationale": "The entry answers the core question but skips the edge case mentioned in the question."
}

打分题适合质量线、候选重排和队列排序。

量表设计。 1–10 整数量表是最常见的选择，分辨率足够排序但不会造成虚假精度。量表范围不要超过 1–100：过宽的范围产生伪精确，rationale 也更难核实。如果需要跨管线阶段比较分数，把量表定义为共享常量，而不是每次调用都重新指定。

如何结合 confidence 使用分数。 confidence 字段表达的是模型对分数准确性的把握，而不是分数高低本身。一个 confidence 为 0.55 的 9 分，和 confidence 为 0.92 的 9 分需要区别对待。实践中，设置一个置信度下限（例如 0.75），低于此值就送人工审核，不论分数是多少。成本与延迟指南介绍了如何为这类审核队列做预算。

组合使用

真实工作流是把三原语串起来。一个客服管线可以：先判断”这条是不是机器人能处理的？“，再选择负责团队，最后在发送前给草稿回复打分。组合时的思路：

1. 判断题当闸口。 先做便宜的 yes/no；unclear 或”否”提前退出转人工。
2. 选择题当分叉。 过了闸口再路由给正确的负责人。
3. 打分题当质量线。 在出口给结果打分，低于阈值就扣下。

每次调用只用一种原语——把选择题和打分混在一个问题里，会让答案空间变浑、confidence 也变难解释。题干措辞、选项枚举和 few-shot 示例的深入讨论见问题设计与状态管理指南。

边界条件与错误用法

了解每种原语在哪里会出问题，能省去大量生产环境调试时间。

判断题的边界情况。

• 输入太短无法判断。 单词输入（如”退款”）几乎总会得到 unclear。在调用 Jev 之前加最短长度校验，或用第一次 API 调用模式先向用户请求补充信息。
• 问题包含两个独立的 yes/no 断言。 “这条既紧急又是账单问题吗？“把两个问题混在一起。拆成两次调用；否则 rationale 只会针对模型认为更突出的那个从句。
• 问题里有否定。 “这不是重复条目吗？“颠倒了自然极性。改成肯定形式，在下游翻转答案。

选择题的边界情况。

• 选项超过约 10 个。 延迟上升，置信度下降。使用两级路由：先粗分，再从候选里精选。
• 输入与所有选项都不匹配。 没有”其他”兜底时，模型会被迫返回最接近的选项。总要加一个”其他”或”升级”选项，处理真正不在分类体系内的输入。
• 选项标签语言与输入语言不同。 保持选项标签和输入同语言。跨语言选项匹配会降低可靠性，相关问题见故障排查指南。

打分题的边界情况。

• 问题里没有注明量表。 没有明确量表，模型可能使用内部启发式默认值。在问题文本里始终注明量表，例如”（1-5）“或”（0.0 到 1.0）”。
• 对比来自不同量表的分数。 7/10 和 3.5/5 数学上等价，但程序上是不同值。如果需要跨量表比较，存储前先归一化。
• 用打分题做阈值二元判断。 如果你只关心分数是否过线——“质量大于 7 吗？“——改用判断题更便宜也更快。

Jev API 三原语的成本与延迟权衡

三种原语的成本不等。了解相对开销有助于构建在预算内运行的管线。成本与延迟指南给出绝对数字；下面的相对规律跨模型版本稳定成立。

对管线设计的实际影响。

把判断题放在管线最前面：它是过滤不需要进一步处理的条目最便宜的方式。把打分题留给最终质量检查，此时成本被高质量输出的价值摊薄。选择题居中——比判断题贵，但通常每条管线分支只需要调用一次。

对延迟敏感的场景（实时对话、亚秒级 SLA），优先使用判断题和选择题；把打分题推迟到不阻塞响应的异步质量监控任务里。编程智能体技能指南展示了代码审查管线中使用的异步打分模式。

如果不确定用哪种原语，先试判断题。管线稳定后，判断结果会告诉你哪些条目值得做更深的打分评估。

关于 Jev AI 三原语的常见误解

“打分题可以用来表达我对数据的置信度。” 不对——每个响应里已经有 confidence 字段来捕捉模型的确定性。打分题是用来评估条目本身在你定义的某个维度上的表现，而不是重新表达模型对自己答案的不确定性。

“选择题不过是一系列判断题的集合。” 选择题和判断题在 API 行为上不同。判断题始终有 unclear 作为第三条路径；选择题强制从你枚举的列表里选一个。三选项的选择题不等同于三次串行判断题——它是一次互斥的单一分类。

“confidence 越高，答案越正确。” Confidence 反映的是模型对其训练分布的校准程度，不是对事实的保证。对抗性输入或分布外输入下，0.99 的 confidence 仍然可能是错的。把 confidence 作为多个信号之一，对高风险决策配合人工审核队列使用。

“同一个打分问题可以复用在不同语义领域。” 客户邮件的质量 1–10 分和客服工单的紧急度 1–10 分，即使量表相同也是语义上不同的尺度。永远不要直接跨问题措辞比较原始分数。如果需要跨领域可比性，把每个分数转换为相对于该具体问题历史分布的百分位数。

“unclear 意味着模型失败了。” Unclear 是经过设计的一等公民答案。模型正确地识别出信号不足。从不返回 unclear 的管线，可能是在压制合理的不确定性而非呈现它。把 unclear 的比率作为健康指标监控：突然飙升通常意味着值得调查的输入分布偏移。更多关于模型设计理念的内容见什么是 Jev AI。

关于 Jev AI 三原语的常见问题

能用判断题来决定要不要调用开销更大的打分题吗？ 可以，这也是推荐模式。在花 token 打分之前，先判断条目是否值得打分。闸门在前期过滤噪声，让每次管线运行的平均成本保持低位。

选择题选项里能有空格或特殊字符吗？ 选项标签由模型在语义层面匹配，不是精确字符串比对。空格和常见标点没有问题。避免把长句子当标签——每个标签保持一到三个词，让 answer 字段能直接映射到下游变量名。

怎么对原语问题做版本管理？ 把确切的问题模板作为常量存入代码库，与 model slug 一起版本化管理。修改问题措辞时，视作新版本：在小批量样本上重新做校准，再上线。环境隔离方法见获取 API Key 指南，可用于这类迁移的灰度发布。

能在 API 调用时强制设定最低 confidence 阈值吗？ 不能直接设定——confidence 阈值在应用层执行。从响应里读取 confidence 字段，再按需分支。具体的 threshold 模式见置信度与回退指南，有可直接复用的代码片段。

Jev 和通用 LLM 做相同决策有什么区别？ Jev 经过专门训练，输出带校准置信度的结构化决策，而不是自由文本。通用 LLM 被问判断题时，可能输出一段话；Jev 输出一行 JSON。详细权衡见 Jev 与 LLM 对比指南。

本文适用版本 Jev 1.13。