首页 > 资讯 > Redis之父质疑Jev狂热！绝大多数开发者其实不需要它

Redis之父质疑Jev狂热！绝大多数开发者其实不需要它

InfoQ 2026-09-23 13:03 3 阅读查看原文

Redis 作者 Salvatore Sanfilippo（antirez）公开给 Jev 热潮泼冷水，称围绕它出现的炒作，暴露了 AI 泡沫中的多数人“分不清什么重要、什么不重要”。

2026 年 9 月 21 日，antirez 在 X 上发文，对近日席卷开发者社区的新模型 Jev 发表评论。这条推文迅速获得超过 11.6 万次浏览，在 Jev 的支持者与质疑者之间引发了新一轮争论。

“Jev 或许有一些很狭窄的应用场景，但围绕它出现的炒作，恰好说明了 AI 泡沫中的大多数人根本分不清什么重要、什么不重要。”antirez 写道，“与 AI 领域正在发生的其他事情相比，Jev 只是一件很小的事，热度却爆发了。”

Jev 由 TypeSafe AI 于 9 月 15 日发布。该公司创始人 Diogo Almeida 自称参与了许多堪称 OpenAI“金曲合集”的项目，包括 GPT-4、ChatGPT，以及 RLHF，也就是 InstructGPT。“可以说，我所在的团队基本上创造了‘后训练’这个概念。”

TypeSafe 将 Jev 定位为“System One 模型”：它不生成文本，只根据输入数据，从预先定义的选项中进行分类、评分和判断，并返回相应的置信度概率。

按照 TypeSafe 公布的数据，Jev 的调用延迟约为 70 至 500 毫秒，每百万输入 token 的价格仅为 0.042 美元，输出免费。在该公司自行设计的工作流评测中，Jev 比用于对比的前沿大模型最高快约 194 倍、便宜约 445 倍。

这些数字在开发者社区引发了近乎狂热的反响。上线 24 小时内，Vercel AI Gateway 上已有近 13%的付费团队使用 Jev；发布 36 小时后，TypeSafe 收到的内测申请涉及约 14 万名开发者。AI 开发者 Theo Browne 形容，自己的 X 时间线上几乎一半内容都在讨论 Jev。用它玩《毁灭战士》、操作网页、压缩上下文、给邮件分类和审查 Agent 工具调用的演示层出不穷。

antirez 的质疑，指向的正是这种热度是否与 Jev 的技术分量相称。

在他的推文下，开发者 Giuseppe Cannizzaro 表示，自己只是对“0%幻觉”和“会做决定的 AI”这类宣传略带讽刺，就在多个社交平台遭到辱骂。“人们已经失去理智了。”他写道。

这场争论由此越过了 Jev 本身。开发者真正需要回答的是：TypeSafe 究竟创造了一类新的智能模型，还是把已有多年的分类技术，重新包装成了一个速度更快、接口更好用，也更擅长制造传播效应的产品？

解决大模型难以进入软件后台的问题

要理解 TypeSafe 对 Jev 的定位，需要回到 Diogo Almeida 创办这家公司的起点。

Almeida 曾参与开发让大模型学会遵循指令、与人对话的训练方法。但几年后，他开始对这条路线产生怀疑：大模型已经非常擅长聊天、写作和编程，真正能够脱离人类监督、在后台稳定运行的软件自动化却没有同步出现。

“尽管 LLM 已经展现出很强的智能，真正被自动化的工作目前仍然只是一个可以忽略不计的零头。”

他将原因部分归结于 RLHF，也就是基于人类反馈的强化学习。RLHF 的训练目标，是让人类更喜欢模型给出的回答。这套方法非常适合 ChatGPT、Claude Code 和 Codex 等有人参与的产品，却很难直接支撑无人值守的软件自动化。

按照他的划分，ChatGPT 和 Claude Code 仍属于 AI 的“辅助时代”，“因为 Claude Code 仍然建立在 RLHF 之上”。而真正的自动化通常发生在服务器后台：模型接收程序状态，作出一个确定形态的判断，软件立即执行下一步，人类甚至不会看到模型返回了什么。

TypeSafe 想推动的是图中右侧的“智能软件”。模型不再包办整条流程，而是被拆成一个个嵌入软件分支的智能判断。代码继续负责确定性的计算、执行和流程控制，模型只在规则难以写清的节点判断“这是什么”“应该走哪条路”“风险有多高”。

TypeSafe 因此重新设计了模型的输出形式和训练目标。Jev 放弃自由文本生成，目前提供三类问题原语：判断一个陈述成立的概率、从给定选项中作出选择，以及依据一套标准进行评分。

TypeSafe 将这种接口概括为：

输入非结构化状态，输出带类型的概率决策。

