Jev AI 是什么？判断模型 API 实用指南

2026 年 9 月，TypeSafe AI 发布了 Jev——其 “System One” 判断模型产品线的第一个模型。它的定位故意做得与众不同：Jev 不聊天，只回答那些”答案空间有限”的问题——判断题、选择题、打分题——并返回带 confidence（置信度）的结构化答案。如果你的 LLM 调用里有一大堆最后是为了从一段话里抠出一个 yes/no，这篇 Jev 模型详解就值得读完。

TL;DR： Jev 是 TypeSafe AI 的判断模型，不是聊天模型。它专注三种题型原语——判断题（yes/no/unclear）、选择题（从选项中挑一个）、打分题（给出量表上的分数），返回包含 answer、confidence、rationale 的 JSON。它可以通过 OpenRouter 的 OpenAI 兼容端点像普通 LLM 一样调用，接进现有管线的成本很低。

Jev 是什么，不是什么

理解 Jev 模型最快的办法，是先把它的边界画清楚。

Jev 是：

• 一个专注”有界问题”的判断模型：这是不是 X、这几项里哪项是 Y、Z 在量表上打几分。
• 一个返回结构化答案的模型：answer 字段、confidence 分数、rationale（理由说明）。
• 通过 OpenAI 兼容渠道访问的模型——主演示渠道是 OpenRouter，请求结构和现有代码几乎一致。

Jev 不是：

• 聊天机器人。它不会多轮对话、不会角色扮演，也不会替你写博客。
• 通用 LLM 的替代品。长文生成、摘要、多轮对话仍然是聊天模型的活。
• 精度保证。它改变的是交互”形态”——从一段散文变成一次结构化判断；问题本身写得好不好，依然决定结果好不好。

Jev 到底在解决什么问题

大多数 LLM 管线里，最终都藏着一个分类步骤。你把一条客服工单发给 GPT-4，系统提示写着”把这条工单分到账单、技术或其他类别”。模型返回一句话。你用正则或再来一轮提示把类别抠出来。如果文本本身有歧义，模型给你一段模棱两可的回答，解析就失败了。

Jev 就是为了去掉这层摩擦而生的。它产生的输出在结构上是确定的，无论输入怎么变。你在提问时就定义好题型和答案空间，模型只能落在那些槽位里。没有段落需要解析，answer 字段永远是你预定义的合法值之一。

这在规模化场景下特别重要。每天跑五万条分类调用，2% 的解析失败率就是一千条每天流进人工队列。更严格的输出结构意味着更低的运营成本——不是因为模型更聪明，而是因为它的答案生来就是机器可读的。

更宏观的定位：Jev 处于受约束的决策空间，不是语言生成空间。聊天模型是你想让模型构造一个答案时的好工具。Jev 是你想让模型从已知空间里选取一个答案时的好工具。这是两件不同的事，用对工具比什么都重要。

三个基本原语：prompt、schema、state

每次 Jev 调用都由三个要素构成。搞清楚每个要素的作用，可以避免最常见的配置错误。

Prompt 是你在用户消息里发送的问题文本。和聊天模型的系统提示不同，它同时编码了题型和上下文。“Judgment question: does this comment contain spam? Comment: {text}” 就是一个完整的 prompt——它告诉模型要产出什么类型的答案（判断题），以及评估什么（这条评论）。消息开头的题型前缀是 Jev 判断用哪种输出格式的依据。

Schema 是你隐式或显式定义的答案空间。判断题的 schema 是固定的（yes / no / unclear）。选择题需要你在 prompt 里枚举有效选项。打分题需要你指定量表的上下界。模型不会产出 schema 之外的答案——这是 Jev 架构上的结构性保证。

State 是你连同问题一起传入的上下文数据，也就是用户消息里问题之外的内容——评论原文、工单正文、简历摘录。Jev 在调用之间不维护对话历史，每次调用都是无状态的，这让横向扩容变得直接，也让模型行为更容易审计。关于需要串联多个调用的多步评估模式，参考状态与问题那篇指南。

