笨問題 - OpenAI 模型的「聊天完成」跟「回應」是什麼意思？

2026-05-07 09:10 PM

上回參加微軟 AI Summit Taipei，Microsoft Foundry(原本的 Azure AI Foundry)這個名詞被提了又提，而這陣子查文件，發現 MS Agent Framework 官方範例愈來愈多是以部署在 Foundry 專案的模型示範。而這幾天興起看了一下 Github Copilot 要怎麼接第三方或地端模型，赫然發現，原本的 AI Tools for VSCode 也已更名為 Foundry Toolkit for VSCode：

然後地端模型是透過「Foundry Local via AI Tools」連接...

答案很明顯，未來要用 AOAI 開發 Agent 或用 Github Copilot 整合外部模型，Foundry 已成必修程課。目前在 Azure 部署模型時可沿用傳統 Azure OpenAI 做法或是新建 Foundry 專案，用 Foundry 的優點是除 OpenAI 模型外，還可部署 Claude、Meta ollama、Mistral、grok、Deepseek 等各家模型，並包含 Agent 管理、監控與 AI 治理功能，目前 AOAI 的模型管理已移到 Foundry Portal，而且還會熱心推薦你改用 Foundry，推測未來 Azure 的 AI 應用都會收攏到 Foundry 統一管理吧!

既然如此，於是我也開了個 Foundry 專案，體驗在 Foundry 專案部署模型，但一開始被兩件小事困惑。

首先，有些模型旁有長條圖 Icon，標示「基準」，查了一下，指的是這些模型已做過 Benchmark，有效能評測數據可參考，在 Foundry 的模型目錄區也有排行榜及性價比分析圖，可作為挑選模型的參考。

至於第二個問題，是有些模型標示「聊天完成」跟「回應」(如 gpt-5.4-nano、gpt-5.4-mini、gpt-5.4)，有些則只有「回應」(如 gpt-5.3-codex、gpt-5.2-codex)。我的 OpenAI API 開發經驗有限，便花了些時間搞懂，補上知識缺口。

這些名詞指的 OpenAI 模型所提供的端點，總共有幾種：

Responses API (/v1/responses)
這是 2025 年後推廣的新一代介面，用以取代複雜的 Assistants API。它將文字、圖片、代碼解譯器 (Code Interpreter) 以及工具調用 (Tool Calling) 整合於單一呼叫，適合用於開發 Agent 應用。
Chat Completions API (/v1/chat/completions)
目前很常用的標準介面(我之前的練習清一色都是它)，與 Responses API 相比的一大優勢是能精確控制對話歷史，是實現決定性 (Determinism) 與自定義 RAG 流程的首選。
Completions API (/v1/completions)
主要用於較舊版模型 (如 gpt-3.5-turbo-instruct)，輸入為單一字串而非對話列表，目前新模型已不再支援。
Realtime API (/v1/realtime)
支援語音對語音 (Speech-to-Speech) 的低延遲互動，適合開發語音助手或需要即時反應的 AI 應用。
Videos API (/v1/videos)
配合 Sora 2 模型推出的介面，可用於生成與編輯高擬真短影片，Sora 2 熄燈後就暫時沒用了。
Images API (/v1/images/generations)
用於 DALL·E 系列及 2026 年新 GPT Image 模型，可處理圖像生成、編輯與變體。
Embeddings API (/v1/embeddings)
將文字轉換為向量，開發向量搜尋與 RAG 系統必備。
Batch API (/v1/batches)
如果不需即時回應，可將大量請求(如 5 萬筆數據分類)打包上傳批次處理，優點是價格打 5 折，且通常在 24 小時內完成。
Moderations API (/v1/moderations)
用來檢查輸入內容是否違反安全政策(如仇恨言論、自殘等)，通常是免費或極低成本。
Files API (/v1/files)
用於上傳訓練數據(Fine-tuning)或供工具使用的文檔。
Fine-tuning API (/v1/fine_tuning/jobs)
管理模型微調任務。
Vector Stores API (/v1/vector_stores)
管理 Assistants/Responses 介面內建的檢索數據庫。

