从 API 到 AGI：Structured Outputs 与 OpenAI API 平台（Michelle Pokrass）

Alessio有意思。那系统稳定性呢？那更像是……我不知道，可靠性问题？SRE 那类？

Michelle很大程度上是的。归根结底都是数据库的问题。无论我在 Coinbase、Clubhouse 还是 OpenAI 工作，Postgres 都是常年存在的挑战。你在一份工作上学到的东西可以带到下一份，因为你总是在凌晨三点调试一个长时间运行的 Postgres query。

不知道为什么，这些技能确实让我受益匪浅。你觉得为什么这类能力没受到足够的重视？显然，Postgres 这个开源项目并不是以千兆规模为目标，但你总会想到有人出来说“嘿，我们要做那种……”

对，我觉得这大概就是 PlanetScale 正在做的事，不过他们不是在 Postgres 上，我觉得是在 MySQL 上。但他们的愿景是零停机迁移，那确实是个很大的痛点。我不知道为什么没人在 Postgres 上做这个，不过我觉得那会挺酷的。他们的连接池，比如 PG Bouncer，已经够用了吧，我也不确定。

是啊，但即使我在到处都用 PG Bouncer，它还是有很多问题。像你说的那种规模，不是很多人能见识到的。确实，每家公司，或者说每家成功的公司，最终都会发展到 Postgres 扛不住的地步，然后就会迁移到某种 NoSQL 数据库。那个过程我见证过很多次了，MongoDB、Redis 之类的。

我们现在在 Azure 上，所以用的是 Cosmos DB。对了，在 Clubhouse 的时候，我特别喜欢 DynamoDB，这话听起来很极客，但这是我需要把东西扩展到极限时会用的数据库。

DynamoDB。我在 AWS 短暂工作过，学到一个道理：它就像是网络世界的内存寄存器。如果你把它当作物理内存来用，就能用得很好；但如果你把它当作真正的数据库来用，就会遇到各种问题。从 Postgres 转到 Dynamo 的时候，你必须彻底改变思维方式。不过我觉得这是一种很好的思维转变，能让你以更具备可扩展性的方式来设计系统。

对，如果有人需要用 DynamoDB，我可以推荐一本书。不过我们今天不是来聊 AWS 的，是来聊 OpenAI 的。你在 ChatGPT 之前就加入了 OpenAI，我当时也有机会加入，但我没加入。你当时的洞察是什么？

我觉得很多人加入 OpenAI 是因为某款让他们非常兴奋的产品。对大多数人来说是 ChatGPT，但对我来说，我是 GitHub Copilot 的每日用户。它的质量让我非常震惊。我还记得第一次在 Hacker News 上看到它时的反应：哇，这太疯狂了，这会改变一切。之后我每天都用。即便现在，如果我在没信号的地方写代码，没有 Copilot 的帮助，效率简直差十倍。所以我对那款产品非常兴奋，觉得也许 AI 的时代到了。我在大学时也做过一些 AI 相关的东西，觉得那些技能可以迁移。后来通过介绍认识了团队，聊过的人都挺喜欢，所以觉得加入会很酷。

我为什么没加入？我当时想，DALL-E 就是全部了吗？我们当时去了 DALL-E 的发布会，我记得你在跟 Lenny 聊，Lenny 那时候在 OpenAI。你说——不用细说——但这是我人生最大的遗憾之一。不过我当时想，好吧，我能生成图片，但我不确定这是不是值得全身心投入的东西。显然你当时的愿景比我更宏大。

确实很酷。我记得第一次跟家人展示时说，我要加入这家公司，这是他们做的东西之一。这真的很能帮助家人理解。而我至今还没搞明白怎么跟我父母解释加密货币是什么。我妈有段时间还以为我在 Bitcoin 工作。所以能告诉家人你真正在做什么，而且他们能亲眼看到，这感觉完全不一样。

对，而且他们自己也都能用上。所以你在那里的时候，一开始就在 API platform 吗？ChatGPT 发布那会儿你也在？

对，不过 API platform 这个说法对当时的情况来说有点太宏大了，其实就那么几个人在做 API。

对，那时候还是封闭测试吧？连 GPT-3 都不是所有人能用，准入模式很不一样，更像是分级推出。Applied 团队大概就三四十人，可能更接近三十人。最多也就五六个人在做 API。所以后来我们扩张了很多，现在是不是六七十人了？

不，Applied 现在比那大得多。Applied 团队现在比我刚加入时整个公司的人都多。我们确实扩张了很多，要做的东西太多了，所以需要人手。我已经有点跟不上最新数字了。

对。ChatGPT 发布的时候，有没有那种全员上阵的故事？几个月前我和 Evan Morawa 吃过午饭，听起来那段时间挺有意思的，要搭建 API，还要应对那么多人涌上来用网页版。你们内部是怎么排优先级的？非 GPU 负载的扩展和 PG Bouncer 这类东西之间，你是怎么取舍的？

其实挺出人意料的，ChatGPT 刚发布的时候，我们遇到很多 Postgres 的问题。因为 ChatGPT 的账号和 API 的账号是绑定的，所以当时你登录 ChatGPT 基本上就是在创建一个开发者账号，毕竟那时候我们只有这套系统，它低调地作为一个研究预览版存在。我记得当时花了大量精力去扩展我们的授权系统，而且那部分经常挂掉。另外就是 GPU，你知道，我以前从没在那种“不能随意扩容”的地方工作过。

以前 everywhere，计算资源好像是免费的，你只需要自动扩容，然后就再也不用管了。但在这里，我们每天都要做艰难的决策，讨论资源应该往这儿投还是往那儿投，而且必须有原则。所以这是一个真正的思维转变。对了，structured outputs 上线了，恭喜你。你还写了那篇博客文章，写得真的很好。我很喜欢里面举的所有例子，真的把整个来龙去脉讲清楚了。

对，从头到尾给我们讲讲这个故事吧。

好，我觉得我们得把时间倒回到去年的 Dev Day。就是在去年 Dev Day，我们上线了 JSON mode，这是我们涉足这个领域的第一款产品。简单介绍一下，JSON mode 是我们 chat completions 和其他 API 里提供的一项功能，如果你选择启用，我们会约束模型的输出，使其符合 JSON 语法。所以你基本上总会得到一对花括号包裹的内容。这对很多人来说已经够用了，你可以在 prompt 里描述你想要的 schema，然后我们会约束它输出 JSON。

但它还没法完全满足需求，因为你不想让模型自己编造键名，或者返回不匹配的值。比如你想要一个枚举或数字，结果它给你返回字符串，这就很让人沮丧。所以我们在这个方向上思考了很久，而且大概过去一年里，每次跟客户聊天，他们基本上都在提这个需求。显然开发者非常需要这个功能，于是我们就开始动手做。这其实是工程和研究团队的紧密合作。光约束模型是不够的——我把那部分看作工程侧的做法，也就是每次生成时把可用 token 掩码到只符合 schema 的范围。

这么做确实可以强行让模型按你的要求输出，但效果不一定好。有时候开发者发现，在 JSON mode 下，模型会输出很长的空白字符，因为它在思考，而空白在 JSON 里是合法字符，但并不是用户想要的。这就是那种过于偏重工程的做法会导致的结果。而模型侧的做法是，同时训练模型去更好地理解你的意图。所以我们把两者结合起来了：我们专门训练了一个模型，它在遵循格式方面比过去的模型强很多；同时我们在 serving 层面也实现了 constrained decoding 的概念，并且能够 scale。

我觉得把这两者结合起来，才是这个功能真正酷的地方。