用选择题把三个原语组合在一起的最小可用例子：

import json, os, requests

ticket_body = "我的账单金额有误，我需要退款。"

resp = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
    json={
        "model": "typesafe/jev-1.13",
        "messages": [{
            "role": "user",
            "content": (
                f"Choice question: which team should own this support ticket? "
                f"Options: billing, technical, returns. "
                f"Ticket: \"{ticket_body}\""
            ),
        }],
    },
    timeout=30,
)
result = json.loads(resp.json()["choices"][0]["message"]["content"])
# result["answer"] 是 "billing"、"technical"、"returns" 三者之一
# result["confidence"] 是 0 到 1 之间的浮点数

answer 字段会严格是你枚举的三个字符串之一，不需要任何后处理。

三种题型原语速览

每次 Jev 调用都对应三种题型之一，这是 jev ai 能力面的核心心智模型。

三个值得注意的细节：

1. 判断题是三值答案。 unclear 是一个正经答案，不是报错。它天然就是”需要人工介入”的分流桶。
2. 选择题的答案是受约束的。 只要在题干里枚举清楚选项，返回的 answer 就是其中之一，下游代码写起来非常省事。
3. 打分题自带量表。 响应里的 scale 字段把取值范围写明，一个 “7” 不会产生”是 10 分制还是 100 分制”的歧义。

一次真实调用的形状：请求体、响应体、出错看哪里

因为主演示渠道是 OpenRouter，调用 Jev 走的就是标准 chat completions 端点。下面是判断题的最小 curl 示例：

# 上线前到 OpenRouter 模型页确认确切的 model slug
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: does this comment contain spam? Comment: \"Buy followers now at cheap-bots.example\""
      }
    ]
  }'

请求体就是普通的 OpenAI 兼容格式——模型 id 加一条用户消息。判断的语义体现在问法上；上线前请到 OpenRouter 模型页确认确切的 model slug。

解析后的答案长这样——示例数据（example fixture），正式字段名以官方文档为准：

{
  "answer": "yes",
  "confidence": 0.97,
  "rationale": "The comment promotes a third-party follower-selling service and contains an unrelated link."
}

出错了看哪里。 如果调用返回 HTTP 错误，OpenRouter 的响应壳里有标准 error 字段，具体信息在那里。如果调用成功但解析出的 answer 不符合预期，先看 rationale 字段——那是模型的推理链，通常能直接指出是提问哪里出了问题。低 confidence 加上一个意料之外的答案，十有八九是问题本身有歧义，不是模型故障。更多常见问题模式参考故障排查指南。

Python 版本同样简短：

import json, os, requests

resp = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
    json={
        # 上线前到 OpenRouter 模型页确认确切的 model slug
        "model": "typesafe/jev-1.13",
        "messages": [{"role": "user", "content": "Judgment question: does this comment contain spam? Comment: \"Buy followers now at cheap-bots.example\""}],
    },
    timeout=30,
)
payload = resp.json()
result = json.loads(payload["choices"][0]["message"]["content"])
print(result["answer"], result["confidence"])

外层 payload 是标准的 OpenAI 兼容响应壳；内层 result 是示例数据（example fixture）——响应形态为示例，正式字段名以 typesafe.ai 官方文档为准。

什么时候不该用 Jev AI

Jev 是一把窄刃的刀。用在它不擅长的地方，不是优雅地退化，而是静默地给出错误答案。

开放式写作任务不要用 Jev。 如果这次调用的产出是一段文本——草稿、摘要、说明、回复——那是语言生成任务，Jev 不是为此而生的。换一个通用 LLM，同样的成本可以得到更有用的输出。

无法定义答案空间时不要用 Jev。 模型需要一个有界的 schema 来落点。如果你的问题是”对于这种情况我们应该怎么做”，根本没有一个有限的答案集可以约束。这类问题需要先被拆解——拆成具体的判断子问题或选择子问题——Jev 才能派上用场。如果你发现自己一句话说不清选项是什么，这个任务大概率属于聊天模型。

