o1模型并非聊天机器人：Altman与Brockman的关注

o1：并非典型的聊天模型

文章讨论了最近关于o1模型的热议，澄清了它并非设计为聊天模型，尽管许多用户最初将其视为聊天模型。这一揭示源于一篇名为“o1不是聊天模型（而这正是重点）”的博客文章，该文章引起了广泛关注，甚至吸引了OpenAI首席执行官Sam Altman和总裁Greg Brockman的注意。

误解与挫败感

Ben Hylak，前SpaceX软件工程师和Apple VisionOS交互设计师，分享了他使用o1的挫败经历。他发现o1的响应缓慢，经常自相矛盾，并且充满了未经请求的架构图和优缺点列表。Hylak最初的反应是o1简直是“垃圾”。

• Hylak经历了5分钟的响应等待时间。
• 响应经常自相矛盾且毫无意义。
• 模型提供了未经请求的图表和列表。

他的挫败感导致他在社交媒体上表达了他的失望，称o1 pro“真的很糟糕”，其输出“几乎是胡言乱语”。他举例说，当他寻求重构建议时，模型建议合并文件，提供的代码却无法合并文件，然后又跳到不相关的结论。

视角的转变

Hylak的经历并非普遍现象。一些用户发现o1非常有效，这引发了更深入的讨论。通过这些互动，Hylak意识到自己的错误：他将o1当作聊天模型使用，而它并非旨在如此运作。

Altman对这种视角的转变表示欢迎，他指出“看着人们在学习如何使用o1（包括专业版）时态度发生变化，很有趣”。Greg Brockman也对此表示赞同，他指出o1是一种不同的模型，需要不同的方法才能获得最佳性能。

o1：一个报告生成器

文章建议，与其将o1视为聊天模型，不如将其视为“报告生成器”。在提供足够的上下文和明确的输出要求的情况下，o1可以有效地提供解决方案。关键在于如何使用该模型。

从提示到简报

当使用典型的聊天模型时，用户通常从简单的问题开始，并根据需要添加上下文，进行迭代式的来回交互。然而，o1不寻求额外的上下文。相反，用户需要预先提供大量的上下文，描述为“大量”信息，或者大约是标准提示所用上下文的十倍。

• 提供所有尝试过的解决方案的详细信息。
• 包括完整的数据库模式转储。
• 解释公司特定的业务、规模和术语。

建议将o1视为新员工，从一开始就提供所有必要的信息。

专注于期望的输出

在提供广泛的上下文后，用户必须明确定义期望的输出。与其他模型不同，用户可能会指定角色或思维过程，而使用o1时，您应该只关注您想要“什么”，而不是模型应该“如何”做。这允许o1独立计划和执行所需的步骤，从而更快更高效地获得结果。

o1的优势与劣势

o1在以下几个方面表现出色：

• 处理整个文件：它可以处理大型代码块和广泛的上下文，通常以最少的错误完成整个文件。
• 减少幻觉：o1在自定义查询语言（例如ClickHouse和New Relic）等领域非常准确，而其他模型可能会混淆语法。
• 医疗诊断：o1可以基于图像和描述提供令人惊讶的准确的初步诊断。
• 解释概念：它擅长通过示例解释复杂的工程概念。
• 生成架构计划：o1可以创建多个计划，比较它们，并列出优缺点。
• 评估：它显示出作为评估结果的有效工具的潜力。

然而，o1也有其局限性：

• 以特定风格写作：它倾向于以学术或企业风格生成报告，并且难以适应特定的语气。
• 构建整个应用程序：虽然它擅长生成整个文件，但它无法通过迭代构建完整的SaaS应用程序。但是，它可以完成整个功能，特别是前端或简单的后端功能。

延迟的重要性

文章指出，延迟从根本上改变了我们对产品的看法，引用了电子邮件与短信、语音消息与电话等例子。Hylak将o1比作电子邮件而不是聊天模型，因为它的响应存在延迟。这种延迟允许产生受益于高延迟、长时间运行的后台智能的新型产品。问题就变成了：人们愿意等待5分钟、1小时、1天甚至3-5个工作日来完成哪些任务？

值得注意的是，o1-preview和o1-mini支持流式传输，但不支持结构化生成或系统提示，而o1支持结构化生成和系统提示，但不支持流式传输。了解这些差异对于开发人员在2025年设计产品至关重要。o1