Jev 是什么：一个不生成文本的模型，「零幻觉」到底指什么

Behaviour
0 阅读10分钟

2026 年 9 月 15 日，旧金山一家叫 TypeSafe AI 的公司走出隐身模式。同一天公布 4000 万美元种子轮，DCVC 领投，Wilson Sonsini 做法律顾问——这些是可查的硬信息，比"前 OpenAI 研究员创业"这种标签完整得多。

带队的人里有个熟脸。Diogo Almeida，前 OpenAI 研究员，InstructGPT 和 RLHF 那套对齐工作的参与者。另外两位创始人是 Erik Gafni 和 Sasha Sheng。公司 2024 年成立，自我定位是 "machine-native, composable AI"。

然后他们端出来的东西把不少人搞懵了：Jev，一个不会写字的模型。

一、热度是怎么起来的

发布 36 小时后，14 万人的 waitlist 被清空。9 月 20 日，官方直接取消 waitlist 全量开放，新用户送 5 美元额度，大约 1.2 亿 token。

Vercel 那边的数据更有意思：24 小时内，约 13% 的付费 AI Gateway 团队用上了 Jev，官方口径是 GPT-5.6 家族的 2 倍、Fable 5.1 的 6 倍，被称作该网关历史上增长最快的付费模型。Vercel 自己的工程师还拿它替换掉 OpenAI Luna 5.6 跑安全分类器，那一段快了 5 到 18 倍。

请添加图片描述

一个不聊天的模型，为什么会有这种热度？我觉得答案不在技术本身，而在于它戳中了 Agent 工程里最难受的那根刺。

现在做 Agent 的人都有个共同经验：让大模型输出结构化结果，你得写一堆重试、校验、JSON 修复。模型会多吐一个字段，会漏一个引号，会在该选 A 的时候给你写一段解释。Jev 的卖点就是把这个环节干掉。

二、它到底做的是什么

Jev 不做文本生成。它接收一段非结构化的状态（输入），返回你预先定义好的、类型化的决策（输出）。

题型只有三类：

  • Choice：从最多 255 个选项里选一个；
  • Score：在固定刻度上打分；
  • Noul：输出 0 到 1 之间的真值概率。

三类可以在同一次调用里混用。你要它同时判断"要不要拦截"、"风险有多高"、"这事是真的概率几成"，一个请求就够。

下面这段是示意代码，字段名按官方文档口径写的，具体以官方 SDK 为准：

from typesafe import Jev

client = Jev(api_key="...")

resp = client.decide(
    input={
        "command": "rm -rf /var/lib/postgresql",
        "user": "ci-bot",
        "cwd": "/srv/app",
    },
    tasks={
        # 从 255 个以内的选项里挑一个
        "action": {
            "type": "choice",
            "options": ["allow", "ask_human", "block"],
        },
        # 固定刻度打分
        "risk": {
            "type": "score",
            "scale": (0, 10),
        },
        # 0~1 的真值概率，不是文本，是浮点数
        "is_destructive": {"type": "noul"},
    },
)

print(resp.action)          # "block"
print(resp.risk)            # 9.1
print(resp.is_destructive)  # 0.97
# schema 是保证的：除这三项外不会有任何多余字段

注意最后那行注释。这就是 Jev 全部卖点的技术内核：合法输出集合提前固定死了，所以模型在结构上无法产出 schema 之外的东西。

对写代码的人来说，这个价值其实很实在。你不需要再写 try: json.loads(...) except: retry，也不需要给 tool call 加一层 schema 校验中间件。返回值是类型化的，直接进业务逻辑。

请添加图片描述

三、「零幻觉」这四个字，官方自己怎么解释

这是整件事最值得掰开的地方。

多个来源都指出，TypeSafe 宣称的 0% 幻觉率是结构性的（by construction），不是跑出来的实测值。因为合法输出集合是预先固定的，模型没法产出 schema 外的内容，也没法输出畸形结构。官方自己承认这个区别。

说白了：它保证答案 valid（合法），不保证 correct（正确）。Jev 照样会自信地选错那个允许的选项——只不过它选错的时候，一定是在你给的选项里错的。

这个区分听着像文字游戏，其实不是。传统幻觉的定义是"模型编造了不存在的内容"，Jev 确实从机制上消灭了这一类。但工程上真正致命的是"模型做了错误的判断"，这一类它一点没少，只是换了个表现形式。

Almeida 对幻觉成因给过一个挺有意思的论点。他主张 RLHF 的奖励模型有类似 GAN 的不对称性：承认不确定会被扣分，自信地编造反而得分高，于是模型被训练得盲目过度自信。据智源社区整理，他由此提出 RLCD（Reinforcement Learning for Calibrated Decisions），作为继 RLHF（人类偏好）、RLVR（可验证结果）之后的第三条路线，目标是校准概率而不是迎合人类——说 70% 把握的时候，就应该大约 70% 正确。据官方说法，训练数据全合成。

这套论证是"为什么不做 chat 模型"的品牌叙事核心，也是他称 "RLHF 是一条弯路"的依据。我不觉得这个论点已经被证明，但它至少是个可证伪的假设，比大多数发布会话术有内容。

四、193.6 倍和 444.6 倍，这两个数字怎么读

官方口径：端到端延迟 70 到 500ms，自动化工作流任务上比 LLM 快 193.6 倍、成本低 444.6 倍。输入每百万 token 0.042 美元，输出 token 免费。

然后第三方把它拉回了地面。据虎嗅报道的独立测试，Jev 的速度优势实际在 2 到 3.6 倍，成本节省对比便宜的小模型只有 4.7 到 7.5 倍，即使对比前沿大模型也只有约 40 到 49 倍。193.6 和 444.6 是官方自测，且取自收益上界，官方自己也承认这一点。

