不要再將 o1 當(dāng)做聊天模型了。

如何定位 o1 模型？你是否常常將其當(dāng)做一個聊天模型來使用。

在剛剛過去的一天，一篇名為《o1 isn’t a chat model（and that’s the point）》的文章引發(fā)了包括 OpenAI CEO Sam Altman、總裁 Greg Brockman 的關(guān)注。

這篇文章表示 o1 不是一個聊天模型，我們可以將它想象成一個報告生成器。

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

2014 年，OpenAI 接連放出了 o1、o1 pro、o3 模型，隨著模型推理能力的提升，隨著而來的是高昂的訂閱費。但很多人在訂閱使用后發(fā)現(xiàn) o1 的表現(xiàn)并不如宣傳的那樣好，當(dāng)然也包括本文的作者——曾任SpaceX軟件工程師、蘋果VisionOS人機(jī)交互設(shè)計師的Ben Hylak。

Hylak 表示每次他問 o1 一個問題時，都要等上 5 分鐘的時間，結(jié)果看到的只是一大堆自相矛盾的胡言亂語，還有未經(jīng)請求的架構(gòu)圖 + 優(yōu)缺點列表。這讓 Hylak 很是惱火，因此直言 o1 就是垃圾。

o1 回答問題，多次自相矛盾。

為了表達(dá)心中的憤怒，Hylak 還在社交媒體上分享了這種觀點，「我今天一整天都在使用 o1 pro—— 我再怎么強(qiáng)調(diào)也不為過 —— 它真的很糟糕?！?/span>

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

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

對于 Hylak 的觀點，有人表示贊同，但也有人強(qiáng)烈反對，他們認(rèn)為 o1 表現(xiàn)非常好。

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

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

奧特曼關(guān)于這條博客的推文瀏覽量達(dá)到 1.5M 。

Greg Brockman 表示：「o1 是一個不同類型的模型。要獲得出色的性能，需要以一種與標(biāo)準(zhǔn)聊天模型不同的新方式來使用它。」

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

我們可以把它想象成一個報告生成器（report generator）。如果你給定足夠的上下文，然后告訴它你想要的輸出，o1 通常會一下子確定解決方案。

接下來的問題是，如何使用 o1。

不要寫提示，要寫 Brief

給它大量的上下文，上下文的數(shù)量作者用 ton 來形容，我們可以把它想象成提示的 10 倍。

這張圖解釋了如何構(gòu)建一個針對 o1 模型的提示（prompt），并將其分為幾個部分。

通常情況下，當(dāng)你使用像 Claude 3.5 Sonnet 或 4o 這樣的聊天模型時，會先提出一個簡單的問題并附帶一些上下文。如果模型需要更多的上下文，它通常會向你詢問。

你會與模型來回迭代，糾正它并擴(kuò)展需求，直到達(dá)到期望的輸出。聊天模型本質(zhì)上是通過這種來回交互的方式從你這里獲取上下文。在與模型交互過程中，我們可能會變得越來越懶，只要還能得到好的輸出，輸入的提示越來越敷衍。

但是，o1 會直接接受那些敷衍的問題，并不會試圖從我們這里獲取上下文。相反，你需要盡可能多地向 o1 提供上下文。

即使你只是詢問一個簡單的工程問題，你也需要：

• 詳細(xì)說明所有你嘗試過但沒有奏效的方法；
• 添加所有數(shù)據(jù)庫架構(gòu)的完整 dump；
• 解釋你公司的業(yè)務(wù)、規(guī)模（并定義公司特有的術(shù)語）。

簡而言之，我們要把 o1 當(dāng)作一個新入職的員工來對待。

把更多的時間用在開頭提示上。圖源：https://x.com/swyx/status/1839213190816870425

專注于目標(biāo)：準(zhǔn)確地描述你想要什么

一旦你向模型提供了盡可能多的上下文，就需要專注于解釋你希望輸出是什么。

