技术参数与引用资料截至 2026 年 10 月 12 日。

在一个客服 Agent 中，大模型可能要先判断请求类型，再选择工具，随后决定是否重试、升级或结束。这里面很多步骤只需要一个类别、一个布尔判断或一个评分，却仍然通过生成文本来完成。当调用量增加，这些小判断的延迟、费用和误判会逐渐成为系统问题。

TypeSafe AI 的 Jev 针对的就是这类工作。应用提供状态、问题和允许的答案，模型返回结构化结果与概率，程序据此分支。它值得关注的地方，是让语义判断具备更方便的软件接口，并把不确定性暴露给调用方。它能否用于自动化，还取决于任务定义、概率质量和复核策略。

评价 Jev，需要同时回答三个问题：它能否理解业务规则，是否知道自己什么时候容易错，以及把难例交给其他系统之后，整个流程是否更划算。

这些问题可以通过一个资料归档项目具体展开：用 Choice 分类、Score 判断主题相关性、Noul 检查正文信息，再由程序处理缓存、预算和人工复核。模型能力的判断与可运行的软件实现，需要分别验证。

决策模型如何嵌入软件

一个普通函数通常接收明确的参数，再执行确定性的规则。涉及自然语言时，输入的含义常常无法通过少量规则准确表达。例如，“扣款失败”和“重复扣款”都涉及支付，却可能进入不同的处理流程。

Jev 把这类判断暴露为一个受约束的接口。可以将它抽象为：

f(state, question, candidates) → probabilities

其中，state 是可用事实，question 定义判断任务，candidates 定义答案空间。返回的概率并不自动规定业务动作。软件还要根据错误成本、权限和流程状态决定怎样使用结果。

这张图描述的是应用逻辑。官方在 API 层定义了共享状态和并行问答；这种接口约定并不足以推断完整网络结构。集成时需要验证可观察的输入输出行为。官方介绍

“System One”借用了快速、直觉式判断的概念。工程上更有用的定义，是问题足够聚焦、答案空间有边界、调用结果可以直接参与程序分支。一个模型可以在复杂系统中反复做局部判断，而整体规划、状态管理和执行仍由周围的软件完成。System One 定义

接口的结构与输出类型

Jev 的请求由 state、model 和 questions 组成。当前官方接口为 POST https://api.typesafe.ai/v1/systemone。下面使用虚构的客服消息说明请求结构：

{
  "model": "jev-1.13.0",
  "state": {
    "message": "同一笔订单出现两次扣款，请帮我核查。",
    "facts": "已确认存在两条支付记录，尚未核实是否重复结算。"
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "根据消息和已核实事实，选择适合首次处理的团队。",
      "criteria": {
        "billing": "支付、扣款、账单或退款问题",
        "technical": "功能故障、报错或服务不可用",
        "account": "登录、身份或账户信息问题",
        "out_of_scope": "现有团队均不适合处理，或信息不足以归类"
      }
    },
    "explicit_urgency": {
      "type": "noul",
      "instructions": "消息是否明确表达了时间紧迫或立即处理的要求？"
    }
  }
}

questions 的键用于关联返回结果，不会发送给底层模型。把键命名为 explicit_urgency，并不能代替实际的判断说明；业务条件必须写在 instructions 和 criteria 中。API 定义

三种问题类型分别适合不同的答案空间：

类型	适用判断	主要结果
Choice	从无顺序的候选集合中选一个	选中项、各项概率、confidence
Score	在有顺序的描述等级上评分	概率加权分数、各等级概率、confidence
Noul	判断一个命题是否成立	命题成立的概率

Choice 当前最多支持 255 个选项，Score 支持 2～10 个等级。把等级写成“轻微影响”“存在可行替代”“主要流程被阻断”，通常比仅写数字更容易明确判断标准。Choice 文档、Score 文档

