大家好，欢迎收听 Latent Space 播客。我是 Allesio，Desible 的合伙人兼 CTO，今天与我一起主持的是我的搭档 Swix，Small AI 的创始人。嘿，今天我们有一位回归嘉宾，还有一位新朋友。欢迎 Michelle 和 Josh。你们好。你们俩都在……我想想，Michelle，之前介绍你时好像说你是 API 团队的经理。自从上次做客播客后，你似乎换了岗位？对，现在我负责研究方面的一个团队，具体是 post-training。
Josh，你也在 post-training 团队？是的，我是 Michelle 团队的研究员。对了，我刚发现你们俩有个有趣的共同点——你们都来自 Waterloo。延续了“极度严谨的工程师”这一传统。哦对，我们上次聊过这个。好。我们今天聚在一起是为了聊 GPT-4.1。你们发布了这款模型。我是说，我们之前得到了一点预览，而且此前也有一些传闻，对吧？它似乎通过 OpenRouter 提前发布过，代号是 Quasar Alpha，然后还有一个 Optimus 版本。我想大家都在琢磨，为什么版本号从 4.5 倒退回 4.1 了？当然还有很多其他方面，但我想知道关于 4.1，你们最想强调的核心要点是什么？我们今天发布了三个新模型：GPT-4.1、GPT-4.1 Mini 和 GPT-4.1 Nano。这些模型的真正重点是打造对开发者非常友好的模型。所以我们改进了指令遵循和编程能力，并首次推出了支持 1 million context 的模型。Josh，还有什么要补充的吗？不知道有没有什么细节是人们应该了解的。没了，我想唯一值得再提一遍的是，这次产品线里其实有个新成员 Nano，对于那些开发低延迟应用的开发者来说，它更快，也更便宜。这些代号背后有什么有趣的故事吗？你知道，OpenAI 的历史里还有“草莓”帽子那种趣事。有。我们非常希望尽可能多地获取开发者对这款模型的反馈，确保它在现实世界中表现良好，所以我们通过 OpenRouter 进行了测试。看到大家抓住那些名字不放、各种理论满天飞，感觉挺酷的。但我们从那里获得的反馈非常有帮助。对，其实甚至不完全是名字的问题，更多的是 API 的形态。一旦大家看到 chat completion 的结构，就很明显能认出是 OpenAI。对，这是个好观察。但我是说，是不是有什么关于天体的寓意？我们从“超大质量黑洞”这种代号里应该推断出什么？我觉得没什么可推断的。我觉得它们就是很酷而已。就是些好玩的名字，让你联想到很酷的概念。氛围感很好。氛围很好。就是这种感觉。对了，还有例子里的另一个东西，我们就是在挖掘 lore，对吧？貘。那种有趣的动物。它在直播和博客文章里出现了好几次。貘是怎么回事？这里谁喜欢貘？我们团队就是特别喜欢貘。所以它们就碰巧出现在了我们很多内容里。好的，酷。太棒了。嗯……
你说。你说。我觉得我们先要过一遍的显然是 4.1 和 4.5 的关系。我想这是大家可能最先感到困惑的地方。而且我知道你们正在弃用 4.5。听起来 4.1 是个非常强的模型，而 4.5 的规模可能不太合适。那只是个研究预览版。所以你们想怎么回应都行，我觉得这也是我们在 Discord 里看到大家提出的问题。对，完全理解。命名真的很难，我们已经尽量不让大家困惑了，但你知道，没有什么是完美的。基本上，我们之所以这样命名，是因为 GPT-4.1 相比 4o 系列有了相当大的提升，我们很想体现这一点。然而，它比 GPT-4.5 小得多，也便宜得多。因此，在 AGI 或其他智能 evals 上，它并没有达到同样的水平。所以它并没有在所有 evals 上都击败 4.5。所以我们觉得把它命名成比 4.5 更高的版本号不太合理。但我们确实认为，对大多数开发者来说，他们可以用 4.1 替代很多原来用 4.5 的场景，而且 Mini 严格优于 4o mini。那 Nano 呢……但我们不知道 4.1 是不是 4.5 的 distillation，或者它们之间有没有关系。我们能说什么关于它们共享 lineage 的事吗？关于这个，我要说的是，我们一直在使用各种研究技术来改进模型，distillation 是我们之前讨论过的东西。它非常有意义，尤其是对小型模型。而且我们把 4.5 身上一些特别出色的地方提炼了出来，比如它在指令遵循方面的优秀表现，也融入到了 4.1 里。太棒了。我记得在 4o 发布时，他们传达的信息是我们正在转向一种新的模型架构，也就是 omni-model，这就是 4o 里“o”的含义。然后 4.1 似乎是这一后续趋势的一部分，试图融合一切——推理模型、omni 模型，所有东西。我想大家有疑问的是，4.1 基本上被宣传为 4o 的直接替代品，但它会不会是 fully omni 的？它是不是和我们认为的 4o 拥有大致相同的架构？我们在 Realtime API 和 Responses API 上已经有不同的模型版本标识了。所以它们已经有一些不同的 checkpoint。我想我们目前没有计划在 Realtime API 中发布 4.1，但情况可能会变。然后还有图像生成那些功能对吧？据我们所知，没有计划，或者说没有宣布任何消息。目前没有。4.1 的重点主要是面向开发者的这三项核心能力。对，我们 Discord 其实还组织了一场发布观看派对，看 Sam Altman 最近做的那期 4.5 播客。我想那里面第一次基本确认了某些大家已经知道的事——比如 Andrej Karpathy 之前就提到过——4.5 的规模大概是 4 的 10 倍。于是大家就在问，能不能做个线性插值，比如 4.1 的规模大概是 2 倍之类的？嗯，我们其实不是这样思考模型命名的。配方里有很多不同的组成部分。所以版本号并不只是反映 pre-training 的配方。我觉得 4.1 这个名字更多是因为我们在编程能力、长 context 等方面有了巨大飞跃。它更多是给终端用户的体验感受，而不是关于训练配方的任何东西。不过我们可以稍微透露一点训练的细节：Nano 显然是一个新的 pre-train。Mini 也是新的 pre-train，而大版本则是一个新的 mid-train。但我们发现，实际上很大一部分性能提升来自新的 post-training 技术。所以我想过去大家普遍认为，要获得更好的性能就需要 pre-train 越来越大的模型，而我们发现其实能从 post-training 中压榨出更多东西。现在说到模型规模，另一方面就是 context window。你们做到了 100 万 context。我记得 Sam 去年某天说过，100 万 context 还要等几个月。那么，正好准时。你能谈谈，达到 100 万 token 有多难，以及你心目中的终局是什么吗？是 1000 万、1 亿，还是无限大？当你开始扩展它时，真正重要的是什么？是的，Josh 在长上下文方面做了很多工作，所以他是最佳人选。当然。嗯，我认为我们在推进长上下文时，第一件让我觉得非常有趣的事，其实是那些你在其他博客头条上看到的评估，也就是 needle in a haystack。实际上大多数模型一出场就表现得很好。但随后我们必须首先针对长上下文推理，在更长的上下文上获取大量测量数据。你知道，我们刚刚开源了两个新的评估，它们涉及以更复杂的方式使用上下文。所以，其中一个需要大量关于排序的推理，另一个实际上是 walking through graphs。嗯，在这些数据集上你需要做很多推理，而这才是长上下文真正更难的地方；至于单针 needle in a haystack，我们很容易就达到了饱和。嗯，然后大部分工作都集中在这些更难的任务上。好的，哦，如果你有后续问题，请继续。是的，我是想说，不，只是想问你如何看待上下文长度，是指消费文档，还是更像主动的思考和规划？嗯，我认为在 prompting 方面，显然有一大块是关于构建 agentic workflow 的。你觉得人们是不是仍然过多地把它看作 needle-in-a-haystack 式的文档检索，而不是在上下文中遍历非常长的计划并做各种迭代？是的，我认为我的心智模型其实可能包含更多变量。所以有单针 needle in a haystack，里面有一定数量的干扰项和一些你要找的针。我认为这更关乎你需要使用的上下文密度。比如摘要，你其实是在使用上下文的全部内容，而 needle in a haystack 则非常稀疏。然后我还通常会考虑有序性。如果你要在此基础上做某种推理，你只是从头到尾看一遍，还是需要在模型采样过程中在上下文里来回跳转，才能生成好的答案？是的。这是你用在 graph walk 上的思路吗？是这回事吗？这可以说是衡量模型最合成、最干净的方式；然后你知道，我们还研究了很多其他训练技术和数据，来测试模型并训练其以某种打乱顺序的方式在整个上下文中推理的能力。是的，你知道，其实我挺喜欢给大家一点视觉辅助的。嗯，所以我其实去你们 Hugging Face 的发布页面找了一个 graph 任务的例子，然后这有几个版本对吧，有 BFS 和 DFS 版本，而且我觉得它非常依赖具体字符，所以我不知道，也许你能告诉我们，比如这个的设计选择，有什么出乎意料的难点，之类的。是的，嗯，这里的思路是你取一个图，通过查看边列表并将其放入上下文中来编码它，然后让模型执行一个操作。嗯，然后你知道，在底层我们其实是在执行真实的操作，并用它来评估模型的工作能力。嗯，起初让我感到惊讶的事情之一是，当模型不确定如何使用其上下文时，它会做什么。你知道，早期版本的模型就会一直循环说：“哦不，我找不到那条我觉得应该在的边。”嗯，是的，我认为我非常惊讶地发现，所有模型在一个任务上似乎都比我想象的更困难，你知道，这个任务我们人类会觉得非常简单，或者比如说，一个本科生可能花几分钟就能写个 Python 脚本跑起来。是的。没错。嗯，好吧。那么，它要建模的真实任务是什么？我觉得，你知道，另一个 MRCR 似乎更直观一些，你有四个不同的故事，然后挑出第二个。嗯，这是人们会遇到的真正任务，但人们并不会真的像这样遍历图，这有点偏理论，但就像，你知道，有没有做过什么相关性研究？嗯，是的，这实际上是 multi-hop reasoning 基准测试的一种理想化版本。所以我们有很多场景，你知道，你把数百份文档放入上下文，然后你可能会问一个问题，而你必须遍历 10 份文档才能回答。但那里的边是隐式的，对吧？就像有一个底层图连接着所有这些文档，你需要遍历它来回答问题。嗯，但它们其实更难遍历，因为边并没有直接给你。所以问题就变成了：好吧，如果我把你需要遍历的所有这些 ID 直接给你，模型能做到吗？嗯，这其实只是模型能力的一个 lower bound，我认为这在我们一些使用更自然数据的内部基准测试中得到了相当好的体现。你可以想象类似报税单的东西，对吧？你把整本税法上传，然后要弄清楚在这个框里填什么，你知道，你需要参考所有这些框。所以这类似于同等水平的 multi-hop reasoning，但再次强调，就像 Josh 说的，所有引用都是隐式的。是的，我认为如果需要某种回溯，那也是超级有趣的。嗯，尤其对 agent 工作来说。嗯，对于长期收听我们节目的听众，我们其实在 New Repres 里介绍过这篇论文，他们确实为 agent 规划中的图遍历建模了图，嗯，这让我立刻想到了那篇。只是他们从未提出过你们这里这种完全相同的格式，但本质上是一回事。是的。我也很喜欢你们加入了空白答案，因为有时候人们会幻觉，或者说模型会幻觉出答案，而你们有相当比例的空白答案。这要归功于我做的基于随机采样的图，我猜。是的。嗯，这也和你们最近发布的 file search API 有关吗？人们应该如何看待这一切在 API 中是如何融合在一起的？是的，我认为在检索方面，你知道，人们可能会用 RAG 来填充上下文，而很多时候这样做是为了绕过短上下文窗口的限制。所以我们确实预期很多开发者会开始更直接地把完整上下文上传给模型。嗯，对于较小的任务，你可能不需要整个 vector store。嗯，但我们确实预计这也会与那种范式很好地配合。就像也许你可以往上下文里塞入多得多的 chunk。嗯，所以我们认为它们会配合得很好。是的。这和我们最近 ChatGPT 里的记忆升级有什么关系吗？嗯，长上下文是可以直接当作记忆来用，还是我们应该始终有一个单独的记忆系统？是的，这是个好问题。所以现在 dreaming 功能里，我们某种程度上把一些记忆嵌入到了上下文中，但你知道，它们是不同的功能，所以 4.1 驱动的是 API，而增强记忆功能只在 ChatGPT 上才有。是的。太棒了。嗯，是的，我认为这很有意思。关于长上下文的最后一点，这有点反直觉，或者也许有某种解释：你们在 MRCR 上用了两个 needle，然后我们有四个和八个，而所有结果都回归到某个基线，比如 30% 或 20% 左右。但有趣的是，有时小模型会匹配甚至超过大模型。我想知道那里有没有什么异常，还是说你认为只是运气不好？我想可能只是运气不好。我想我更关注的是，随着 needle 数量增加，这些模型的表现会下降，因为上下文中不同事物的顺序涉及更复杂的推理。是的。太棒了。好的，很高兴继续。我们还有很多其他 eval 可以过。我笔记里记了，我们可以聊任何你想聊的内容。还有 Collie from Shyu，我们请他来播客聊过 instruction following。然后我意识到他加入了 OpenAI，我想知道他是否在那个评估中发挥了作用。不，我们没有合作。老实说，我认为评估作者和模型开发者不要过多合作是最好的，因为这样可以让事情尽可能客观，不会试图去钻任何空子。然后我想还有第一次宣布或提及来自 API 数据的内部 instruction following benchmark。人们已经可以选择加入共享数据一段时间了。其实我发了一条推文，因为我在后台发现你可以选择加入，而且这个项目基本上还剩 16 天，你可以获得免费推理。所以我很好奇，从那种 IF eval 中你们发现了什么，它可能和人们常用的 IF eval 有什么不同。完全同意。很多开源的 instruction following eval，你知道，都是以容易构建的方式设计的。比如 graph walks 相对容易构建，你可以创建这个图并轻松验证，但它并不完全与用户实际在做的事情对齐。一些 instruction following eval 也是如此，你要求模型输出恰好四个词，或者三段话之类的，这些用代码很容易验证。这些指令是有用的，但我们发现很多真正有趣的指令其实很难打分。所以开源评估通常没有这些。因此，获得这种真实世界的多样化数据实际上帮助我们发现开发者在做什么的共同之处，什么是负面指令的好例子，然后我们可以在此基础上研究如何评估。我认为还有一个有趣的问题是，人们在什么领域使用你们？我想知道是否有办法告诉你，因为有时这很令人困惑，特别是如果我在构建一个应用并让别人用我的 key，但还有其他人在我的基础上构建应用。所以你有很多层抽象的混乱，你必须解析这些 prompt。是的，确实。我想说我们在内部尽可能使用我们自己的产品。所以我们不会在匿名化后逐一手动阅读每个 prompt。我们去除任何识别数据。然后我们用模型来分类。所以如果我们收到反馈说我们在有序指令上表现不好，我们就可以对所有数据做一次遍历，找到一些好的例子。所以这里有 instruction following 部分，以及这些关于提示 GPT-4.1 模型的精彩内容。也许我们可以过一遍这些例子。第一个引起我注意的是，没有必要使用全大写和其他激励措施如贿赂或小费，但开发者可以试验这些来获得额外强调。我想这后半部分让我困惑。你是说人们仍然应该尝试这样做，有时模型会积极响应吗？你觉得这只是传说的一部分吗？我很好奇为什么——我希望你能明确说要么“是的，有用”，要么“不，你应该停止。这看起来很傻。”
我想真相介于两者之间。真相总是复杂的。现实是，我们的模型在遵循清晰、单次陈述的指令方面已经变得好很多。但老实说，我们发现开发者通常会成为提示我们模型的最佳专家，因为你以此谋生，会非常深入地了解细节。所以我想说这些东西不会损害模型性能，但我们总是希望留给人们空间去弄清楚什么最有效。然后你们提到要始终以响应规则或指令部分开头。这些关键词是要逐字理解的吗？就像那些是最有效的 token？或者只是举个例子？更多是例子。好的，酷。这很棒。我觉得直到今天，我们做了一期关于提示报告的节目，讲了所有这些提示技术，但还不清楚对哪个模型哪种最有效。所以这非常有用。然后你们在 agentic workflows 中有一个关于 persistence 的内容。就像“是的，请继续”。这个，我想我读到你提到它让 SWE-bench 提高了 20%？仅仅靠这种 persistence，“请继续”——
我不认为单单这一个 prompt 就能让 SWE 提高 20%。而是我们发现这是对我们模型最有效的 harness。结合所有 post-training 的改进，才带来了巨大提升。但是的，模型非常努力想提供帮助，经常想回头询问用户，比如“我应该继续吗？我走对方向了吗？”所以这样的 prompt 能确保它继续前进，不再打扰你，只是完成任务。是的。我认为这里有一个有趣的权衡：persistence 与将控制权交还给用户。模型越想表现得 agentic，就应该越 persistent，但有时它会失控。我想知道你们如何解决这个权衡，因为有时它走得太远了。有人批评 Claude Sonnet 试图一次性重写太多文件，而我只想改一个东西，例如。那是一种不好的 persistence。你思考这个问题的维度有哪些？我想这里有一点很有趣：我们有一个 extraneous edits eval，你让模型做一个编辑，然后分类它的所有改动是否都与被要求做的事情相关，还是它跑偏了做得太多。我们发现 GPT-4o 得到了 9%。这挺疯狂的。9% 的时间做出无关编辑已经很多了。4.1 是 2%。所以这是很大的改进。所以我想说，专注于这一点，我们听到了反馈，我们做了一个 eval，并确保在训练过程中跟踪和改进它。是的，我的意思是，一切都归结于 eval，这对任何人来说都不奇怪。确实。还有一个有趣的 eval，我认为引起了一些讨论。我想也是第一次，而且作为 structured output 的大师你应该知道——JSON 现在不行了，我们都应该用 XML。呃，我想说我不知道你们指的是哪个 eval，但它就在 prompt guide 里，可能不是你们写的。所以我们有点突然拿这个来问你们。是的。嗯，我们团队的 Noah 和 Julian 写了 prompt guide，做得很棒。我确实觉得 XML 在构建 prompt 结构方面很有帮助，而至于解析输出，情况可能略有不同，有时候用 JSON 输出确实很有用，可以直接接入你的应用，但我认为模型用 XML 作为输入时表现特别好。不过好奇你们还有什么要补充的吗？没有。没有。嗯，好的。我是说，我觉得大家一直都很关心代码工具调用和结构化输出，这你们也知道，所以那边任何关于指令的更新都是好事。大家还对这样一个概念很感兴趣：显然把指令和用户查询同时放在上下文的开头和结尾更好，也就是在顶部和底部各放一份，这比只放顶部好，也比只放底部好得多。呃，这同样来自 prompt guide，所以我不确定你们对此有多了解。是的。我觉得这部分纯粹是经验性的。我们在评估模型时三种方式都试了，有这种冗余肯定是最好的。不过，把指令放在开头，模型在处理时就能将其纳入考量。是的。我觉得很多人会认为这和 prompt caching 相冲突，因为显然你会想把经常变化的内容放在底部。基本上，这能在 post-training 中解决吗？比如我们能不能直接告诉模型只在底部接收指令或用户查询，因为我们想优化 prompt caching。等我们弄明白了就会这么做。我是说，这看起来是可行的。嗯，这看起来像是 post-training 层面的事。我、我不知道，也许我对 post-training 的理解有误。实际上，我认为把内容放在 prompt 开头，你仍然可以享受到 prompt caching。比如，如果你放了一个很大的 needle in a haystack 式 prompt，而每次数据都变化，比如这些用户级别的数据，你仍然可以通过不同方式把 prompt 放在开头并获得大量缓存命中。这主要取决于你的使用场景。是的。太好了。嗯，还有一件事我注意到了，我知道 Sean 你也记了这点。就是关于 chain of thought 和推理，以及人们应该如何看待这个模型与 reasoning model 的区别？嗯，你觉得呢？我是说，我是不是该直接用 4.1 并 prompt 它做 chain of thought？是不是该用 o1 制定计划，然后用 4.1 执行计划？人们应该怎么看待可组合性？这是个好问题。我们发现 4.1 在收到提示时，做规划和在 CoT 中逐步思考的能力比之前那些 non-reasoning model 强多了。但我们的 reasoning model 旨在制定更连贯的计划，并能在更长的时间跨度上进行推理，这是这些 non-reasoning model 比不了的。这一点在智能基准测试中有所体现。比如 AIME、GPQA 之类的，你会看到 reasoning model 表现好得多。所以总的来说，我觉得你真正想问的是：我是个开发者，我该用哪个模型？我觉得答案永远是：能完成你任务的最快的那个模型，对吧？所以也许你可以先拿 4.1 作为起点来 prompt。如果它表现很好，那就可以降到 4.1 mini 来降低延迟，甚至用 nano。反之，如果 4.1 有点吃力，可能需要更连贯的、跨越更长时段的推理，那就可以升级到 reasoning model。有什么快速的方法掌握这些启发式规则吗？我知道很多人做法是：用 o1 做规划，然后把这个计划放到 Cursor 里，让它应用到代码库上。听起来可能并没有什么固定规则来决定什么时候用哪种，完全是任务导向的。是的，我觉得我们都在摸索如何最好地组合使用这些模型。所以我确实认为，用 reasoning model 做规划，再用更具针对性的模型执行，这绝对是一种好的架构。嗯，好的。如果这边没什么其他问题了，我想深入聊聊代码能力，这是我们非常强调的一点。它表现非常好，在 SWE-bench 上比 o1 还强。这在意料之中吗？呃，并不完全是。是啊，我是说，这背后是怎么回事？还有一个更新的基准叫 SWE-Lancer，会给任务标上金钱价值。基本上，大家该怎么理解这里发生的事？它是一个更好的代码基础模型，还只是一个 coding agent 模型？而且我觉得还有一个问题：如果我不是在搞代码场景，代码能力对我有多重要？是的。首先我想说，我们的目标就是做一个在各种场景下——不管是终端、编辑器还是其他地方——都很擅长写代码的模型。所以我们把它拆解成涵盖的各种问题。比如开发者希望模型生成更好的 diff，或者希望模型正确探索代码库，或者希望生成能编译的代码，或者希望生成测试代码，所以我们的方法大概是教会模型所有这些不同方面。嗯，有很多工作流最终都汇聚到了 GPT-4.1 上。是的，我觉得 post-training 全方位大幅改进，让它成了更好的编程模型。是的，我觉得编程也有不同类型，对吧？比如我很感兴趣地观察到，呃，我在这把图表调出来，因为我总喜欢给大家看可视化数据。你们在 SWE-bench 上是 55 分，o1 大概是 41 分，但然后在……哦，我想我没放其他的，但是 Aider……它的表现就没那么……呃……没达到 o1 的水平。所以我很难直觉地判断什么时候……编程到底有哪些不同要素？我猜有单文件编辑，不管是 diff 还是整文件重写，然后有整个项目的编辑。这种划分合理吗？还有更多维度吗？是的，这是一种思考角度。基本上，GPT-4.1 的优势在于它能探索、遍历整个 repo？它在这方面训练得特别好。而，你知道，如果只是拿到一些代码然后做修改，reasoning model 可能表现更好，因为它能对整个文件进行推理。所以这是一种很好的思考方式。是的，有道理。那对于更小的模型，你们怎么看？更小的模型……基本上我是不是写代码只用 4.1 就行，其他的都不用管了？所以你可能想用更小的模型，比如你的 IDE 里需要自动补全功能的时候。或者如果你需要极快的速度，比如你在做一个 text-to-SQL 的功能，你可能希望第一版结果能瞬间生成。所以你能看到 4.1 mini 实际上比 4o mini 好不少，而且离旧的 4o 也不远。所以我认为这个模型会在很多编程细分场景中找到用武之地。还有，我知道这可能不方便说，但今天有个 AI CFO 谈 agentics 的片段好像正在病毒式传播。看起来每个实验室都在大力投入编程领域。所以我只是好奇，关于大家该如何看待 OpenAI 在编程方面的布局，你们能分享些什么吗？显然，现在你们还没有像 Claude Code 那样的东西。嗯，你们没提到任何与编程相关的内容，而且我觉得今天 Windsurf 的合作——他们接下来几周免费提供 4.1——可能算是 OpenAI 在直播里的一种背书吧。不过我知道这可能不是 PR 团队会乐意回答的问题，但我很好奇你们有没有什么看法和想法。我想说的就是：敬请期待。编程对我们的用户来说是一个非常重要的应用场景，这也是为什么我们在 4.1 上重点投入了很多。而且我们在内部也很喜欢用自己的产品，所以出于一点“私心”，做好 4.1 能让我们公司自身运转得更快，而这正是这款模型的真正重点所在。你们会追踪内部有多少比例代码是由 4.1 写的吗？我们确实有一些这类指标。我一时想不起来具体数字，但我刚才还在和团队里一位研究员聊天，他周末在做一个项目，他说 GPT-4.1 帮他在一个超大的 PR 里完成了 50 个 commit 中的 49 个。听到这个我们挺开心的，我也很期待用上它。太棒了。我觉得编程是一个超级令人兴奋的应用场景，而且 OpenAI 一向非常以开发者为先，这一点你也知道，Michelle。所以很高兴看到这种融合。另外，我觉得最后一块我特别关注的能力是视觉，或者说广义上的多模态。它现在好多了。我非常喜欢 MathVista 和 ChartQA 这类细分基准测试。关于视觉方面，你们有没有什么想补充的、但可能没放进博客文章里的细节？有的。我想说的一点是，其实 4.1 mini 在这方面非常令人兴奋。正如我们之前聊到的，它采用了不同的预训练基础模型，我觉得这在一些视觉评测中体现得特别明显。没错，我们谈到过编程、指令遵循、长上下文，这些很多都得益于 post-training，但特别是多模态这块——基本上你看到的所有提升都来自于预训练。所以要给预训练团队点赞，他们在感知和多模态方面做了不可思议的工作。完全同意。其实我们内部探索了一段时间，我很好奇你们怎么看：在我所谓的“屏幕视觉”和“具身视觉”之间，是不是存在明显的分野？比如，你们是否在针对 computer use 训练电脑截图，或者图表、PDF 上的内容——这些都和屏幕视觉很类似；而另一方面则是真实世界的照片，更偏向具身视觉，机器人可能会用到。人们对此争论不休。我很好奇趋势在哪，或者你们的侧重点是什么。我觉得……首先，我认为 4.1 在这两方面都更好了。不管它实际是怎么训练的，我觉得具体该用哪一种，我可能会比较听从预训练团队的意见。我们两种都在用，而且各项评测结果都有提升。太棒了。我觉得人们肯定也应该去探索更多具身视觉的东西，因为基准测试往往更聚焦在屏幕视觉那些更容易打分的对话评测上。没错，正是如此。这些肯定是被看得最多的指标。我觉得挺有意思的一点是，无论是 4.1 mini 还是 nano，我们都遇到了一些奇怪的内部分析结果。后来发现，原来是因为新的视觉能力让它们能读出背景里的指示牌之类的东西，而这实际上影响到了我们某些结果的有效性。所以随着模型能力提升，我们反而遇到了不同的评测问题。
4.1 有图像生成功能吗？还是说视觉是完全不同的部分？在某种程度上，视觉是 image to text，反过来是 image gen。是这么简单的划分，还是另有门道？并不是，目前还没有 4.1 image gen。好吧，但这个功能非常火爆，简直是在烧你们的 GPU。我是说说到 GPU，对吧？你知道，这次弃用 4.5、把用户迁移到 4.1，部分原因就是要回收 GPU。Shuki 和 Kevin Wild 都提到过这一点。但你们接下来三个月要同时跑所有这些模型，我不知道你们怎么回收 GPU，说不定用量还会涨得更多。对，我觉得大家会收到弃用通知，然后开始迁移。随着开发者逐渐少用旧模型，我们就能回收一部分算力，但你说得对，这需要时间。这里的权衡其实是我们对开发者的承诺：只要 API 里有的东西，我们就不会不给出足够通知就下架。要有通知期，所以这个取舍对我们来说是正确的。好的，太棒了。还有几个小公告：fine-tuning 在发布第一天就上线了，我觉得这对 OpenAI 来说挺新鲜的，通常你们得等一两个月才开放。第一天先上 4.1 和 mini，nano 和后续模型会跟上。关于 fine-tuning 有什么特别想说的吗？我的意思是，fine-tuning 作为通用方法一直都适用，但你们能讲讲有什么成果吗？首先，要向 fine-tuning 团队致敬，他们非常努力才让它在发布首日就上线。另外我想说，我觉得大家都忽视了 preference fine-tuning，我想这是我们产品的叫法。SFT 大家都比较熟悉，是我们最原始的 fine-tuning。而这种 preference fine-tuning 在引导特定风格上非常有用，所以我觉得用的人还不够多。那不是只针对 reasoning model 的吗？还是说所有模型都能用？不，reinforcement fine-tuning 才是只针对 reasoning model 的，对吧？preference 提供的是成对数据。对，没错。而且我以为它还在 alpha 阶段，所以我才没去研究。我以为……RFT 应该还在 alpha 吧。好吧，看来我们刚才澄清了不少混淆。对，我六月份要再办一场大会，到时候我们可能会做一个工作坊，专门讲所有 fine-tuning 选项，应该能澄清很多事情。这很好。好的，新模型。我知道很多还不能多谈。你们 reasoning 团队的 Noam Brown 刚说 reasoning model 应该很快会有后续。我们能透露点什么吗？听起来问他可能更合适，不过敬请期待吧。但 4.1 是接下来一切的良好基础，对吧？对。我们的模型不一定都是相互叠加构建的，但我们认为 4.1 对开发者来说是一款非常出色的独立产品。而且我们也觉得 reasoning model 是工具箱里很好用的工具。没错。更广义地说，我一直想探索非推理模型和推理模型之间的关系，还有我们怎么融合它们。会做路由吗？或者类似的东西。显然你们有很多秘方。酷。然后我觉得还有一件很多人在呼吁和询问的事，就是那个 creative writing model。它最终会见天日吗？我们正在努力把这些改进更广泛地整合到模型里，不会单独发布。大家很喜欢 4. 的……
5 的特点是幽默感、绿字和细腻之处。嗯，所以我们听到了这些反馈，而且我知道，是的，有很多人正在为此努力，试图将其融入我们的下一代模型中。太好了。Allesio，还有别的吗？嗯，没有了，这次聊得很棒。对开发者社区有什么期望吗？有没有什么事情你希望他们去尝试，但现在可能还没人做的？或者你希望他们为你构建些什么，使用这些新的 API？我觉得首先，请给我们反馈。看看那些正在使用我们模型的不同合作伙伴和客户，并获得他们这种整理好的反馈，真的非常有用。这让我们能更快地迭代。沿着这个思路，选择加入数据共享。这能帮助我们为你把模型做得更好。而一个有点被忽视的方式就是 eval 产品。你可以上传一个 eval，这样如果我们也能使用这个 eval，我们就会为你支付推理成本。这只是另一种很好的方式，我们会用这些 eval 来确保我们的模型能随着时间的推移为人们带来持续提升。是的，我认为这个 eval 的活动是永久性的。目前没有公布结束日期，但 API 中的选择加入至少会持续到 4 月 30 日。嗯，我觉得很多人还不知道这件事。我们可能会想要延长这个期限，这样人们就能做更多。好提醒。我会全部向团队反映的。是的。太好了。嗯，我想我最后一个问题是关于定价的。 uh，我觉得定价，你知道，总体上基本比 40 便宜。呃，但也不是便宜很多，但就是更便宜一些。而且你们还首次推出了这种 blended pricing 的概念，至少我是第一次见，不过也许它已经存在一段时间了，因为你们有 caching 之类的功能。嗯，一般来说，当我们考虑工作负载时，应该思考什么样的 cache 与非 cache 比例？有没有什么经验法则？所以先澄清一点，GPT 4.1 mini 并不比 GPT40 便宜。所以这并不是所有模型都全面降价，不过 4.1 mini 确实比 4.1 便宜。嗯，另外不确定这是否被广泛报道了，但在这些模型上，我们将 prompt caching 折扣从 50% 提高到了 75%。是的，我看到了。所以这在决定构建什么类型的应用时，是一个很重要的考量因素。嗯，然后你的问题是关于什么的，对了，blended pricing，对吧？就像，我觉得存在一个跨模型、甚至跨厂商的价格可比性问题，因为就像，你知道的，有些人的上下文与输出比例是三比一，然后其中一部分还被 cache 了。嗯，出于私心，我会做一张图表，把所有模型厂商和你们所有的价格都画上去，我相信你们也看过。但我不知道该往里面填什么数字。那么人们在现实中观察到的是什么？中位数，你知道的，caching 比率是多少？我觉得我们没法立刻给出这个数字。Blended pricing 更多是为了让比较更容易。比如你可以直接说 GPT4.1 比 GPT4 便宜 25%。对。你想要一个数字。是的。是的。是的。没有这个数字。好吧，我们都得自己去琢磨了。呃，但非常感谢。这次访谈太棒了。感谢你们的所有工作。我觉得大家都很兴奋，会开始动手测试，给你们反馈。嗯，我相信我们下次还会再来的。可能是关于 reasoner 的那次。太好了。谢谢你们。谢谢。