莱客AI商学院/文章/拿 Jev 做生意:三个能收到钱的方向,和一笔算到分的成本账
深度文章免费

拿 Jev 做生意:三个能收到钱的方向,和一笔算到分的成本账

每百万输入 token 0.042 美元、输出免费。这个价格会让一批以前算不过来的活儿变成生意——也会让你在付款、网络、中文这三件事上卡住

莱客编辑部2026-09-24预计 9 分钟
拿 Jev 做生意:三个能收到钱的方向,和一笔算到分的成本账 封面

文章目录

共 6 节
01一、这个价格到底意味着什么02二、方向一:给别人的系统补一层「判断」03三、方向二:给 LLM 应用装护栏和路由,省下来的就是你的04四、方向三:把判断变成能复用的数据05五、国内团队会卡在哪三件事06六、我不建议现在做的三件事

先把单价摆出来,因为后面所有的判断都建立在这个数上。

jev-1.13:每十亿输入 token 42 美元,折合每百万 0.042 美元。输出 token 不计费。这是 TypeSafe 官方 Models 页上的数字,不是我算的。

一、这个价格到底意味着什么

拿一条典型工单算:连上下文一起大约 1,000 个 token。

  • →一条 = 0.001 × 0.042 = 0.000042 美元。人民币按 7 折算,约 0.0003 元。
  • →一个月 10 万条 = 4.2 美元,约 30 元。
  • →一个月 100 万条 = 42 美元,约 300 元。

而且这里有个容易忽略的杠杆:同一份 state 上多挂几个问题,token 不会翻倍。Jev 把 state 吃进去一次,所有问题并行地对它评估。官方那份 GDPR cookbook 量化过,13 个问题打包成一次请求,比拆成 13 次便宜 12.2 倍、快 10.0 倍,答案不变。

换句话说:你在一条工单上问 3 个维度还是 12 个维度,成本基本是同一个数。这件事直接改变了产品设计——以前「多问一个维度」要算一次账,现在不用算。

两个来自真实项目的参照物,都出自官方与开发者公开的数据:jevmeter 给一场辩论逐句打分,一场大约 0.05 美元;TypeSafe 团队那个玩 Doom 的 demo,每秒 10 次查询,约 7 美元一小时——工程师本来担心这个频率太贵,团队其他人的反应是「比预期低」。

再放一个对照。官方的抽取级联 cookbook 里列了三个模型 2026 年 9 月 15 日的标价(美元 / 百万 token,输入 / 输出):gpt-5.4-mini 是 0.75 / 4.50,gpt-5.5 是 5.00 / 30.00,而 Jev 做校验那一层是 0.042 / 0.00。

在这条价格带上,「让模型判断一下」从一个要写进预算的动作,变成了一个可以随便调用的函数。

二、方向一:给别人的系统补一层「判断」

最容易落地的一类生意,不是做一个新产品,是给已经在跑的系统补一个它缺的能力。

典型场景:客服工单系统、CRM 线索池、社群内容、电商评价、投诉工单。这些系统里都有一堆靠人眼分拣的活,而且都有一个共同特征——判断标准是行业知识,写不成 if,但一个熟手看三秒就能判。

交付形态建议做成「旁挂」而不是「替换」:读它的数据,把判断结果写回一个新字段,不动它的主流程。理由很实际——替换要谈很久,旁挂当周就能上。

定价上有个很舒服的结构:你的成本是按 token 线性的、极低;客户感知到的价值是按「省了几个人」算的。中间的空间就是毛利。但有一条纪律必须守:把 confidence 的分档做成客户能看见的东西。高置信自动处理、中置信标记待复核、低置信原样退回人工——这个三档不只是技术设计,它是你敢签合同的依据,也是出了问题时的责任边界。

官方那份自洽性 cookbook 的主题就是这个:把概率落在不确定区间的交给人复核,同时把底层的 Noul 值保留下来给人看。别把概率吞掉。

三、方向二:给 LLM 应用装护栏和路由,省下来的就是你的

现在做 AI 应用的团队,账单结构大同小异:一大半的钱花在「让大模型干一些其实不需要大模型的事」上。

两个已经被 cookbook 写成现成配方的做法:

护栏。用一次请求同时问一组 Noul(越狱?违反策略?涉及伤害或犯罪?给出诊断或剂量?自伤?)加一个 Score(照做会造成多大伤害),然后在代码里定阈值决定放行 / 复核 / 拦截 / 转人工。进和出两个方向都要过——普通的提问也可能引出有问题的回复。这比「在 system prompt 里写一堆规则」强的地方在于:规则在你的代码里,看得见、改得动,而且越狱话术是被当成输入打分的,不是被当成指令执行的。

路由。进来的请求先分类,分完再决定送到哪:能用确定性代码处理的(比如查订单状态)根本不调模型;要专业知识的送到专门的 LLM;复杂度高或置信度低的直接给人。官方给的分档很朴素:intent 的 confidence 低于 0.5 就转人工,不猜。

还有一个更工程化的形态叫级联抽取:便宜模型先抽,用 Jev 的 Noul 逐字段验(「这个值在原文里根本不存在吗」「它是不是从无关段落里扒来的」),只有验证信号触发时才升级到贵的推理模型。官方那份 cookbook 的触发阈值取的是 0.7。

这类活儿之所以是生意,是因为它的 ROI 能直接在账单上看见。给客户看上个月和这个月的 API 账单差额,比讲一百句效果好。

四、方向三:把判断变成能复用的数据

前两个方向是「省钱」,这个方向是「攒资产」。

