不要再將 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—— 我再怎么強調也不為過 —— 它真的很糟糕。」

「輸出內容幾乎接近胡言亂語，在同一個答案中多次自相矛盾。例如：我向它征求關于重構的建議。它建議合并文件，但輸出的代碼塊中文件并未合并，然后又出現了完全不相關的結論?！?/span>

圖源：https://x.com/benhylak/status/1864835651725910023

對于 Hylak 的觀點，有人表示贊同，但也有人強烈反對，他們認為 o1 表現非常好。

隨著 Hylak 與那些持反對意見的人交流越來越多，他逐漸意識到自己完全錯了：他把 o1 當作聊天模型來使用，但實際上 o1 并不是聊天模型。

對于作者態度的轉變，奧特曼很是欣慰，表示道：「隨著人們學會如何使用 o1（包括 pro 版），觀察人們對它態度的轉變真是很有趣?！?/span>

奧特曼關于這條博客的推文瀏覽量達到 1.5M 。

Greg Brockman 表示：「o1 是一個不同類型的模型。要獲得出色的性能，需要以一種與標準聊天模型不同的新方式來使用它?！?/span>

如果 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 年設計產品時，實際使用該模型做什么將會非常重要。