你刚才提到“以花括号开头”，大家可能会联想到 Claude API 里的 prefills。你怎么看 JSON mode、structured outputs 和 prefills 之间的关系？因为有些方案大致就是“以花括号开头，然后向模型要 JSON”；Instructor 则是“嘿，这是我用的数据 schema”。你怎么看待这些不同的做法？

我们把 structured outputs 设计成最容易使用的方式。在我们的 SDK 里，你只需要创建一个 Pydantic 对象或 Zod 对象，传进去，然后拿到一个对象回来。你完全不需要处理序列化，parse helper 都不用管。进和出都不需要处理序列化。所以我觉得这个功能面向的开发者是：我需要把这个接入我的系统，我需要精确的函数调用，我不想处理任何解析。structured outputs 就是为这个场景量身定制的。而如果你想让模型更有创造性，让它帮你生成你自己都还没想好的 JSON schema，那 JSON mode 更适合那个场景。不过我预计大多数开发者最终都会想要升级到 structured outputs。

你刚才把几个词混着用了，它们其实是同一个东西：Tool、function calling 和 structured outputs。我们之前在这档播客里也有过争论或讨论，它们到底是不是一回事？语义上还是有些差别的。它们确实是。因为 function calling API 先出来，然后是 JSON mode，我们以前经常滥用 function calling 来当 JSON mode 用，对吧？你觉得我们应该把它们视为同义词吗？

不。

好的，请解释一下。

对，而且顺便说一句，还有 tool calling。历史是这样的：我们最开始推出的是 function calling，它的出发点是想看看如果给模型一些工具权限，它会怎么做。当时我们内部已经有了后来 code interpreter 的原型，我们觉得太酷了，想把它做成 API，但还没准备好给所有人托管 code interpreter，所以就先把这个底层能力暴露出来，看看大家会怎么用。但即便到了现在，function calling 和 structured outputs 之间还是有很大区别的。

你应该在真正有函数想让模型调用的时候才用 function calling。比如你想让模型查询数据库，或者发邮件，或者为某个实际操作生成参数。模型在微调时就被训练成把 function calling 当作真正的工具调用来用，并获取工具的返回结果。而新的 response format 只是让模型以结构化的方式回应用户，这两者是截然不同的：回应用户 vs “我要去发封邮件”。很多人以前会用 function calling 的 hack 方式来获取他们想要的 response format，所以我们才推出了这种新的 response format，让你能直接得到想要的结果。

而且这样你能更多地让模型自由发挥，让它以更接近自然对话的方式回应用户，而不是那种纯程序化的 tool calling。不知道我说明白没有。

你们有没有在 SDK 里做什么功能来真正把这个 loop 跑通？因为现在的流程是，模型返回要调用的函数，然后你得自己去执行，接着还得伪造一条消息塞回去，才能继续对话。他们好像在 beta 里有个 runs 功能？

对，我们在 Node SDK 里已经有了 beta 版本，Python 版也在路上了。所以我之前不知道，毕竟我是写 Node 的。不过基本上，你写一个函数，加个装饰器，然后有个 run tools 方法，它会帮你把整个循环跑完，挺酷的。

我在 Node SDK 里看到这个的时候，不确定它是不是就在同一台机器上直接运行了。如果是的话，你可能并不希望这样吧？

对，我觉得如果你是在快速原型开发，随便搭点东西玩玩，那直接写个函数加个装饰器就太方便了。但你有完全的灵活性，可以按自己的方式来。比如你肯定不想把它放在 Web 请求的关键路径上，虽然肯定会有人这么做。这基本上是最快上手的方式。但如果你想把这个函数放到异步任务队列里去执行，那就不适合用这个了。

那在先前的探索上，像 Instructor、Outlines、JSONformer 这些项目，你们研究了什么？从它们那里借鉴或学到了什么？

对，这个领域有很多不同的做法。有一种更像是“填空”风格的采样，你预先填好键，然后让模型只采样值。这里头的流派很多。我们没有直接照搬其中任何一种，但我们真的很欣赏社区里的做法，以及那些优秀的开发者体验，这是我们最大的灵感来源。

还有个问题关于 constrained grammar。我最早是在 llama.cpp 里看到这个功能的，它似乎是目前在学术上最为开放和宽松的项目。如果你愿意的话可以解释一下。他们用的是 Backus-Naur form，这东西你大概只有在大学学编程语言和编译器的时候才会接触到。我不知道你们底层有没有用这个，或者你们有没有调研过？

我们并没有用其他现成的方案，而是从零开始搭建了解决方案，以满足我们的特定需求。但我觉得外面已经有很多很酷的东西，允许你提供自己的 grammar。目前我们只支持 JSON schema 及其某种方言。不过未来如果能让你更广泛地提供自定义 grammar，应该会是个很酷的扩展，而且也许比 JSON 更节省 token。这里面机会很多。

你前面还提到，为了优化 function calling 而专门训练了模型。内部关于资源分配是怎么讨论的？比如有人会说“我们得把 JSON mode 做得更好”，然后另一些人会说“你们就不能在 API platform 层面解决吗，别碰模型不行吗？”API 团队和模型团队之间的协作真的很紧密吗？

其实我就在 API models 团队工作。我们好像还没聊过我具体在 API 部门做什么。你觉得你是做什么的？我是 API 的技术负责人，同时也在 API models 团队。这个团队的目标是为 API 打造最好的模型。通常常见的模式是研究部门训好模型，然后 API 这边直接上线。但这样做会错过很多东西，尤其是开发者的反馈，还有一些不那么显而易见的细节。我们的做法是，收集大量开发者反馈，然后针对性地改进模型。所以我们团队也做模型训练，和后训练团队紧密合作。像 structured outputs 这个项目，就是好几个团队合作的成果，包括 Safety Systems，大家一起做出了这个很棒的模型，让它能很好地做 structured outputs。

说到 Safety Systems，你们有个 refusal field。想聊聊这个吗？这似乎挺有意思的。

对，这个挺有意思的。你可以想象一下，既然你约束模型必须遵循某个 schema，那么如果用户提供的 schema 本身带有风险，或者让模型按这个 schema 输出会有害怎么办？我们希望保留模型拒绝的能力，当某些内容不符合我们的政策或有害时，它可以说不。所以我们需要给模型一个在存在 schema 的情况下依然能拒绝的通道。但另一方面，如果你是开发者，定义了 schema，结果返回的东西不匹配，你会觉得“这功能坏了”。

所以我们想给开发者一个非常清晰的方式来编程处理这种情况：如果返回在 content 里，你就知道它是合法的、可解析的 JSON；如果返回在 refusal field 里，你就可以用另一种方式展示给用户，写起代码来也更方便。这背后有几个目标，但主要是想让模型保持拒绝的能力，同时给开发者提供很好的使用体验。

那为什么不用 error code 的形式返回呢？反正我们都要处理错误码。

对，我们在 API 设计上纠结了很久，这是我们一贯的作风。有几个理由让我们不把它做成 error code。你可以想象把它做成 4xx 错误码，但开发者是在为 token 付费的，而在 4xx 的情况下还收费，这有点不太对劲。而且出错本来就要付费。4xx 是客户端错误，这也不完全对；它也不是 5xx，因为这不是我们的错。你知道，这是 API 和模型设计方式决定的。我觉得 HTTP 规范在很多方面对 AI 来说有点局限。有些东西介于你的错和我的错之间，更像是“模型的错”，但根本没有对应的错误码。所以我们真的得在这个范式上自己发明很多东西。