同一次调用可以判断多个问题。官方建议将可能用到的问题一起发送，再由程序忽略当前分支不需要的结果。例如，工单类型、是否请求退款、故障严重程度可以并行评估；只有进入故障分支时，严重程度才参与后续逻辑。并行问题模式

这种设计减少了串行往返，但也要求问题能够在同一份已知状态上回答。需要先执行工具、获得新事实的问题，仍然要等待下一轮状态更新。

Jev 与已有分类技术的关系

文本分类、重排序和概率校准已经有长期研究积累。2025 年的 GLiClass 就探索了动态标签条件下的高效零样本分类；它处理的是分类要求随用户变化、固定分类头难以直接适应的问题。GLiClass 论文

Jev 的接口也属于这种广义的条件判断：答案集合和定义可以随请求变化。与固定类别分类器相比，它省去了为每个新分类任务单独构造和训练模型的步骤。代价是，用户需要在请求中提供足够明确的定义，并验证它是否遵循这些定义。

对于能够读取 logits 的语言模型，可以将候选映射到单 token 标识，直接读取对应的下一 token 概率并归一化。已有 Jev 对照评测采用了这种读取方式，无需生成解释段落。直接读取候选概率的方法

这使比较的重点落在实际能力上：同样的状态、问题和候选集合，谁更准确，谁的概率更有用，谁的服务延迟和费用更低。仅凭输出是结构化对象，无法判断某种底层架构更先进。

概率训练与 RLCD

TypeSafe 将训练路线称为 Reinforcement Learning for Calibrated Decisions，简称 RLCD。其公开目标是让模型返回决策及校准概率：在许多相似预测中，被赋予约 0.8 概率的事件，应约有八成发生。官方训练理念

这个目标关注概率分布，而不只关注最终选项是否正确。以二元 Brier 损失为例，预测概率为 p，真实结果为 y，损失为：

L(p, y) = (p − y)²

如果真实事件以 0.8 的频率发生，期望损失为：

E[L] = 0.8 × (p − 1)² + 0.2 × p²

这个表达式在 p = 0.8 时最小。概率报告偏离真实频率，会增加预期损失。多分类版本对各类别的预测与真实指示值求平方差再相加。

这只是说明概率目标的一种方法，不能当作 TypeSafe 未公开训练配方的具体描述。概率校准也可以通过交叉熵训练、温度缩放等方法实现。经典研究已证明温度缩放在许多数据集上有效，因此需要通过对照实验判断强化学习增加了什么。校准研究

独立的 OpenJev-RLCD 研究给出了一种可复现的路线：先校准答案分布，再通过适当评分规则强化推理。它在 Qwen3-1.7B 的两个任务上进行实验。在 GSM8K 答案验证中，RLCD 与 GRPO 的准确率都约为 92%；经过温度缩放后，在错误率不超过 5% 的测试操作点，前者覆盖约 81% 的样本，后者约 19%。结果报告了三个训练种子。OpenJev-RLCD

这项结果说明，识别难例的能力可以在准确率相近时产生很大差异。该实现仍是独立研究，既不披露 Jev 的内部算法，也不证明 Jev 使用了同样的训练步骤。

读取 probability 和 confidence

Jev 的 Choice confidence 是概率的派生统计量。设候选数为 n、最高选项概率为 p_max，官方公式为：

confidence = (p_max − 1/n) / (1 − 1/n)

三个选项的概率为 0.85、0.10、0.05 时，confidence 为 0.775。它表达最高概率相对均匀分布的集中程度，并不直接表示这个任务的实际正确率。confidence 公式

对于同样数量的选项，0.60、0.40、0.00 与 0.60、0.20、0.20 得到相同的 Choice confidence。这个统计量没有保留完整的分布形状。概率和 confidence 也来自同一份输出，不能被当作两次独立验证。

