當下，大模型領域已然步入 “百模大戰” 時期，形形色色的大模型如雨后春筍般不斷涌現。那么，若我們打算學習大模型的 API，是否真的需要逐一去鉆研呢？答案無疑是否定的。

盡管大模型的數量極為可觀，然而就編程接口層面而言，它們大體上頗為相似。用編程領域的專業表述來講，即便各模型的內部實現千差萬別，但其接口卻基本保持一致。所以，只要深入研習其中一個模型的 API，掌握其他 API 對于我們而言也并非難事，能夠較為迅速地入門上手。

既然確定要展開學習，那自然需要設定一個具體的學習目標。在此，我選定的是 OpenAI API。之所以做出這樣的抉擇，首要原因便是 GPT 模型在行業內所產生的深遠影響力，眾多后來者在設計自身 API 時，或多或少都會對其予以參考借鑒。

此外，還有一個極為關鍵的因素，OpenAI API 幾乎已成為行業內公認的事實標準。在當下的眾多項目中，許多都傾向于提供與 OpenAI API 相兼容的接口。甚至存在一些具有中間件特性的項目，無論其后臺實際接入的是何種模型，面向自身用戶所提供的均為 OpenAI 兼容的 API。鑒于如此這般的行業現狀，倘若僅打算學習一個 API，那么 OpenAI API 顯然是不二之選。

OpenAI API

為了讓你有一個直觀的感受，我們來看一個具體的例子：

curl https://api.openai.com/v1/chat/completions
-H "Content-Type: application/json"
-H "Authorization: Bearer $OPENAI_API_KEY"
-d '{
"model": "gpt-4o",
"messages": [
            {"role": "user", "content": "寫一首關于AI的詩"}
        ]
    }'

在了解具體內容之前，我們先從整體上看一下這個 API。雖然我們的主要工作是面向大模型進行編程，但 Open AI API 其實提供了許多功能，比如：Text Generation：生成和處理文本Embeddings：文本轉向量Speech to Text：語音轉文本Image Generation：生成圖像Vision：處理圖像輸入……

這些不同的接口是通過不同的路徑進行區分。這里看到的 /v1/chat/completions 就是我們常用的大模型的編程接口。除了各種強大的功能，OpenAI API 還有兩個關鍵的參數是各個接口統一的，一個是訪問地址，一個是 API Key。

訪問地址之所以需要被單獨提及，原因在于實際運用該 API 之際，我們并非總是徑直訪問 OpenAI API。有可能是借助他人所提供的兼容 API，亦或是通過代理途徑所給予的訪問方式。總而言之，我們所運用的地址會有所不同，所以需要專門進行配置。

而 API Key 的概念則相對容易理解，不同的 Key 主要用于區分不同的用戶。從上述實例中能夠清晰地看出，此 Key 是被寫在 HTTP 訪問的頭部信息之中。

倘若我們采用的是 OpenAI 所提供的程序庫，那么這兩個參數既能夠借助程序來設定，也可以通過命令行來進行設置。以下即為使用命令行設置的相關示例：

export OPENAI_API_BASE="your_api_base_here"
export OPENAI_API_KEY="your_api_key_here"

有了這些通用的知識，接下來，我們來具體關注一下最核心的大模型編程接口。

Chat Completions

大模型編程接口所對應的路徑為 /v1/chat/completions 。在此路徑中，“v1” 代表的是版本編號，而該接口被命名為 “聊天補全”。“補全” 這一名稱恰好與我們之前所闡述的 GPT 工作原理相互呼應。實際上，OpenAI 起初擁有一個單純執行補全功能的接口，然而在 ChatGPT 迅速走紅之后，聊天形式逐漸成為主流應用模式，于是 “聊天補全” 接口便成為了我們重點關注且廣泛使用的核心接口。

新舊兩種補全 API 之間最為顯著的區別在于，舊版 API 所接收傳入的是一個單一的提示詞，而新版 API 接收傳入的則是一個消息列表。

請求

我們來看看這個接口的具體內容。作為一個 HTTP 請求，它分為請求和應答兩個部分。我們先來看請求。請求的參數非常多，我們會做一個通覽。有一點需要提示一下，你學習到這篇內容時，可能與最新的 OpenAI API 文檔對不上，因為這個 API 本身也在不斷的演化過程中，它會不斷地增刪參數。為了方便你理解，我把請求參數劃分成四類：

