o1 不是聊天模型

作者 | Ben Hylak、swyx & Alessio

译者 | 平川

策划 | 褚杏娟

本文最初发布于博客 Latent Space。

自 o1 于 10 月发布、o1 pro/o3 于 12 月发布以来，许多人都在努力厘清自己的看法，有积极的，也有消极的。在人们对 o1 Pro 的情绪跌至谷底时，我们采取了一种非常积极的态度，并描绘了 OpenAI 若推出每月 2000 美元的代理产品可能需要付出的代价。

 

我们一直在关注 Ben Hylak 在 Apple VisionOS 方面所做的工作，并邀请他在世界博览会上做了演讲。此后，他推出了 Dawn Analytics，并继续发表关于 o1 的真实想法——最初他是一个响亮的怀疑论者，后来慢慢成为了一名日常用户。两种意义上的 “思想改变者”我们都喜欢，同样的对话正在全世界发生，因为人们正在努力从聊天模式转向崭新的推理世界，以及像 Devin（在世博会上宣布，现在已正式发布）这样的 x00 美元/月的专业 AI 产品。以下是我们的想法。

o1 不是聊天模型

我是如何从讨厌 o1 到每天用它来解决最重要的问题的？

我学会了如何使用它。

https://x.com/sama/status/1877814065088663763

当 o1 pro 发布时，我毫不犹豫地订阅了。为了证明 200 美元/月的价格是合理的，它只需每月提供 1-2 个小时的工程师时间。但是，经过一天的认真尝试，我得出结论：这是个垃圾模型。

每当我提出一个问题，都要等上 5 分钟，而迎接我的却是一堵自相矛盾的大墙，里面还附带着未要求的架构图和优缺点列表。

o1 在回答我的问题时，多次自相矛盾。我在推特上发出了这样的评论，很多人表示赞同，但更有趣的是，有些人强烈反对。事实上，他们对它的出色表现感到震惊。

当然，每次 OpenAI 有发布，人们往往都会大肆炒作。但这次的感觉有所不同——这些评论来自于深入一线的人们。

我与持不同意见的人进行了交谈，越交谈就越是意识到自己完全弄错了：我把 o1 当成了一种聊天模型，但 o1 并不是。

如何使用 o1 ？

如果 o1 不是聊天模型，那它是什么？

我认为它就像一个 “报告生成器”。如果你给它提供足够多的上下文，并告诉它你想要什么，它往往一次就能给出解决方案。

swyx 按语：OpenAI 确实发布了关于提示 o1 的建议，但我们认为那并不完整。从某种意义上说，你可以把这篇文章看作是一本 “缺失的手册”，它提供了在实践中使用 o1 和 o1 pro 的经验。

1. 不要写提示，要写简介

提供大量的上下文信息。不管你是怎么理解“大量”的，提供 10 倍那个量的上下文信息。

当使用 Claude 3.5 Sonnet 或 4o 等聊天模型时，通常你会先提出一个简单的问题和一些上下文信息。如果模型需要更多的上下文，它通常会询问（或者从输出结果中可以明显看出）。

根据 OpenAI 官方文档，对于 OpenAI 模型，将上下文放在末尾更适合

你要来回迭代多次，纠正它并扩展需求，直到得到理想的输出。基本上，聊天模型就是通过这种反反复复的方式从你那里获取上下文信息。随着时间的推移，我们提问题会越来越快、越来越懒——在获得好的输出结果的同时尽可能地懒。

o1 会按字面意思理解懒惰的问题，而不会试图从你那里获取上下文。相反，你需要尽可能多地向 o1 提供上下文信息。

即使你只是问一个简单的工程问题：

• 说明你尝试过的所有无效的方法

• 添加所有数据库 Schema 的完整转储文件

• 解释你所在的公司是做什么的，规模有多大（并定义公司专用术语）

总之，要把 o1 当新员工对待。注意，o1 的错误包括推理它应该推理多少。有时，差异无法准确地反映任务难度。例如，如果任务非常简单，它往往会无缘无故地陷入推理的兔子洞。注意：o1 API 允许你指定低/中/高推理难度，但这并不向 ChatGPT 用户公开。

向 o1 提供上下文的小技巧

我建议使用 mac/手机上的语音备忘录应用。只需用 1-2 分钟的时间描述整个问题空间，然后将转录文本粘贴进去。

实际上，我有一个便签，里面记录了很长一段可以重复使用的上下文。

swyx：我使用 LS Discord 中由 Sarav 开发的 Careless Whisper。

产品中不断涌现的 AI 助手往往能简化这种提取过程。例如，如果你使用 Supabase，就可以尝试让 Supabase 助手转储/描述所有相关的表/RPC 等。

swyx：我会把开头改为 “在提示方面多提供 10 倍的上下文”

2. 关注目标：事先准确地描述你想要什么，而不是你想怎么做

在给模型提供了尽可能多的上下文之后，接下来的重点是解释希望它输出什么。

对于大多数模型，我们接受的培训是，告诉模型我们希望它如何回答我们。例如，“你是一位专家级的软件工程师。慢慢思考，仔细研究。”

这与我成功使用 o1 的方法恰恰相反。我不告诉它怎么做，只告诉它做什么。然后让 o1 接管并规划和解决自己的问题。这就是自主推理的作用，而且实际上，比你 “人工介入”手动审查和聊天要快得多。

来自 swyx 的图解

swyx 的专业建议：为你所认为的 “好 ”与 “坏 ”制定一个非常好的标准，这有助于为模型提供一种评估自身输出和自我改进/修正自身错误的方法。从根本上说，你可以将 LLM 作为法官加入到提示符中，让 o1 可以在需要时运行它。

