Jev 判断型模型集成指南：路由、置信度门控与复合评分

Jev 是 TypeSafe AI 推出的判断型模型，它的定位不是替代 ChatGPT 或 Claude 这类生成模型，而是在既有程序与 LLM 之间充当一个「只负责判断」的环节。它不输出自由文本，而是按预先定义好的结构返回判断结果，因此更适合被当作一个函数来调用：给它一段输入，它告诉你这段输入属于哪一类、该打几分、某个命题成立的概率是多少。本文面向需要在业务系统或 AI Agent 中嵌入判断能力的开发者，介绍 Jev 的三种判断类型、四种常见集成模式、一个可直接改造的完整请求示例，以及落地时必须注意的限制。如果你只是想找一个能写文章的模型，这篇内容并不适合你；如果你手上有一堆「分类、打分、是否」的小判断散落在代码和 LLM 提示词里，Jev 值得纳入评估范围。站内也有对应的工具页可供参考：Jev。

准备工作

在动手写代码之前，需要先确认几件事。Jev 通过 API 调用，官方同时提供 Python SDK，但理解 API 结构对排查问题更有帮助，因此下面的示例以 cURL 为主。

账号与密钥

你需要一个 TypeSafe 账号，并在控制台生成 API 密钥。调用时通过 HTTP 头传递：

Authorization: Bearer $TYPESAFE_API_KEY
Content-Type: application/json

建议把密钥放在环境变量里，不要硬编码进源码。示例中统一使用 $TYPESAFE_API_KEY 这个变量名。

请求体的三个核心字段

一次 Jev 请求至少包含以下内容：

model：要使用的模型标识，例如 jev-latest。具体可用的模型名与版本请以官网当前信息为准。
state：被判断的对象，也就是输入数据本身。它可以是一段用户消息、一份文档片段、一条待匹配的记录。
questions：一个对象，里面每个键是一个问题名，值是问题的定义（类型、指令、判定标准）。

questions 是 Jev 与普通生成模型差别最大的地方。你不是在写提示词求它输出一段话，而是在声明一个结构化的判断任务。

三种判断类型

类型	作用	典型用途
Choice	从多个候选中选出一个	工单分类、意图识别
Score	按定义好的档位打分	重要度、紧急度、情绪强度
Noul	返回命题为真的概率	「这段话是不是投诉」这类二值判断

Choice 与 Score 除了给出结果，还会返回 probabilities 与 confidence。Noul 返回的是 0 到 1 之间的「是」的概率，它没有独立的 confidence 字段。这一点在做阈值判断时容易踩坑：不要试图从 Noul 的结果里再取一个 confidence。

另一个关键能力是：一次请求可以包含多个问题。同一段 state 可以同时被分类、打分、判定，不需要发多次请求。

操作步骤

第一步：判断哪些逻辑该交给 Jev

在写任何请求之前，先做一次职责划分。Jev 擅长的是自然语言层面的模糊判断，不擅长精确计算。可以按下面的方式分流：

处理内容	合适的承担者
数值计算、计数	代码
日期比较	代码
字符串完全匹配	代码
自然语言分类	Jev
从模糊候选中做选择	Jev
长文本生成、复杂规划	生成式 LLM

TypeSafe 自身也把数值计算、计数、日期比较列为 Jev 的弱项。把能精确计算的事情交给代码，是后面所有模式的前提。

第二步：用 Choice 做意图路由

最常见的用法是把 Jev 放在流程前端，只负责决定「这件事该交给谁处理」。以客服系统为例，用户来信可能涉及订单查询、商品咨询、退换货、投诉等。Jev 只输出分类，后续动作由代码、专用 LLM 或人工完成。

设计 Choice 时有一个必须处理的细节：选项要覆盖所有可能的输入。如果候选类别无法穷尽，应显式加入 other 或 none of the above 这样的兜底选项，并在代码里把落到该选项的请求转给人工确认。这不是为了消除误分类，而是为了让「无法归类」有一个明确的去处，而不是被硬塞进某个不合适的类别。