模型上標示著「聊天完成」跟「回應」，便意味著其有提供 Chat Completions 及 Responses 等端點。

上面提到 Chat Completions 的優點是可以完全掌控交談歷史上下文，反過來說，Responses 有個好處是模型能自動保存交談記錄，不像在先前寫的 ChatClient 範例，必須自行蒐集並每次傳入之前的對話內容(範例程式)，或在 Agent Framework 用 AgentSession 物件保存(參考：簡單寫個能讀網頁會看圖的 LINE AI 助理 - 我的 .NET 黑殼蝦)。這個特性有好有壞，有時我們需要精確控制當次丟給模型的上下文以提升回答的品質；但對於 Agent 之類的任務執行，交給模型來做顯然更省事。

我寫了一小段程式來展現二者的區別：(如何在 .NET 專案使用 Foundry SDK 可參考 MS Learn 文件)

using System.Reflection.Metadata;
using Azure.AI.Projects;
using Azure.Identity;
using OpenAI.Chat;

DotNetEnv.Env.Load();

var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")
    ?? throw new InvalidOperationException("Set AZURE_OPENAI_ENDPOINT");
var apiKey = Environment.GetEnvironmentVariable("AZURE_OPENAI_APIKEY")
    ?? throw new InvalidOperationException("Set AZURE_OPENAI_APIKEY");
var deploymentName = "gpt-5.3-chat";

// Endpoint URL 格式為 https://<foundry-resource-name>.services.ai.azure.com
// Foundry ProjectClient 使用 EntraID 驗證，不支援 API Key 登入
AIProjectClient projectClient = new AIProjectClient(
    endpoint: new Uri(endpoint),
    tokenProvider: new DefaultAzureCredential());

string[] msgs = new string[]
{
    "Hi, my name is Jeffrey, nice to meet you.",
    "Calculate 1+1 for me.",
    "What is my name?"
};

Action<string, string, ConsoleColor> print = (role, msg, color) =>
{
    Console.ForegroundColor = color;
    Console.Write($"{role}: ");
    Console.ResetColor();
    Console.WriteLine(msg);
};

Console.WriteLine($"\n=== Using ChatClient ({deploymentName}) ===\n");
var chatClient = projectClient.ProjectOpenAIClient
    .GetChatClient(deploymentName);
foreach (var msg in msgs)
{
    print ("User", msg, ConsoleColor.Yellow);
    var response = await chatClient.CompleteChatAsync(new List<ChatMessage>()
    {
        new SystemChatMessage("You are a helpful assistant."),
        new UserChatMessage(msg)
    });
    print("Assistant", response.Value.Content[0].Text, ConsoleColor.Cyan);
}

Console.WriteLine($"\n=== Using ProjectResponsesClient ({deploymentName}) ===\n");
var responseClient = projectClient.ProjectOpenAIClient
    .GetProjectResponsesClientForModel(deploymentName);
string respId = null!;
foreach (var msg in msgs)
{
    print("User", msg, ConsoleColor.Yellow);
    var response = await responseClient.CreateResponseAsync(msg, respId);
    respId = response.Value.Id;
    print("Assistant", response.Value.GetOutputText(), ConsoleColor.Cyan);
}

測試採用 gpt-5.3-chat 模型，分別使用 Chat Completion 及 Responses 端點進行三次對話，傳送內容刻意不包含先前的歷史交談內容。結果如下：

一如預期，第一句開場有自我介紹，但最後詢問模型我的名字時，Chat Completion API 表現得像失憶患者，有禮貌地說我還沒跟他說，而 Responses API 則默默記住(先決條是每次要帶入 Response ID 參數)，由此驗證二者的特性差異。

至於一開始提到，像 gpt-5.3-chat 支援「聊天完成」跟「回應」，而 gpt-5.3-codex 只有「回應」，便會影響不同應用情境的模型選擇。例如，我們將程式碼裡的 var deploymentName = "gpt-5.3-chat"; 改成 gpt-5.3-codex，由於它不支援 Chat Completion，在 chatClient.CompleteChatAsync() 時會噴出 HTTP 400 錯誤：