一个额外的好处，最终你可以获得一个 LLM-as-Judge 评估器，当它正式上市时，你就可以将其用于强化微调。

这就要求你非常清楚自己想要什么（而且你真的应该在每个提示中要求它提供一个特定的输出——它只能在开始时推理）。

听起来比实际做起来要简单。我是想让 o1 在生产中实现一个特定的架构，还是创建一个最小的测试应用，或者只是探索特定选项并列出利弊？这些要求是完全不同的。

通常，o1 默认使用报告式语法解释概念——完全采用带编号的标题和副标题。如果你想跳过解释，输出完整的文件，只需明确说明即可。

自从学会了如何使用 o1，我就被它在第一时间生成正确答案的能力深深震撼了。它确实在各方面都好很多（除了成本/延迟）。下面是几个特别突出的小例子。

3. 知道 o1 擅长什么，不擅长什么

以下是 o1 擅长的：

• 一次性完美地生成整个/多个文件： 到目前为止，这是 o1 最令人印象深刻的能力。我只需要复制/粘贴大量的代码，并说明我正在构建的内容，它就能按照我代码库中现有的模式，一次性地、完整地生成整个（或多个）文件，通常不会出现任何错误。

• 减少幻觉： 总的来说，它更不容易把事情搞混。例如，o1 在处理定制查询语言（如 ClickHouse 和 New Relic）方面非常出色，而 Claude 却经常把 Postgres 的语法搞错。

• 医疗诊断：我的女朋友是一名皮肤科医生，所以，只要我的朋友或大家庭中的任何人有任何皮肤问题，都会把照片发给她！出于好玩，我开始并行询问 o1。令人震惊的是，通常情况下，它 5 次中有 3 次接近正确答案。对于医学专家来说，这更有用——它几乎总能提供极为准确的鉴别诊断。

• 解释概念： 我发现，它非常善于用实例解释高难度的工程概念。几乎就像是生成了整篇文章。在做困难的架构决策时，我经常会让 o1 生成多个方案，并列出每个方案的优缺点，甚至还会对这些方案进行比较。我会将这些回复复制/粘贴为 PDF 格式，然后进行比较——几乎就像我在考虑提案一样。

• 额外的好处：评价。我历来对使用 LLM 作为评价法官持怀疑态度，因为从根本上说，法官模型常常会遇到与最初生成输出时相同的失效模式。然而，o1 却展现出了巨大的潜力——通常，在上下文信息很少的情况下，它就能够判断生成的内容是否正确。

以下是 o1 尚不擅长的：

• 以特定的口吻/风格写作：不，我写这篇博文时没有用 o1 。我发现，它写任何东西都相当糟糕，尤其是用特定的口吻或风格进行写作的时候。它总是倾向于遵循一种非常学术/企业报告的风格。我认为，有太多的推理 token 偏向于这种语气，所以它生成的东西很难摆脱这种风格。下面这个例子是我尝试让它写这篇博文——这是经过多次反复之后的——它只想生成一份平淡无奇的学校报告。

• 构建整个应用：o1 在一次性处理整个文件方面的能力令人惊叹。尽管如此，尽管你可能会在 X 上看到一些比较乐观的演示—— o1 不会为你构建整个 SaaS，至少不会进行大量的迭代。但它几乎可以一次性地完成整个功能，尤其是前端或简单的后端功能。

为报告生成器设计界面

延迟会从根本上改变我们的产品体验。

swyx：我们同意——现在，AI 延迟经常有多达6个等级。

考虑一下邮件、电子邮件和短信之间的区别——主要是延迟。语音信息与电话相比——延迟。视频与 Zoom 相比——延迟。诸如此类。

我之所以称 o1 为 “报告生成器”，是因为它显然不是一种聊天模式，感觉更像电子邮件。

这一点并未在 o1 的产品设计中体现。我希望看到这种设计能更真实地反映在界面上。

这里有一些具体的 AI 用户体验建议，供所有基于 o1 开发产品的人参考：

1. 可以方便地查看回复的层次结构（考虑一个小型的内容目录）

2. 类似地，使层次结构更易于浏览。由于每个请求通常都大于窗口的高度，我会采取类似 Perplexity 的方法，即每个问题/答案页面占一个部分，而不是自由滚动。在一个答案中，粘性页眉、可折叠页眉等都会很有帮助。）

3. 可以方便地管理和查看你为模型提供的上下文信息。(颇具讽刺意味的是，Claude 的用户界面在这方面做得更好——当你粘贴一段长文本时，它会以一个小附件的形式呈现）。我还发现， ChatGPT 项目不像 Claude 项目那么好用，所以我经常复制和粘贴东西。

题外话：

另外，当涉及到 o1 时，ChatGPT 的 bug 非常多。推理描述非常滑稽，经常完全无法生成，而且，在手机应用上也经常无法使用。

Kenya 的美好一天 ？

未来展望

我非常期待看到这些模型的实际应用。

我认为 o1 将使某些产品首次成为可能——例如，可以从高延迟、长时间运行的后台智能中受益的产品。

用户愿意为什么样的任务等待 5 分钟？一小时？一天？3-5 个工作日？我认为，如果设计得当，会有很多。

随着模型越来越昂贵，实验的合理性变得越来越难以证明。在短短几分钟内浪费数千美元比以往任何时候都要容易。

o1-preview 和 o1-mini 支持流式处理，但不支持结构化生成或系统提示。o1 支持结构化生成和系统提示，但不支持流式处理。

考虑到响应所需的时间，流式处理似乎是一个必要条件。

随着 2025 年的到来，我们将看到开发人员如何使用该模型，这将是一件很酷的事情。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.latent.space/p/o1-skill-issue