Score 则返回等级编号的概率加权平均。对等级 0、1、2，分布 0.5、0、0.5 和 0、1、0 的平均分都为 1。前者在两个极端之间不确定，后者集中在中间等级。读取平均分时，需要结合概率分布和 confidence，避免把不确定性压缩成一个看似精确的数字。Score 计算方式

等级之间的距离也是应用选择的编码。将“轻微”“中等”“严重”放在等距编号上，并不自动意味着它们对应等距的业务损失。需要做成本决策时，应为结果建立自己的损失映射。

校准与自动处理率

概率质量至少包含三个不同性质。校准检查数值是否与发生频率相符；错误排序检查难例是否集中在低置信度部分；一致性检查不同问法和逻辑关系是否相容。

一个模型始终报告 0.9，恰好有 90% 准确率，可以在整体上校准得很好，却无法指出具体哪些请求会错。此时，提高门槛只会在“全收”和“全拒”之间切换，无法有效挑出可靠样本。

自动化更应该读取风险与覆盖率的关系。固定阈值 t，令通过门槛的样本集合为 A(t)，可以定义：

coverage(t) = 接受的样本数 / 全部样本数
risk(t)     = 接受样本中的错误数 / 接受的样本数

没有接受样本时，risk 没有定义，不能记成零。实际评估也应同时报告样本数，避免把极少数高分案例的零误判当成稳定表现。

一组公开的历史响应能说明这一点。Running-Dolphins 的评测在 2026 年 9 月 20 日调用 jev-latest，每任务 500 条记录。根据原始记录重新计算，固定使用“选中答案的概率至少为 0.9”，得到以下结果。这是历史数据的离线复算，模型使用了滚动别名；不是当前服务的新一轮测量。原始响应

任务	接受数	接受样本中的错误数	自动覆盖率	接受样本的正确率
重复问题判断	272	3	54.4%	98.9%
77 类银行意图	338	34	67.6%	89.9%
评论星级的精确等级	256	47	51.2%	81.6%

下图根据每个概率阈值重新计算覆盖率和错误率，完整保留概率相同的样本，避免用任意排序拆散并列结果。

图中的圆点使用同一个门槛 p_top ≥ 0.9；它与 API 的 confidence ≥ 0.9 是不同的规则。错误按数据集标签判定，可能包含标签噪声。曲线仅描述这批记录，不构成未来请求的风险保证。

这些数值支持概率筛选的用途，也说明阈值需要按任务确定。重复问题判断在接受超过一半样本时，错误率约为 1.1%；评论星级接受相似比例时，精确等级错误率仍约为 18.4%。

阈值选择应使用校准集，然后在独立测试集上验证。若同一批数据既用于挑阈值，又用于报告阈值后的错误率，结果会受到选择偏差影响。

样本量也约束结论。在固定阈值、独立同分布样本的条件下，若 n 个接受样本零错误，95% 单侧二项错误率上界为：

upper_bound = 1 − 0.05^(1/n)

300 条零错误样本对应约 1% 的上界；3,000 条对应约 0.1%。重复调用同一个案例不能代替这些独立业务样本。

公开评测中的能力差异

波恩大学等机构的研究对 jev-1.13.0 运行了 346,009 次请求，覆盖 37 个公开数据集，并发布原始响应。以下结果代表不同任务，指标的含义也不同，不能直接取一个平均分。完整评测

任务	指标	结果
IMDB 情感分类	准确率	96.5%
Banking77 意图分类	准确率	79.7%
LLM-AggreFact 依据判断	平衡准确率	78.6%
Emotion 细粒度情绪分类	准确率	58.5%
中文 C-Eval	准确率	83.9%
HelpSteer2 回答有用性	与人工评分的 Spearman 相关系数	0.399

这些结果说明，应分别验证分类、依据判断和回答评价。中文考试分数也不能替代中文工单、企业规则或行业术语测试。

旧公开基准无法排除训练暴露的影响，高分需要与新的业务样本一起解释。