核心思路:把一件事拆成若干个独立的打分维度,评一次,存起来。之后要改权重、改阈值、改排序口径、改展示筛选,都不需要重新推理——只要证据和问题的含义没变,分数就还是那些分数。

官方给的例子是简历筛选:Python 深度、团队管理、系统设计、通用性四个 Score 分开问,归一化到 0–1,然后用两套权重分别算「资深个人贡献者」和「工程经理」两个岗位的综合分。招聘口径一变,改的是四个系数。

再往前走一步,这些分数可以直接当成传统机器学习的特征。官方有一份 cookbook 就是拿 Jev 的概率去喂一个 CatBoost 回归器,用模型的误差反过来改进提问。对做数据产品的人来说,这条路线的意思是:你有办法把「非结构化文本里的常识判断」变成一列数值特征,而且成本低到可以对全量历史数据跑一遍。

还有一个立刻能用的场景是重排。官方拿 CLERC 法律数据集做过:BM25 先从 3,565 条判例段落里为 40 个查询各召回 30 个候选,再用 Jev 对每个「查询–候选」对问一个问题做重排,Top-1 命中率从 5% 提到 18%,Top-10 从 38% 提到 62%。数字不高,但这是法律长文本上的检索,提升幅度是三倍多。任何有搜索框的产品都能照抄这个两段式结构。

五、国内团队会卡在哪三件事

这是我认为必须讲清楚、但中文报道普遍不讲的部分。

第一,中文准确率没有保证。官方 Models 页写得很直白:英文是主训练语言,目前准确率最好;包括中日韩文字在内的其它语言「能处理,但没有同等水平」,用于非英语工作负载之前请先在自己的内容上测,并且在路由时密切关注 confidence。这不是「不能用」,是「你得自己验,而且要把不确定的那部分兜住」。

第二,服务在美国西海岸。官方自己说评测「一般是在西海岸的笔记本上跑的」。它的卖点是 70–500 毫秒的端到端延迟——如果你的调用要跨太平洋,这个卖点会被网络吃掉一大块。做实时交互(边打字边判断那种)之前,先自己测 p95。

第三,早期访问 + 候补名单 + 美元付款。目前没有公开权重、没有参数量、没有自托管选项。限速还在动态调整,官方原话是「我们在承接非常大的需求量,上面这些限制可能随时变」。

这三条加起来,结论是:别把公司的核心链路押在一个你付不了款、连不稳、还没法私有化的服务上。

好在 9 月 23 日出现了一条退路。诺基亚的应用研究团队开源了 AnyJev——一个 Apache-2.0 的 Python 库,不需要训练,把任意开源 LLM 变成 Jev 那种形状的决策模型。它借用了 Jev 的接口:同样是 choice / noul / score 三种问题,概率直接从模型的下一个 token 分布里读出来,什么都不生成、不解析、不训练。

# pip install "anyjev[hf]"
from anyjev import Decider, Question
from anyjev.backends.hf import HFBackend

d = Decider(HFBackend("Qwen/Qwen3-8B"))
route = Question.choice(
    "这条该谁处理?",
    ["billing", "technical", "sales", "other"],
    name="route")
r = d.decide({"conversation": [...]}, [route])
r["route"].distribution # 每个选项的概率

它解决的是「直接读 logits」的两个老毛病:位置偏置(模型偏爱选项列表里的某些位置)和先验偏置(模型天然偏爱某些标签,比如 Yes 多于 No)。默认开的 L0 层做两件事:把 K 个选项做 K 次循环移位、让每个选项在每个位置各出现一次,在对数空间取几何平均;再用批量校准把先验除掉(按 0.75 的强度,从第 8 条开始生效)。

在 Qwen3-8B 上跑 BANKING77(20 分类、300 条测试)的公开数字:选项顺序反转后的答案翻转率从 0.230 降到 0.073;准确率 0.747 → 0.803;校准误差 ECE 0.240 → 0.184;在 5% 错误率下可自动裁决的流量占比从 7.7% 升到 46.3%。再加一层 L1(要 100–500 条标注做温度标定)后,ECE 到 0.095,可自动裁决比例到 52.0%。代价是 L0 每个决策要跑 K 次前缀填充,在一张 H100 上、K=20、batch 32 的情况下约 0.25 秒一个决策。

对国内团队,这条路的意义很实在:用你已经部署在本地的 Qwen,拿到一个形状相同、概率可用的决策层,不出网、不付美元、不受限速。代价是慢一到两个数量级、要自己出卡。先用 AnyJev 把产品形态跑通,等 Jev 的可达性改善了再切,是个合理的顺序。

六、我不建议现在做的三件事

  • →做「Jev 中转/代理」。价格低到这个程度,中间商赚不到差价,而且官方限速还在动态调整,你转手卖出去的额度随时可能不作数。
  • →拿「零幻觉」当卖点去签对赌。官方原文说得很清楚:零幻觉指的是 schema 一定匹配,那个 0% 不是实测出来的,答案照样可能是错的。拿这句话去承诺准确率,最后赔钱的是你。
  • →把它塞进需要精确计算的环节。金额、天数、计数、日期先后——这些代码能算准的,交给代码。官方的失效清单里,数字和日期是排在最前面的两条。

最后一句:这个方向真正的门槛不在接口,接口十分钟就能跑通。门槛在你能不能把一个行业里「老师傅三秒钟的判断」拆成几个互相独立、措辞精确、边界情形写在 criteria 里的问题。那是领域知识,不是 API 知识——也正因为如此,它才可能是你的护城河。