• 核心參數
• 工程參數
• 工具參數
• 模型參數

核心參數

首先來看最為核心的兩個參數，它們在之前的示例中已然有所呈現。

其一為 “model”，此參數用于指定與哪一個模型進行交互溝通，在相關示例里所采用的便是 “gpt - 4o” 模型。

其二是 “messages”，它代表著發送給模型的消息，這里的消息呈現為一個列表形式，簡單來講，可將其視作一個包含歷史消息的列表，其目的在于為模型提供更為豐富的上下文信息。

每條消息通常由兩個主要部分構成：“角色（role）” 和 “內容（content）”。其中 “內容” 較為直觀，即消息自身所包含的具體信息。而對于常規對話場景而言，“角色” 主要分為 “系統（system）” 和 “用戶（user）”。可以理解為開發者所設置的相關內容對應 “系統” 角色，而用戶提出的問題則屬于 “用戶” 角色。有時，我們還會把大模型所生成的消息添加進去，例如在聊天歷史記錄中，這類消息的角色即為 “助理（assistant）”。

除了上述這兩個關鍵參數之外，還有三個常用參數。

“temperature”，其概念在之前已經有所提及，主要用于設定大模型回復的確定性程度。當該值越小，表明回復的確定性越強；反之，值越大，則意味著回復的隨機性越強。

“max_completion_tokens”，它表示大模型生成應答時的最大 token 數量。由于大模型生成內容通常依據 token 數量來計費，所以對 “max_completion_tokens” 進行合理限制是一種有效控制成本的方式。不過，也不能將其設置得過大，因為每個模型內部實際上都存在自身的最大限制，當我們所設置的限制值超出其內部限制時，模型將會忽略我們的設置。值得注意的是，該字段曾被命名為 “max_tokens”，所以在許多地方，包括一些參考 OpenAI 設計的框架之中，仍然能夠看到 “max_tokens” 的存在。

“stream”，此參數用于確定是否需要流式應答。流式應答的主要作用在于提升聊天過程中的響應速度，關于這部分內容將會在下一講中展開詳細探討。

需要特別指出的是，對于不同的模型，這些參數的取值范圍可能會存在差異。例如不同模型各自擁有其特定的 “max_tokens” 取值范圍。此外，鑒于眾多服務供應商提供了兼容的 OpenAI API，即便是相同的參數，其取值范圍也可能不盡相同。比如在 OpenAI API 里，“temperature” 的取值范圍是從 0 到 2，其默認值為 1，然而對于某些兼容模型而言，其取值范圍或許會有所變化，具體情況需要依據相關文檔來確定。

通過以上梳理，我們對大模型編程中最核心的參數有了較為清晰的認識。在常規聊天場景下，多數情況中我們所進行調節的便是這些參數。接下來，我們將進一步探討其他參數。

工程參數

在請求參數之中，存在一部分是基于工程目的而設立的。

首先是 “user” 參數，它代表著終端用戶標識。這一參數由我們作為開發者提供給 OpenAI，其主要用途在于實現對 API 濫用情況的監控與檢測，并且其監控的精細程度能夠具體到單個用戶個體層面。

接著是 “n” 參數，該參數用于指定針對每條輸入消息生成回復的數量。盡管從表面上看，設置此參數能夠獲取更多的生成內容，但由于生成內容是需要計費的，所以在沒有特殊需求的情況下，建議不要對這個參數進行額外設置。

還有 “response_format” 參數，即應答格式。在默認狀態下，此接口僅僅生成文本內容。然而在開發過程中，我們常常會用到 JSON 格式。對于獲取 JSON 格式的輸出，我們既可以借助提示詞要求大模型進行返回，也能夠通過設置 “response_format” 參數使 API 直接返回 JSON 格式，具體的操作方法可以參考 OpenAI 的結構化輸出相關內容。

不過需要說明的是，這些參數雖然存在被使用的可能性，但在實際應用中真正用到它們的機會并不多。例如，若發現某個用戶存在濫用 API 的行為，我們通常不會將其相關信息傳遞給 OpenAI，而是自行在本地進行處理。再比如，盡管 OpenAI 支持 JSON 格式輸出，但考慮到模型的兼容性問題，我們可能仍然會傾向于選擇使用提示詞的方式，讓大模型直接返回所需內容。

工具參數

