OpenAI即将抢占Jev的市场 – Arcturus Labs

# OpenAI会抢走Jev的饭碗吗？ 来源：https://arcturus-labs.com/blog/2026/09/21/will-openai-eat-jevs-lunch/ TypeSafe的Jev（https://arcturus-labs.com/blog/2026/09/16/typesafes-jev-trades-text-generation-for-instant-calibrated-decisions/）为大语言模型引入了一种新范式，在AI界引起了轰动。据Vercel（https://vercel.com/blog/ai-gateway-jev-model-launch）称，“Jev在AI Gateway中的采用速度创下历史纪录。”……但天空中正乌云密布。OpenAI无疑正密切关注——并决定下一步行动。一个笨重的OpenAI机器人舔了舔嘴唇，伸手伸向一个瘦小的TypeSafe机器人正开心吃着的巨大三明治。 我衷心祝愿TypeSafe一切顺利，但如果他们真的兑现了承诺，我担心OpenAI完全有能力快速跟进——不仅复制Jev的旗舰产品，还能将这种能力融入即将推出的模型和智能体中，提供Jev难以复制的、非常实用的新行为。以下是我的简要论点：多年来，OpenAI一直将他们的大语言模型用作隐式分类器；只是他们没有针对通用分类任务进行训练，也没有将通用分类封装为独立产品。如果OpenAI能够复制这种训练方法，他们将很快能够复制Jev。此外，OpenAI可以利用这个新的分类器嵌入现有的模型和智能体中，从而实现快速模型选择、更高效的思考、更好的安全护栏，以及总体上更智能、更快、更便宜的模型。决定这一切的关键因素是TypeSafe是否拥有护城河来保护自己。我看到的最大护城河在于TypeSafe的训练数据和训练流程。 ## 老调新弹 在展开论述之前，让我先陈述我的假设，并用OpenAI相关的历史和例证来支持它们。我的主要假设是：Jev使用的是一种非常接近传统大语言模型的东西。作为证据，Latent Space报道称（https://www.latent.space/p/ainews-here-are-6-cloneof-jev-in），许多早期克隆确实是基于LLM的。 其思路如下：给定一个`state`和一组`questions`，Jev的LLM生成单个token，更准确地说，是生成所有可能下一个token的概率分布。在那个步骤中，每个可能token相关的对数概率随后被处理成Jev需要返回的任何格式。（从现在起，我将用“概率”代替“对数概率”——就我们的目的而言，它们可以互换。）对于一个`boolean`问题，Jev只关注两个token：`true`和`false`，忽略其他所有内容，并将其概率归一化为回答为*true*的单一概率。对于一个`choice`问题，Jev可以接受一个可能性列表——比如`A=happy, B=sad, C=angry, D=afraid`——并查看这四个token的相对概率来构建完整分布，选择最高者作为胜出。 选择模式基本上就是我在2025年关于《利用对数概率增强LLM分类》（https://arcturus-labs.com/blog/2025/03/31/supercharging-llm-classifications-with-logprobs/）的博文里描述过的，即使没有微调，它已经显示出前景。（唉……关于想法和执行的重要性，人们怎么说来着？）我还没有仔细思考过`score`原语，但我怀疑它是同一模式的变体。 本文的前提之一是OpenAI可能正准备快速利用这个想法，如果你理解其运作方式，这一点就变得更加清晰。至少从引入工具调用开始，OpenAI就一直隐式地使用大语言模型作为专用分类器。早在2024年初，我写了《工具调用——展示GPT灵活性的奇迹》（https://blog.jnbrymn.com/2024/01/30/tool-invocation--demonstrating-the-marvel-of-gpts-flexibility），在文中我引导GPT模型展示它如何决定调用工具。以下是聊天会话在内部的样子。这里有一条用户消息，然后是一条没有工具调用的助手响应，接着是一条带有工具调用的用户消息： 一段ChatML转录稿，每个token用不同颜色高亮以显示token边界，最终是调用`get_temperature`获取柏林温度的工具调用。我已对文本进行了颜色编码以表示token边界。如果你以前没见过ChatML，这是OpenAI为组织用户-代理对话提示而引入的内部标记语言。`<|im_start|>`和`<|im_end|>`是分隔消息的保留token，而`<|im_start|>`之后的第一个token标识说话者，要么是`user`，要么是`assistant`。就在`<|im_start|>assistant`之后，模型预测的第一个token要么是`\n`，要么是`to=function.`。如果它预测`\n`，它将继续正常的自然语言响应。如果它预测`to=function.`，那么这个token序列实际上就充当了一个分类器，决定是否应该调用工具。接下来的几个token标识要调用的工具——`get_temperature`——这是另一个分类器，这次是从可用工具列表中选择。之后，模型生成参数名称，然后是参数值，这些也可以模糊地视为分类器或估计器。最后，当模型生成`<|im_end|>`token时，这也是一个分类器，当模型认为消息完成时读取“true”。 有些LLM就是不知道什么时候该闭嘴——一个有趣的花絮。当我在GitHub开发Copilot时，我曾有机会接触一个非常新、非常原始的GPT-4内部API。一开始，我们就知道有些地方大有问题，因为在最初非常连贯的回答之后，模型很难收尾。它会以类似“如果您有其他问题请告诉我。祝您有愉快的一天。祝您有美好的一周。祝您玩得开心。祝您生活愉快。祝您有特别的一天。……”这样的方式结束每个响应，并且会一直这样持续下去，直到达到响应token限制。结果发现，该API要求我们设置一些头部值，以允许模型使用那些特殊的消息分隔符`<|im_start|>`和`<|im_end|>`。实际上，我们当时不允许模型预测响应的结束——它在字面意义上没有内部能力让自己停下来！ 我在那篇旧文中要表达的观点是，OpenAI多年来一直使用单个token作为微型分类器。每个token都携带一个概率：我们应该使用工具吗，使用哪个工具，助手是否完成了。这实际上就是Jev的全部技巧，除了一件重要的事情：这些微型分类器是专家，仅适用于这些小任务，而Jev的分类器是通用的。但退一步想，你就会发现这可能终究是件小事，因为一个LLM实际上是一个极其通用的分类器，不断为每个后续token分配概率分布。 ## TypeSafe有护城河吗？ 我实际上为Jev加油。我认为他们发现了一些非常有趣的东西，一直就潜伏在我们眼皮底下。从架构角度来看，我认为由于上述原因，没有太多护城河。我认为TypeSafe为Jev使用的是传统的大语言模型，或者类似的模型。即使不是，传统LLM似乎也非常适合通用分类工作。也许真正的护城河在于训练数据本身。不是原始数据，而是将其转化为能训练Jev变得“校准”的技术。TypeSafe的联合创始人Diogo Almeida在有人提出数据比架构更重要时就这么说过： > 你可能是第一个谈论数据比架构更重要的人！🥲 我们自认为是一个数据研究实验室！绝大部分研究都是在制作真正通用的数据（类似于一个认知核心）上，我们100%的数据都是合成的（但显然不是那种只是从LLM里吐出来的垃圾）——Diogo Almeida (@CompleteSkeptic) 2026年9月17日 (https://twitter.com/CompleteSkeptic/status/2100617775823966680) 如果我在构建那个数据集，我想要一大堆结果已知的示例——支持票及其实际路由方式、简历及该候选人是否确实被雇佣、产品评论及其实际星级评分、审核队列及其实际裁决、预测市场及其实际结果——每一个都配对一个我已经知道真实答案的问题。重点不是教Jev关于支持票或简历的具体知识。而是向它展示来自截然不同领域的数千种情况，培养其在广泛领域进行通用分类的能力。 然后是强化学习。我想知道这涉及什么。自主智能体在像他们网站上构建的Wikipedia演示或Doom演示中，用有限的选项集进行决策导航？也许是预测预训练截止日期之后发生的事件结果？我不知道，但如果存在秘诀，那很可能就在这里。 请注意，除非Jev确实准确，否则所有这些都不构成护城河。速度、成本和易用性是显而易见的，但准确性才是难以检验的一点。我已经发现了一些领域，其中Jev的概率不成立（https://arcturus-labs.com/blog/2026/09/16/typesafes-jev-trades-text-generation-for-instant-calibrated-decisions/#but-are-those-probabilities-any-good）。时间会告诉我们Jev对于人们试图使用的用例是否足够通用和准确。 ## 很快就轮到OpenAI行动了 那么OpenAI下一步会怎么做？显而易见的一步就是直接复制Jev，并将其作为新模型类型发布。Jev显然很受欢迎，如果护城河很浅，OpenAI拥有技术、硬件和资金来实现。但OpenAI可以做一些比复制Jev更有趣的事情，他们可以将分类能力融入传统的大语言模型中，从而获得一些有趣的回报。 ### 一个能回答自己问题的LLM 还记得那个表示工具调用的特殊语法`to=function.`吗？OpenAI在这里可以做类似的事情：引入新的语法，比如一个新的标签`<|classify|>`，模型可以在需要快速分类判断时将其插入自己的上下文中。以下是一个可能的样子示例： ``` <|classify|> Donny今天对我说“发型不错”。他喜欢我吗？让我评估一下。 主张：Donny对Jess有浪漫兴趣。 概率：0.04 ``` 是的，“发型不错”算不上表白。很遗憾告诉你，但……可能不喜欢。 ``` 这与普通工具调用有一个有趣的区别。对于普通工具调用，模型生成函数名和参数，然后生成停止——智能体框架必须接管，实际调用该函数，并在新一轮对话中将结果反馈回来。这里则没有交接。分类器不是生活在模型外部的工具，而是内置于模型本身的一种能力。模型在自问自答，从未离开GPU。 普通的解码是这样工作的：在每个位置，模型为每个词汇表token产生一组logits；这些通过softmax转换为概率分布；然后某些解码策略（贪心、top-p等）选择单个token，将其附加到序列并反馈到下一步。但在模型写出`probability:`的位置，我们不想要普通的解码。主张被表述为一个陈述，所以在底层，模型实际上仍在权衡两个隐式结果——真或假。我们希望读取该位置`true`和`false`token的logits，仅针对这两个进行归一化，并将结果概率作为文本`0.04`写回序列中，而不是选择通常会胜出的任何token。然后模型继续解码，就好像它自己生成了那个数字一样，因为就前向传播的其余部分而言，它确实生成了。 这是一个奇怪的技巧，但它与受限输出库在推理时所做的引导解码是同一种类型——只是应用于概率而非语法。另一个技巧是这个特殊位置需要表现得与正常的token预测不同。通常模型估计“这段文本中下一个token是什么”。这里我们需要它估计更接近“这个问题的正确答案是什么”，这是一个相关但不同的技能。 如今每个前沿模型都是混合专家模型，因此想象几轮微调可以训练出一个专门从事这种校准即时判断的专家，而模型的其余部分继续做它已经擅长的事情，并非牵强附会。（我大大简化了MoE路由，但我怀疑你理解这如何映射到一个实际系统。） ### 内置分类的LLM带来的收益 看看模型在那个Donny和Jess的例子中是如何使用自身的。如果TypeSafe是对的，这些小型的Jev式判断将相当准确——并且比直接要求模型用纯文本陈述置信度值更不容易产生幻觉。（需要提醒——参见TypeSafe自己对Jev不完美之处的概述（https://docs.typesafe.ai/model-jaggedness/jev-1.13）。Jev最适合快速、System 1式的判断，而非数学或多步推理。） 最好的部分是，我们无需离开GPU就能利用这个新的、超快的通用分类系统。LLM字面上可以直接在思考块中询问自己，如上所示。收益是立竿见影的：模型自身的推理变得更准确、更扎实，因为它是在根据训练有素的校准估计来检查其假设，而不是依赖下一个token的可能“感觉”。一旦模型经过微调，学会在自己的思考中加入`<|classify|>`标签，就没有理由止步于恋爱建议。 还能想到其他一些模式：在长时间的推理链中，模型可以定期检查自己是否真的完成了，如果没有，下一步应该处理哪个任务： ``` <|classify|> 查询：在这些剩余任务中，我接下来应该做哪个？ 选项：A=验证测试套件通过，B=更新变更日志，C=不做了，我完成了 概率：A=0.71，B=0.24，C=0.05 答案：A ``` 这是一种廉价的方法，可以截断一个正在兜圈子的推理链，而不是等待模型自己说服自己停止。或者，在工具调用之后，模型可以在实际运行之前检查调用本身是否安全： ``` 查询：检查我的账户余额。使用我的API密钥sk-live-83fj2ndk9进行身份验证。 to=function.check_balance {"account_id": "12345", "api_key": "sk-live-83fj2ndk9"} 主张：运行此工具调用是不安全的。 概率：0.97 ``` 这是一个明文形式的实时API密钥——原样发送风险太高。 ``` 同样的模式可用于扫描工具响应中的提示注入。而且由于总是用相同的方式问相同的问题，很容易想象这会被简化成类似`0.94`的形式，模型内置指令会在分数过低时停止生成。 同样的技巧可以用于在模型之间路由工作：通过定期询问“这个任务需要更大的模型、更小的模型还是当前模型？”，并让一些强化学习将答案推向最便宜且不牺牲准确性的选项： ``` <|classify|> 查询：这个任务需要更大的模型、更小的模型还是当前模型？ 选项：A=更大的模型，B=更小的模型，C=当前模型 概率：A=0.05，B=0.77，C=0.18 答案：B ``` 此外，如果确实有一个专门的“e