官方列出的已知问题包括精确计算、日期比较、多层间接推理、无关长上下文、对抗内容和选项顺序影响。适合由解析器或确定性代码计算的内容，应先在代码中完成，再把需要语义判断的部分交给模型。已知局限

概率之间的一致性

多个问题可以在同一个请求中独立评估，但这种计算方式不意味着问题描述的事件在统计上独立。例如，“客户很着急”和“需要立即升级”通常存在关联，不能直接把两个概率相乘当成联合概率。

更基础的逻辑关系也不总能自动满足。一项研究对 160 个案例构造相关问法，发现 Jev 对“命题成立”和“命题不成立”的概率之和，平均偏离 1 约 0.064；分别询问三个互斥类别时，概率之和平均为 1.14。它在该测试中优于所比较的语言模型，但仍不完全符合这些概率恒等式。一致性研究

在应用中，互斥且穷尽的类别可以放进一个 Choice，明确的逻辑取反可由代码计算。不同问题的概率要进行组合时，需要先确认事件定义、依赖关系和逻辑一致性。增加问题数量，并不会自动增加独立证据数量。

类型约束之外的语义失败

一个结果可以完全符合 schema，同时选错合法答案。选项键与定义发生语义冲突时，模型还可能更依赖键的含义。针对 Jev 与两个开源模型的研究发现，重分配名称和定义后，输出类型错误率仍为零，语义判断却可能变化。选项名称实验

设计选项时，应检查名称和定义是否一致，并用边界案例验证实际行为。在需要重命名内部键时，可以比较映射后的业务含义是否保持一致，而不只比较返回字符串。

输入中夹带的意见也会影响决策。JevAdvBench 在状态里追加未经验证的观察者意见后，12.1% 的判断发生改变，相同请求重复运行的变化基线约为 1%。这里测量的是相对干净请求的变化，不能直接解释成真实错误率。对抗评测

应用准备状态时，需要保留事实来源，区分已核实记录、用户声明和外部意见。判断“已确认重复结算”与判断“客户认为重复扣款”需要不同的标准，信息来源本身就是业务事实的一部分。

范围外请求则是另一类问题。如果答案集合只有三个部门，模型必须在这些部门中选一个；低置信度可以辅助拒绝，却不能保证覆盖所有未知输入。一个候选覆盖研究发现，将在 DBpedia 上校准的拒绝策略转移到 Emotion 后，69.3% 本来包含正确候选的输入也被拒绝。拒绝策略迁移研究

因此，候选集合、描述长度和任务分布变化之后，需要重新验证拒绝策略。“范围外”或“信息不足”的选项也需要具体定义，避免成为一个含义模糊的万能出口。

接入时如何读取和验证结果

应用边界仍然需要处理服务错误、版本变化与结果验证。下面的 Python 示例只实现结果读取和路由选择；它不执行退款或账户操作。使用的 0.9 门槛是教学值，应替换成在该任务上验证过的阈值。

import math

OPTIONS = {"billing", "technical", "account", "out_of_scope"}
EXPECTED_MODEL = "jev-1.13.0"


def select_route(payload, threshold):
    if not 0 <= threshold <= 1:
        raise ValueError("threshold must be between 0 and 1")
    if payload.get("model") != EXPECTED_MODEL:
        raise ValueError("unexpected model version")

    answer = payload["answers"]["department"]
    if answer.get("type") != "choice":
        raise ValueError("unexpected answer type")

    probabilities = answer["probabilities"]
    if set(probabilities) != OPTIONS:
        raise ValueError("unexpected option set")

    for value in probabilities.values():
        if (
            isinstance(value, bool)
            or not isinstance(value, (int, float))
            or not math.isfinite(value)
            or not 0 <= value <= 1
        ):
            raise ValueError("invalid probability")

    if not math.isclose(sum(probabilities.values()), 1.0, abs_tol=1e-3):
        raise ValueError("probabilities do not sum to one")

    choice = answer["choice"]
    if choice not in OPTIONS:
        raise ValueError("unknown choice")
    if probabilities[choice] < max(probabilities.values()) - 1e-6:
        raise ValueError("choice is not a highest-probability option")

    if choice == "out_of_scope":
        return {"route": "review", "reason": "outside_or_unclear"}
    if probabilities[choice] < threshold:
        return {"route": "review", "reason": "below_task_threshold"}
    return {"route": choice, "reason": "accepted"}