在當下，除了用于常規的聊天場景之外，大模型還有一種較為常見的應用方式，那便是構建 Agent。Agent 有著十分重要的用途，其中關鍵的一點在于它能夠拓展大模型的能力邊界，使其可以完成更多類型的任務，像查詢天氣、搜索網頁這類操作都涵蓋在內。那么，大模型是如何知曉自己能夠做這些事情的呢？即通過工具參數來進行傳遞。

這里的 “工具” 這一說法其實是經過改進之后的稱呼，之所以進行這樣的改進，主要是為了與社區的習慣保持一致。最開始的時候，它被稱作 “函數（Function）”。之所以要特別說明這一點，是因為在部分資料當中，我們依然能夠看到 “函數” 這種表述方式。并且在 API 文檔里也存在 “函數” 相關內容，只不過目前已經被標記為廢棄狀態了。

工具參數里最常用的是這兩個：

對于 “tools” 參數，它代表著模型能夠調用的工具列表。在該列表中的每一個工具均包含 “type”（類型）與 “function”（函數）這兩個組成部分。

就當前而言，“type” 所表示的工具類型僅有 “function” 這一種。

而 “function” 的主要作用在于告知模型該函數的調用方式，它涵蓋了 “description”（函數的描述）、“name”（函數名）以及 “parameters”（函數參數）這些要素。

另外，“tool_choice” 參數則用于確定如何調用工具。當參數值為 “none” 時，意味著不調用任何工具；若參數值為 “auto”，則表示由模型自行決定是生成消息還是調用工具；而參數值為 “required” 時，則表明必須調用工具。此外，該參數值還可以是一個對象形式，例如，如下這行代碼便是告知模型需要調用指定的這個工具。

{"type": "function", "function": {"name": "my_function"}}

模型參數

若上述所提及的部分參數還算比較易于理解，僅通過參數名便能知曉其大致用途的話，那么還有相當多的參數看起來則令人頗為費解，就比如 “frequency_penalty”。實際上，這些參數通常并非是供開發應用的工程師使用的，我們可以將其視為是為模型開發者所準備的，所以，我把它們歸到了模型參數的類別之中。大家對此僅作簡單了解即可，待日后真有需要用到它們的時候，再深入探究也為時不晚。

先來說說 “seed”，即種子值。種子值的設立主要是為了解決可重復輸出的問題。具體而言，如果采用相同的種子值并且搭配相同的參數，那么所生成的輸出結果理應是完全一致的。從開發的角度來看，我們可以將這種現象理解為緩存操作。

接著是 “stop”，也就是停止序列。它的作用在于告知大模型，在生成文本的進程中，一旦遇到停止序列，便立即停止生成文本。

再看 “frequency_penalty”（頻率懲罰）和 “presence_penalty”（存在懲罰）。這兩個參數主要是用于降低內容重復出現的概率，這也是它們名稱中都帶有 “懲罰” 二字的原因。二者的區別在于，“frequency_penalty” 是依據一個 token 在已生成文本里出現的頻率來進行計算的，而 “presence_penalty” 則是根據一個 token 是否已經出現過進行計算。

“logit_bias”，即 logit 偏差。這里的 logit 是統計學中的一個函數。該參數的作用是在 logit 函數計算過程中對計算結果進行調整，其主要目的是改變某些 token 出現的可能性。例如，當我們不希望某些詞匯出現在最終結果中時，便可以借助此參數來實現。

“logprobs”：它用于確定是否返回對數概率。正如我們之前所提到的，大模型生成每個 token 都是有相應概率的。若設置了此參數，就能夠將這些概率以對數的形式返回。對于大模型開發人員而言，這有助于他們進行調試工作。

“top_logprobs”：該參數用于設定返回每個位置最有可能返回的 token 數量。在調試大模型時，除了想要知曉概率信息之外，有時我們還希望了解排名較為靠前的 token 都有哪些。通過設置這個參數，就能夠讓大模型返回這些排名靠前的 token。

最后是 “top_p”：這是另一種采樣方式，與 “temperature” 相對應。我們之前闡述過，“temperature” 決定了大模型如何選取下一個 token，而 “top_p” 則是另外一種采樣策略，即從概率排名靠前的若干 token 中進行選擇。在實際使用過程中，選擇 “top_p” 和 “temperature” 其中之一即可。

總結：

圖片