那弄个 6xx 啊。对，这也是一种选择。其实我们还考虑过一些很生僻的错误码。328 是我最喜欢的。还有那个茶壶错误码（teapot）。我们还在琢磨这些事。不过我觉得确实有一些场景，比如有时候模型会生成一些基于我们内部语言来说无效的 token，这时候算是个错误。但这种情况返回 500 也可以，我们目前就是这么做的，但它表达得不够准确。所以这就是 Web 2.0 遗留的一些问题吧。

0 这个状态码目前不太适用于 AI。如果必须要在规范里做一项改动，你会向 HTTP 委员会提出的头号建议是什么，来重塑世界？

是的，这确实是个方向。我认为我们需要一个模型错误码的范围，可以有多种不同的模型错误。比如拒绝就是一种模型错误——601，模型拒绝。

对，就像我们之前提到的，chat completions 使用的是 ChatML 格式。所以当模型没有遵循 ChatML 时，这就是一个错误。我们正在努力减少这类错误，但大概可以算……我不知道，602 吧。

其实很多人已经不知道 ChatML 是什么了。

是的，因为它当初由 OpenAI 短暂推出，后来某种程度上被弃用了。所有在底层实现这个的人都知道，但可能 API 用户并不了解。

基本上，API 最初只有一个端点，就是 completions 端点。在那个端点里，你输入文本，得到文本输出，可以通过特定方式提示。后来我们发布了 ChatGPT，并决定也把它放到 API 里，这就成了 chat completions API。这个 API 不再只是接收字符串输入并产生输出，它实际上接收消息并产生消息，因此你可以区分助手消息和用户消息，这带来了各种各样的行为。底层使用的格式就叫 ChatML。

有时，因为模型根据你的操作完全偏离了分布，也许 temperature 设得非常高，那它就无法遵循 ChatML。

是的，我之前不知道那里也会产生错误，也许是我问的问题还不够有挑战性。这种情况很少见，我们正在努力降低它的发生率。但实际上，这是 structured outputs 带来的一个副作用——我们现在已经消除了一类错误。我们没能在博客里提到这一点，只是因为篇幅不够，但这就是我们在这里要做的事情。

对，模型过去偶尔会选一个无效的 recipient，这就会导致错误。但现在我们能够以更有效的方式将其约束到 ChatML，这也减少了一类错误。

recipient 是指……系统定义了一些角色，比如 user、assistant、system。所以这里的 recipient 指的是选择正确的工具。哦，所以以前模型可能会 hallucinate 出一个工具，但现在当你使用 structured outputs 时，它不会这样了。

你们会和其他模型开发者合作，试图搞清楚这类错误吗？比如如何展示这些错误，因为很多人会尝试使用不同的模型。

是的，有这种合作吗？

嗯，不太多。我们主要专注于为开发者打造最好的 API。很多研究和工程工作，我觉得是和 evals 结合在一起的。你们发布了一些 evals，我记得 GORILLA 是其中之一。你怎么看目前 function calling 和 structured output 的 evals 现状？

是的，我们其实和 BFCL 有一点合作，我想就是那个 function calling 排行榜。向那个团队致敬，那些 evals 很棒，我们内部也在用。我们还针对一些评分有误的地方反馈过意见，所以我们正在合作改进它们。总的来说，我觉得 evals 可能是 AI 中最难的部分。我们和开发者交流时发现，evals 很难上手，建立一个稳健的 pipeline 非常困难。而且你不希望 evals 只有 80% 的成功率，因为你知道情况会大幅改善。要设计出合适的 eval 非常难，你基本上想覆盖难度曲线上所有部分。

我发现很多这类 evals 基本上已经饱和了。比如在 BFCL 上，所有模型都接近满分，错误更多只是默认行为上的差异。我觉得排行榜上大多数模型通过不同的 prompting 都能拿到 100%，所以更多是在区分不同的默认设置。因此总的来说，我们缺少 evals。你知道，我们内部在这上面投入很多，但这很难。

除了 BFCL 之外，你会推荐其他的吗？只是供那些想探索这个领域的人参考。

SWE-bench 其实是一个非常有趣的 eval。如果还有人不知道，它基本上就是给模型一个 GitHub issue 和一个仓库，看它处理这个 issue 的能力如何，我觉得这超酷。对模型来说，这更像是一种 integration test。

这有点不公平吧？

你说的不公平是什么意思？

因为通常作为人类，你有更多机会去问这个问题本该怎么做，而你给模型的信息太少了，让它去完成这个工作很难。但没错，SWE-bench 考察的是你能多好地遵循 diff 格式、如何跨文件搜索、以及写代码的能力。所以我对这类 evals 非常兴奋，因为通过率很低，还有很大的提升空间。

是的，而且这针对的是一项非常酷的能力。我还看到过其他 function calling 的 evals，可能也是 BFCL，它们评估不同类型的 function calling。人们最关注的似乎是 parallel function calling，不知道为什么，虽然我个人并不觉得这对我来说有那么重要。我想你确认过你们目前还不支持这个，对吧？为什么这很难？能多说说吗？

是的，我们在去年的 Dev Day 也推出了 parallel function calling。这算是 function calling 的进化。V1 版本你只能得到一个函数调用返回，V2 版本可以同时返回多个，从而节省延迟。我们的 API 里有这个功能，所有模型都支持，或者说所有较新的模型都支持。但目前我们不支持在 structured outputs 中使用它，这背后其实有一个非常有趣的权衡。

所以当你调用我们的 API 并使用新 schema 进行 structured outputs 时，我们需要构建一个用于后续快速采样的 artifact。但当你做 parallel function calling 时，我们遵循的 schema 不再只是单个函数的 schema，而是基于多个函数组合而成的 combined schema。如果我们每次传入函数列表时都做同样的事、构建索引，一旦你更改列表，就会产生更多延迟。我们认为这对开发者来说会非常反直觉，而且难以推理。所以我们决定等一等，直到能支持无额外延迟的解决方案，而不是让开发者感到困惑。

提到延迟，人们发现的是，第一个 token、第一次请求的成本和延迟都会增加。

是的，第一次请求。

这是个问题吗？以后会降低吗？还是说解析 JSON 的开销根本就是无法逾越的？

这绝对不是无法逾越的，而且我相信随着时间推移一定会降低。我们采取的策略就是尽早发布、频繁发布。如果你发现没有什么需要修复的地方，那可能说明你发布得太晚了。所以我认为延迟会逐步降低。对大多数开发者来说，这不是大问题，因为你在测试集成、开发阶段发送一些请求，到了生产环境就快了，所以对大多数人来说还行。

我们探索过的另一种设计方向是预先注册 schema，比如一个完全不同的端点，然后传入一个 schema ID。但我们觉得这样开销太大，还要维护另一个端点，对开发者来说也更复杂。而且我们认为这种延迟会随时间降低，所以把它保留在 chat completions 里是合理的。

我的意思是，假设未来推出缓存功能，那基本上就是这件事的超集了。我觉得这个领域探索得还不够深入，目前见过两个版本，但也许有办法让开发者负担更少。不过我们还没有承诺任何东西，只是在积极探索让一切更便宜的机会。

AI agents 是否就只是把 structured outputs 和 function calling 并排堆砌在一起？你怎么看？有人认为模型应该包办一切，这条线该怎么划？因为你们并不把这些叫做 agent API，但如果我是一个想融 C 轮的创业公司，我可能会做个 function calling 然后就说这是 agent API。你怎么看待其中的区别，以及人们如何在此基础上构建 agentic 系统？

是的，这个问题问得好。我们想要构建 structured outputs 的原因之一，就是让 agentic 应用真正能够工作。现在这非常难，如果某个环节只有 95% 的可靠性，而你把一堆调用链串在一起，放大错误率后，你的应用就没法用了。所以从 95% 提升到 100% 是非常令人兴奋的。我在 API 团队工作，做 function calling 和 structured outputs，所以观点可能很偏颇，但我认为这些基础模块会被用来把这项技术推广得很远。它们是你将自然语言连接起来、把用户意图转化为应用操作的方式。所以老实说，没有它们就无法构建。你需要 function calls 能正常工作，而我们就是想让它变得更简单。