路由的典型分工如下：

订单状态查询 → 普通程序直接查数据库
商品咨询 → 商品知识库方向的 LLM
退换货 → 专用处理流程
复杂投诉 → 人工坐席
other → 人工确认

第三步：用 confidence 做人工兜底

Choice 和 Score 会返回 confidence，可以据此决定哪些结果自动执行、哪些转人工。做法是给每类操作设一个阈值，高于阈值自动处理，低于阈值进入人工队列。

这里有两个容易误解的地方。第一，confidence 不是准确率，它来自回答候选上的概率分布，confidence 高仍然可能判错。第二，合适的阈值取决于用途和误判的代价，不存在一个通用数值。官方文档在举例时提到，像余额查询和转账授权这类风险不同的操作，应当使用不同的阈值。

一个实用的分层思路是：

误判后容易重做的处理，可以放宽自动化范围
涉及重要数据变更的处理，要求额外确认
对外发送、删除等高风险操作，不应仅凭模型判断就执行

第四步：用一次请求批量执行多个判断

同一段输入往往需要多个独立判断。例如一条 bug 报告，你可能想知道：它属于哪类问题、严重程度如何、是否包含复现步骤、是否夹带退款诉求、用户情绪有多强烈。逐个提问意味着多次 API 往返，而 Jev 允许把这些放进同一个 questions 对象。

需要注意，多个问题是各自独立评估同一个 state 的。也就是说，「这是不是 bug 报告」的答案不会自动成为「严重程度」这个问题的上下文。即使输入不是 bug 报告，严重程度那个问题照样会被执行，需要由程序侧忽略无意义的结果。

关于性能，公开的实测数据可以作为参考：有团队在 2026 年 9 月 20 日对 jev-1.13.0 做过测量，单问题约 400 token 时响应在 358 至 611 毫秒之间，七个问题约 711 token 时响应在 377 至 544 毫秒之间。这组数字来自特定团队的测试环境，不能直接外推到其他系统。实际是否缩短总耗时，还取决于输入规模、问题数量、网络状况和后续处理。批量提问能确定减少的是 API 往返次数。

第五步：用 Composite Scoring 拆分复杂评价

当你要的是一个综合结论时，不要直接问「这个人优秀吗」。正确做法是把评价拆成若干独立维度，让 Jev 逐项打分，再由代码加权汇总。

以工程师候选人评估为例，可以拆成 Python 技术深度、团队领导经验、系统设计能力、通用型能力等维度，各自用 Score 评估，然后在代码里计算：

final_score = (
    python_depth * 0.40
    + leadership * 0.10
    + system_design * 0.40
    + generalist * 0.10
)

各项先归一化到 0 到 1 再代入。权重取值来自官方示例，实际项目应按自己的用人标准调整。

这种拆法的价值在于把「判断」和「计算」分开：Jev 负责每个维度的语义判断，代码负责最终算术。想调整结果时，你可以检查单项判断，也可以只改权重。如果让 Jev 一次性给出总评，就很难说清是哪个因素影响了结论。TypeSafe 也不建议把精确计算交给 Jev。

第六步：在 AI Agent 内部承担小判断

Jev 也可以嵌进 Agent 的内部流程，而不是替换整个 Agent。一个公开的落地案例来自 Construct：他们把 Jev 用在 Agent 记忆系统的实体匹配上。

场景是这样的：Agent 从对话中抽取人物、公司、项目等信息存入记忆。当新出现一个「Dr. Priya Shah」时，需要判断它是否就是已存的「Priya Shah」。名字完全一致不代表是同一实体，纯字符串比较解决不了这类问题。

