OpenAI 提供兩種類型的模型：推理模型（例如 o3 和 o4-mini）和 GPT 模型（例如 GPT-4.1）。這兩個模型系列的運作方式不同。
本指南涵蓋：
- 我們的推理模型與非推理 GPT 模型之間的差異
- 何時該使用我們的推理模型
- 如何有效地為推理模型撰寫提示詞
進一步了解推理模型及其運作方式。
推理模型與 GPT 模型的比較
相較於 GPT 模型，我們的 o 系列模型擅長不同的任務，也需要不同的提示詞。兩個模型系列並無優劣之分，只是各有特色。
我們訓練 o 系列模型（「規劃者」），讓它們花更多時間、更深入地思考複雜任務，因此它們擅長擬定策略、規劃複雜問題的解決方案，以及根據大量含義不明的資訊做出決策。這些模型也能以高度準確性與精確度執行任務，非常適合原本需要人類專家處理的領域，例如數學、科學、工程、金融服務和法律服務。
另一方面，我們的 GPT 模型（「執行主力」）延遲較低、成本效益較高，專為直接執行任務而設計。應用程式可以使用 o 系列模型規劃解決問題的策略，再由 GPT 模型執行特定任務，尤其適合速度與成本比完全準確更重要的情況。
如何選擇
對你的使用案例而言，什麼最重要？
- 速度與成本 → GPT 模型速度更快，成本通常也更低
- 執行定義明確的任務 → GPT 模型擅長處理明確定義的任務
- 準確性與可靠性 → o 系列模型能可靠地做出決策
- 解決複雜問題 → o 系列模型能釐清含糊資訊並處理複雜情況
如果完成任務時最重要的考量是速度與成本， 而且 你的使用案例由簡單、定義明確的任務組成，那麼我們的 GPT 模型最適合你。不過，如果你最重視準確性與可靠性， 而且 需要解決非常複雜、涉及多個步驟的問題，我們的 o 系列模型可能更適合你。
多數 AI 工作流程會結合這兩類模型：由 o 系列負責智慧體的規劃與決策，GPT 系列負責執行任務。
我們的 GPT-4o 和 GPT-4o mini 模型會結合客戶資訊，初步整理與分類訂單細節，找出訂單問題和退貨政策，再將所有這些資料交給 o3-mini，由它根據政策做出是否可以退貨的最終決定。
何時該使用我們的推理模型
以下是我們從客戶及 OpenAI 內部觀察到的幾種成功使用方式。這並未完整涵蓋所有可能的使用案例，而是提供一些實用指引，協助你測試我們的 o 系列模型。
1. 處理不明確的任務
即使資訊有限或零散，推理模型也特別擅長透過簡單的提示詞理解使用者意圖，並處理指示中不完整的部分。事實上，推理模型通常會先提出問題釐清情況，而不是貿然猜測或試圖自行補足缺少的資訊。
「o1 的推理能力讓我們的多智慧體平台 Matrix 在處理複雜文件時，能產生完整、格式良好且詳盡的回應。例如，只需基本提示詞，o1 就能讓 Matrix 輕鬆找出信貸協議中受限制付款條款下可使用的例外額度。過去的模型都無法達到這樣的表現。在針對內容密集的信貸協議所提出的複雜提示詞中，o1 有 52% 的結果優於其他模型。」
—Hebbia，為法律與金融領域提供 AI 知識平台的公司
2. 從大量資料中找出關鍵資訊
當你提供大量非結構化資訊時，推理模型擅長理解內容，並只擷取最相關的資訊來回答問題。
「為了分析一項公司收購案，o1 審查了數十份公司文件，例如合約與租約，以找出可能影響交易的棘手條件。模型的任務是標記關鍵條款，而它在過程中發現了註腳裡一項重要的『控制權變更』條款：如果公司出售，就必須立即償還 7,500 萬美元的貸款。o1 對細節的高度關注，讓我們的 AI 智慧體能找出攸關任務成敗的資訊，支援金融專業人士。」
—Endex，AI 金融情報平台
3. 找出大型資料集中的關聯與細微差異
我們發現，推理模型特別擅長針對複雜文件進行推理，即使文件包含數百頁密集的非結構化資訊，例如法律合約、財務報表和保險理賠資料，也能應付。這些模型尤其擅長找出不同文件間的相通之處，並根據資料中隱含的事實做出決策。
「稅務研究需要綜合多份文件，才能得出有理有據的最終答案。我們將 GPT-4o 換成 o1 後，發現 o1 更擅長推理文件之間的相互關係，得出無法從任何單一文件直接看出的合理結論。因此，改用 o1 後，我們的端到端表現達到原本的 4 倍，令人驚豔。」
—Blue J，AI 稅務研究平台
推理模型也擅長針對包含細微差異的政策與規則進行推理，並將其應用於當前任務，以得出合理的結論。
「在財務分析中，分析師經常需要處理與股東權益相關的複雜情境，並理解其中繁複的法律細節。我們用一個困難但常見的問題，測試了不同供應商提供的約 10 個模型：募資會如何影響現有股東，尤其是當他們行使反稀釋權利時？這需要推理投資前與投資後估值，並處理稀釋計算中的循環相依問題，即使頂尖財務分析師也要花 20–30 分鐘才能釐清。我們發現 o1 和 o3-mini 都能毫無差錯地完成！模型甚至產生了清楚的計算表，顯示對持股價值 10 萬美元的股東有何影響。」
–BlueFlame AI，AI 投資管理平台
4. 智慧體的多步驟規劃
推理模型對智慧體的規劃與策略制定至關重要。我們觀察到一種成功的做法：讓推理模型擔任「規劃者」，針對問題產生詳盡的多步驟解決方案，再根據每個步驟更重視高智慧還是低延遲，選擇並指派合適的 GPT 模型擔任「執行者」。
「我們讓 o1 在智慧體基礎架構中擔任規劃者，由它協調工作流程中的其他模型，完成多步驟任務。我們發現 o1 非常擅長選擇資料類型，以及將大問題拆解成較小的部分，讓其他模型能專注於執行。」
—Argon AI，製藥業的 AI 知識平台
「在我們的 AI 工作助理 Lindy 中，許多智慧體工作流程都由 o1 驅動。模型透過函式呼叫，從你的行事曆或電子郵件中擷取資訊，接著就能自動協助你安排會議、傳送電子郵件，以及管理其他日常任務。我們將過去容易出問題的智慧體步驟全數改用 o1，結果發現智慧體幾乎一夜之間就不再出錯了！」
—Lindy.AI，AI 工作助理
5. 視覺推理
截至目前，o1 是唯一支援視覺能力的推理模型。它與 GPT-4o 的不同之處在於，即使是最難判讀的視覺內容，o1 也能理解，例如結構不明確的圖表與表格，或畫質不佳的照片。
「我們為數百萬件線上商品自動執行風險與合規審查，涵蓋奢華珠寶仿品、瀕危物種和管制物質。在我們最困難的影像分類任務中，GPT-4o 的準確率達到 50%。在完全不修改處理流程的情況下，o1 就達到了令人印象深刻的 88% 準確率。」
—SafetyKit，AI 驅動的風險與合規平台
在我們的內部測試中，o1 能從細節豐富的建築圖面辨識固定裝設的設備與材料，產生完整的物料清單。最令我們驚訝的發現之一是，o1 能找出不同影像之間的對應關係：即使沒有明確指示，也能將建築圖面某一頁的圖例正確套用到另一頁。如下所示，針對 4x4 PT 木柱，o1 根據圖例辨識出「PT」代表經過加壓處理。
6. 審查、偵錯與改善程式碼品質
推理模型特別擅長審查與改善大量程式碼。考量到這類模型的延遲較高，通常會讓它們在背景執行程式碼審查。
「我們在 GitHub 和 GitLab 等平台上提供自動化 AI 程式碼審查。雖然程式碼審查流程本身對延遲並不敏感，但確實需要理解多個檔案之間的程式碼差異。這正是 o1 的強項：它能可靠地偵測到人類審查者可能忽略的細微程式碼變更。改用 o 系列模型後，我們的產品轉換率達到了原本的 3 倍。」
—CodeRabbit，AI 程式碼審查新創公司
GPT-4o 和 GPT-4o mini 的延遲較低，在設計上可能更適合撰寫程式碼；不過，我們也觀察到，在對延遲稍微不那麼敏感的使用案例中，o3-mini 的程式碼生成表現十分出色。
「o3-mini 能穩定產生高品質、確實解決問題的程式碼。只要問題定義明確，即使程式設計任務非常困難，它也經常能找到正確解法。其他模型可能只適合小規模、快速的程式碼迭代，o3-mini 則擅長規劃並實作複雜的軟體系統設計。」
—Windsurf，由 Codeium 打造、以智慧體式 AI 驅動的協作 IDE
7. 評估其他模型的回應並進行基準測試
我們也觀察到，推理模型在評估其他模型的回應和進行基準測試方面表現良好。資料驗證對確保資料集的品質與可靠性至關重要，在醫療照護等敏感領域尤其如此。傳統驗證方法使用預先定義的規則與模式，而 o1 和 o3-mini 等先進模型能理解上下文，並針對資料進行推理，提供更靈活、更智慧的驗證方式。
「許多客戶在 Braintrust 的評估流程中，會使用 LLM 擔任評判者。例如，醫療照護公司可能先使用 gpt-4o 這類執行主力模型摘要病人的問題，再由 o1 評估摘要品質。有一位 Braintrust 客戶將評判模型從 4o 換成 o1 後，F1 分數從 0.12 提升到了 0.74！在這些使用案例中，他們發現，面對最困難、最複雜的評分任務，o1 的推理能力為辨識生成回應之間的細微差異帶來了突破性的改變。」
—Braintrust，AI 評估平台
如何有效地為推理模型撰寫提示詞
這些模型在提示詞簡單明確時表現最佳。某些提示工程技巧，例如要求模型「逐步思考」，可能無法改善表現，有時甚至會適得其反。請參閱以下最佳實務，或從提示詞範例開始。
- 開發人員訊息取代系統訊息：從
o1-2024-12-17開始，推理模型支援開發人員訊息，而非系統訊息，以符合模型規格中所述的指令優先順序行為。 - 提示詞應簡單直接：這些模型擅長理解並回應簡短、清楚的指示。
- 避免使用思路鏈提示詞：這些模型會在內部進行推理，因此不必要求它們「逐步思考」或「解釋你的推理過程」。
- 使用分隔符號釐清結構：使用 Markdown、XML 標籤和章節標題等分隔方式，清楚區分輸入的各個部分，協助模型正確解讀不同區段。
- 先嘗試零樣本提示，再視需要使用少樣本提示：推理模型通常不需要少樣本範例就能產生良好結果，因此請先嘗試撰寫不含範例的提示詞。如果你對輸出的要求較複雜，在提示詞中加入幾組輸入與預期輸出的範例可能會有幫助。務必確保範例與提示詞中的指示高度一致，因為兩者之間的差異可能導致結果不佳。
- 提供明確的準則：如果你希望對模型的回應加上特定限制，例如「提出預算低於 $500 的解決方案」，請在提示詞中明確列出這些限制。
- 明確說明最終目標：在指示中，盡量具體列出理想回應應滿足的條件，並鼓勵模型持續推理與反覆調整，直到符合你的成功標準。
- Markdown 格式：從
o1-2024-12-17開始，API 中的推理模型會避免產生使用 Markdown 格式的回應。如果你希望回應使用 Markdown 格式，請在開發人員訊息的第一行加入字串Formatting re-enabled，向模型表明這項需求。
如何兼顧低成本與高準確度
隨著 o3 和 o4-mini 模型推出，Responses API 處理已儲存推理項目的方式也有所改變。過去使用 o1、o3-mini、o1-mini 和 o1-preview 時，即使將推理項目納入後續 API 請求的輸入項目中，這些推理項目仍一律會被忽略。使用 o3 和 o4-mini 時，部分與函式呼叫相鄰的推理項目會納入模型的上下文，以盡可能少的推理 Token 用量改善模型表現。
為了充分發揮這項變更的效益，我們建議使用 Responses API，將 store 參數設為 true，並傳入先前請求中的所有推理項目。你可以使用 previous_response_id，或將先前請求的所有輸出項目作為新請求的輸入項目傳入。OpenAI 會自動將相關推理項目納入模型的上下文，並忽略不相關的項目。若你的使用情境較進階，希望更精確地管理模型上下文的內容，我們建議至少納入最新一次函式呼叫與前一則使用者訊息之間的所有推理項目。這樣可確保你回應函式呼叫時，模型不必重新開始推理，從而改善函式呼叫表現並降低整體 Token 用量。
如果你使用 Chat Completions API，推理項目一律不會納入模型的上下文，因為 Chat Completions 是無狀態 API。在涉及大量函式呼叫的複雜智慧體使用情境中，這會使模型表現略微下降，並增加推理 Token 用量。如果不涉及複雜的多次函式呼叫，無論使用哪種 API，模型表現應該都不會下降。
其他資源
如需更多靈感，請造訪 OpenAI Cookbook，其中提供範例程式碼與第三方資源連結；你也可以透過以下資源深入瞭解我們的模型與推理能力：