是的。你认为 Assistants API 这类东西在人们构建 agents 时会变得更重要吗？

我觉得大多数人可能还是直接用 messages 和 completion。所以我说 Assistants API 其实是在几个方向上的押注。一个方向是 hosted tools，我们提供了 file search 工具和 code interpreter。另一个方向是 statefulness，这是我们第一个有状态的 API，它会存储 threads，你可以稍后获取。我觉得 hosted tools 方面非常成功，人们很喜欢我们的 file search 工具，不用自己搭建 RAG pipeline 省了很多时间。至于 stateful 这块，我们还在迭代形态，让它尽可能好用。目前你需要调用几个端点才能开始一个 run，我们希望让它随着时间变得更直观、更简单。

有一点我很好奇：当你增加更多 structured output 能力时，有没有注意到它在某些其他方面变差了，就是那种你完全没想到会相关的东西？

是的，这是个好问题。模型是非常不稳定的，RL 也很难预测，所以每个模型在某些方面会提升，在其他方面可能持平。要增加一项能力而其他方面完全没有 trade-off，这是非常罕见的。我一时想不出具体例子，但我会说每个模型都有自己的特性。这就是为什么我们在 API 中提供不同日期的模型版本，让开发者自己选择最适合他们的。总体而言，我们努力在所有 evals 上持续改进，但它是随机的。

可以将 structured output 系统应用到旧模型上吗，比如 4O，或者 mini，或者之前的版本？

其实，新的 response format 只在两个模型上可用：4 和新的 4O。

所以旧的 4O 没有新的 response format。

对。不过对于 function calling，我们能够为所有支持 function calling 的模型启用它，因为这些模型已经训练过要遵循这些 schema。我们基本上只是不想把新的 response format 加到那些表现会很差的模型上，因为它们可能会一直输出无限空白——如果你完全不知道该怎么办，空白就是最可能出现的 token。

我只是想再提一下你们博客里的内容，就是那些使用场景，对吧？我想让人们知道，对，我们给你们讲清楚了：用这些从非结构化数据中提取结构化数据。顺便说一下，它也支持 Vision，对吧？这很酷。还有 Dynamic UI generation，我们来聊聊这个吧。我觉得 Gen UI 是人们非常感兴趣的领域。你们的第一个例子是什么？你是怎么发现它的？

是的，我只是觉得这是我们现在拥有的一个超酷能力。我们支持递归 schema，这让你能做非常酷的事情。你知道，每个 UI 都是一个有子节点的嵌套树，所以我觉得这太酷了。你可以用一个 schema 生成大量 UI。作为一个总是在前端 JavaScript 上挣扎的后端工程师，这对我来说太酷了。我们现在已经构建了一个系统，我可以得到任何我想要的前端，所以真的非常酷。

提取结构化数据方面，很多 AI 应用的现实是，你把它们接入企业业务，已有可用的东西，但想让它更好一点。而你在可靠性上的提升就在于，你永远不会再用错 enum 做分类了，它完全就是你定义的类型。所以我对这个非常兴奋。当然，实际值还是可能会 hallucinate，对吧？

所以我们来明确一下保证是什么：保证的是输出符合 schema，但 schema 本身可能太宽泛。因为 JSON schema 的类型系统无法表达我只想要 1 到 11 的范围，它可能给你 0，也可能给你 12。所以 JSON schema——这其实是个值得讨论的点——非常庞大，我们没能支持每一个角落，所以我们支持的是自己的一种方言，文档里有说明，我们在那里不得不做一些权衡。

默认情况下，如果你在 schema 里没有传入 additionalProperties，默认值是 true，这意味着你可能会得到其他你没列出来的键，这基本上和开发者想要的相反。你提供了键和值，就希望得到这些键和值。于是我们做了一个决定：是否要重新定义 additionalProperties 的默认值？那感觉很糟糕，因为这套 schema 规范在我们之前就存在了，这样做不好，最好和社区友好相处。所以我们要求你显式传入 false。我们的设计原则之一是非常明确，让开发者知道该期待什么。所以在这个问题上，我们决定虽然这样更难发现，但我们认为你应该传入这个值，这样我们对你的意图和我们的行为就能有非常清晰的定义。

还有一个类似的情况是关于 required。默认情况下 JSON schema 里的每个键都是可选的，但这不是开发者想要的。如果你传入了一堆键，结果有些没返回，你会很惊讶。所以我们做的权衡是让所有键都变成 required，让开发者自己明确写出来。

那有没有 require false？人们能关掉它吗？还是说必须全部返回？

开发者基本上……我们对此的建议是把你实际的键做成 union type。对，让它变成 int 和 null 的 union，这样就能实现同样的效果。

你还想深入聊聊其他例子吗，比如数学 Chain of Thought？

是的，你现在可以指定一个 Chain of Thought 字段，放在最终答案之前。这其实是提取最终答案的一种更有结构的方式。我们有一个例子，我记得我们放了一个数学辅导的 demo app，或者很快会推出。

我错过了。

哦，好吧。基本上这是一个数学辅导工具，你输入一个方程式，它可以一步步来，插入……这是你现在用 structured outputs 就能做到的事。以前开发者必须自己定义格式，然后写解析器去解析模型的输出，这很难。现在你只需要指定 steps，它是一个步骤数组，每一步都可以渲染，然后用户可以尝试，看是否符合，再继续。所以我觉得这打开了很多机会，对于任何你想把模型回应的不同部分分开处理的 UI，structured outputs 都非常有用。

我想起之前的问题了。我基本上就是在以一个用户的身份，一个你们产品的日常用户，来问你所有这些问题。一个是很多人不知道的技巧，我在 Twitter 上跟你提过，就是你们会尊重 JSON schema 的 description，对吧？你基本上可以把它当作字段的 prompt 来用。

完全正确。我猜这是官方认可的做法，人们应该这么做，对吧？

有件事我开始做了，但我不确定这是不是我的幻觉：我把属性名改成提示模型该做什么的内容。比如，我不会把属性名叫做 topics，而是写成 brainstorm a list of topics up to five 之类的作为属性名。我也可以把这个放在 description 里，但这样做会不会太过分了？

是的，我想说，AI 还处于非常早期的阶段，人们正在摸索最佳实践。我很喜欢从开发者那里学到他们发现的让某些东西生效的方法。总的来说，我认为有三四个地方可以放指令。你可以把指令放在 system message 里，我觉得这对判断何时调用函数很有帮助。比如说你在做客服系统，想让它验证用户的电话号码，你可以在 system message 里告诉模型：这是你应该调用这个函数的时机。然后在函数内部，我觉得 description 应该更多是关于如何调用函数。

很常见的情况是，有人定义了 date 为 string，但不告诉模型你想要年年月月日日，还是倒过来，而 description 就是说明这类事情的绝佳位置：该如何调用这个工具。然后有时候还会有你这种做法，就是用键名本身来表达你想要什么。有时人们会写 do not use，如果他们在某些情况下才不想用这个参数。我觉得这很有趣，你就是在摸索从模型那里得到想要结果的最佳方式。

好吧，所以我听到的意思是，你们没有官方推荐的做法？

嗯，官方推荐就是……你知道，在 system message 里说明如何调用模型，在函数 description 里说明如何调用函数，就是这样。

