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