o1 模型不是聊天機器人：Altman 與 Brockman 的觀察

o1：非典型的聊天模型

文章討論了最近關於 o1 模型的熱議，並澄清它並非設計為聊天模型，儘管許多用戶最初將其視為聊天模型。這個啟示源於一篇名為“o1 isn’t a chat model (and that’s the point)”的部落格文章，該文章引起了廣泛關注，甚至吸引了 OpenAI CEO Sam Altman 和總裁 Greg Brockman 的注意。

誤解與挫折

Ben Hylak，一位前 SpaceX 軟體工程師和 Apple VisionOS 互動設計師，分享了他使用 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 年設計產品時至關重要。