你们会对这类事情做 benchmark 吗？比如同样是 date，description 里写用 ISO 格式返回，或者你把键名叫做 date_in_iso_8601。我觉得 benchmark 不会深入到这个层面，但 AI 工程社区里大家做的很多工作都是：哦，实际上这样效果更好。但然后就没法验证了，对吧？比如甚至那个“我要给你 10 万美元小费”之类的，有人说有用，有人说没用。你们在构建这个的时候会关注这类东西吗？还是说模型反正会越来越好，何必浪费时间在这些小事上跑 evals？

是的，我想说的是，我们基本上会选择自己的战场。LLM 的可探索表面太大了，我们主要专注于提升所有人的基础能力。我觉得对于客户，我们合作过很多客户，开发他们自己的 evals 其实杠杆效应非常高，因为每当我们推出新模型，你就能快速升级，有信心地试验这些东西。所以我们希望让制作 evals 变得更简单，我觉得这对开发者普遍来说非常有帮助。

我来总结一下关于 structured outputs 的讨论。我立刻就实现了，我们用 structured outputs 做 AI 新闻。我之前用 Instructor，现在把它移除了，省了大概 20 行代码，但更重要的是，根据我的测量，API 成本降低了 55%，因为我们省掉了重试。

太好了，很高兴听到这个。

我觉得很多人不理解的是，你不能简单地加个 Instructor 或者 Outlines 就完事了。你可以这么做，但实际上你会花很多重试才能拿到想要的模型输出，而你们现在等于是把这套机制内建到模型里了。

是的，我觉得这种功能只有和 LLM 提供商深度集成时才能真正发挥作用。其实我身边有人，甚至我丈夫的公司，他在一家小创业公司，他们以为我们只是在重试。所以我必须澄清，我们不是重试，而是一遍过，这就是节省延迟和成本的方式。

太棒了。

还有其他幕后的事情吗？关于 structured outputs 的，我们接下来要聊其他模型了。

是的，我觉得就这些了。

看吧，这是个出色的产品，我觉得每个人都会用上它。现在人们可以试用了，完整的故事已经有了。所以路线图上是 parallel function calling，还有什么是你提到过的、很快会推出的？

很快了。我们还在考虑是否有意义暴露自定义文法，超越 JSON schema。

你们想从开发者那里听到什么信息？无论是自定义文法还是 structured outputs 的其他方面，你们还想了解更多什么？

你知道，我们总是对功能请求和哪里不好用感兴趣。但我真的很好奇，大家具体想要什么样的文法。我知道有人想要匹配编程语言，比如 Python，但我们的实现方式在表达能力上存在一些挑战。所以 yeah，就是大家想要的文法类别。

我有一个非常简单的需求：很多人试图用 GPT 做评判，对吧？这意味着他们要做评分系统，然后有 10 种不同的评分系统，什么李克特量表之类的。如果有一个官方认可的、用 structured outputs 做评分系统的方式，所有人都会用。

对对，这说得通。我们经常建议在分类任务中使用 log probs。与其采样——比如说有四个选项红、黄、蓝、绿——与其采样两个 token 得到 yellow，你可以直接用 ABCD，然后看它们的 log probs。这样每次采样固有的随机性就不会被纳入考量，你可以直接看哪个 token 最可能。我觉得这更像是一个校准问题：如果我让你从 1 到 10 打分，一个未经校准的模型可能总是选 7，就像人类会做的那样。所以能真正在 1 到 10 之间有良好的区分度，大概就是这个思路。

是的，而且就算用 structured outputs，我也不能只是说有一个 1 到 10 的评分字段，因为我得验证它，它可能给我 11。

绝对是。

那么模型选择呢？现在你们有很多模型。最开始的时候你们只有一个模型端点，我猜你们有……然后大多数人只用一个模型端点。今天你们有很多有竞争力的模型，我觉得我们快到 3. 的尾声了。

你一般怎么建议人们在任务和成本两方面进行实验和选型？你的通用 playbook 是什么？

我觉得大家应该从 GPT-4o mini 开始，那是我们最便宜的模型，也是一台很棒的主力机，适用于很多优秀用例。如果你发现性能不够，比如不够聪明，那我建议换成 GPT-4o。如果 GPT-4o 对你来说表现很好，那就太好了。最后还有一些非常前沿的高级用例，可能它还不够，这种情况下我推荐我们的微调 API。甚至只要 100 个样本就足够起步了，你真的可以获得想要的性能。

我们提前录制这期节目，不过你正在宣布一些其他微调相关的事情，大家应该关注。

是的，实际上明天我们要正式发布 GPT-4o 微调功能。GPT-4o mini 已经上线几周了，现在 GPT-4o 也即将全面开放。我们还会提供一段时间的免费训练额度，我觉得是到 9 月 23 日为止，每天提供 100 万免费训练 token。这个已经宣布过了对吧？哦，我是不是在说另一个？之前那是针对 GPT-4o mini 的，现在 GPT-4o 也享受同样政策。所以我们很期待看到大家会用它做什么。实际上上手比很多人想象的要容易得多，他们以为可能需要几万个样本，但哪怕 100 个高质量的，或者一千个，就足够起步了。

哦，我们可能会为此单独做一期播客，不过还没确定。

基本上，我觉得每次人们对微调的担忧在于，他们似乎被锁定在某一模型上了。而我认为你们正在铺平模型迁移的道路，只要他们保留原始数据集，至少就能顺利迁移。

是的，我不确定我们是否已经公开说过，但我们肯定希望让大家的迁移更容易。这是头号担忧，你知道，这很明显。

我还想让大家去看你们的官方模型选型文档，在指南里，我们会放到 show notes 中。文档说首先要优化准确率，所以是 prompt engineering、RAG、eval、validation——这是去年 Dev Day 讲过的，所以我只是重复一下——其次再优化成本和延迟。里面还有几组优化延迟的步骤，大家可以去阅读。

是的，完全没错。

我们有一期节目请到了 DeepMind 的 Nicholas Carini，我们聊到有些人其实并未触及模型性能的边界，他们只是试了一个模型，然后就说“哦，LLM 做不到这个”，就停下来了。人们该怎么跨过这道坎？你怎么知道是碰到了模型性能上限，还是你自己技术不行？比如你的 prompt 写得不好，或者该换另一个模型试试。有没有什么简单的判断方法？

这很难。有些人很擅长写 prompt，他们一下子就能写对，但对另一些人来说更有挑战性。我觉得我们在让模型更容易被 prompt 方面还有很多可以做，但目前我认为这需要很多创造力，而且不要轻易放弃。

是的，现在很多人都有使用 ChatGPT 的经验。你知道，在 ChatGPT 之前，玩我们模型最简单的方式是在 Playground 里，但现在基本上每个人都用过某种模型，他们有了某种直觉，比如你知道，如果我告诉你我奶奶生病了，也许我就能得到正确的输出。我们希望能消除这种需要，但多玩玩 ChatGPT 确实是培养感觉的好办法，对如何使用 API 也有帮助。

prompt engineering 会永远存在吗？还是说随着模型变好，它正在消亡？

我的意思是，这也是软件工程领域的永恒问题。随着模型在编程方面变得更好，比如我们在 SWE-bench 上达到 100 分，那又意味着什么呢？我认为，那些能够清楚解释自己想构建什么的人，永远会拥有超额收益。工程的大部分工作在于理清需求并准确表达你要做什么，我相信 AI 领域也是如此。你必须非常清楚地说明你需要什么，有些人就是比另一些人更擅长这个。人们会一直进行构建工作，只是工具会变得好得多。

过去两周你们发了两个模型，一个是 GPT-4o-2024-08-06，另一个是 ChatGPT-4o latest。我觉得大家有点困惑，然后你们发了一个澄清，说一个针对聊天做了调优，另一个更针对函数调用做了调优。你能详细说说吗？

