Jett 1.0
给一段情况和一组问题，Jett 一次调用把它们全部答完。 回来的是选项与把握程度，以及需要的那个数 ——精确值，带单位，可以逐位核对。
候选里没有正确答案时，它返回的是「没有对的」， 而不是从错的里面挑一个最像的。
口径：191 道题（好题 172 + 坏题 19）· 串行测量 —— 并发会把延迟污染 25 倍
类型化的输出
问题分三类：从一组候选里选一个、回答是或否、在有序的档位上打一档。三类的返回都是结构化的，值加上完整的概率分布，不是一段还要再解析的文字。
调用方因此不需要写解析器，也不需要为「这次它多说了一句」准备容错。
数值是精确的
要拿去跟阈值比大小的数，Jett 给的是精确值，带单位，可以逐位核对。
部署口径下 191 道计算题全对，而且不随题目变难而退化：指数衰减、单位换算、两个单位之间的比值，和一次减法一样精确。
它会说「这里面没有对的」
给它一道候选全错的题，Jett 返回「无匹配」，不从错的里面挑一个最像的。实测 19 道坏题检出 19 道，误报 0；同一批题上，判断类模型检出 0 道。
自动流程要用得上它，这一条是前提：接口永远给得出答案，就没法把「这件事该转人工」表达出来。
同样的输入给同样的答案
调换候选的顺序，分数逐比特相同；同一个请求重复发，结果一致。实测重复调用不一致 0 次，作为对照，判断类模型在 160 次里出现 4 次。
对接入方来说这意味着：回归测试可以写死期望值，线上的异常一定来自输入变化，不来自模型抖动。
右边是一次真实请求
页面加载时发出，一跳一跳地落。这是一条四跳的流水线：后一跳问什么由前一跳的结果决定，所以它们必须串行，单跳延迟会被跳数乘起来。
每跳的耗时是服务端自报的，不含网络往返。刷新一次会重跑。
同一道题的所有问题合并成一次请求。实测：问 1 个问题 13.8 ms、问 8 个问题 21.9 ms —— 成本主要来自往返次数，而非问题数量。
POST /v1/systemone
{
"model": "jett-1.0",
"state": "电量 38%，还能飞 18 分钟。
距返航点 2.1 km，顶风地速 24 km/h。",
"questions": {
"action": {
"type": "choice",
"instructions": "现在应当怎么做？",
"criteria": {
"continue": "继续完成航点",
"return_now": "立刻返航",
"land_here": "就近降落",
"other": "以上都不合适"
}
},
"margin_ok": {
"type": "noul",
"instructions": "电量余量够吗？"
},
"risk": {
"type": "score",
"criteria": ["低", "需要留意", "高"]
},
"eta": {
"type": "number",
"instructions": "飞回返航点要多久？",
"unit": "min"
}
}
}{
"answers": {
"action": {
"value": "return_now",
"probs": { "continue": 0.122,
"return_now": 0.798,
"land_here": 0.040,
"other": 0.040 }
},
"margin_ok": { "value": "no", "p_yes": 0.269 },
"risk": { "value": "高", "p": 0.811 },
"eta": { "value": "5.25",
"unit": "min",
"exact": true }
},
"usage": {
"output_tokens": 0,
"server_ms": 42
}
}exact: true 表示这个值是精确的，不是近似 —— 可以直接拿去跟阈值比大小。
output_tokens = 0 —— 模型不生成任何 token，所以延迟与「要说多少话」无关。
候选里没有正确答案时，value 返回 no_match。
下表中对照一列是我们自己的实测结果，不是其公开宣称值。两次评测的坏题样本量不同（15 与 19），因为题库版本不同。
| 维度 | 判断类模型（实测） | Jett 1.0 |
|---|---|---|
| 候选里没有正确答案时能否说出来 | 0 / 15 | 19 / 19 |
| 调换候选顺序后结论翻转 | 7.5% p=0.0047 | 0 |
| 同输入重复调用不一致 | 4 / 160 | 0 |
| 计算题全量准确率（191 道） | —— | 191 / 191 |
| P50 / P95 延迟 | —— | 42.1 / 272.6 ms |
口径：191 道题（好题 172 + 坏题 19）· 串行测量。
同一道题的两种返回
切到「选项全错的题」：这道题的四个候选都不是正确答案。判断类模型仍会挑出一个并给出较高置信度；Jett 1.0 返回 no_match。
每个场景都会发出真实请求，卡片上的数由本次请求算出。点开可以看到它收到了什么、答了什么、用了多久。
这两个每一帧都要重新问一次。判断要是花三秒，这一类应用整个不存在。
虚拟驾驶：每一帧都问一次
三车道、前车、限速 —— 一秒几跳，而刹车距离必须算准
一帧 16 毫秒。判断要是花三秒，这个循环根本立不起来 —— 不是「慢一点」，是这一类应用整个不存在。
游戏 NPC：守卫该不该动手
玩家在逼近，同伴还在路上 —— 先算谁先到，再决定站还是跑
回合制还能等，实时战斗不能。每个 NPC 每回合一次调用，几百个 NPC 同时在场，慢一点就是全场卡住。
一次调用答完一组问题，再把需要的那个数算准。点标题进去看它这一次的请求与回包。
具身智能
2售后与客服
2四步以内的计算链是可靠的，站点上最长的场景就是四跳。更深的链路在做。
在有序档位上打分这一类，部署时按「拿不准就升级」处理，约七成请求交给更大的模型。这是设计上的选择：这一类的准确率我们只认升级后的那条线。
虚拟驾驶与游戏 NPC 每一跳状态都不同，没有参考答案可比。这里验证的是数值精确与单位正确 —— 这两条每一跳都成立。