從模型到產品：你的第一個大型語言模型應用

模型還不是產品

你可以打開一個聊天視窗、輸入一段巧妙的提示，然後得到一個出色的答案。那是一個展示（demo），不是一個產品。建構大型語言模型應用意味著把一個大型語言模型（large language model）包裹在真實使用者所需的一切之中：可靠的介面、合理的預設值、錯誤處理、安全性、成本控制，以及一種能判斷它是否真的有效的方法。模型只是其中一個元件——而且往往是最容易加上去的那個。

和模型對話：API 整合

API 整合是管線工程。你送出一個請求——一串訊息加上像溫度（temperature）與 token 上限這類設定——然後收到一個完成（completion）。從第一天起就有兩個重要模式。第一，使用串流（streaming），讓使用者看到文字逐漸浮現，而不是盯著一個轉圈圈的圖示十秒。第二，當你需要機器可讀的輸出時，要求JSON 模式或受限的結構，這樣你就能解析答案，而不是用正規表示式去硬抓散文。

POST /v1/messages
{
  "model": "<your-model>",
  "max_tokens": 512,
  "temperature": 0.2,
  "stream": true,
  "system": "You are a support agent for Acme. Answer only from the given context.",
  "messages": [
    { "role": "user", "content": "How do I reset my password?" }
  ]
}

一個典型的請求：system 角色設定行為、低溫度讓它可預測、串流讓它有反應。

為產品做提示工程（不是在遊樂場）

為產品做提示工程和聰明的一次性提示（prompting）不同。遊樂場（playground）裡的提示只要對你、只要成功一次就好。產品裡的提示必須對每一位使用者、在你從未見過的輸入上、每次都以同樣的方式有效。於是你不再手動微調字串，而開始把提示當成有版本控管的資產：一段定義角色與規則的穩定系統提示（system prompt）、一個有欄位可填入使用者資料的可重用模板（template），以及對真實使用者會送出的空白、惡意與荒謬輸入的明確處理。

把系統提示寫成一份契約：助理是誰、它必須永遠做什麼、它絕不能做什麼，以及確切的輸出格式。
把會變動的資料放進模板中界線清楚的欄位，絕不要黏進指令裡，以免使用者把指令蓋掉。
只有在格式難以用文字描述時，才加上幾個示範（few-shot）；示範在每次呼叫時都要花 token。
為提示加上版本，並記錄哪個版本產生了哪個輸出，這樣回歸（regression）才追得回去。

應用會長成的形狀

大多數大型語言模型產品都是少數幾種應用模式（application patterns）的重新混搭。聊天機器人維持一段對話；摘要器或擷取器把長輸入對映成短的結構化輸出；分類器把請求導向某個類別；副駕（copilot）在使用者本來就在操作的工具裡建議修改；檢索增強助理透過檢索增強生成（RAG）從你的文件作答；代理（agent）則會規劃並使用工具來完成多步驟任務。知道你在建的是哪一種模式，就知道該擔心哪些風險——分類器需要準確度指標，代理則需要護欄與復原機制。

這個學習軌的去向

你現在有了四個基礎：應用思維、API 整合、產品提示，以及模式。這個學習軌接下來會加上那些把週末展示和「敢掛上公司名字」的東西區隔開來的層次——選擇架構、以評測與護欄上線、讓它又快又負擔得起，最後則是代理式系統的前沿與負責任的部署。