当然可以。这么做部分动机是为了更透明地展示 ChatGPT 和 API 上运行的是什么。基本上我们一直在迭代模型，而它们的用例不同。在 ChatGPT 里，你其实不太需要针对用户自定义函数做函数调用，这让我们有自由为每个用例打造最好的模型。所以在 ChatGPT-4o latest 中，我们发布的是一种滚动更新的模型，权重不固定，随着我们发新模型它会更新，这 literally 就是我们在用的模型。

对，就是 ChatGPT 里在用的那个，所以非常适合聊天类场景。但在 API 层面，你知道，我们真的会针对开发者想要的东西调优模型，比如函数调用和结构化输出。开发者构建应用时，希望自己的功能所依赖的权重是稳定的。所以我们提供这样一种服务：如果你针对某个特定模型做了调优，而且你的功能跑通了，那我们就不会在你不知情的情况下更换底层权重。这些模型我们承诺长期支持，而且我们认为它们对开发者来说是最好的。但我们想把选择权交给开发者：你想要 ChatGPT 的模型，还是 API 的模型？

你可以自由选择最适合自己的。

我觉得大家确实想要固定模型版本，所以我不知道他们什么时候会用 ChatGPT 那个滚动更新的模型，除非他们真的只是在复刻 ChatGPT，但那样做有什么意义呢？

我的意思是，我认为开发者在不受限时能做出很多有趣的东西，所以我们不想人为限制他们。这有点像适者生存，哪个模型更好，大家就该用哪个。

是的，我跟朋友聊起这件事，说这其实不是什么新鲜事，基本上 OpenAI 以前从来没把真正的 ChatGPT 模型开放给你们，现在他们开放了。呃，其实也不完全对，实际上我们发布的很多模型本来就是一样的。

好吧，但你知道，有时候它们会分化，而我们不想把这种限制一直保留下去。关于这个新模型还有什么我们应该知道的吗？

我觉得没有发布什么 eval 之类的东西，但人们说它更好了。显然 LMSYS 上它在所有项目上都好得多，排名第一，干得好。

是的，我们发布了一些 release notes，但还没有达到我们想要的深度，因为这仍然有点像科学，我们还在学习每个模型实际变化了什么，以及如何更好地理解其能力。不过我们正努力在未来做更多 release notes，让大家及时了解情况。是的，目前这既是艺术也是科学。你需要全世界最好的 evals 团队来帮你搞清楚这些。

是啊，evals 很难。我们在招人，如果你想来做 evals，先记住这一点。关于招聘我们最后再说，聊聊你想要什么样的人，因为显然大家想加入你们，也想知道你们看重什么素质。

那我们刚聊了 API 和 ChatGPT 的区别。那你对这个界面的愿景是什么？你知道，OpenAI 的使命是打造可广泛使用的 AGI，它会以什么形式实现呢？

完全没错。我相信 API 是我们分发 AGI 最广泛的载体。你知道，我们在打造一些第一方产品，但它们永远无法触及世界上的每一个细分领域和每一个角落、每一个社区。所以我们真的很喜欢和开发者合作，看看他们能想出什么不可思议的东西。我常常觉得开发者比任何人都更早看到未来，我们很乐意和他们一起把它变成现实。因此，API 本质上是在广泛覆盖上下注；我们的第一方产品也会做得非常深入，但我认为，每扶持一位开发者，我们的影响力都会绝对放大。他们可以做最后一公里的事情，而 ChatGPT 只是一种产品形态，还有很多其他形态。

事实上，我观察到，我觉得在二月左右，ChatGPT 的用户增长基本停滞了，因为 API 一上线，大家都能拿去构建别的东西了。但这个说法现在已经不成立了，因为 ChatGPT 的增长还在继续。不过你也不用确认这些，这是我引用 SimilarWeb 的数据，方差很大。

呃，API 其实比 ChatGPT 更早。API 实际上是 OpenAI 的第一个产品，也是第一个商业化的想法，那比我还早。

大规模发布，就是全面开放，任何人都能注册立即使用。对，我就是说这个。但 yeah，我确实相信……而且你知道，你们也必须开放所有 OpenAI 的模型对吧，比如所有多模态模型。我们等下会问这方面的问题，但我认为这个 API 的使命很重要。

有趣的是，所谓最热门的新编程语言本该是英语，但实际上还是软件工程，对吧？就是，你知道，我们还在聊 HTTP 错误码之类的。

是的，我认为工程仍然是使用这些模型的方式。我觉得有些公司在做工具，想让工程对每个人更易上手，但单纯写代码和部署这件事仍然有很大超额收益。

是啊，有人甚至会把它叫做 AI 工程。完全正确。所以从搭建这个平台的过程中有很多 war stories。我们在你职业生涯起点时开始，然后直接跳到了结构化输出，中间跳过了大概两年的事情，对吧？你形成了什么原则？你最喜欢讲哪些故事？

我们在开发 Assistants API 的过程中非常开心，而且在 Dev Day 前夕，你知道，当你有一个硬截止日期，还要上台，还有一千人要来的时候，事情总是特别混乱。你总可以发一个 waitlist，我是说我们在努力不这么做，因为你知道，我们希望人们能在第一天就用上。所以 yeah，Assistants API 那会儿我们团队很小，大家拼尽全力把它做出来。其实就在当天上午，我不知道你还记不记得，Sam 做了主题演讲，然后 Raman 上台，给大家送了免费额度，那都是现场直播的，当天所有 demo 都是完全实时的。

但其实就在大概两小时前，我们出了一点故障，所有人都在拼命抢修。所以 yeah，这里还处于早期，比较 scrappy，你知道，我们当时坐在台下看直播，真的是非常紧张，很高兴最后一切顺利。

那种情况下的 plan B 是什么？能透露吗？是放视频吗？这是经典的 demo 做法对吧？我不知道，我其实也不知道 plan B 是什么。没有 plan B，只能成功。但我们就是，你知道，修好了，让所有东西重新跑起来，demo 进行得很顺利。

就是高压下的水冷循环技术问题，和往常一样，有时候你就是得把它搞定。

我能想象这其实很激励人，但我听说 Dev Day 之后全公司放了几周假，稍微放松一下。

是的，我们有时会有，比如刚过去的 7 月 4 日那周全公司放假。yeah，休假很难，因为大家在做非常令人兴奋的事情，休假时你会有很多 FOMO。所以全公司一起放假会好一些。

提到 Assistants API，你们其实在那里公布过路线图，而且事情也有进展。我觉得大家可能不了解最新情况，现在的产品和一年前相比有什么不同？

是的，我们做了很多关键改进。我觉得最大的一项是在 file search 产品里。以前我们每个 assistant 只支持大概 20 个文件，而且使用这些文件的方式效率比较低，基本上模型会根据文件名来决定是否搜索某个文件，而文件名里的信息很有限。所以我们几个月前发布的新功能现在允许每个 assistant 放 1 万个文件，数量大幅增加了。而且这是一种不同的操作方式，你可以一次性对所有文件做语义搜索，而不是由模型先挑一个。所以很多客户看到了很好的性能表现。我们还开放了更多 chunking 和 reranking 的选项，reranking 大概下周或者很快会上线。这让开发者在那里有更多控制权和灵活性。我们正努力让它成为大规模做 RAG 最简单的方式。

是的，我觉得 Dev Day 上最缺少的就是对 RAG 系统的可见性，然后大家形成了第一印象，之后就不再关注了，所以这点很重要。

