Jev 尝鲜：让模型做几个小判断

拿到 Jev 的 API 之后，我最想试的是两件小事：给输入选一个处理方式，以及给一组候选内容打分。跑完之后，除了几个数字，印象最深的反而是一个漏掉的响应头。

这是一篇尝鲜记录。只保留脱敏后的汇总结果，示例另外构造，不包含真实查询、原文、业务提示词和系统配置，也不是生产选型结论。

先看看它返回什么 ​

有些模型调用只需要回答一个很小的问题：这条输入走哪条路径？这篇内容相关到什么程度？

Jev 把这些判断做成了明确的接口类型。按 TypeSafe 的介绍，它接收一份 state 和一组 questions，返回结构化结果。主要有三种类型：

这次主要用了前两种。它们都能直接接到程序的分支或排序逻辑里。返回了合法选项，当然不代表判断就一定正确。

下面是一个构造的请求示例，没有使用测试集里的原始输入：

{
  "model": "jev-1.13.0",
  "state": {
    "query": "History of the fictional Aurora mission"
  },
  "questions": {
    "presentation": {
      "type": "choice",
      "instructions": "Choose the most useful presentation for this query.",
      "criteria": {
        "timeline": "A sequence of dated events explaining one evolving story.",
        "topics": "An overview organized into themes."
      }
    }
  }
}

接口是 POST https://api.typesafe.ai/v1/systemone。示例使用这次实际测试的版本 jev-1.13.0，没有把模型别名当作固定版本。

两个小实验 ​

第一个实验是选择展示方式：适合按时间讲的事件，还是适合按主题展开的内容。

我准备了 60 条输入：20 条预设为时间线，20 条预设为主题，另外 20 条没有明确预设。两类明确输入刻意保持相同数量，避免模型一直选占多数的那类，也能得到好看的分数。

这里的“预设”是调用前由助手拟定、尚未人工复核的参考。它只能用来检查模型是否符合这份参考，不能直接叫准确率。

另外 20 条边界输入不计对错。没有先定义清楚期待的行为，就不该在看到模型输出后再补一个答案。

第二个实验是 rerank：固定一组候选内容，让模型逐篇判断相关性，再按分数排序。这里用的是 Score，排序由调用方完成。

查询 + 固定候选内容
        │
        ▼
为每篇内容定义一个 Score 问题
        │
        ▼
一次请求取得各篇分数
        │
        ▼
调用方按分数排列候选内容

这轮跑了 18 个查询，每个带 30 篇候选内容，Jev 完整请求平均约 0.70 秒。质量评估中只有 16 组可计算，文章相关性参考也来自 AI。我没有把这个结果当作它能替代专用 reranker 的证明。

这两个实验使用了不同输入和任务，0.31 秒与 0.70 秒也不能解释成“多问几个问题会慢多少”。这需要另做固定输入的对照测试。

0.70 秒里，模型到底用了多久？ ​

一开始，我只在客户端记录了请求开始到结果返回的时间，也保存了响应正文。

后来才发现，响应头里还有这个字段：

x-envoy-upstream-service-time: 177

于是用同一组 30 篇候选内容补测了三次。下面是原样保留的测量值，没有把第一次请求丢掉：

这组输入的上游服务耗时平均约 190 ms。只是同一输入的三次记录，不是新的平均性能基准；它们也不是前面 18 组请求里的计时拆分。

这里还得小心一个名字：上游服务耗时不等于纯推理耗时。

按 Envoy 的定义，这个字段包含上游处理请求的时间，以及 Envoy 与上游之间的网络延迟。它可以帮助排除客户端到网关这一段的影响，但仍不能分离 GPU 计算、排队和其他处理。

客户端 ──────── 网关 ──────── 上游服务
          网络          内部网络 + 请求处理
                     └── 响应头计时范围 ──┘
└────────── 客户端完整请求计时 ──────────┘

所以我能说的是：这三次调用报告的上游服务耗时为 177–213 ms。 不能写成“Jev 纯推理只要 190 ms”，更不能拿这个数去对比另一个模型包含网络的总耗时。

下次做类似测试，我会同时保留这两个时间。原始响应头里可能还有请求标识或其他元信息，只保存需要的计时字段就够了。

目前我会怎么用它 ​

这次最想继续尝试的，是那些输出很短、调用却很频繁的小判断：选路径、打相关性分、决定是否需要进入下一步。

Choice 和 Score 让这些调用的输入输出更明确，但判断标准仍然要自己写，参考答案仍然要验证。特别是 rerank，把分数排好只是接口接通了，排出来是否符合人的搜索意图，还需要另一轮检查。

下一步我会先做隐藏模型名字的排序复核：把两种排序的前几条放在一起，看具体内容。计时则分开记录客户端总耗时和上游服务耗时。比起再多跑一串小数，这两件事更能回答我现在的问题。

测试日期：2026-09-20。本文是小规模、目的抽样的探索记录，未做生产总体推断。汇总数值沿用实际测量，未将脱敏示例冒充实测输入；原始数据不随文公开。