创意型和发散型任务不要用 Jev。 头脑风暴、创意发想、多角度探索，以及任何需要模型自由漫游可能性空间的任务，和 Jev 的优化目标正好相反。这个模型是为了快速收敛到一个答案而设计的，不是为了探索。

需要推理步骤的决策不要用 Jev 独自完成。 如果这个判断需要综合模型没有被提供的信息——调用世界知识、运用领域专业判断、依赖未说明的上下文——你会得到一个听起来很自信的错误答案。Jev 最好用的情景是：做判断所需的全部上下文都已经在 prompt 里。

成本与延迟的量级感受

确切定价会随时间和渠道变化，下表数字只作量级参考，建立成本模型前请到 OpenRouter 模型页确认当前费率。

跨渠道、跨版本保持稳定的规律是：对于分类任务，Jev 的调用成本和延迟都低于同级别的 GPT-4 类调用。粗略量级如下：

延迟差距在串联调用时最显著。一个内容审核管线里串联三次 Jev 调用——是不是垃圾、是不是有毒、属于哪个类别——端到端可以在一秒内完成。同样的管线换成 GPT-4 类模型，每条内容要花好几秒。

成本差距在量级上最重要。每天五万条分类调用，哪怕只有 2 倍的成本差异，长期下来也相当可观。结构上的取舍是：Jev 只处理有界问题。任务合适的时候，成本剖面很划算；任务不合适的时候，无论成本如何都需要换工具。详细的数字分析参考成本与延迟指南。

Jev 和 LLM-as-a-judge 怎么分工

LLM-as-a-judge 是一种常见的评测模式——用一个高能力的聊天模型对模型输出打分或批评。它有效，但贵：一次 GPT-4 级别的 judge 调用，成本和一次生成调用差不多。当你的评测管线跑到任何有意义的量级，判断本身的成本就会逼近生成的成本。

Jev 在筛选层天然是个补充。实践中的分工：

Jev 做第一轮筛选。 一次置信度打分的分类调用，150 ms 完成，成本是零头，可以在任何昂贵的 judge 介入之前把清晰案例剔除——明显的垃圾、无歧义的违规、明确超出范围的工单。如果 80% 的案例是清晰案例，你就只需要对 20% 的流量跑 LLM judge，整体质量基本不变。

LLM-as-a-judge 处理有争议的案例。 当 Jev 的 confidence 分数低于你的阈值——比如 0.75——或者判断结果是 unclear，这就是升级到更昂贵但更强大的评测的信号。judge 只看那些真正需要深度推理的内容。

这个双层模式在 Jev 与 LLM-as-a-judge 对比指南里有详细拆解。简短的版本：Jev 不是 LLM 评测的替代品，它是让 LLM 评测在规模化下可持续的成本过滤器。

什么场景适合，什么场景不适合

基于三种题型，适合的场景：

• 内容审核：对每条评论、帖子做垃圾信息识别、毒性检测、违规标记。
• 客服分流：把进线工单分类到你的某个团队（选择题），再判断是否可自动处理。
• 筛选与打分：在人工介入之前，先对简历、答案、销售线索按固定量表打分。
• 评测闸口：在管线里对模型输出或 RAG 答案打分，决定放行还是拦截。

不适合的场景：

• 起草内容、写代码、输出长篇分析——这些请用聊天模型。
• 用户期待”对话感”的开放式交流。
• 你无法枚举答案空间或定义量表的模糊问题。给不出有界选项，Jev 就没有锚点。

如果你正在为其中某类任务权衡 Jev 和通用聊天模型，《Jev 与 LLM 对比》这篇做了逐项拆解；想深入题型设计，看《Jev 三原语》这篇；想看内容审核的完整落地案例，参考垃圾评论识别那个 case。

本文适用版本 Jev 1.13。