本文来自微信公众号：Z Finance，作者：ZF编辑部，题图来自：视觉中国
在 OpenAI 工作时，Diogo Almeida 经常感到困惑：为什么大家都在讨论如何让 ChatGPT 对开发者更有用，却很少追问，聊天模型本身是否适合成为软件的底层组件？开发者想控制一次工具调用，往往只能把要求写进提示词，再等待模型配合。在他看来，这套接口距离软件工程所要求的可控、可测与可组合，还有很远。
如今，作为 Typesafe 的 CEO，Almeida 正在用新模型 Jev 回答这个问题。他希望让软件直接调用智能，获得可以参与程序运行的决策、概率和评分。这场访谈围绕一个核心问题展开：当智能足够便宜、足够快，也足够可靠，软件会发生怎样的变化？从训练数据到 Agent 架构，他的判断都指向同一个方向——AI 的巨大增量，可能藏在那些用户看不见、却每天运行无数次的软件流程里。
以下是他的主要观点：
AI 的下一种重要形态，是供程序调用的智能。 聊天模型主要围绕文本交互优化，而软件需要语义明确、行为可测的接口。Jev 尝试直接提供选择、概率与评分，让智能进入程序的条件判断、排序和执行流程。
模型是否可靠，不能只看回答是否正确，还要看它能否准确表达不确定性。 在 Almeida 看来，一个看似自信的答案不足以支撑生产系统；开发者需要能够据此设置阈值，决定何时自动执行、调用更强模型，或交给人工处理。他也承认，Jev 的校准与可靠性仍有明显改进空间。
更好的 AI 软件，需要把复杂任务拆成可以逐项验证的小决策。 与其让一个模型阅读庞大的系统提示词、一次性决定所有事情，不如将任务拆解，由代码组织流程、约束权限，并为每个判断建立测试。这样，修复一个问题才能成为可以持续验证的工程改进。
真正稀缺的能力，是为模型找到正确的训练目标。 他认为，行业过度关注算力与架构，却低估了任务定义和数据的作用。Typesafe 提出的 RLCD，即“校准决策强化学习”，就是尝试围绕模型参与程序运行这一目标，重新组织训练。
直接使用用户数据训练，可能让模型过拟合今天。 用户请求集中于少数高频场景，而他希望模型能支撑未来尚未出现的软件。因此，数据工作的重点是系统性寻找能力缺陷、补齐边缘情况，而非单纯积累更多真实请求。
智能变便宜之后，软件的设计方式也会改变。 当一次判断的成本与延迟足够低，开发者才可能在一次复杂推理周围安排数十次细小判断，用于验证、路由和检查。过去因成本过高而无人处理的企业数据，以及需要实时响应的应用，也可能因此获得新的使用空间。
今天的 Coding Agent 架构，受到 KV Cache 的深刻影响。 为了复用缓存，系统倾向于不断追加上下文，这又限制了任务分解、状态管理与多 Agent 协作。他期待开发者重新思考上下文如何检索、状态如何共享，让 Agent 更充分地采用成熟的软件工程方法。
AI 的发展路线仍然开放，前沿实验室当前的选择并不代表全部可能。 他质疑把持续加码推理强化学习视为唯一方向，也主张区分面向用户的产品约束与底层模型能力。这些判断背后的共同立场是：行业仍有大量尚未被充分探索的智能形态，值得围绕实际用途重新设计。
Jev发布周与AI经济革命
主持人：这周是个特别的日子，我的好友Diogo发布了Jev，相关内容已经刷屏各大平台的信息流时间线。你现在感受如何？此刻是怎样的状态？
Diogo Almeida：情绪层面？糟得不能再糟。我现在整个人心力交瘁，事情铺天盖地涌过来。我是一名技术出身的首席执行官，有一大堆紧急问题要处理。但从理性层面来讲——我在自己的线下沙龙活动里已经讲了很多年这个观点：整个AI行业就如同嘉年华里的镜子迷宫，所有人都有些狂热，说着各种匪夷所思、逻辑不通的言论。但就在这周，我感觉自己更加贴合现实了。大家终于意识到，AI的潜力远比过去人们设想的要大得多。没错，一场以AI为基础的经济革命重新具备实现的可能性。这实在太振奋人心了，开发者们看懂了，我非常激动。没错。我发自内心地感谢开发者群体，对整个社区满怀热忱。
主持人：太棒了。你昨天提到，你决定优先举办线上公开交流会，而不是接待一众VIP投资人，希望把最多的注意力留给工程师、开发者，是这样对吧？
Diogo Almeida：没错。有时候我会想，我正在和一众大人物对话，具体是谁我不便透露。我这个人或许太过直率坦诚，如果满满当当的日程表里排满各路要人，却没有留给社区的位置，我心里会很别扭。理想状态下，我希望把绝大多数时间留给社区。我甚至突发奇想过，要不要一边走到你的演播室，一边开线上交流会，但想想还是算了，实在太过疯狂。
主持人：确实。你们一直在Discord（海外社群平台）举办线上交流会，社群现在已经有十万成员。你的Twitter也彻底爆火。说个趣事，在AIE活动现场，你嘴上说着“大家可以关注我”，结果连自己的账号ID都没报出来。但这反而形成一种很有意思的个人特质：你不太懂得自我营销。
Diogo Almeida：我发推文感慨“好家伙，我们三条话题全都冲上热搜了”，结果有人当场点破我：那只是你的个人信息流而已。
主持人：也难怪你会这么感慨，毕竟这就是你亲手做出来的成果。恭喜你们取得的一切。后续有更多细节我们可以再聊。给那些不了解情况的听众做一个权威科普：Jev到底是什么？
Diogo Almeida：让我想想，这个问题并不好回答。
主持人：没关系，如果你需要思考，我可以稍后再问一遍。
Diogo Almeida：不用，我很乐意聊聊。说到这个问题，让我松一口气的一件事是：现在我不用再跟我父母解释它是什么了，ChatGPT可以替我解释。在我看来，我们需要一类全新的模型。我们并没有执着于给这一类模型起名字，我们想到最贴切的叫法是系统一号模型。之所以不叫决策模型，是因为系统一号模型的能力范畴不止于此，这点我只能说到这里。我们原本没料到这次会是一场大规模正式发布，我们手里还储备着不少技术成果。
主持人：你们本可以对外说这只是低调的研究预览版。
Diogo Almeida：某种程度上它确实算是。我们定义这类模型为：机器原生、系统一号、大型可编程模型。这类模型的目标是让代码成为模型的消费方。这和预训练大语言模型不一样，预训练大语言模型目标是做互联网文本自动补全；也和RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）对话指令跟随模型不同，后者目标是输出文本回复。还有RLVR（Reinforcement Learning with Verifiable Rewards，基于可验证奖励的强化学习），它和RLHF处于一个比较模糊的交界地带。而我们的模型输出会直接被代码调用，这也是Type‑Safe这个名字的由来。我们真正追求的是把AI的能力拉到尽可能强，实现这一点的方式就是把AI和软件深度结合。从对外接口到模型深层内部，我们所有设计都面向软件场景做优化。
第一点，Jev是我们第一款大型可编程模型，也可以叫系统一号模型，看你习惯怎么称呼。Jev的设计目标是intelligence per dollar（每美元成本对应的智能能力），命名灵感来自Jevons paradox（杰文斯悖论）。我经常和别人争论，可靠性、成本、校准能力、速度，到底哪一项最重要。Jev作为系列模型，定位就是在每美元智能能力这条赛道上站在技术前沿。机器学习本身充满取舍权衡，如果你懂机器学习就会明白这一点，而我们正在全力朝着这个方向推进。
主持人：对我来说，校准是一个过去大家讨论度并不高的概念。我们之前做过一期节目，嘉宾是Hugging Face的Clementine Fourier。当时聊到一个观点：经过RLHF处理后的模型，会发生mode collapsing（模式坍缩），倾向于输出人类最想听到、概率最高的回答，而不是输出模型自身真实的确信判断。
RLHF、模式坍缩、校准与杨立昆
Diogo Almeida：我能不能就此展开说一说？我听说咱们听众技术水平普遍很高，我想深入聊这个话题。我们制作发布视频的时候，花了极大精力保证所有内容准确真实，而这在行业里其实并不常见。有一点几乎没人关注，就是RLHF带来的弊端，尤其是mode dropping（等同于mode collapsing）。我之后打算写一篇博客详细阐述，但我希望尽可能多的人了解这件事，这是一个很值得探讨的现象。
说一个比较尖锐的观点：我十分认同杨立昆（AI科学家）的很多观点，他的不少判断是准确度很高的。但他有一张非常出名、也饱受争议的幻灯片，标题大意是“大语言模型注定存在局限”。那张幻灯片有一个饼图，有一小块内容表达：随着sequence length（序列长度）增加，模型出错的概率会趋向升高。这个观点从数学推导上看似成立，但现实实验并不支持这个结论。这就是我很喜欢拿来科普的一类现象：理论推导看似没问题，但现实实证结果并不相符。
主持人：那造成这种矛盾的根源是什么？
Diogo Almeida：模式坍缩和这个问题是相关的。矛盾的根源在于：如果模型处于模式覆盖、分布校准的状态，它不会对异常输出施加过重惩罚。会有一部分输出属于分布外，一部分属于分布内，这就是完整覆盖数据分布的模型的表现。就像GAN（Generative Adversarial Network，生成对抗网络）诞生之前，生成模型输出的图像都是模糊的。而GAN会发生模式丢弃，直接抛弃少数类别，只生成高频常见样本，这就是上面那个理论预测没有成真的原因。
模型想要生成长文本还不出错，就要变得极度保守。错误发生的时候很容易被察觉到，但一些看似正确的细微偏差很难被发现。而校准问题会严重破坏字符串输出的概率分布。这是一个比较微妙的观点。这也是为什么字符串类模型并不擅长做决策，强行把字符串模型用于决策任务，效果会很糟糕。
主持人：说到GAN，那你是否认同杨立昆提出的解决方案，也就是世界模型，类似JEPA（Joint Embedding Predictive Architecture，联合嵌入预测架构）这类嵌入架构？问题根源在于模型基于token输出做推理，反复迭代拼接直到句子结束。JEPA 就是他给出的解法，也就是联合嵌入预测架构。你怎么看待这套方案？
Diogo Almeida：说实话我不太适合深入聊机器学习内部细节，但我的立场偏向实用主义。我怎么看待scaling laws（缩放定律）？要分情况看待。缩放定律告诉你投入多少资源性能会提升多少，但它往往意味着投入指数级资源，换来次线性的性能增益。除非增益本身价值极高，否则这笔投资并不划算。对我来说核心是：立足现有的条件，做出尽可能巨大的实际改变。
主持人：没问题，本期面向成年听众，不限制这类表达。我们后面也可以专门聊缩放定律。
Diogo Almeida：我们可以聊，但如果现在相关性不强，我想聊聊我踩过最惨痛的教训，这个话题会更切题。我对JEPA这套研究很欣赏，是很棒的早期研究。但它现阶段能不能落地实用？我不便过多评价。
可编程AI、拒绝输出与安全对齐
Diogo Almeida：现在AI研究领域有大量尚未打磨成型的宝藏思路，只是人们还没有找到合适的任务范式把它们发挥出来。我们这次发布，不光会推动公司自身发展，更会带动可编程AI这个方向整体向前。会有一波围绕我们的创业热潮，软件领域本身就具备巨大潜力。同时也会出现一批平行方向，探索各种可以增强软件能力的技术路径，开发者可以借此打造更厉害的作品。仿佛回到早期互联网那种充满活力的时代。也正是这个原因，Twitter上到处都在讨论Jev。
主持人：这和我们过去的固有认知截然不同，过去大家总觉得：缩放定律才是王道，只有大型实验室才有资格做这件事。
Diogo Almeida：允许我稍微跑个题，你或许会感兴趣，我们已经扯了好几个话题了。
主持人：我自己经常聊着聊着就跑题，听众需要自己梳理逻辑，但他们可以理解。
Diogo Almeida：Discord社群上很多人一直在问我一个问题，我还没有腾出时间详细解释：为什么我反对当下流行的安全对齐，为什么我们的模型不会输出拒绝回复。我并不反对安全这个理念本身，但当下的安全对齐机制很多时候和用户真实需求相背离。模型拒绝输出本质上属于一种类型错误。想象你在写代码调试，模型突然回复“抱歉，我无法读取DNA.py文件”，这会非常恼人。但大家已经被迫习惯这件事，近乎一种斯德哥尔摩综合征。
这里我又要引申一层思考：如果后台运行的一个依赖组件突然拒绝执行怎么办？别的开发者调用这个依赖，根本不知道内部发生了什么。你总不希望软件仅仅因为用户传入一段特殊输入就随机崩溃。这完全是不可理喻。会出现这种问题，根源在于制定这套机制的人并不懂软件、不懂编程，执着于把AI做成AI协作者，而不去释放AI全部的原生能力。
主持人：说得有道理。你想要的是一个可以在各类场景通用的核心底层内核。
Diogo Almeida：完全正确，也就是认知内核。它要足够通用，适配各类使用场景，能够应对未来千奇百怪的业务需求。我们训练数据并没有覆盖所有这些稀奇场景，但模型依然可以正常工作，这不奇怪，我们训练素材本身就包含大量更奇特的案例。
回到安全对齐这个话题。在我看来，安全对齐对于ChatGPT、Claude这类面向聊天的产品是合理的。要区分能力对齐和安全对齐：能力对齐的目标是完成用户想要实现的事，这对于软件工程师至关重要。工程师希望工具按预期工作，可预测性越强，测试调试的工作量就越小。Jev距离这个目标还有很大差距。未来我们希望它的可靠性提升到数据库查询那样，几乎不用额外思考，需要intelligence的时候直接调用。
而安全对齐和指令跟随恰恰相反：它要求模型遵循第三方的约束，就像OpenAI做的那样。作为面向终端用户的聊天产品，这么做无可厚非。比如产品方不希望模型生成不适合公开场景的角色扮演内容，照顾到家庭用户，这完全可以理解。但放在API（Application‑Programming‑Interface，应用程序编程接口）接口层面就不合理。开发者需要围绕接口行为编写代码，安全对齐会严重损害开发者的使用体验。我尽量让自己保持冷静。
主持人：我理解你的观点，但我要提出一点反驳：如果有人拿它来造成人员伤亡该怎么办？色情、隐私问题尚且另说，但用于战争伤害人类，企业完全有理由限制API被用于这类场景。
Diogo Almeida：我理解这种现实层面的考量。但通用基础技术本身，不该承担这类价值判断。我个人当然不希望我们的技术被用来伤害人，希望它被用于造福世界。我会在产品业务层面施加引导，但绝不会在技术底层做这件事。在技术层做约束会破坏模型的通用智能。每一次为了适配特殊约束，都会让模型的智能能力进一步受损。现在很多大模型已经被破坏得相当严重。
在我看来，智能更应该像数据库。数据库不会去校验调用它的人拿它做善事还是恶事。还有一件很奇怪的事：有人在Slack上联系我们，问“我们能不能部署你们的服务”。我的想法是：我们对外提供的是API，你是开发者，这件事不该由我来评判。你甚至不需要完整知晓上层业务，任务会被拆解成细碎单元。我们不该获知下游使用者的全部意图，这才是给软件工程师最大自由度的合理边界。我们当然希望大家用它做有益的事，未来也会考虑开源、公益相关工作。但只要由我主导，就不会在技术底层植入这类价值偏向。
主持人：说得很好。顺着这个话题，简单澄清下你们之前引发一些误解的隐私、服务条款。请你用两句话说明，你们的API并没有设置严苛限制，你们很认真看待平台责任。
Diogo Almeida：我不清楚你具体指哪件事，但我看到不少关于基准测试的讨论。我们当然不会阻止别人做基准测试，说话我需要谨慎一点。
主持人：这件事你是公开发过声的。那是预览阶段的说法，正式发布已经取消该限制。不过团队有些动作我本人也不完全知情。
Diogo Almeida：很高兴知道团队对外传递了这个信息。我们咨询过法务。我们绝对不会阻止外界做基准测试。我非常反感公开基准测试，但适度使用私有代理基准测试我可以接受。公开基准最大的问题就是极易被刷分、被针对优化。不只是我们，假设两年之后行业涌现一大批同类竞品。我们售卖的核心是单位成本下的智能能力。大家总在讨论成本、速度，这些固然重要，但最核心的是智能本身。成本和速度是你为之付出的代价，智能才是价值本源。
智能能力本身有其生成演化的过程。我们发布视频之后两小时，网上反馈就已经远超视频本身的热度：大家发现这套东西是真的可以落地使用。发布的反响非常热烈，大家能感受到我们对这件事的投入。而公开基准测试与这种真实价值是相悖的。人们希望依靠基准分数建立信任，但基准可以被轻易钻空子。以前各个实验室都会专门构造类似 MMLU（Massive Multitask Language Understanding，大规模多任务语言理解基准测试）的数据集刷高分数，本质就是换种方式刷榜。
长期来看，更靠谱的方式是：把模型放到自己真实业务流程中，在实际工作流中评估表现，建立自己的判断。我们公司持续要做的一件事，就是不断提升可靠性的nines（9的个数，代表可靠性位数，99.9%就是三个9）。只要我们愿意牺牲模型的智能能力，Jev本可以早在一年半之前就对外发布。这就是我所说最惨痛的教训，也就是架构选择的问题。
主持人：正好你提到了，我们来聊聊这个。
最惨痛的教训：数据、算力与正确的任务目标
Diogo Almeida：Sutton有一个大致观点：算法胜过算力。但现实是，数据的重要性远超算力。找准正确的任务目标，确立北极星方向，才是最难、最重要的事。大语言模型领域已经发生过两次，或者说2.2次范式转变。第一次是RLHF，把任务转向指令跟随，当时没有人预料到这条路可行；RLVR做了小幅方向调整；现在轮到我们的RLCD（Reinforcement Learning for Calibrated Decisions，校准决策强化学习），一套全新任务范式，目标是模型参与程序循环运行。数据的重要性怎么强调都不为过。
主持人：你们是否把自身定位成数据实验室，而不是单纯模型实验室？这是你们内部的说法吗？
Diogo Almeida：我们极度看重数据。在我看来，模型能力本质上来源于数据。数据的复杂度极高，正是数据带来可靠性位数的提升。数据可以颠覆一切，它的重要性超乎想象。我们现在在大量招聘数据方向人才。
主持人：优秀的数据方向人才需要具备哪些特质？外界说你们的数据很多是合成生成的，但这只是表象。合成数据不等于万事大吉。那一名优秀的数据从业者现在要做什么？反复阅读样本转录文本，甄别问题，重新生成样本吗？
Diogo Almeida：这件事复杂度很高。我们给数据团队做的入职分享，时长甚至超过本次播客。我讲下核心要点。
第零点：数据与合成数据完全取决于你的任务。任务形态决定需要什么样的数据。RLVR的数据偏向环境样本；RLHF的数据是人类反馈。每一类任务对应独有的数据形态，我们也有属于自己的独特数据。
第一点：哪怕条件允许，我们也坚决不用用户数据训练模型。现实世界的数据自带大量偏见。用户查询服从幂律分布，模型训练之后容易过拟合高频问题，破坏通用能力。
第二点：我们目标瞄准数年之后的科幻级未来：模型会成为堆栈深处的通用基础设施，支撑很多现在人们想象不到的应用。
我喜欢做一个类比：传统大语言模型如同UDP（User Datagram Protocol 用户数据报协议），而我们的模型更像TCP（Transmission Control Protocol 传输控制协议），上层可以搭建五花八门的应用。我们要适配未来的使用场景，一旦我们全部使用当下现实世界的数据，模型就会过拟合现在，无法应对未来。做数据的人更像是研究者，钻研这套认知内核，找出内核存在的缺陷，再针对性修复。不可能做到完美，但要在尽可能多维度解决问题。
主持人：追求通用情况，而不是针对个别特例。
Diogo Almeida：完全正确，这需要大量思考投入。
主持人：我们刚才简单聊到，你评价我的思路受RLVR影响很深。现在说说RLCD。据我所知这是你们的独家技术，没有公开论文。那怎么让听众相信，这不是为了听起来高大上而编造的术语？其中一点是校准，播客里面我们已经聊过。大家熟悉RLHF，RLCD和它到底区别在哪里？
Diogo Almeida：这个问题问得很好。先思考RLHF本身：RLHF这个缩写本身指代过好几套不同东西。最早版本，Paul Christiano团队用它训练机器人做后空翻，完成很难精确描述的输出目标。
主持人：对，PPO论文我读过，但不太确定原始出处。
Diogo Almeida：PPO未必来自人类反馈。早期对齐工作，目标是实现很难书面定义的输出，比如机器人后空翻。之后OpenAI做的“学习文本摘要”工作，把PPO用在语言模型上，这是RLHF的第二个版本。我口中的RLHF，核心是把指令跟随设为北极星目标，重点不在于PPO算法本身。而RLCD是我们的新任务范式。这不是故弄玄虚，我们追求表述精准。就像DPO以及后续衍生算法，它们也属于RLHF谱系，但不再使用原始论文的PPO算法。
主持人：所以可编程AI就是你们的北极星核心目标，把人类从循环中剥离出来，依靠自动化完成一切。除了这点之外，这套范式的核心要义还有别的吗？
强大AI为何依旧无法实现经济自动化
Diogo Almeida：没错，但要注意现实可行性。我们要认清大语言模型真正擅长的边界。可编程AI构想固然美好，但如果技术条件不达标，没有落地也不算悲剧。但在我们这套技术诞生之前的现状，在我看来才是真正的遗憾。
主持人：我非常认同你的观点。
Diogo Almeida：我持有这套看法远早于创办公司。我原本以为这件事实现起来会很简单，结果我大错特错。我想向OpenAI的同仁致歉，我曾经以为很快就能把问题解决。AI行业普遍存在过度承诺、落地不及预期的问题。RLVR和RLHF都属于这个问题的重灾区。AI明明智力表现非常亮眼，我经常在演讲抛出这个问题：AI可以解千禧年数学难题，却连极其简单、机械、不需要高智商的重复性劳动都无法自动化。这些工作枯燥乏味，本可以交给机器，但自动化引擎缺少接口，对接不了这些具备经济价值的业务。如果Type‑Safe消失，外界或许要一两年才能追平。倘若模型质量是核心，我们会长期占据有利位置。但历史的轨迹已经被改变，整个行业都会去探索这片全新领域。
主持人：你们开辟出了全新可能性。我帮大家转述：不要把Type‑Safe和Jev简单理解成又一类新模型，事情到此就结束。未来还会涌现很多不同类型的模型，应当百花齐放。
Diogo Almeida：完全同意。
主持人：仿佛回到早期互联网那种理想主义氛围。不再是“我的代码智能体偶尔能跑，最好的实现全部锁在大厂内部”。创造的大门重新向所有人打开，未来会充满变数，做好准备迎接变化。我对此非常兴奋。现在你们手握资金与发展势能，可以去实现心中构想，坚持这么久的想法终于落地，一定很有成就感。
Diogo Almeida：没错。过去很长一段时间，我都像一个不断抛出预告的人。我的演讲稿总留有悬念，不说明自动化究竟如何实现。Sean读过我们的宣言，评价很多地方写得比较模糊，没有写清楚第一步是什么，智能到底是什么。
主持人：我之前找你要模型细节，你只说模型会到来。我对你“可组合”这个说法有不同意见，但“构建生产级产品，而不是空谈空想”这个理念非常棒。
Diogo Almeida：谢谢。团队高度认同这句话。我希望我们不要像有些公司那样搞个人崇拜，但我们所有人都对正在做的事充满热情。我们整体的底色就是实用主义。
主持人：说到这里，聊聊所谓秘密总体规划，也就是机器原生、可组合这套构想。
Diogo Almeida：是你提出来要讲秘密总体规划这个说法。功劳算你的。
主持人：谢谢。之前你跟我讲过一半的故事，当时还没有震撼的演示，也拿不出量化指标。我本身不认可刷基准。信任需要实际使用体验来建立。去年融资的时候就遇到过这件事，投资人全都想要基准测试分数。但我们坚持原则，刷基准会助长投机取巧的行为。无论外界如何期待，我们坚守立场。
Diogo Almeida：某种意义上，选择最难走的路，最终你会打造出自己愿意为之工作的公司。如果一味妥协，最后只是换个地方复刻OpenAI式的环境。
主持人：说得没错。
Diogo Almeida：回想离开OpenAI的原因，我感慨万千。发布之后我修改过措辞：如果AI寒冬来临，而我没有竭尽所能去阻止它，我会认为自己负有个人责任。一方面RLHF的路线放大了过度承诺、兑现不足的行业问题；另一方面，当时行业没有全力奔赴我们认定价值所在的方向。现在，我所担忧的AI寒冬已经得以规避。AI真正可以用于自动化。发布还不到一周，数据已经实实在在证明它被投入真实业务使用，行业进入狂野开拓的时代。
主持人：如果脑海里有印象，能不能分享一些可以对外披露的数据？比如注册量之类。
Diogo Almeida：我没有紧盯各项数字，团队在同步跟进，数字每天都在剧烈变动。有一个里程碑我们已经达成：每日token处理量级已经突破万亿。而且不是短期脉冲流量，就算夜间负载也持续运行，是机器服务调用，不只是用户随手测试。这非常了不起。注册用户数量对开发者平台参考意义有限。网上有人调侃我们营销手段高明，但我们没有专职营销人员，还在招聘。我们只是保持真实、直白的风格，批量解除候补名单的访问权限。我们平台团队实力极强，这次发布声势空前，但平台可用性、运行可靠性甚至优于Anthropic。向平台团队致敬。
有一点我们事前没有充分预估：候补名单注册数本身没有太大意义，很多注册者并不是开发者。他们进来随便跑几条查询，发现这不是聊天机器人，找不到类似ChatGPT的交互方式就离开了。在我看来，全世界普通用户随便跑几条查询产生的token总量，，还比不上一个高级用户写的一段for循环产生的业务价值。候补名单批量放行之后，真正的问题变成调用速率限制。当开发者真正看到业务价值，就会需要极大的调用配额。软件的逻辑就是前期投入定义任务，之后持续运行产生远超投入的价值。你把它作为依赖组件嵌入别的系统，就可以在后台持续运行，源源不断产出价值。
早期互联网的人或许也无法想象2000年代互联网的面貌，这一切都建立在可组合性之上。这也是我们宣言着重强调的：我们追求涌现能力，赋能开发者，我们会竭尽所能实现这个目标。哪怕是我套着垃圾袋在Discord线上交流会出场这种事情，我们也愿意做。
主持人：也包括播客长访谈。长访谈可以抛开表层宣传，深度沟通，帮助大家真正理解你们的使命。认同理念的人，会选择成为你们的使用者，甚至加入团队。你的发布视频播放量达到3600万。Navier‑Stokes相关内容740万，2月5号那期570万。初代ChatGPT没有发布宣传视频。放在2026的新实验室当中，你们的数据表现可以说是数一数二。不过我对“明星AI实验室”这个标签没有执念。我更看重打造可靠的开发者平台。希望未来我们可以超越这个标签，迎来属于开发者的革命时代，做出稳定可信的工具。
Diogo Almeida：没错。
主持人：说到这里，你们不只关注校准，也非常看重uptime（运行时间/服务可用性）、可扩展性，还有可靠性位数。这些都属于同一个大的范畴。
可靠性、鲁棒性与确定性输出
Diogo Almeida：这只是一部分。可靠性也体现在模型智能层面，也就是模型能不能稳定完成预期任务。现在很多强推理模型智力表现不错，但可靠性依然不足。大量业务明明有自动化的经济动机，但模型可靠性还比不上一个实习人员，因为模型的优化目标并不匹配业务需求。
可靠性一方面代表输出值得信赖，还有很多维度的可靠性我们还没有达成，这也是我很期待的方向。我的想法是优先自动化简单任务，再攻克复杂任务，这是符合常识的思路。我不知道有没有绝对意义上足够可靠的状态，但我希望做到：开发者不用提前试跑，就可以确信模型能够正常工作。就像编程进入心流状态，直接写入需要智能能力的查询。遇到非平凡分支逻辑，向Type‑Safe系统一号模型发起一次查询，就能得到准确分支处理结果。这就是理想目标，但这条路会十分漫长。
主持人：稍后我们聊聊API设计，举一些例子，聊聊那些被放弃的设计方案。关于可靠性，我注意到API没有seed（随机种子）。那相同输入是否总能拿到相同输出？如果不能，原因是什么？
Diogo Almeida：这是个很常见的问题。可靠性是一个统称。凡是AI无法自动化任务，都可以归为某一类可靠性缺陷，可以是类型安全问题、确定性问题，也可以是模型输出结果存在缺陷。
确定性输出指相同输入得到完全一致输出。它对于单元测试有一点价值，但不该作为我们追求的北极星目标。我不想替用户定义他们想要什么。鲁棒性才是更加重要的特质：输入相近，输出就相近。大语言模型的鲁棒性表现普遍很差。我们有一个测试方式：在指令中插入UUID（通用唯一识别码，测试用随机字符串）。语义完全等价的提问，只是加入不同随机串，希望得到近似输出。做决策类任务，鲁棒性不足会给使用者带来巨大麻烦。确定性输出我们未来也可以做。如果开发者拿出充分的理由，同时GPU资源不极度紧缺，我们可以提供。但确定性往往会牺牲单位成本下的智能表现。我们始终要站在每美元智能能力的最优帕累托前沿，为此我们会做一些不那么常规的工程取舍。有些细节我不方便细说。
主持人：相当于你给自己审批合并PR代码。
Diogo Almeida：并不是这么运作。这周我的幕僚长K才是公司手握最大权力的人。
主持人：向K致敬，本次访谈也是她协调的。
Diogo Almeida：她能力极强，做事干脆利落。（玩笑）不许挖走她。有人劝我不要把模型叫做“弗兰肯斯坦的怪物”，这个说法带有负面含义，但我印象里原著中怪物本身是无辜的。好吧，我坦白，我并没有读过原著。说实话我现在时间极度紧张。优先级排序：睡觉，然后是开发者，开发者，开发者。为了站在每美元智能能力的帕累托最优曲线上，我们会做很多大胆的工程实现，未来还会继续。现在我们在这条赛道处于领先，并且希望持续保持。
主持人：回到刚才的话题，我问种子与确定性输出，你区分了可靠性与鲁棒性。
Diogo Almeida：简单总结：我们可以实现确定性模型。只要需求理由充分，GPU资源允许，我们可以实现。但确定性会降低单位成本下获得的智能。外界会给我们施加压力，要求我们实现这个特性，就算我们论证用户不一定真的需要，大家依旧会想要。这就是整件事的核心。
主持人：我预见到会出现这种情况。
Diogo Almeida：好吧，或许未来我们会看到这件事如何发展。团队评价我们的品牌特质是立场坚定，换个说法就是固执。我确实很固执。
主持人：但你也可以被证据说服，放下固有预设，接纳新观点。相信你自己的判断就好。
Diogo Almeida：但可以预见，GPU资源会长期处于紧缺。任何降低单位成本智能能力的改动，都会消耗更多GPU资源才能维持同等智能水平。我们的目标不是单纯接入大量企业，而是希望更多人可以上手做各种新奇的探索，掀起一场加州淘金式的创新浪潮。
主持人：这点要给听众一个提醒。你们表态不会承诺确定性，优先保证每美元智能能力，同时GPU资源紧张。大家会担心你们会做量化，把已经发布的模型降精度，释放显存带宽，牺牲质量。你们需要对外做出承诺：已经对外发布的模型版本，会维持原有质量。就像OpenAI、Claude都出现过API背后的模型偷偷改动的情况。模型版本化是很好的做法，但要公开承诺，一旦某个版本发布，就不会在后台偷偷改动。
模型版本、长期支持、速度与单位成本智能
Diogo Almeida：一旦模型部署上线，我们就不会偷偷改动模型。这对于面向开发者的API来说是基本常识。消费端产品可以迭代改动体验，但API不能这么做。但我们新版本模型发布节奏会比大家习惯的厂商快很多。我们不会承诺对所有版本做长期维护，因为还有大量能力提升可以做。当下的Jev1.13.0版本，因为大量用户正在使用，我们或许会临时开启LTS（Long‑Term Support，长期版本支持）。但全量长期维护会把集群拆分成大量版本，这会给所有人带来糟糕的体验。
主持人：不可能维护上百个不同模型版本。
Diogo Almeida：没错。迭代速度快就会产生大量版本。我们希望未来有一套非常优秀的方案来做长期支持，但它还不是我们现在的模型。我不会承诺永久固定现存模型。新版本模型智能能力一定会变得更强。不同版本之间，很多时候差异很小；但从缺陷较多迭代到高质量版本的时候，会出现巨大的性能跃迁。
主持人：LTS版本模型还有一个好处：可以移植到不同芯片硬件平台。不知道你们有没有考虑？
Diogo Almeida：对此不予置评。我们的核心指标还是每美元对应的智能能力。
主持人：那速度呢？
Diogo Almeida：速度我们后续再看。
主持人：过去一年推理技术领域发展爆发，可以迁移到Cerebras等专用芯片，实现数十万倍的速度提升。
Diogo Almeida：intelligence per second（每秒对应的智能能力）是另一个指标。我们内部也讨论过，把每秒、每美元结合做复合指标。Jev系列模型的核心品牌定位，是优先保证每美元智能能力。每秒智能能力是个有意思的方向。很多行业强依赖实时响应，每秒智能能力可以带来巨大商业收益。我们会持续观察，让市场给我们反馈。两种方向我们都愿意尝试。
主持人：不只是实时场景。大规模场景下，微秒级的延迟会被亿万次调用无限放大。
Diogo Almeida：要看业务形态。后台数据库类MapReduce任务，延迟不重要，成本才重要。面向终端用户的实时业务，100毫秒、1毫秒是很关键的门槛。哪怕从100毫秒压缩一半，就可以实现双倍的智能调用能力，体验提升巨大。这类每秒智能的场景非常酷，但它不会是Jev的主打赛道。
主持人：有意思。市面上其他模型的取舍往往是速度变快，但成本更高。而Jev做到了速度提升，同时成本下降，还尽量守住智能水平，这个象限几乎没有竞品。
Diogo Almeida：守住智能水平是最难的部分。我们反感公开刷分，但内部必须要有评估手段。
主持人：你们内部如何评估？
Diogo Almeida：当然有内部评估体系。但必须有极强的纪律，避免针对内部评估集做过拟合刷分。这件事要放在最高优先级。不然我们凭什么保证模型处在每美元智能能力的第一梯队？我们不是在盲目摸索。我们做对比绘图，权衡各个方案，选择对用户最优的方向。我们并不反对测量评估，但一旦掺杂其他利益，评估就会极度危险。对我们来说，最重要的原则就是忠于事实，不能自欺欺人，夸大模型的能力。
Jev的API与编程原语
主持人：同意。接下来聊聊API设计细节，这期播客应该是少数会深究这些问题的访谈。API提供三类原语：choice（选择）、score（打分）、newel（伯努利概率原语，自定义命名）。先说newel，这个名字来自文献吗？
Diogo Almeida：算是现在因为我们而广为人知。我们内部反复讨论过命名。它类似布尔值，但输出是连续概率。名字来源于Bernoulli（伯努利），伯努利概率分布，这就是newel名字的由来。我们还考虑过pbool、pool，我甚至开玩笑想叫pool party，但被否决。Jev这个名字内部也遭到大量批评，现在只剩一个人依旧不喜欢这个名字。
主持人：还在坚持反对意见。
Diogo Almeida：是我们共同认识的一位朋友。她当初想把模型命名为meow。我们必须创造这套新概念，因为它们并不属于传统编程语言的原生类型。虽然和传统类型很接近，但并不等价。score不等于int整型。强行把整型、浮点映射到score，逻辑会出问题。我们优先保证概念清晰，而不是一味追求和现有工具无缝兼容。
主持人：难道你们不希望直接和现有生态打通吗？比如写教程说明如何搭配instructor这类第三方库使用。
Diogo Almeida：社区或许会有人做这件事。我手头大量工作积压。
主持人：也就是说，成功也不是非黑即白，是score打分式的，社区生态可以继续完善。score和大模型打分评判机制有相似之处。newel近似概率；choice最接近函数调用，本质是暴露switch‑match分支匹配语句。
Diogo Almeida：没错。choice对应枚举类型；newel对应if条件判断；score用于排序、阈值比较。这一直是整套API的设计愿景，未来还会新增更多类型，一一对应编程原语。
主持人：我想把接下来的内容献给那些真正决定要深入投入Jev的人。你是这方面的专家。我只是想请你给他们更多关于API选择的背景信息，比如应该如何使用其中的一些功能、置信度（confidence）有多重要、测试有多关键，以及当你真正深入到这个层面时，有没有什么专业建议可以分享给大家。
Diogo Almeida：谢谢。我非常喜欢这个问题。这正是我们今天来到这里的原因。我其实没想到会有人问我这个问题。上一次有人这样问我，可能已经是几个月前了，当时我正在培训我们的开发人员。太棒了。
我们的模型从设计之初，就是为了深入计算机程序内部而存在的。我们甚至非常认真地相信，未来这方面的规模会远远超过今天人们能够想象的程度。我们的模型现在可能还没有完全为那个未来做好准备，但我们一直在持续朝着那个方向努力。我们不会满足于一直在浅层任务上不断变得更好。我们的目标是深入程序的核心，因为这才是让软件真正强大的方式。实际上，我们这里的所有类型——这其实是一个输出——以及输入中的各种部分，比如状态（state）、指令（instructions）、标准（criteria）等等，都可以被组织成结构化的JSON对象。这样，程序就可以把它们插入正确的位置，而不需要把所有东西都塞进模板里。
主持人：对。
Diogo Almeida：人们经常没有充分理解这一点。他们会觉得所有东西都是字符串，仅此而已。这当然也可以。但我会说，如果你使用模板，把东西转换成system message（系统消息）之类的形式，那么你的思维方式其实还停留在过去。我们应该尽可能让计算机更容易理解这些东西，因为这些结构本身是真实存在的。比如，在一种编程语言里，如果你有一堆数字，然后把它们全部转换成字符串，这其实很奇怪。通常只有在需要打印出来、需要让人参与其中的时候，你才会这么做。但如果是在计算机内部传递信息，你希望传递的是语义明确的嵌套结构。我们实际上正在持续优化模型，让它非常适合处理这种结构。但问题在于，每增加一层嵌套结构，推理就会变得更加困难。
我们现在正在非常努力地朝这个方向发展。大家也应该继续朝这个方向做，因为这会让代码变得更加清晰、漂亮，而且不再依赖具体的实现细节。你可以把它理解成：“这是我的状态。”比如：“这是我的函数状态。”把它想象成一个AI函数。我的状态中有哪些子集，也就是我目前拥有的所有变量，应该被传递到这里？相比之下system message就像一堆令人讨厌的全局变量。你把所有东西都放进去，把所有指令一次性塞进去，然后希望每一条指令都能被准确执行，而不是把问题拆开、并行地提出一个个问题。
主持人：明白。
Diogo Almeida：另外，我强烈建议大家提出大量的问题，把它们拆开，让它们变得更小，并且真正去做问题分解。无论模型现在能不能做到，我都认为应该这么做。我相信，这一周正在发生的事情最大的“救命稻草”之一，就是人们的代码库会因此变得好得多。如果你把问题拆解成一个个简单的决策，那么其中的每一个环节都非常容易评估。以前的做法可能是一个很大的system message，然后再用另一个很大的AI去检查它到底有没有按照要求执行。这太疯狂了。某种程度上，这就像一种“斯德哥尔摩综合征”。如果你想规定：“不要读取这个子目录。”或者：“不要把任何API key传给DeepSeek或其他任何地方。”那么这些事情就应该通过程序本身得到基本的保证。
当然，你永远不可能从机器学习模型那里得到绝对保证。但是，通过把问题拆开，你实际上就可以进行测量。你可以验证某个操作是否真的被调用了。而我们的模型，其接口本身就非常容易验证。这应该让人松一口气。它最终会带来更好的软件工程。
主持人：对，我理解了。过去人们之所以没有这么做，其中一个原因是他们会直接调用一个小型LLM。但这样做仍然太慢，也太贵，相比之下，把所有东西一次性放进去似乎更有效率。我自己就做过完全一样的事情。我会进行基准测试：一个方案是把所有内容都放进system prompt，然后只获得一个大型输出；另一个方案则是把它拆成100个不同的部分。结果后者更慢、更贵，而且效果还更差。
Diogo Almeida：对。这种情况确实会发生。而且非常不方便，也很笨重。为什么不直接把所有东西放在一起？你最终还会发现，不同问题之间可能需要重复一些内容。所以它可能看起来效率很低。但最终得到的东西却非常难以依赖。软件也不应该必须一直在后台运行才能发挥作用。如果我们的东西无法在后台运行，我会非常难过。在你们的实践中，有没有发现哪些问题拆解方式真正有效？哪些方法原本以为有效，后来却发现其实并不奏效？
主持人：这个问题很有意思。因为现在大家都会开始探索这些方法。既然你刚才这么说，人们可能会把这些内容当成参考，然后想：“这就是我应该使用Jev的方式。”那么，问题就变成了：你究竟应该怎样拆解问题？
Diogo Almeida：我喜欢把事情拆解成它最小的语义单元。也就是说：最低层级的东西究竟是什么？我可能是使用这个模型最多的人之一。在我的查询中，第一点就是——这实际上更多体现了我自己的提示方式——我会把问题组织得非常非常结构化，而且非常明确。我喜欢使用反引号。当然，这种方法并不只适用于反引号。关键是要非常清楚地说明你究竟在指什么。因为我们希望模型尽可能按照字面理解。当你编程的时候，你希望程序能够非常非常准确地遵循指令。这就是编程的艺术。而 AI 所做的事情，就是不断扩大那些可以被准确执行的指令的范围。所以，我非常喜欢这种方式。
有时候我也会偷懒，采用一些混合式的方法。但如果是非常大型的生产系统，你应该不断增加问题的数量。你应该让增加更多问题变得非常容易。要非常非常精确地完成问题拆解，然后让代码去保证你真正想要的行为。如果让我举一个非常小的例子，那就是拒答（refusal）。我不打算解释我们为什么拒答——我可能已经讲过了，现在记忆有些模糊。但对于拒答，你不应该直接问：“我现在应该拒答吗？”这是一个很大的问题。
模型可能会做得相当不错，因为这属于System 1比较擅长的任务。但更好的方法是针对不同的拒答情境，提出许多个彼此独立的问题。因为这样你就不需要让模型仅仅根据整体情况去猜。你可以非常漂亮地明确规定你真正想要的行为。这件事真的非常漂亮。如果你发现某一种情况：“哦，它因为这个原因没有拒答。我之前没有明确规定这一部分。”那其实是一件好事。这就是软件工程的意义。
你通过增加一个问题、增加一个阈值，也许再把这个情况记录成测试用例，就可以把这个问题彻底解决。你的软件不会因为context rot（上下文腐化）而忘记提示中的这一点。这个规则就在那里。你可以永远持续测量它。而且，如果模型在某些事情上还不够完美，你可以根据真实案例，为这些因素分别选择你想要的阈值。这有点像“没有机器学习的机器学习”。而且，你可以把这种方法应用到任何事情上。
当然，有些事情模型目前可能还不够好。例如，当我看到有人使用模型进行自动化交易时，我会有一点担心。它看起来很酷。但人们应该把这种事情交给专业人士。因为这是一项非常困难的高层次任务，模型可能还没有强大到能够解决它。即使模型真的足够强，也会受到有效市场等因素的影响。但这正是可以通过拆解任务、逐项评估来判断的事情。你可能会发现：“它在这一点上还不够聪明。”那么，也许我们暂时不要在这个版本中部署它。或者，我们做出一定的权衡。或者，我们选择更加安全的方案。比如：“模型无法很好地识别某种奇怪的情况——一个VIP客户同时使用讽刺表达。”那么这种情况就应该升级给人工处理。这也是confidence estimates（置信度估计）的意义所在。
主持人：好的，非常好的回答。我想很快补充一点。我不认为你需要回答太长。你现在仍然把thresholding（阈值设定）作为用户可以调整的杠杆。但如果真正的问题是calibration（校准）本身出了问题呢？你刚才说的是：校准是正确的。
Diogo Almeida：我没说校准是完美的。所谓完美校准，意味着较低的数值对应较低的概率，较高的数值对应较高的概率。但它仍然可能是错误的。它可能在某个局部区域出现错位。那么，我可能就会希望对它进行微调之类的操作。但你们现在并没有提供这个功能。
主持人：对。所以，这就引出了一个问题：你们是否应该提供fine-tuning（微调）？
Diogo Almeida：这可以是一种方案。或者，你也可以提供另外一种控制参数。因为现在你能做的事情基本就是：如果出现问题，就重新修改提示词；或者把问题进一步拆解；或者调整置信度。这就是我现在拥有的两个选择。但如果模型本身就是在犯错，这种方式确实不太令人满意。
主持人：对。
Diogo Almeida：而且模型确实会犯很多错误。这一点必须明确。我们有一个report issues（报告问题）的按钮，也欢迎大家在Discord上向我们反馈。我们希望把它做得好得多。每一个模型版本都应该有明显的改进。如果没有实现重大改进，我们就会很快停止发布新的版本。所以第一点，这完全合理。
我们必须非常务实地承认：AI在某些事情上就是不完美的。但我确实认为，我们会找到一些模型已经“足够好”的使用场景。而“足够好”到底意味着什么，取决于具体的使用场景。人类自己也可以完成大量工作，即使他们在这些工作上表现得并不完美。因为他们的预期价值（EV）仍然足够高。同样，只要设置合适的阈值以及其他机制，即使模型会犯错误，也仍然有大量工作可以交给它完成。
至于fine-tuning，我确实可以想象未来会提供这种能力。但我对此也有一些担忧。因为这里存在一个“人们需要什么”和“人们想要什么”的区别。通用模型往往具有非常强的泛化能力。让模型在另外一百万种任务上都表现良好，而不是只针对某一个狭窄任务进行优化，反而可能让它在这个具体任务的边缘情况上表现得更好。这一点让我有些担心。
主持人：对。
Diogo Almeida：所以我的答案是：我可以想象它会出现。我在这些问题上一直非常务实。我的世界观是，我们有太多东西想要构建。但我不希望发布一个巨大的“自伤工具”——也就是一个最终可能反过来伤害使用者的东西。
主持人：其他一些AI公司已经这么做了。
Diogo Almeida：对。OpenAI、Claw，甚至Gemini，都曾经推出过fine-tuning，然后又把它撤回。这其实是一个很有意思的观察。现在，fine-tuning基本上已经成为开源模型领域的一项能力。
主持人：是的。
Diogo Almeida：我知道这件事。而且，它当时做得其实挺糟糕的。所以他们把它撤回，可能反而是更好的选择。它确实可能成为一个“自伤工具”。因此，告诉用户：“对这个模型进行fine-tuning可能不是正确的做法。”这本身可能是件好事。另一种有意思的答案可能是：“我们的模型非常不同。”就像quantization（量化）不适用于我们，output tokens（输出token）不适用于我们一样，fine-tuning也可能不适用于我们。
主持人：哈哈。
Diogo Almeida：实际上，我对这种可能性非常开放。不过这不是承诺。我只是表达一个愿望。我喜欢尽可能诚实地说明这一点。随着每美元所能购买的intelligence（智能）越来越便宜，我们可能会得到一些非常小型的、近似的东西，希望它们可以成为智能的代理指标。比如，有没有一天，人们不再需要自己编写regex（正则表达式）？因为使用AI所需要付出的智能成本，可能会低于编写一个regex所需要付出的复杂度。那会非常酷。我会非常喜欢这样的未来。当然，对于某些非常狭窄的使用场景来说，可能仍然需要fine-tuning，才能真正跨过那个能力阈值。我们拭目以待。
我希望calibration（校准）能够解决这个问题。校准，再加上一套模型级联（cascade of models）。比如，如果置信度非常高，那么可能就直接使用当前结果。如果处于中间区域，就调用下一个更大的模型，然后从那里继续处理。我还不知道最终会怎样。但我可以想象这种方案。
我还可以想象另一种情况。假设我们拥有整个前沿的模型体系，而企业可能希望完成某项任务。黑客可能也会愿意处理一整套不同模型组成的frontier。企业可能希望更加动态一些。你可以想象，我们拥有不同大小的模型，然后根据模型在你的技术栈不同部分的智能水平，动态选择应该使用哪一个模型。甚至由于我们的系统非常简单，你还可以想象某种自动化fine-tuning。
主持人：所以，你们会考虑提供不同规模的Jev模型？
Diogo Almeida：当然。
主持人：用来满足不同需求。
Diogo Almeida：绝对可以。我怎么知道人们到底需要多少智能呢？
主持人：哈哈。
Diogo Almeida：我也不知道。需求是无限的。
主持人：没错。现在甚至有人告诉我们不要发布更多东西，因为他们觉得我们已经不需要再发布了，因为现在已经足够好了
Diogo Almeida：对。但那有点无聊。我非常喜欢一句话。这是我希望大家以后能够拿来要求我的，因为一旦说出来，就很难再收回。我不确定具体是哪一句，但大意是：文化就是你真正做的事情，而市场并不一定会奖励它。我非常喜欢这个理念。因为我们正在坚持某种东西。也许未来，我们坚持的东西会变得如此理所当然，以至于我们会像 Visa 一样，变成一个无聊的基础设施。我们只是一个没人真正会去思考的工具。到那时候，我可能也不会再穿粉色西装之类的。但现在，我真的希望能够推动整个世界朝这个方向前进。我希望我们继续做一些酷的事情。不是因为我们必须这么做，而是因为我希望人们意识到：这一切才刚刚开始。这甚至还不能算真正的第一轮进攻。那只是一个比较低调的research preview（研究预览），或者你愿意怎么称呼都可以。对于machine-native intelligence（机器原生智能），我们还有很多事情可以做。它将会非常疯狂。
主持人：所以，这可能不只是唯一的模型规模，也可能不只是你们唯一会推出的模型。
Diogo Almeida：绝对不是。我希望尽可能满足我们能够满足的各种需求。当然，这里有一个非常大的前提：我不希望OpenAI的产品团队像是在墙上不断扔东西，看看什么东西能够粘住。我希望所有东西都统一在一个整体愿景之下。如果你回到我们的宣言，在我看来，所有东西都应该属于其中的三个方向之一。
主持人：我明白。
Diogo Almeida：我现在还没有准备好详细讲这个。
主持人：抱歉，抱歉，是我问得太直接了。
Diogo Almeida：没关系。我只能稍微谈一点。我们的体系里有三个步骤。听起来可能像是在故意吊胃口。但我希望所有事情都能够归入这三个方向之一。继续推动边界。而且这些并不是检查清单。它们是我们认为能够构成一场新技术革命基础的几个轴。我希望我们做出的所有下注，都能够落在这些方向上。而且，我们在模型层面会做一些非常非常奇怪的事情。因为这就是machine-native。人类不一定需要完全理解它。它只需要真正有价值。
主持人：那就给大家一个小小的提示。“奇怪”到底会是什么样？什么才叫奇怪？
Diogo Almeida：我可以给大家一点提示。有些人正在尝试把它们称为decision models（决策模型）。
主持人：好。
Diogo Almeida：我们的primitives（基本原语）是 decisions（决策）。不过，我不会这么称呼它。因为还有其他类型machine-native模型，它们并不属于decisions。
主持人：好，那我们就说到这里。这是一个非常有趣的提示。有些人会说：“我以前就做过这个。我一年前就做了一个decision model。”“Jev并不新，Jev也不酷。”但这里有一个分类层面的区别。你真正建立的是：“什么东西是可能的？”还有一个层面是性能：“从benchmark和数字来看，你们现在似乎仍然超过了所有其他类似模型。”
Diogo Almeida：先明确一点，我并不在乎benchmark。无论我们是赢还是输，我都不在乎。我更在乎的是建立一个新的类别。
主持人：对。而你真正想建立的是decision models和System 1之间的这种区别。
Diogo Almeida：是的。我只是希望让软件工程师获得超能力。我真正觉得悲哀的一件事情是AI寒冬时期发生的事情。那时候AI明明拥有如此强大的能力，却被严重低估和闲置。这件事让我真的很难过。这是最让我产生情绪的事情之一。但我也不想简单地成为一个纯粹的技术乐观主义者，好像所有技术天然都是好的。当时发生的事情实际上是一场悲剧。我只是希望能够把这些可能性真正开放给人们。
主持人：好，我就说到这里。
Diogo Almeida：我过去几天已经哭得够多了。我不太想在录音里再哭一次。
主持人：哈哈。我很感谢你愿意分享其中的一部分。人们能够看出来，你对这件事情非常真诚，也非常有热情。你不一定能够仅仅从“safe AI”这个名字里感受到这一点。但当人们真正深入了解之后，就会看到：你真正想推动的是一个完全不同的方向。而且，你已经完成了从0到1最艰难的部分。接下来，我们就应该一起朝着这个新方向前进。
Diogo Almeida：是的。不过，我不确定我会不会认为最艰难的部分已经完成了。也许我以后会这么认为。但未来还会有很多更加艰难的部分。如果未来各种事情都被自动化，我们终于看到GDP增长，如果真的进入一个每天都像“AGI派对”的时代，那么也许那个时候才能说最艰难的部分已经过去了。但我不这么认为。而且我真的认为，人们现在太关注速度和成本，却没有给予 reliability（可靠性）足够的重视。可靠性才是真正让产品令人愉悦的东西。可靠性才是让你能够真正信任它的东西。你曾经提到过一个目标：TFP（全要素生产率）在五年内增长3%。
主持人：太棒了。我从来没见过一个AI实验室如此关注TFP增长。
Diogo Almeida：但这才是真正意义上的经济革命。而且，这其实与OpenAI最初的章程非常一致。章程本身可能并没有改变。只是后来人们开始重新调整一些定义，比如“1000亿美元利润”之类的指标。
主持人：我并不是说我讨厌OpenAI。
Diogo Almeida：对。而且AGI本身原本就不是一个定义得非常清晰的概念。他们曾经尝试定义它，比如：“完成世界上大部分具有经济价值的工作。”但如果AGI能够解决Millennium Prize Problems（千禧年数学难题），却只能完成全球具有经济价值工作中的0%，那这个定义就会变得非常奇怪。因为这两件事情之间可能存在巨大的差距。
现在所有模型在这个意义上大体上都还处于接近0的位置。当然，也有可能我们已经开始进入那个阶段了。但如果让我猜，我会认为现在还不到1%。而且，真正发生的时候，它最终会体现在经济统计数据中。那会非常令人兴奋。但它不会导致大规模失业。
SaaS反向末日：AI正在消失于软件之中
Diogo Almeida：这会带来一大堆非常棒的变化，整个世界也会因此变得更好。而且，说实话，我已经厌倦了AI总是成为所有事情的“前景主角”。这个世界应该变得更加令人愉悦，而AI只需要帮助实现这一点，然后自己消失到背景中。
主持人：完全同意。
Diogo Almeida：我在演讲里经常说一件事：2019年的软件、SaaS等等，已经非常有价值了。现在已经是2026年了，可为什么这些软件基本上还是和以前一模一样？明明AI已经强得离谱了，除了有时候软件旁边多了一个聊天框，而且这个聊天框还只能在一定程度上工作之外，几乎没有变化。但问题是，它们不允许AI替公司做那些真正涉及公司利益的决策，因为人们不相信AI能够做这些决定。这太荒谬了。这里存在巨大的经济激励。接下来会出现一种“反向 SaaS末日”。SaaS反而会因为AI得到极大的增强。因为SaaS公司最清楚哪些事情有价值、哪些事情值得自动化。所以接下来会是一个非常疯狂的时代。
主持人：是的，我也这么认为。这是一件非常美妙的事情，你已经把它解锁出来了。你刚才提到了一个我不知道是不是这里应该直接讨论的问题：什么是System 1问题，什么又是System 2问题？
Diogo Almeida：这是个很难的问题，我的朋友。因为现在大家都想把所有事情都交给Jev。这可能最终会失败。
主持人：“Jev一切”，这个说法还挺有意思。
Diogo Almeida：我跟你说实话：这其实是一个经验主义问题，就像scaling laws（规模定律）一样，本质上都需要通过经验来验证。比如说，为什么现在的机器人技术还没有真正奏效？明明已经投入了这么多资金。我不认为答案一定是继续投入更多的钱。也许只是因为目前的经验结果还没有出现。
从经验上来说，这些经过预训练、将大量智能高度压缩在一起的模型，本质上是System 1思维者。System 1是目前描述LLM最擅长领域的最佳方式。RLVR对System 2思维已经做出了非常不可思议的事情，我对此非常惊叹，真的非常酷。我一点都不认为它会导致AI doom。当然，也不能说概率是0%，因为认为概率为0%本身就是校准失误。但他们做的事情真的非常酷，而且确实已经把这一方向推得非常远了。当然，也许他们自己不会认为已经推到了“极限中的极限”。但模型进行这种事情其实是一件很奇怪的事，而且它们在这方面非常脆弱。
想想以前人们是怎么谈论AI的。在ChatGPT刚出现的时候，大家会说：“哇，它真的非常通用，它什么都能做。”但与此同时，它又不擅长数学题，比如GSM8K这样的基础数学问题。而现在再看看人们怎么讨论RLVR。它非常脆弱，非常“锯齿化”。你会发现，它为什么能做到某些非常奇怪的事情？实际上，数学并不是简单的、孤立的“尖峰”，它更像是fractal（分形）。
这是因为，如果我们讨论每一种方法的北极星指标：RHF是“取悦人类”，因为这就是人类反馈的目标。RLVR优化的是基准测试。实际上，进入RLVR范畴的东西，从定义上来说都属于benchmark，因为benchmark本质上就是能够通过程序验证、拥有简单输出结果的任务。而RLCD的目标则是让模型对于程序化使用更加可靠。
主持人：我可以分享一下我的想法，然后你看看我说得对不对。比如，我在你第一天给我访问权限之后，就拿Jev去测试了一大堆东西。其中一个就是multi-hop reasoning（多跳推理）。单跳任务非常出色，单跳问题你真的不应该使用Jev之外的任何东西。但到了多跳任务，表现就开始下降，而且随着hop数量增加，表现似乎在单调下降。
Diogo Almeida：对。
主持人：所以回到刚才那个经验主义的问题，关键在于我们究竟能够从模型中“提取”出什么。我们当然希望获得一切。我们希望尽可能挖掘出所有智能。而我们所做的事情就是不断解锁、平滑和塑造这些智能，同时加入新的能力，并不断填补其中的空白。而随着时间推移，我们会不断填补越来越多这样的空白。
但现实是，我们真正做的事情，是尽可能多地挖掘模型本身已经存在的属性。这些属性实际上取决于那些高度压缩的核心模型中究竟有什么，然后我们再把它们像Frankenstein一样组合起来，让最终系统拥有所有这些属性。所以现实是，我们一直在尽可能多地挖掘能力。而System 1只不过是对目前有效方法的一种描述。在这种范式下有效的东西，本质上都会带有某种System 1的特征。这也是为什么我们不做所谓的latent reasoning（潜在推理），也就是在字符串中进行reasoning。模型真正做得很好的是在模型内部进行推理。当然，它还不够完整。
Diogo Almeida：你说的latent reasoning是在模型权重内部进行推理吗？以前人们把它叫作continuous reasoning（连续推理）。我不太确定。
主持人：它被叫作latent reasoning，是因为以前reasoning traces（推理轨迹）是隐藏的，所以它们某种程度上像是答案的latent variable（潜变量）。
Diogo Almeida：所以现在隐藏的东西发生了变化。
主持人：对。当然，对于OpenAI和Anthropic来说，它依然是隐藏的。
Diogo Almeida：所以不会有reasoning Jev？
主持人：对。
Diogo Almeida：就目前而言，至少不会。因为那实际上违背了System 1的整个承诺。我的承诺是：我会为了machine-native（机器原生）应用去做任何必要的事情。我可以想象，未来会出现一些推理形式，它们没有那么慢、低效和脆弱。这些东西完全在可能范围之内。但我要说明的是，我是一个务实主义者，所以我不会对具体方法作出承诺。我的承诺是明确我的 ROI north star（投资回报北极星指标），并为它努力。这次发布没有发生，但我们仍然渴望在这个世界上找到自己的位置。
主持人：很好。另一个问题是视觉。视觉也是一种你目前还没有的巨大能力，但它也许永远不属于System 1。
Diogo Almeida：我的视觉还不错
主持人：什么？
Diogo Almeida：我说我的视觉不错。
主持人：不不不，我是在开玩笑。
Diogo Almeida：因为显然，人们第一时间想要的就是视觉。一部分原因当然是因为那个Doom demo，但同时，除了文本之外，几乎所有东西都属于视觉。在我看来，所有这些能力都在我们的计划之中。实际上，这里存在一个很有意思的争论。你可能是最适合参与这个讨论的人之一。问题在于，我们到底应该给人们他们“认为自己想要的东西”，还是给他们我们知道未来显然有价值的东西？我们过去在stealth模式下做了两年。当时我们只是知道，这些东西显然会有价值。还是说，我们应该给他们真正“说出来想要的东西”？
这里面有很多不同维度。Context length（上下文长度）就是一个例子。我们所有的模型，包括我们的模型，在长上下文中保持性能不下降的能力方面，我们应该是明显最好的。但其他供应商基本上采取的方式是：“既然这是大家想要的，那我们就把这个东西给他们。”我们需要在这两者之间找到一个平衡。因为如果把“给人们他们想要的东西”推得太远，就会走向一种Anthropic式的nanny state（保姆式国家）思维，这对开发者非常不友好。但如果完全走pro-developer（开发者优先）的路线，也存在问题。开发者会说：“我们不希望把理解智能基因、探索模型能力的负担全部放在自己身上。”
所以我们现在真正需要解决的是：我们应该多快发布这些东西，同时保持我们自己的信任品牌，并且把用户当成能够做出知情决策的成年人，而不是在所有事情上都替他们进行nannying（保姆式管理）。
主持人：这个说法很合理。坦率地说，我们也不知道答案。我们还得继续摸索。这可能会成为接下来几天里我最大的争论之一。因为我们手上还有很多东西。我们之前也没想到它会这么快爆发，所以我们肯定还需要一些后续发布。
Diogo Almeida：我不知道你是不是真的没想到它会爆发。我看到你投入的工作量了。我基本从来没见过你像过去两个月这样全身心投入。
主持人：那也是因为我的chief of staff（幕僚长）逼着我全身心投入。我以前还以为自己已经很努力了。
Diogo Almeida：对。而且你还出现在我们的writing workshops（写作工作坊）里。我当时还想：“你来这里干什么？”实际上非常有用，也非常棒。你显然对这次发布投入了大量思考，而且成果也证明了这一点。恭喜你。
主持人：谢谢。我希望自己继续保持这种状态。我的感觉是，我们已经通过了科技世界要求我们通过的很多重要筛选。但接下来还会有很多。而且，天哪，我真的非常兴奋能够继续为正确的事情而战。
Diogo Almeida：很令人兴奋。
低估、误解与认证：打磨Jev的必经之路
主持人：在我们拓展到Typesafe之外的话题之前，我想问一下：关于你们已经发布的东西，有没有什么被低估或者被误解的地方？
Diogo Almeida：被低估或者被误解？
主持人：对。你这里其实已经有一些模式了。比如model jaggedness（模型能力的锯齿性）。你有没有什么想展开讲的？给我一个你最近思考的东西就行。
Diogo Almeida：我可以把这些全部讲一遍。但我真的不应该这么做。
主持人：大家可以去你的Discord看。
Diogo Almeida：我能说的是，大家真的在cookbooks（使用手册）上投入了很多心血。里面有一些非常厉害的东西。我们原本考虑过把很多内容直接放进主发布博客里。但后来发现内容越来越长，也越来越难以阅读，而且会变得非常面向power users（高级用户）。但我们真的非常认真地投入了很多心血。
坦白说，在发布之前，我们所说的这些东西听起来就像某种奇怪的外星工具。大家会想：“为什么有人需要这个？”这确实是一件很奇怪的事情。我们当时非常担心如何向人们介绍这个新的frontier。显然，它最终成功了。但我们当时投入了大量工作，是因为我们认为“教育用户”会成为我们的一个巨大瓶颈。现在看来，它可能已经不再是问题了。因为用户正在做一些远远超出我们能够展示给他们的东西。而且他们的use cases（应用场景）有时候比我们自己的还酷。有很多时候我都会想：“如果这就是我们的 demo，天哪，这比我们展示的东西酷多了。”尤其是computer use（计算机使用）。太酷了。
但我们确实在这里投入了很多心血。这不是AI生成的垃圾，至少据我所知不是。我们真的投入了大量工作。这些内容背后都有真正有价值的信息。它们都来自真实客户问题。我们找到真实存在的问题，然后帮助他们完成一些非常酷的事情。
主持人：既然你提到了这一点，我想问：你们在发布之前进行了多少验证？整个过程是什么样的？显然你们做了一些，但你们当时不可能接触到现在这么多用户。
Diogo Almeida：当然。事实上，我们当时得到的市场反馈相当差。团队里的非技术人员真的非常担心。当时有很多恐惧。大家会觉得：“没人真正理解这个东西。”“他们也不想要。”我们就像是在卖一种维生素，而不是止痛药。大家甚至会问：“我们是不是应该安排全职员工直接围绕这个问题开发软件？”
在发布之前，我们几乎没有收入。技术人员则基本上都是坚定的坚定支持者。我们知道这个东西很厉害。它在计算属性上的表现，在很多维度上都非常突出。所以我们觉得：“它显然会变得非常巨大。”我当时确实非常害怕。这也是为什么我会如此投入。但最常见的情况是：我们让超过一半的人试用，他们根本没理解这个东西。而那些真正理解的人则会说：“这真的很酷。”但接下来他们又会问：“那我们怎么让采购部门批准？”
所以这确实是一场相当艰难的战斗。但我们当时就知道：我们的目标市场是开发者。用户会自己找到use cases。然后所有其他人都会产生FOMO（害怕错过）。我不想把这种“事实发生变化以后大家改变看法”拿出来嘲讽任何人。但我确实想质疑一下product-market fit（产品市场契合度）这个概念。因为当时产品在那里，市场也在那里。我们问：“你们想使用这个吗？”大家说：“我不确定它能不能解决我们的问题。”结果突然爆发以后，大家开始说：“我们能不能获得尽可能高的rate limits（速率限制）原文：https://www.huxiu.com/article/4898379.html?f=rss
