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 同时在场,慢一点就是全场卡住。
泛娱乐与互联网
每个 NPC 每一回合都要决策,每条内容都要过一遍闸门 —— 量大、单价低、慢不得。4具身智能
机器在等一个能跟阈值比大小的数,而链路随时可能断 —— 这一层只能放在机上。2出行与车载
判断慢一秒,路口就过去了。车机算力有限,云端往返不可靠。3制造业
停机一分钟的代价是可以精确算出来的,所以「停不停」这个判断也必须精确。2售后与客服
规则是死的、金额要算对、能自动的别转人工 —— 三件事要在一次请求里做完。2生活与健康
不酷,但每次都要算对。算错的代价是柜子放不下、半夜睡不着、吃到过敏原。4需要连续七步以上才能得到结果的题,目前端到端不成立。四步以内的链路是可靠的,站点上最长的场景是四跳。
在有序档位上打分这一类问题,模型自己答的准确率未达到我们的上线判据。部署时走的是「拿不准就升级」,结果可用,但其中约七成请求会被升级处理。
场景页的虚拟驾驶与游戏 NPC 每一跳状态都不同,没有参考答案。能验证的只有数值精确与单位正确;「这个决策是对的」没有判据,我们也没有这样声称。