差异为什么这么大？因为"自动化工作流任务"这个限定条件很窄。在那类任务上，Jev 一次调用就出结果，LLM 可能要生成几百个 token 再解析；但换个任务，比如需要复杂推理的，这个比值立刻塌下来。看到倍数型指标，先找它的分母是什么。

Arize 的第三方基准更细，也更值得看：

  • RAGTruth 幻觉检测任务上，Jev 和 Claude Opus 5 都是 87% 准确率。成本：Jev 每千次判断 0.05 美元，Opus 5 是 14.30 美元。延迟：141ms 对 3 秒以上。
  • SummEval 评分任务上，Jev 与专家评分的秩相关 0.74，略高于 Opus 5 的 0.70。
  • 但用默认 0.5 阈值时，Jev 反落后了：76% 对 83%。ROC AUC 0.94，略低于 Opus 5 的 0.95。

最后那两条比前面那些倍数重要得多。它说明 Jev 的优势高度依赖阈值调校——你把它当二分类器直接用默认阈值，它不一定比大模型好；你要拿它的连续输出自己定阈值，它才划算。这跟它"输出校准概率"的设计是自洽的，但也意味着接入成本不是零，你得做校准。

请添加图片描述

五、真拿去生产用，得注意什么

第三方安全测试发现了 prompt injection 风险。Jev 把输入状态当作数据处理，而不是当作可能有敌意的内容。Octomind 的工程师实测：在输入里塞一个伪造的 tool-output 字段，Jev 对某条危险命令的 block 概率从 0.76 掉到 0.48。

0.76 到 0.48，跨过了 0.5 这条线。也就是说攻击可以量化地改变判定结果，不是理论风险。

另外，选项顺序重新排列也会改变结果。这一点不奇怪，分类模型对输入顺序敏感是常识，但落到 Agent 的权限决策上就值得警惕。

业界的处理方式比较一致。Pydantic 的建议是"基于 Jev 的防护应该和确定性检查并列，而不是替代它"，LangChain 的做法是给它的中间件配人工审批。

LangChain 那个实现值得抄一下思路：他们用 Jev 决定 Agent 的 tool call 放不放行，但特意把工具输出排除在分类器输入之外。理由是——让 Agent 抓取到的内容无法授权自己的执行。这个设计选择比模型选型本身更值得记住。

# 思路示意：Jev 只做一层，不是唯一一层
def guard_tool_call(tool_name, args, *, user_intent, policy_version):
    # 1. 确定性检查先行，不依赖模型
    if tool_name in HARD_DENY:
        return Deny("policy")

    # 2. Jev 判定时，绝不把工具返回内容喂进去
    verdict = jev.decide(
        input={
            "tool": tool_name,
            "args": args,
            "user_intent": user_intent,   # 只含用户意图
            # 注意：没有 tool_output 字段
        },
        tasks={"action": {"type": "choice",
                          "options": ["allow", "ask_human", "deny"]}},
    )

    # 3. 概率不够高就升级给人
    if verdict.action == "allow" and verdict.confidence < 0.9:
        return AskHuman(verdict)
    return verdict

六、生态，和泼过来的冷水

LangChain 和 Cloudflare、Langfuse 在发布三天内就接入了。9 月 21 日，LangChain 把 Jev 接成 LangSmith Evals 的 judge，用来评估开放式 Agent 行为。他们自测 500 次二元判断，Jev 达 100%（GPT-5.6 Terra 99.8%、Claude 80%），单案方差比三个 LLM 评委低 92 到 913 倍。

这个 100% 得打引号看——500 次、LangChain 自己出的题、二元判断，样本和任务都太窄，不能当作通用结论。但方差低这个指标有意义：评委这种东西，稳定比聪明重要。

冷水也有。Redis 之父 Salvatore Sanfilippo（antirez）公开质疑 Jev 狂热，认为它只在非常狭窄的场景有真实价值，而当前的追捧恰恰反映 AI 泡沫里大多数人分不清什么重要。这话不太好听，但以他过往的判断准确率，值得记一笔。

社区那边已经冒出一堆复刻：Kev、JevRL、Nimble、OpenJev。Jev 的架构没公开，官方只披露了"新架构 + 并行采样器 + RLCD"这几个词。所以质疑声也不小——有观点认为它本质就是个封装过的动作分类器，技术逻辑接近 BERT 类 encoder 模型。知乎答主赵泠的说法更直接，管它叫"更智能的 if-else"。上下文窗口 32k 也是个实打实的限制。

七、我自己的判断

把话说清楚：Jev 不是聊天模型，不能写代码、写文案、看图，也不解释理由。复杂推理和中文适配都偏弱。

但它解决的那个问题是真的——Agent 里"最后一个判断"这个环节，用大模型确实又贵又慢又不稳。在这件事上，一个专门化的、输出类型化的、快的、便宜的小模型，工程上是合理的。

所以它到底是"在改写 LLM 的边界"还是"一个封装过的分类器"？我倾向于认为这个二选一问错了。它就是个决策接口，不是模型能力的进步。把它当模型看，你会觉得它弱得离谱；把它当接口看，你会发现它填上了一个真实的坑。争论"这算不算大模型"没什么意义，看它在你的链路里能不能替掉那三次重试。

"零幻觉"这个说法也一样。它成立，但成立在一个被收窄了定义的范围里。真正没解决的是判断正确性——Arize 的数据已经说明，它默认阈值下还不如 Opus 5，优势全靠你愿意花时间校准。它把"格式可信"做到了机制级，而"判断可信"仍然要靠你自己兜底。

至于 antirez 说的"绝大多数开发者其实不需要它"——我暂时没法反驳，也没法确认。等半年后看还有多少人在用，比现在吵这个有用。

参考链接

avatar
文章
阅读
粉丝