reranker 是其他一些基础模型实验室的核心功能。OpenAI 会提供 reranking 服务或 ranker 模型吗？我们确实把 reranking 作为其中的一部分，而且我想我们很快会推出更多相关控制选项。

好的明白了。那如果我是现有的 LangChain、LlamaIndex 这类产品的用户，你们怎么比较？你们会做不同的选择吗？它在整个选择光谱上处于什么位置？

我觉得我们的切入点就是努力成为最简单的选项。所以理想情况下，你不需要知道什么是 ranker，也不需要设计 chunking 策略，这东西开箱即用。我想说这就是我们的方向，然后再给高级用户控制权，让他们做需要的调整。

太好了。我再问几个事情，就是 Dev Day 上宣布过的一些东西的更新。我们之前也聊过，确定性是人们非常想要的。Dev Day 宣布了 seed parameter 和 system fingerprint，但客观来说，我听说有问题。

是啊，我也不知道怎么回事。seed parameter 并不是完全确定的，它只能尽力而为。你会注意到在前几个 token 上确定性更高，这就是目前的实现方式。我们收到了很多反馈，正在思考如何改进，但这很有挑战性，因为它要在可靠性和时间之间做权衡。

另一个可能是 API 里独有的东西，logit bias。那东西看起来很有用，但大多数人可能觉得太麻烦了，不想用。你有没有什么例子，比如哪些用例或产品通过使用它变得好多了？

是的，分类是最大的一类。logit bias 能让你的分类输出有效，而且你更可能得到匹配的结果。我们见过人们用 logit bias 处理标点符号 token，也许是为了让输出更简洁。是的，这基本上是一个重度用户功能，所以用的人不多。

我其实想过用它来减少“delve”这个词出现的频率。

是啊，有人这么做过吗？可能吧，我不知道。“Delve”是一个 token 吗？你可能得做很多排列组合，这太麻烦了。它是不是一个 token 取决于 tokenizer。

那有没有非公开的 tokenizer？我猜你没法回答，或者你会拒绝回答。你们用的 100K 和 200K 词表是跨模型通用的吗？

是的，我觉得我们有文档公布了更多信息。我现在记不清，但我认为我们公布了每个模型用的是哪个 tokenizer。

好的，所以这两个是唯一……等等，rate limiting 系统。我觉得没有正式的博客文章宣布这个，但提到过你们开始把微调和 tiering 以及功能推出绑定在一起。从你的角度看，你们怎么管理这件事？关于 tiering 系统和 rate limiting，大家应该知道什么？

是的，我觉得这里的主要变化是为了更透明、更易用。以前开发者不知道自己属于哪个 tier，现在你可以在 dashboard 里看到了。而且我认为我们还公布了如何从一个 tier 升到另一个 tier。所以这帮助我们对微调功能做分批发布。我想 tier 2 及以上都有完整访问权限。这很合理。你知道，我会建议人们尽快升到 tier 5，就像……好吧，就像大客户一样，我不知道，但这似乎很合理。

我们要不要聊聊未来的事情，以及你对设计和各种事物的思考？你刚才提到你们想做成做所有事情最简单的方式。那你们和开发者生态里其他建设者是什么关系？我觉得早期可能是这样：我们只有这些 API，然后大家来帮我们。但现在你们其实在搭建一整个平台，你们怎么做决策？

是的，我觉得这里适用 80/20 原则。我们会做那些能覆盖 80% 价值的东西，然后把长尾需求留给其他开发者。所以我们真正按优先级排序的依据是：我们收到多少反馈，这能让事情变得多简单，比如会不会让 Vercel 的集成之类的事情更容易。所以 yeah，我们想在这个领域做更多，不只是做 LM as a service，而是做 AI development platform as a service。

哦，这正好联系到我准备笔记时写的一点。有其他公司也在试图成为 AI 开发平台，所以你们会和他们竞争？还是说他们只想知道你们不会做什么，好让他们来做？

是啊，这是个很难的问题。我觉得我们还没有……完全确定哪些做、哪些不做。但你可以这么理解：如果某件事能让开发者集成起来容易很多，那它很可能在我们的雷达上，我们会按影响力做 stack rank。

是啊，所以有成本追踪和 model fallbacks。model fallbacks 是个有趣的例子，因为人们确实会这么做。我不觉得它本身能带来巨大价值，但如果你不做，我就得自己做，因为如果一个 API 挂了或者出什么问题，我需要回退到另一个。

是的，我的意思是，我们满足那个用户需求的方式就是大量投入可靠性，所以我们干脆就不出故障。我的意思是，过去一年我们把 uptime 提升了很多，这是大家努力工作的结果。你可以在我们的 status page 上看到，而且我们未来也会持续投入。

拥有平台的好处在于，你可以灵活地把所有复杂混乱的东西藏在幕后。对，那你怎么划分界限，决定要把什么包含进来？

我就是把它看作：我们怎样才能让下一代 AI Engineers，就像你说的那样，快速上手？让他们做出很酷的应用的最简单方式是什么？我觉得就是通过构建一些东西来隐藏这种复杂性，或者让集成变得非常简单。所以我经常想，除了模型本身，我们还能提供什么 value add，让这些模型真正好用。

好的，我们再聊四个我们准备的 API 平台功能：batch、vision、whisper，然后是团队/企业相关的东西。所以你想聊聊 batch？

是的，大致思路是，你我之间的契约是：你交给我一个 batch job，你有 24 小时来运行它。这有点像 API 版的 spot instance。大家需要了解什么？

所以它能打五折，非常省钱。而且它还能配合 GPT-4o mini 使用，所以在 GPT-4o mini 的基础上再省钱，就很夸张了，你能做很多事情……

Olivier每百万 token 大概只要 5 美分左右，对，我其实应该把这个数字牢牢记在脑子里，但它便宜得惊人。所以我觉得这开辟了很多新的使用场景。

比如说你有一个用户激活流程，想给用户发邮件，也许每天发一封，或者在用户旅程的某些节点发。现在你可以通过 Batch API 来做这件事，以前可能要贵得多、不太可行的事，现在变得非常容易了。

Swyx对了，目前我们有这个 24 小时周转时间，价格减半。我挺好奇的，很想听听你们的社区反馈，他们想要什么样的周转时间？

我本来是 Batch 的理想用户，但我没法用 Batch，因为 24 小时太久了，我需要两到四小时，两到四小时。

Olivier好的，这很好了解。对，只是很多人还没听说过 Batch API。它也非常适合跑 eval，离线运行，一般不需要在两小时内返回结果。

Swyx我觉得可以做一个区间，对吧？对我来说是两到四小时，因为我需要做一个日报类的东西；然后 24 小时对应普通使用场景；再然后也许一周、一个月也无所谓，就是给那些有大量任务要跑的人。

Olivier是的，完全同意。对，这就是 Batch API，我觉得大家应该多用它，挺酷的。

Swyx未来有没有可能，比如半年后这类东西就免费了？有没有可能 GPU 运行时间可以被切成超级小的碎片，只要时间线拉得足够长，这些任务就能免费跑完？

Olivier是的，完全有可能。我觉得我们正在进入这样一个阶段：其中很多东西几乎已经免费了，事实上现在就已经是这样了。

Swyx那他们为什么还要去做完全免费的东西呢？我不知道。

好的，那说说 Vision。去年 Vision 非常受关注，GPT-4 的演示让大家非常兴奋，那主要就是 Vision。打造 Vision API 是什么体验？

Olivier是的，Vision API 非常酷，我们有一支很棒的团队在做这个。我觉得 Vision 的酷之处在于它横跨我们的 API，你可以在 Assistants API、Batch API 和 Chat Completions 里使用它，它也支持结构化输出。我觉得它帮了很多人做数据提取，那种数据之间的空间关系太复杂了，你用文本无法获取，但 Vision 可以。当然，还有很多非常酷的使用场景。