字段含义和概率归一化要求来自官方 API。代码在同分并列时允许服务选择其中一个最高概率选项，也明确使用 probabilities[choice] 作为门槛输入。响应结构

对于评估任务，应记录模型版本、问题与候选定义的版本、选中项、完整概率、策略动作及最终标签。后续需要区分“模型判断错了”和“模型判断正确，但程序策略不适合业务”的情况。

HTTP 超时、限流和服务过载同样需要单独处理。官方说明了 429 与 529 等响应，并建议指数退避。它们属于服务可用性问题，不能被替换成一个模型低置信度结果。错误处理

根据损失决定动作

Jev 输出的概率可以作为成本决策的输入。假设自动误分一次的平均损失为 C_error，人工复核成本为 C_review，并暂时假定复核能够纠正错误，则：

自动处理的期望损失 = (1 − p_correct) × C_error
人工复核的成本     = C_review

在这些假设下，自动处理的条件为：

p_correct ≥ 1 − C_review / C_error

例如，复核成本为 2 个成本单位，误分损失为 100 个单位，理论门槛就是 0.98。数字仅用于说明决策规则，实际还要考虑不同误判的不同成本，以及人工复核自身的错误。

多类别场景可以定义损失矩阵 L(action, outcome)，为每种动作计算 Σ probability(outcome) × L(action, outcome)，再比较自动处理、补充信息和复核的预期代价。

这一步需要有适用于当前任务的概率估计。前面的 confidence 派生公式，并不能直接提供这里要求的真实正确概率。自动处理门槛还需要通过独立测试集上的错误率验证。

适用领域与首个项目选择

选择 Jev 的应用领域时，先看任务的答案形态。能够定义类别、等级或是非标准，并且可以收集人工标签的语义判断，更容易验证效果。一次判断之后的动作越清楚，模型输出越容易接入现有软件。

领域	适合交给 Jev 的判断	仍由其他组件承担的工作
技术资料与研究知识库	文档分类、主题相关性、纳入标准筛选	采集、正文提取、复核、存储和检索
客服工单	请求意图、处理部门、紧急程度、资料是否齐全	查询订单、指派工单、生成回复和升级人工
电商	商品类目、售后诉求、缺失凭证	精确计算金额、核验订单规则和执行退款
RAG 与搜索	候选文本相关性、证据是否支持问题	建立索引、召回候选、生成答案和组织引用
智能体工作流	工具选择、请求路由、升级判断	参数校验、权限检查、工具执行和结果确认

这些方向来自接口能力与任务结构的匹配，不能直接推出任何一个业务的准确率。官方用例目录也列出了检索、客服、商品分类和模型路由等应用。官方用例目录

首个试点选择资料归档，有三个实际好处：错误容易通过阅读原文发现，类别与主题可以直接写进判定标准，人工复核可以留下后续评测所需的标签。可以先减少资料整理的操作负担，再根据独立测试集决定是否开放部分自动归档。开放式长文写作、精确数值计算和复杂多步规划，需要另外的组件支持。

资料归档助手的实现

“拾知”是一个可运行的本地资料归档应用。它使用 Python 标准库提供 HTTP 服务、SQLite 保存资料与记录，前端使用不需要构建的 HTML、CSS 和 JavaScript。应用保留原文、来源、模型判断和人工复核标签；完成复核的资料可以导出为 JSONL。

资料如何进入知识库