TypeSafe 希望借此把 AI 从需要全程参与任务的助手，变成可以嵌入软件分支的基础组件。这个构想很有吸引力，但也划定了 Jev 的能力边界：它主要改变了语义判断的成本、延迟和输出形式，并没有因此获得复杂推理能力。

在近期接受 Latent Space 播客的深度访谈中，Diogo Almeida 本人也对 Jev 的定位和边界给出了清晰界定。他反复强调，Jev 是“为软件而生，而非为上帝而生”（Prod, not God），其核心目标是让代码成为消费者，而不是与 ChatGPT 争夺聊天场景。

但开发者真的需要它吗？

“智能水平大致和一个 switch 语句相当”

TypeSafe 公布的“快 193.6 倍、便宜 444.6 倍”，来自公司自行设计的四套工作流评测。四项任务以相同权重计算平均准确率、成本和耗时；评测所用的参考标签，由 GPT-6 Astra 与 Claude Fable 5.1 在高推理设置下的回答平均生成。官方同时承认，这些数字处在现实收益的高端，评测工作流由公司内部人员制作，可能存在偏差。

即便如此，Jev 在这类任务上的速度和成本优势仍然相当明显。它放弃自由文本生成，不需要逐个 token 写出字段名、标点、解释和完整 JSON，只输出预先定义的选择与概率。当一次任务包含多道相互独立的问题时，Jev 还可以并行计算。

但这也意味着很多人会本能地把速度优势理解成智能能力的跃升。

System One 的概念来自 Daniel Kahneman 的《思考，快与慢》。系统一对应人脑快速、直觉式的判断，也就是几乎不费力就能完成的那部分认知。你看到一个人，会立刻判断：“对，他的衬衫是蓝色的。”系统二则对应缓慢、审慎的推理。

按照 TypeSafe 的划分，Jev 负责第一类任务，推理模型继续负责第二类任务。

Theo Browne 对 Jev 的概括很形象：把它看成一个“聪明的 if 或 switch 语句”。程序提供当前状态和有限选项，它立即决定下一步走哪条分支。邮件是否属于垃圾邮件、工单应该交给哪个团队、哪条告警需要优先处理、搜索结果如何排序，都是适合它的任务。

但是，“它的智能水平大致和一个 switch 语句相当。它适合分类，却不知道怎样浏览整个代码库并作出高质量决定。”

这就是 Jev 的能力边界。它放弃长文本生成和测试时推理，换来稳定延迟与极低成本。遇到需要综合背景、建立中间结论、反复检查假设的任务，这种设计会受到明显限制。

还有人给 antirez 反馈说，这个“狭义”的使用场景是 Agent Loop 中的每次工具调用。

X 上有一个巨火的视频也是源自这个场景。

开发者 Tamara Tran 用 Jev 为 Claude Code 历史中的工具调用逐项打分，删除被判断为无关的记录，将一段约 15.6 万 token 的对话迅速压缩到约 6.2 万 token。这段演示传播很广，因为它把原本可能耗时数分钟的上下文处理缩短到了几秒之内。

“都 2026 年了，为什么上下文压缩还要靠提示词生成摘要？Jev 可以为每次工具调用打分，删除无关内容，瞬间完成压缩。”

Theo 认为，这个实验在概念上很有意思，但我们不应该让一个不进行推理的分类模型负责压缩 Agent 上下文。

上下文压缩并不是简单的内容过滤。系统需要综合此前发生的一切，生成一份能够支持后续工作的摘要。哪些信息应该保留，取决于任务目标、已经尝试的方法、工具返回的结果，以及此前决策背后的依据。它应该在上下文过长时谨慎使用，而不应为了维持较小的上下文，持续删除看起来像噪声的内容。

而且 Jev 只有 32K token 上下文，对此前发生的事情了解又有限，因此它的数据不足够做出可靠判断。删除这些记录后，模型可能忘记自己已经尝试过哪些方法，反复执行同样的操作，最终陷入循环。

此外，Jev 完全无法访问模型的推理数据，OpenAI、Anthropic、xAI 和 Google 不会通过 API 公开这些内容，只会返回加密载荷，而 Jev 看不到这些数据，也可能在压缩过程中将其丢弃。运气好的话，也许会拿到一份推理摘要。但模型在做决定时究竟想了什么，你并不知道。

因此，任何试图压缩这些信息的方案，都无法保留隐藏在推理过程中的决策依据。

Anthropic 在这方面更加严格。想要继续使用任何推理数据，就必须完整保留全部历史记录。因此，在 Claude Code 中使用这种方案，肯定会让模型变笨很多。

