Jev 札记

做出它的是前 OpenAI 研究者 Diogo Almeida 创办的 TypeSafe AI。他是 InstructGPT 论文的共同作者，也就是第 1 期・三章里 RLHF 的出处。他形容 Jev：「就把它当成一个聪明的 if 语句」。

让 LLM 做工单分类，返回的是一段文字。就算要求它输出 JSON，长度和形式仍由模型决定，于是每次都得自己去校验。Jev 则根本没有输出字符串的能力，返回值必定落在我们定义的类型里。

LLM 是一个词一个词地往下写（第 1 期・一章）：要写 100 个词就得跑 100 趟。Jev 不写文章，也就没有这一层循环。不是输出短，而是输出的机制本身不同。

输出词元免费，是因为它吐不出值得计费的量：返回的只有几个概率和一个置信度。计价单位不是「百万」而是「十亿」，也是同一个道理。

还有「快 193.6 倍、便宜 444.6 倍」这样的数字，但那来自 TypeSafe 自己的评测，比较对象也由他们挑选。量级大致可信，不过还是要用自己的数据重新测一遍再下判断。

只要交两样东西

传给 API 的是 state（希望它看的东西）和 questions（想问的问题）。

state 只要是「希望模型去看的东西」就行：字符串、对象、数组都可以，直接传 JSON 也行。上面的例子放了标题、正文和套餐等级。

问题有三种

三种类型都要写 instructions（在问什么）。criteria 是可选的，用来说明每个选项或每一档的含义。经由 SDK 调用时名字可能不同，比如 Vercel 的 AI SDK 把 Noul 叫作 boolean。

返回的东西

这里是与 LLM 最大的不同：没被选中的选项的概率也一并返回，而且置信度是单独给的。也就是说，「倾向于 billing，但没什么把握」这种状态，我们这边的代码是读得到的。

置信度高就直接自动处理，低就转交给 LLM 或人。阈值由自己的代码来定，模型只负责给出材料。这种分工大概就是 Jev 的设计思路本身。

先说清一个前提：Jev 不会操作浏览器。动手的是 Playwright 之类的代码，Jev 只负责看着当前画面判断「下一步做什么、是否通过」。

state 里放什么

这应该是问题的核心。不要把 HTML 原样丢进去：上下文长度是 32,000 词元，真实页面的 DOM 很快就会超出。要放的是「摘要过的画面」。

• goal・expected ── 要验证什么。没有这个就没法判断通过与否
• step・history ── 现在是第几步、之前做了什么。可以借此发现原地打转
• page ── URL、标题、可见文本、警告或提示的文案
• actions ── 可点击元素的清单。它本身就是选项

questions 怎么搭

nextAction 的选项最多 255 个，所以可点元素超过 255 的页面，得先在代码里筛一遍。

截图是传不进去的（仅文本）。如果就是要判断外观，得先让能读图的模型把画面描述出来，再把那段文字放进 state，做成两段式。

发布后几天里，已经出现了每 300ms 左右判断一次盘口的交易机器人、按品种各自独立持仓的结构，以及只做纸面交易的验证版本。也有更稳一些的用法，比如港股方向预测、银行咨询分类（正确率 92.4%）。

这些实例的共同点是：把 state 压到 400 词元左右交给它，再用自己的策略去处理返回的概率。Jev 不会自己去看行情。用什么做特征、怎么压缩，全是我们这边的活儿。

要留心的地方

• 校准不等于「猜得准」 ── 概率被校准，指的是在它学过的分布上说 0.7 就约有七成命中。行情是非平稳的，而且有对手方，那是分布之外
• 70〜500ms 只是对 AI 而言快 ── 对拼速度的策略来说仍然太慢
• 仅文本、32,000 词元 ── 图表图片传不进去，历史也不能无限塞
• 它是概率性的 ── 同样的输入未必给同样的答案。止损线、持仓上限这类绝对要守的规则，放在代码里而不是模型里
• 基准是自家测的 ── 关于快与便宜的说法，自己环境里量过再判断更稳妥

Jev 不是 LLM 的替代品。第 2 期・一章说过的「让它去猜什么」的差别，直接变成了各自的守备范围。

另一个很有前景的用法，是充当 LLM 的看守：在智能体调用工具之前，先让 Jev 判断这次调用有没有风险，危险就拦下。这大概是第 1 期・六章所说「可靠性累乘」问题的一个现实解法。

想先试的话

目前只让 LLM 做分类的那些地方，最容易替换。输入和期望输出都是现成的，可以用同一批数据把两边都跑一遍再对照。先在自己的场地上验算一遍那些关于快与便宜的说法，是个不错的起点。