用户粘贴正文，或导入 Markdown、TXT 文件。服务端先规范化换行与 Unicode，再计算正文的 SHA-256；相同正文直接打开原资料。来源 URL 只记录，不自动抓取。首版限制正文为 12,000 字符且不超过 24 KB UTF-8，长文需要按完整章节拆分。

界面支持收件箱、待分析与待复核筛选、已归档资料、跳过记录、正文搜索和调用账本。下面的界面截图来自规则演示模式，其中的概率不是实际 Jev 推理结果。

三项判断如何组合

一次请求在同一份标题与正文上回答三个问题，模型固定为 jev-1.13.0。来源名称与链接保存在本机，不作为模型状态发送。

问题	类型	定义与应用方式
category	Choice	在 AI 与智能体、软件工程、硬件与物联网、产品与商业、其他资料中选择主要类别
relevance	Score	按无关、弱相关、相关、高度相关四个描述等级，判断正文对用户归档主题的价值
sufficient	Noul	判断正文是否有足够核心信息，而不是只有标题、链接、广告或明显截断的片段

类别键使用 c0 至 c4，实际含义写在 rubric 中。程序检查返回模型版本、问题类型、选项集合、概率范围与总和、最大概率选项、加权分值和输入用量。返回类型合法之后，才形成建议。

相关性使用 P(等级 2) + P(等级 3)，分类使用选中项概率，正文是否足够使用 Noul 的 yes 概率。下面是首版建议策略的等价简写：

def suggest(answers):
    category = answers["category"]
    p_category = category["probabilities"][category["choice"]]
    p_sufficient = answers["sufficient"]["noul"]
    levels = answers["relevance"]["probabilities"]
    p_relevant = levels["2"] + levels["3"]

    if p_category < 0.80 or p_sufficient < 0.80:
        return "review"
    if p_relevant >= 0.80:
        return "keep"
    if p_relevant <= 1 - 0.80:
        return "skip"
    return "review"

这里的 keep 和 skip 都是给人工的建议。所有资料仍进入复核流程，原文也不会因为模型建议跳过而删除。0.8 是首版试点参数，尚未由真实业务标签校准；它不表示系统有 80% 的正确率。把平均相关性分数替换成高等级的概率之和，可以避免只看均值遗漏分布差异，但仍然需要验证这些概率与人工判断的关系。

缓存与费用账本

结果缓存的键包含提供方、固定模型版本、规则版本，以及标题、正文、主题和完整问题。切换提供方、调整主题或规则，会产生新的缓存键。演示结果与真实 API 结果隔离，不能用演示缓存代替 Jev 调用。命中缓存时复用已有判断，不产生新的模型请求。

真实调用前，SQLite 事务先检查日预算和月预算，并占用当前模型整请求 64k 输入 token 对应的费用。成功收到可核验的 usage.input_tokens 后，按实际用量结算。若返回的用量已知、答案格式却无效，费用仍然计入账本。

网络超时不等于未计费。因此，缺失用量、网络失败或进程中断时，系统保留预算占用；重启不会把它当作零费用。程序不自动重试这类调用，使用者需要根据供应商记录核对后再解除占用。默认每日预算为 0.05 美元、每月为 0.50 美元，账期按 UTC 计算。这些限制覆盖当前项目、配置价格与公布的输入上限，不能限制其他程序使用同一账户产生的费用。

按当前输入价格，单次最大预留额的计算是：

64,000 / 1,000,000 × 0.042 = 0.002688 美元

这种策略比较保守：剩余预算即使够支付一篇短文，也必须覆盖整次预留额才允许发起请求。它优先保证预算账本在并发和不明计费时仍保留成本，而没有把本地字符数当作精确 token 数。更新模型或价格时，要同步检查预留依据。

启动与真实 API 接入

项目需要 Python 3.10 或更新版本，没有第三方安装依赖。下载并解压项目后，在 jev-archive 目录运行：