最重要的是，前沿模型本身也已经针对上下文压缩和长时间运行进行训练。过去一年里，前沿实验室一直把这两项能力纳入训练流程，模型已经学会如何执行压缩。在 Codex 中，即使用户中途切换了模型，只要对话需要压缩，系统仍会调用此前使用的模型完成这项工作。

修改较早的历史记录还可能使后续推理块或提示缓存失效，节省输入 token 的同时增加缓存重写成本。因此，Jev 这类工具能在 Agent 开发工作中发挥作用，但不应让它编写代码、压缩上下文，或者随意更改 Harness 正在做的事情。

“今天的 Harness 已经相当成熟，背后投入了数十亿美元，应当充分利用这些成果，没有必要反复重新发明轮子。”

“0%幻觉”保证了格式，没有保证答案

TypeSafe 宣称 Jev“不会产生幻觉”。但“幻觉”的范围远远超过在返回类型中编造字段。这里真正得到保证的是输出结构：如果开发者规定答案只能是“销售”“技术支持”“财务”和“其他”，Jev 必须从这四个选项中选择，不会返回第五个类别，也不会漏掉字段或写坏 JSON。

TypeSafe 在官方发布文中称，Jev“永远不会出现类型错误”，并承认图表中的 0%并非实际测试结果，而是由 schema 匹配机制直接保证。

也就是说，Jev 放弃了字符串生成能力，专门针对结构化输出进行了优化，因此不会在输出结构上产生幻觉。模型必须按照指定格式输出，因此不会擅自改变结构，也不会凭空编造格式——而通用大模型在这方面出错的频率确实有点高。

Jev 看成一次具备前沿智能的函数调用：输入非结构化状态，输出带类型的概率决策。这就是核心。你把一堆乱七八糟的文本数据交给它，拿到一个类型安全的数据结构。

如果我们写一个函数，返回包含 name: string 和 age: number 的用户对象，那么每次调用时，结果都会保持这个结构。换成 LLM，它可能把 name 的格式弄错，也可能把本应是整数的 age 写成浮点数。整个过程中可能发生很多错误。

Jev 的价值在于，你能够像调用代码一样可靠地调用它，而且它的运行速度也很接近代码。它还能并行处理大量输入，这一点相当酷，token 成本也低得惊人。它的输入价格大约是每百万 token 4 美分，而 Fable 这类模型每百万 token 可能要 10 美元。

那么，它具有确定性吗？

输出格式是确定的。但我们需要区分两种确定性：结构确定性与内容确定性。它输出的内容没有完全确定，真正确定的是格式，它永远会按照你定义的结构返回结果。

GitHub Staff Software Engineer、技术博主 Sean Goedecke 将这种宣传称为一种“语义上的规避”：Jev 不会凭空创造用户没有提供的选项，但完全可能选错，例如把天空判断成红色。格式确定，不代表内容正确。

“不会破坏接口契约”和“不会给出错误答案”，显然是两件不同的事。将前者包装成“0%幻觉”，容易让使用者高估它在生产环境中的可靠性。

另外，给概率模型再加一层概率，并不会自动带来可靠性。

Jev 与普通分类器相比，最受 TypeSafe 强调的区别，是它会为每个判断返回概率和置信度。公司为此提出了 RLCD，也就是“用于校准决策的强化学习”。

所谓校准，是指模型给出 80%置信度的一批判断，最终应该有约 80%正确。现代神经网络的研究早已表明，分类准确率高并不代表置信度可靠；模型可能频繁答对，也可能在答错时表现得非常自信。一旦用户、语言、提示方式或业务数据偏离训练分布，原本有效的概率还可能迅速失准。

TypeSafe 声称，RLCD 可以让 Jev 的概率更加诚实，但目前尚未公布可靠性图、ECE、Brier Score 或分布变化测试。开发者仍然需要使用自己的标注数据，验证 Jev 给出的 80%究竟是否接近 80%的实际正确率，再根据误判成本设置自动执行、转交人工或调用推理模型的阈值。

Simon Willison 认可“决策模型”这个定位，但他还指出，Jev“实际上代表着机器学习系统向黑箱系统的进一步倒退。”

大模型本身已经像黑箱。虽然可以要求它们解释自己的决定，却无法保证这些解释有用或准确。Jev 甚至连这点都不给你：你输入任何你想输入的文本，最终只会得到一个浮点数。如果它将一封邮件标为垃圾邮件，用户无法知道哪些内容触发了判断。

这也意味着，对偏见的担忧应该被放在首位。Simon 曾让 Jev 判断旧金山湾区的每座城市是不是一座“好城市”。结果中，Cupertino 排名最高，East Palo Alto 排名最低。一个看似客观的浮点数，可能隐藏训练数据中的社会、经济和文化倾向。如果 Jev 被用于筛选求职者、判断欺诈或调整信用额度，这种不透明性会带来更大的风险。