不要再将 o1 当做聊天模型了。
如何定位 o1 模型？你是否常常将其当做一个聊天模型来使用。
在刚刚过去的一天，一篇名为《o1 isn’t a chat model（and that’s the point）》的文章引发了包括 OpenAI CEO Sam Altman、总裁 Greg Brockman 的关注。
这篇文章表示 o1 不是一个聊天模型，我们可以将它想象成一个报告生成器。
原文链接：https://www.latent.space/p/o1-skill-issue
2014 年，OpenAI 接连放出了 o1、o1 pro、o3 模型，随着模型推理能力的提升，随着而来的是高昂的订阅费。但很多人在订阅使用后发现 o1 的表现并不如宣传的那样好，当然也包括本文的作者——曾任SpaceX软件工程师、苹果VisionOS人机交互设计师的Ben Hylak。
Hylak 表示每次他问 o1 一个问题时，都要等上 5 分钟的时间，结果看到的只是一大堆自相矛盾的胡言乱语，还有未经请求的架构图 + 优缺点列表。这让 Hylak 很是恼火，因此直言 o1 就是垃圾。
o1 回答问题，多次自相矛盾。
为了表达心中的愤怒，Hylak 还在社交媒体上分享了这种观点，「我今天一整天都在使用 o1 pro—— 我再怎么强调也不为过 —— 它真的很糟糕。」
「输出内容几乎接近胡言乱语，在同一个答案中多次自相矛盾。例如：我向它征求关于重构的建议。它建议合并文件，但输出的代码块中文件并未合并，然后又出现了完全不相关的结论。」
图源：https://x.com/benhylak/status/1864835651725910023
对于 Hylak 的观点，有人表示赞同，但也有人强烈反对，他们认为 o1 表现非常好。
随着 Hylak 与那些持反对意见的人交流越来越多，他逐渐意识到自己完全错了：他把 o1 当作聊天模型来使用，但实际上 o1 并不是聊天模型。
对于作者态度的转变，奥特曼很是欣慰，表示道：「随着人们学会如何使用 o1（包括 pro 版），观察人们对它态度的转变真是很有趣。」
奥特曼关于这条博客的推文浏览量达到 1.5M 。
Greg Brockman 表示：「o1 是一个不同类型的模型。要获得出色的性能，需要以一种与标准聊天模型不同的新方式来使用它。」
如果 o1 不是聊天模型，那它是什么？
我们可以把它想象成一个报告生成器（report generator）。如果你给定足够的上下文，然后告诉它你想要的输出，o1 通常会一下子确定解决方案。
接下来的问题是，如何使用 o1。
不要写提示，要写 Brief
给它大量的上下文，上下文的数量作者用 ton 来形容，我们可以把它想象成提示的 10 倍。
这张图解释了如何构建一个针对 o1 模型的提示（prompt），并将其分为几个部分。
通常情况下，当你使用像 Claude 3.5 Sonnet 或 4o 这样的聊天模型时，会先提出一个简单的问题并附带一些上下文。如果模型需要更多的上下文，它通常会向你询问。
你会与模型来回迭代，纠正它并扩展需求，直到达到期望的输出。聊天模型本质上是通过这种来回交互的方式从你这里获取上下文。在与模型交互过程中，我们可能会变得越来越懒，只要还能得到好的输出，输入的提示越来越敷衍。
但是，o1 会直接接受那些敷衍的问题，并不会试图从我们这里获取上下文。相反，你需要尽可能多地向 o1 提供上下文。
即使你只是询问一个简单的工程问题，你也需要：
- 详细说明所有你尝试过但没有奏效的方法；
- 添加所有数据库架构的完整 dump；
- 解释你公司的业务、规模（并定义公司特有的术语）。
简而言之，我们要把 o1 当作一个新入职的员工来对待。
把更多的时间用在开头提示上。图源：https://x.com/swyx/status/1839213190816870425
专注于目标：准确地描述你想要什么
一旦你向模型提供了尽可能多的上下文，就需要专注于解释你希望输出是什么。
在大多数模型中，我们会告诉模型我们希望它如何回答我们。例如：你是一位专家级软件工程师。你需要模型进行慢思考且思考的很仔细。
这与使用 o1 取得成功的方法完全相反。不要告诉它如何做 —— 只告诉它做什么。然后让 o1 接管，自行规划和解决问题的步骤。这就是自主推理的作用所在，实际上这比你作为人工环节手动审查和聊天要快得多。
知道 o1 擅长什么、不擅长什么
o1 擅长什么：
- 完美地一次性处理整个 / 多个文件：到目前为止，这是 o1 最令人印象深刻的能力。例如，复制 / 粘贴大量代码，大量关于正在构建内容的上下文，o1 会完全一次性地完成整个文件（或多个文件），通常没有错误，遵循现有模式代码库。
- 减少幻觉：例如，o1 确实擅长定制查询语言（如 ClickHouse 和 New Relic），而 Claude 经常混淆 Postgres 的语法。
- 医疗诊断：Hylak 的女朋友是一名皮肤科医生，当朋友或家人有皮肤问题时，他们通常会给 Hylak 的女朋友发一张照片。当 Hylak 拿照片询问 o1 时，o1 的回答通常与正确答案惊人地接近（约 60%）。对于医疗专业人员来说更有用 ——o1 几乎总能提供极其准确的鉴别诊断。
- 解释概念：Hylak 发现 o1 非常擅长通过示例解释非常困难的工程概念。
- 在制定困难的架构决策时，Hylak 经常会让 o1 生成多个计划，甚至比较这些计划，每个计划都有优缺点。
- 评估：Hylak 一直对使用 LLM 作为评估的判别器持非常怀疑的态度，但 o1 表现出巨大的希望 —— 它通常能够在很少的上下文下确定生成结果是否正确。
o1 做得还不够好的地方：
- 用特定的声音 / 风格写作：Hylak 发现 o1 不擅长写任何东西，尤其是在特定的声音或风格中。它遵循一种非常学术 / 企业的报告风格。
Hylak 尝试让 o1 写这篇博客的一个例子 — — 经过多次反复，它只会写一份平淡的报告。
- 构建整个应用程序：o1 非常擅长一次性构建整个文件，但 o1 不会构建整个 SaaS，至少不会进行大量迭代。不过，它几乎可以一次性完成整个功能，特别是前端功能或简单的后端功能。
延迟从根本上改变了我们对产品的体验。考虑一下电子邮件和短信之间的区别 —— 主要是延迟，语音消息与电话通话 —— 延迟，等等。
Hylak 将 o1 称为「报告生成器」，因为 o1 显然不是聊天模型 —— 它感觉更像电子邮件。
Hylak 认为 o1 将首次使某些产品成为可能 —— 例如，可以从高延迟、长时间运行的后台智能中受益的产品。
用户愿意等待 5 分钟来完成什么样的任务？一个小时？一天？3-5 个工作日？如果设计正确的话，有很多。
需要注意的是，o1-preview 和 o1-mini 支持流式传输，但不支持结构化生成或系统提示。o1 支持结构化生成和系统提示，但尚不支持流式传输。
当开发人员在 2025 年设计产品时，实际使用该模型做什么将会非常重要。