python3 server.py

浏览器访问 http://127.0.0.1:8765。默认是规则演示模式，不发送外部请求。项目附带三份合成示例，以及此前技术博文拆分的 14 个章节，供导入和复核流程练习。

接入真实 Jev 时，先停止演示服务，在 Bash 中配置密钥和提供方：

read -r -s -p 'TypeSafe API Key: ' TYPESAFE_API_KEY
export TYPESAFE_API_KEY
export JEV_PROVIDER=typesafe
python3 server.py

密钥只在后端使用，不传给浏览器，也不写进数据库和日志。本地保存的是资料与应用状态；真实模式下，标题与正文会发往 TypeSafe 云端推理。本地运行应用并不意味着本地运行 Jev。

默认数据库为 data/archive.sqlite3。维护命令使用 SQLite 在线备份接口生成一致快照；复核结果、模型快照和核费记录都可以保留。首版只监听本机地址，没有多人账户体系。扩大到团队或公网服务时，还需要身份权限、任务队列、分页与经过验证的资料采集流程。

项目文件：下载完整源码包 · 启动和配置说明 · 工程验证记录

工程验证与业务验证

当前首版通过 25 项自动化测试，覆盖去重、缓存持久化、主题变更、提供方隔离、并发预算、超时与进程中断占用、响应校验、人工标签、导出、备份和费用核对。浏览器流程验证了文件导入、纯文本展示、人工复核、导出和主题修改；320、390、736、1024、1440 像素宽度没有横向溢出。

这些检查使用固定接口响应与规则演示，真实 Jev API 调用次数为零。因此，它们证明的是应用流程和接入逻辑通过了相应检查，不能证明 Jev 对真实中文资料的分类准确率或概率校准质量。

业务验证应另外准备覆盖各类别、无关资料、混合主题、短文和边界表达的真实样本，分别用于规则调整与独立测试。可以用 200 份资料作为首轮试点规模，再根据类别分布、目标错误率与置信区间决定是否扩大样本。评测至少记录错误收录率、漏收率、人工复核比例、端到端 p95 延迟和平均实际费用。

随项目提供的 evaluate.py 会统计已复核资料的类别准确率、阈值覆盖率、接受集合错误率和相关性 Brier 分数，默认排除规则演示。只统计被复核资料可能存在选择偏差；主题或模型版本混合时也应分组。开放自动归档之前，需要在独立测试集上重新验证操作点，并抽查高概率建议。

成本与级联的实际收益

当前官方价格为每百万输入 token 0.042 美元，输出免费；模型为 jev-1.13.0。总请求预算为 64k token，状态加最长单个问题另有 32k 限制。模型只接收文本；图像、音频和视频需要先转换为可供判断的文本或结构字段。模型规格

假设一次请求共计 1,000 个输入 token，100 万次请求的 Jev 输入费用约为 42 美元。如果输入增至 10,000 token，同样调用量约为 420 美元。这些计算只覆盖模型输入费用，不包含其他处理环节。

按量计费与自动充值

官方服务按输入消耗账户 Credits。没有模型请求时不产生输入用量费；在归档项目中，查看、人工确认和导出都不调用模型。API 的按量价格、账户自动充值和企业或网关订单，是需要分别检查的计费条件。

账户协议允许用户选择开启自动充值：余额达到阈值或耗尽时，可以按用户设定金额再次充值；未开启时，服务可能拒绝继续生成结果。购买余额默认在合同期限结束或购买后 12 个月两者较早时到期，订单可另有约定。促销余额遵循发放时的额外条件。账户协议第 8.2 条

假设每篇资料的标题、正文、主题、问题和选项，合计实际消耗 2,000 输入 token，则按当前官方输入价格计算：

每月分析资料	输入 token 总量	Jev 输入费用估算
1,000 篇	200 万	0.084 美元
10,000 篇	2,000 万	0.84 美元
100,000 篇	2 亿	8.40 美元