他们的分工是：先用代码检索候选，完全匹配或可唯一确定的名字由代码处理，只有模糊候选才交给 Jev 判断是否为同一实体，判断结果再回到代码执行合并或新建。据其报告，原本最多需要调用三次生成模型做判断的流程，被替换成一次 Jev 调用，同时保留了 Jev 调用失败时回退到原判断逻辑的兜底路径。

可以交给 Jev 的 Agent 内部判断包括：用户意图分类、工具选择、检索结果相关性判断、新旧信息是否指向同一对象。长文本生成和复杂规划仍应由生成式 LLM 承担。

第七步：作为 LLM 输出的检查环节

Jev 也可用于对生成模型的输入输出做校验，例如判断回答是否回应了用户问题、是否满足指定条件、是否需要额外确认。用 Noul 判定「该回答是否回应了用户问题」，再根据结果决定直接展示还是转人工或重新处理。

但必须清楚：Jev 的检查结果本身也可能出错。官方文档提到，对抗性输入可能影响 Jev 的判断。因此安全敏感或高风险操作的判定，不能把 Jev 当作唯一防线。

一个完整示例

下面这个请求把分类、评分、概率判断放在一次调用里。输入是一段用户抱怨 Stripe 集成失败的英文消息，需要同时判断该由哪个团队处理、客户情绪有多强烈、是否紧急。

curl -X POST \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- << 'EOF'
{
  "model": "jev-latest",
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions",
        "other": "Requests that do not fit any of the above categories"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated does the customer appear?",
      "criteria": [
        "Calm, just stating facts",
        "Frustrated but civil",
        "Very angry, strong language"
      ]
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}
EOF

这个结构里，department 是 Choice，候选里显式加了 other；frustration 是 Score，档位从平静到强烈不满；is_urgent 是 Noul，只判断一个命题。

响应中，各问题的结果会出现在 answers 里。后续程序可以这样分流：

department = technical → 转技术支持
department = billing → 转账单团队
department = sales → 转销售
department = other → 转人工确认

如果 department 的 confidence 偏低，就不要自动定路由，直接进人工队列。需要强调的是，即使加了 other，也不能保证 Jev 每次都能正确选中它；这个选项的作用是提高类别覆盖度，而不是消除误分类。

上面的命令是结构示例，未在真实环境执行过，因此不提供实际响应内容和耗时数据。请以自己环境中的返回为准。

注意事项

只传判断需要的信息

Jev 基于传入的 state 做判断。如果 state 里塞了大量与问题无关的内容，判断精度可能下降。更稳妥的做法是先用代码或检索把相关信息抽出来，再交给 Jev。Construct 的实体匹配案例就是这个思路：先由代码检索候选，再把模糊候选交给 Jev。

阈值要用真实数据定

不要把返回的概率或 confidence 当成通用标准。Construct 是基于自家测试数据来设定实体匹配阈值的。此外，2026 年 9 月 29 日公开的一项独立评估在部分二值分类任务上发现，把 0.5 作为固定判定阈值会导致性能偏低。正确做法是用自己的数据跑一遍，看误判率，再决定阈值。

提前设计失败路径

API 不可用或结果不可采用时要有兜底。可以按三种情况分别处理：判断可采纳则走正常流程；判断不确定则转人工复核；API 报错则走回退逻辑。Construct 的实现中，Jev 若在 2 秒内没有响应，就会回退到原有的判断方式。

输出格式受约束不等于判断正确

Jev 的输出格式是受限的，不会像生成模型那样自由发挥出定义之外的值。但格式正确和内容正确是两回事。jev-1.13 的已知限制包括数值处理、日期比较、复杂间接推理、对抗性输入，以及 Choice 选项顺序带来的影响。不要因为输出结构稳定就认为判断一定可靠。

价格与配额以官网为准

Jev 的计费方式、模型版本、可用区域和调用配额都可能调整，本文不给出具体数字。在正式接入前，请查阅官网当前公布的定价与限制信息，并据此估算成本。