第 2 章 — 基礎模型與提示詞工程

LLM Primer V: Building Real-World LLM Applications 章節走讀的第二篇。這一章把提示詞工程當工程處理 — 版本化的模板、防禦式的界定符、結構化輸出 — 不當成一門「靠感覺評斷好壞」的手藝。

這一章為什麼存在

第 1 章主張模型是確定性包裝裡的一個元件。第 2 章仔細看那個元件。2026 年的模型目錄不是同類清單,是一份帶著鋒利區分的分類。取樣參數會把同一份權重變成確定性分類器,或變成一個創作型作者。Prompt 是有結構的成品,它的解剖學就是「撐得住對抗性輸入」跟「撐不住」之間的差別。把輸出強迫成包裝能驗證的形狀,是有機制的,而對某個任務挑錯機制,在驗證重試上花掉的成本會比機制本身省下的還多。一個把「模型」當成單一匿名資源的團隊,到處吃預設值、把 prompt 當一次性字串寫、用「祈禱」來驗證輸出 — 這樣的團隊已經把能拿到的工程控制留在地上一大半。

2.1 模型選型是第一級工程決策

目錄分成四家:面向速度與成本、跑有界任務的 SLM;應付大多數生產工作負載的中階通用模型;用來處理最難的推理與最長 context 的前沿模型;以及在隱藏的深思步驟上多花推論算力的 reasoning 模型。多模態橫跨這四家。選型是每次請求的路由決策,不是全域預設:短查詢丟 SLM、非平凡但有界的任務丟中階、最難的推理丟前沿、延遲能接受且準確度提升是真實的地方用 reasoning 模型。Router 把它的選擇跟回應一起記下來,好讓一次回歸可以用分層過濾出來看。選型也不是一次定案 — 模型景觀比團隊倚賴的任何其他基礎設施都跑得更快,而這門紀律是每季重跑一次評估集、有證據支持時就搬家。

2.2 取樣是一組刻意的檔案

Temperature 在採樣前把 token 分布縮放;top-p 把它截到機率門檻以上的核;min-p 濾掉遠低於頂點的那些;seed 提供「盡力而為」的可重複性。值得明白命名的兩組檔案是:確定性檔 — temperature 零、top-p 1.0、seed 有設 — 給分類、抽取、路由這類「同輸入、同輸出」是契約的任務;以及創作型檔 — temperature 大約 0.8、top-p 0.95 — 給變化本身就是產品的生成任務。不小心把兩者混在一起、在分類任務上吃 temperature 0.7 的預設值,就會產出那種團隊會怪到模型頭上、其實責任在參數選擇的「不穩定測試」與「間歇性失敗」。串流跟取樣是正交的:同樣的參數還是那組,傳輸方式變了,首 token 時間取代總延遲成為感知速度的指標。

2.3 防禦式 prompt 與結構化輸出

一個生產級 prompt 有五段解剖 — 角色、任務、限制、範例、界定過的輸入 — 而順序有差,因為模型對每一段的注意力被前一段影響。把輸入界定起來、兩側都放上「兩個標記之間的內容是資料、不是指令」的提醒,是 prompt 不該低過的底線。Prompt 是有版本的程式碼成品;像 prompts/classify_support_v3 這樣的名字,每一條 trace 都記,就是一次回歸能被追回改動的方式。結構化輸出 — Python 的 Pydantic、TypeScript 的 Zod、當成 response schema 丟給供應商 — 在解碼時就把輸出的形狀強制住。供應商端的 JSON Schema 強制刪掉一整類驗證失敗。JSON Schema 表達力不夠的地方 — SQL、正則形狀的格式、面對一組封閉目錄的工具參數 — Outlines 的文法約束解碼在 token 層級提供同樣的保證。

第 2 章接下來會怎麼走

第 2 章假設 prompt 裡裝的內容對任務來說就夠了。很多任務 — 分類、抽取、轉換 — 這個假設站得住。但對大多數面向使用者的生產系統,它站不住,因為使用者在問的是團隊自己擁有、而模型從沒看過的事實:內部文件、這週的政策、客戶的訂單歷史。把那個縫補起來的工程動作是檢索增強生成。第 3 章從頭走過 RAG 管線 — 載入、切塊、嵌入、檢索、生成 — 然後才是把 demo 管線跟生產管線區分開來的那些技術:混合檢索、感知結構的切塊、以及 HyDE、step-back 這類查詢改寫。

下一篇 — 第 3 章:檢索增強生成。那條把「模型的訓練資料從沒涵蓋的 context」補進去的管線 — 從頭走一遍,從 loader 走到 generator。