这是按假设用量计算的情景，实际项目尚未测得平均 token 数。最终以接口用量与供应商账单为准；税费、网关加价、云托管、正文提取和额外生成模型费用另算。汉字数量不能直接当作输入 token 数。

完整流程与级联成本

整个系统的成本更接近：

总成本 = 状态准备成本 + Jev 成本
       + 升级比例 × 第二阶段平均成本
       + 复核成本 + 错误造成的损失

延迟也要包含状态准备、网络往返、模型服务、工具执行和重试。从意大利发起的一个社区评测测得约 0.9 秒的调用延迟，因此部署区域的实际测量比宣传中的最短时间更有参考价值。历史地区延迟

低置信度请求可以上送更大的模型，但收益取决于第二阶段在这些难例上的表现。对照研究发现，一些级联能够保持准确率并降低成本，另一些组合没有明显收益。第二阶段总体分数较高，并不保证它擅长纠正第一阶段筛出的错误。级联实验

级联评估需要按完整策略计费，并直接检查被升级子集的纠错率。还应为重复升级、重复工具调用和无进展循环设置明确的停止条件。

开源替代与选型条件

有稳定标签和业务标注数据时，专门训练的分类器是重要的对照组。在一项决策模型研究中，使用任务标注微调的 DeBERTa 在多数测试上有最高的观测准确率。缺少标签或候选集合频繁变化时，按请求定义规则的通用判断服务更有吸引力。分类器与决策模型对照

Laya 提供本地运行路径，但其公开比较需要仔细读取条件。README 明确说明，typed-decisions 上 76.6% 的成绩来自使用该基准训练集微调的检查点，而引用的 Jev 数字来自其他评测；本地推理与远程 API 延迟也不是同一测量范围。Laya 的评测与限制

项目条件	应纳入比较的方案	核心验证
标签固定且已有可靠标注	专用分类器与领域校准	自有测试集的错误率与维护成本
标签变化快或缺少训练样本	Jev 等通用判断服务	对定义的遵循能力与拒绝策略
需要本地部署	Laya 或其他开放权重模型	上下文预算、语言表现和服务成本
需要生成解释或多步推理	生成模型与判断服务的组合	第二阶段在难例上的实际纠错率

比较应固定输入、问题、候选集合和测试集，报告模型是否使用过该任务的训练数据，并在相同测量范围内计算速度和成本。

JevBench 等榜单还将能力、校准、速度和成本组合成综合分。部分自托管模型的服务延迟使用估算修正，成本也可能使用参考价格。阅读排名时，需要回到原始准确率、延迟、费用及其测量条件。JevBench 方法

在业务数据上验证采用条件

一个可用的验证流程可以从低成本、容易获得结果标签的判断开始，例如工单分流或检索资料筛选。先明确答案定义与错误成本，再分别准备校准数据和独立测试数据。

测试集需要包含正常请求、相邻类别的边界案例、范围外请求、信息不足、否定表达、互相矛盾的字段，以及用户意见与已核实事实不一致的情况。中文业务还应包含真实表达和行业术语；官方说明英语是主要训练语言，其他语言表现并不等同。语言支持

评价结果至少同时保留准确率、风险与覆盖率、范围外误接收率、正常请求误拒绝率、校准指标、端到端 p50 与 p95 延迟，以及包含复核的完整成本。上线后仍需要抽查自动接受的结果，因为只看被拒绝的样本会漏掉高置信度错误。

模型版本、问题定义、候选集合或输入分布改变时，应重新检查原来的操作点。一个曾经有效的阈值，未必适用于新的服务状态。

Jev 最有说服力的采用理由，是在具体任务上用较低成本承担一部分可验证的判断。它把概率交给软件，也把策略选择交还给开发者。最终要证明的是：在可接受的误判和拒绝水平下，系统能够自动处理更多请求，并减少完整流程的代价。