Swyx我觉得对我来说棘手的是，要理解把 Vision 从处理单张图像转变到实质上持续观看的频率应该是多少。现在人们好像只是每秒发一帧。这种模式会改变吗？未来会不会变成我直接给你推视频流，然后……

Olivier是的，我觉得很有可能我们会推出一个 API，让你把视频流输进去。也许一开始我们会帮你做帧采样，帧采样现在是默认做法，对吧？但我总觉得这有点 hacky。

是的，我觉得这对开发者来说很难做，所以我们肯定应该努力让它变得更简单。

SwyxBatch API 里有这个功能吗？你们有没有时间上的保证，或者顺序上的保证？比如我发了一个视频分析的批量请求，我需要每一帧都按顺序处理完。

OlivierBatch 的话，你发的是一份请求列表，每个请求都是独立的。所以你会拿到所有结果，但它们之间不会链式依赖。

Swyx嗯，如果你是在处理视频，你知道，如果你要分析视频，我之前没把视频和 Batch 联系起来，但这么一说挺有意思的。

Olivier是的，视频的话，如果你有一段很长的视频，你可以直接把所有图像做成一个批量请求去处理。

Swyx按顺序处理是对的。

Olivier对对对，完全正确。但 Batch 的核心就在于，你只是在利用空闲时间去跑这些任务。

Swyx我们来聊聊我最喜欢的模型 Whisper。我做了一个叫 Small Podcaster 的东西，对，给播客主用的开源工具。我的主要问题是，为什么 Whisper API 没有说话人分离（diarization）功能？大家都在转录多人对话啊。

Olivier是的，问得好，而且你来对人了。我其实参与过 Whisper API 的开发并把它上线了，那是我最早上线的 API 之一。长话短说，我们开源的 Whisper V3 是有 diarization 功能的，但存在一些性能上的权衡。Whisper V2 在某些方面比 V3 更强，所以相比我们的其他优先事项，上线 V3 似乎没那么值得。我觉得我们最终还是会上线的，但你知道，总有太多事情可以做，很难把所有事都做了。

Swyx我们有一个 Python notebook 可以给播客做说话人分离，但我只是觉得，你能翻译 50 种语言，却不能告诉我谁在说话，这太好笑了。

Olivier这有点像 XKCD 里关于 AI 难题的漫画，我忘了具体是哪一集。比如识别公园里有没有鸟，这很容易；但判断照片里有没有鸟，可能就得给研究团队配 10 个人。你永远不知道哪些事情其实很棘手。Diarization 我觉得就比预期中更有挑战性。

Swyx对对，它碰到重叠语音的时候还是会崩，obviously 有时候声音相似也搞不定，我得重新核对一遍。但总之，这是个很棒的模型。

我的意思是，做转录本来会花我们很长时间，而且不知道为什么，Small Podcast 的转录效果比绝大多数商业工具都好。我就是用了这个模型而已，literally 什么都没做，就是个 notebook。

Olivier是的，这说明有时候直接用简单的 OpenAI 模型，比你自己搭一套 pipeline 要好得多。

Swyx完全同意。我觉得那里最热门的功能需求应该是……你看，又把你当成提需求的垃圾桶了……就是能够偏向特定词汇。我觉得原始 Whisper 里好像可以这么做，在 API 里你也可以通过 prompt 传入，你把它放在 prompts 里。

Olivier好的，是的，目前没有更确定性的方式来做这件事。所以当你遇到一些模型不太熟悉的缩写词时，这非常有用。你可以把它们放进 prompt 里，这样转录结果基本上就会正确使用这些词。

Swyx我们 AI Engineer 的解决方案就是搞一个字典。

Olivier不错。

Swyx我们一路上各种拼错，然后做 G-sub 全局替换，能跑就行。就像 llama 少写一个 L，各种奇奇怪怪的拼法，或者 LangChain 被转录成 length chain，大小写也有三四种不同的写法。你们应该试试 PR 这个功能。

Olivier我喜欢这种专业技巧。

Swyx好的，一个有趣的问题，我知道我们还不确定，但我最近在用高级语音模式，它真的能做到双向流式传输，还能处理打断。等这个功能上线后，你们的音频端点会怎么变化？

Olivier我们正在探索新的 API 形态，看看它如何在这种 speech-to-speech 范式里工作。我觉得我们还没准备好公开分享，但我们肯定在做了。我认为常规的 request-response 模式可能不是正确的解决方案。

Swyx给正在收听的观众补充一下，OpenAI 在 ChatGPT app 里用了 LiveKit，这基本上是公开信息，它似乎是一种基于 socket 的方案，大家至少应该了解一下。我觉得很多开发者只会做 request-response，但那不适合流式场景。

Olivier是的，等我们推出这个 API 的时候，我觉得我们会让开发者很容易上手。

Swyx是的，很难，这会是一个 paradigm 转变。

好的，然后我觉得我们清单上的最后一个问题是 Team 和 Enterprise 相关的东西：审计日志、服务账号、API Key。关于 Enterprise 方案，大家应该了解什么？

Olivier是的，我们最近上线了 admin 和 audit log API。很多企业用户要求这个功能很久了，就是以编程方式管理 API Key、管理项目、获取审计日志。所以我们已经上线了，有需要的用户可以用起来，也欢迎反馈。

Swyx是的，太棒了。我自己不用这些，所以不太清楚。我猜它就像是让你搭建自己的内部网关，方便内部开发者管理你们部署的 OpenAI 服务。

Olivier是的，如果你在一个需要追踪所有 API Key 的公司工作，以前要在 dashboard 里做这件事挺难的。我们也改进了 SSO 方案，现在好用多了。企业公司最爱 SSO，这是最重要的功能。

Swyx好的，我们来聊聊 OpenAI 之外的话题，你个人方面。你提到了 Waterloo，我们就聊聊吧，为什么 Waterloo 出来的人都那么 cracked，为什么他们这么强，为什么其他地方没能复制这种模式，或者你对这段经历还有什么别的看法？

Olivier首先是 co-op 项目，obviously 非常棒。你知道，我做了六次实习，从中学到了很多。我觉得另一个原因是，Waterloo 的冬天非常冷，pretty miserable，除了学习和 hack 项目之外没什么别的事可做。那里有一种很强的 hacker 文化氛围，Hack the North 是非常有名的黑客马拉松，还有很多创业孵化器。整个环境就有一种创业和 hacker 精神。再加上六次实习，意味着你毕业时已经有了两年工作经验，这些人非常有创业精神，而且愿意埋头苦干。

Swyx我确实注意到气候和工程师 crack 程度之间存在相关性。所以西雅图是微软和亚马逊的发源地，这绝非巧合。

Olivier我看过一个关于丹麦的汇总，那里诞生了很多东西：C++、PHP、Turbo Pascal、Standard ML、BNF、我们刚才聊到的 MD5 crypt、Ruby on Rails、Google Maps，还有 Chrome 的 V8。就像 Bjarne Stroustrup（C++ 之父）说的，之所以会发明 C++，是因为那里没什么别的事可做。

Swyx对，芬兰还有 Linus Torvalds 呢。我的意思是，你经常听到这种说法，关于旧金山也是，人们说纽约好玩多了，旧金山没什么可玩的。也许科技行业集中在这里是有点刻意为之的。气候太好了，如果我们又有好玩的，大自然又这么美，你可以去 touch grass，那我们为什么不去 touch grass 呢？你知道，餐厅晚上 8 点就关门了。

请提供需要翻译的英文访谈实录片段。