在大多數(shù)模型中，我們會告訴模型我們希望它如何回答我們。例如：你是一位專家級軟件工程師。你需要模型進(jìn)行慢思考且思考的很仔細(xì)。

這與使用 o1 取得成功的方法完全相反。不要告訴它如何做 —— 只告訴它做什么。然后讓 o1 接管，自行規(guī)劃和解決問題的步驟。這就是自主推理的作用所在，實際上這比你作為人工環(huán)節(jié)手動審查和聊天要快得多。

知道 o1 擅長什么、不擅長什么

o1 擅長什么：

• 完美地一次性處理整個 / 多個文件：到目前為止，這是 o1 最令人印象深刻的能力。例如，復(fù)制 / 粘貼大量代碼，大量關(guān)于正在構(gòu)建內(nèi)容的上下文，o1 會完全一次性地完成整個文件（或多個文件），通常沒有錯誤，遵循現(xiàn)有模式代碼庫。
• 減少幻覺：例如，o1 確實擅長定制查詢語言（如 ClickHouse 和 New Relic），而 Claude 經(jīng)常混淆 Postgres 的語法。
• 醫(yī)療診斷：Hylak 的女朋友是一名皮膚科醫(yī)生，當(dāng)朋友或家人有皮膚問題時，他們通常會給 Hylak 的女朋友發(fā)一張照片。當(dāng) Hylak 拿照片詢問 o1 時，o1 的回答通常與正確答案驚人地接近（約 60%）。對于醫(yī)療專業(yè)人員來說更有用 ——o1 幾乎總能提供極其準(zhǔn)確的鑒別診斷。
• 解釋概念：Hylak 發(fā)現(xiàn) o1 非常擅長通過示例解釋非常困難的工程概念。
• 在制定困難的架構(gòu)決策時，Hylak 經(jīng)常會讓 o1 生成多個計劃，甚至比較這些計劃，每個計劃都有優(yōu)缺點。
• 評估：Hylak 一直對使用 LLM 作為評估的判別器持非常懷疑的態(tài)度，但 o1 表現(xiàn)出巨大的希望 —— 它通常能夠在很少的上下文下確定生成結(jié)果是否正確。

o1 做得還不夠好的地方：

• 用特定的聲音 / 風(fēng)格寫作：Hylak 發(fā)現(xiàn) o1 不擅長寫任何東西，尤其是在特定的聲音或風(fēng)格中。它遵循一種非常學(xué)術(shù) / 企業(yè)的報告風(fēng)格。

Hylak 嘗試讓 o1 寫這篇博客的一個例子 — — 經(jīng)過多次反復(fù)，它只會寫一份平淡的報告。

• 構(gòu)建整個應(yīng)用程序：o1 非常擅長一次性構(gòu)建整個文件，但 o1 不會構(gòu)建整個 SaaS，至少不會進(jìn)行大量迭代。不過，它幾乎可以一次性完成整個功能，特別是前端功能或簡單的后端功能。

延遲從根本上改變了我們對產(chǎn)品的體驗?？紤]一下電子郵件和短信之間的區(qū)別 —— 主要是延遲，語音消息與電話通話 —— 延遲，等等。

Hylak 將 o1 稱為「報告生成器」，因為 o1 顯然不是聊天模型 —— 它感覺更像電子郵件。

Hylak 認(rèn)為 o1 將首次使某些產(chǎn)品成為可能 —— 例如，可以從高延遲、長時間運行的后臺智能中受益的產(chǎn)品。

用戶愿意等待 5 分鐘來完成什么樣的任務(wù)？一個小時？一天？3-5 個工作日？如果設(shè)計正確的話，有很多。

需要注意的是，o1-preview 和 o1-mini 支持流式傳輸，但不支持結(jié)構(gòu)化生成或系統(tǒng)提示。o1 支持結(jié)構(gòu)化生成和系統(tǒng)提示，但尚不支持流式傳輸。

當(dāng)開發(fā)人員在 2025 年設(shè)計產(chǎn)品時，實際使用該模型做什么將會非常重要。