AI 工程
Chip Huyen|用基礎模型建出可靠產品
🎛 調整手段的順序 提示 → RAG → 微調
🎯 什麼情境該想到我
當你用 LLM 但輸出不穩、不照指示、格式亂時——這是第一個、最便宜的調整手段。
⚙️ 怎麼用
- 清楚具體的指示:說明角色、任務、限制、輸出格式;把「要什麼」講到不需要猜。
- 給範例(few-shot):示範幾組輸入→輸出,比純描述更有效。
- 要求結構化輸出:指定 JSON/schema,方便下游程式解析、也減少亂答。
- 引導推理:複雜任務讓它「先想再答」(分步/思考),別逼它一步跳到結論。
- 迭代:用固定測試集比較不同版本(配 工具-AI系統評估),別憑感覺調。
🧪 我實際套用的紀錄
- 2026-07-15:(待填)
⚠️ 注意
- 提示改一點行為可能大變 → 一定要有評估集把關,否則是在瞎調。
🔗 相關工具
- 工具-AI系統評估 —— 提示改一點行為就大變;沒有固定評估集比較版本,你只是在瞎調
- 工具-RAG檢索增強生成 —— 提示調到頂還是答錯事實時的下一步:把知識餵進上下文,而不是繼續改字
🎯 什麼情境該想到我
當模型「不知道你的私有/最新知識」、或你想讓它根據特定文件回答、並減少幻覺時。
⚙️ 怎麼用
- 把知識切塊(chunking)並建索引:文件切成適當大小、轉成 embedding 存進向量庫。
- 查詢時先檢索相關片段,再連同問題餵給模型:讓模型「有本可據」地回答。
- 檢索品質決定成敗:好的 embedding、混合檢索(關鍵字 + 向量)、重排序(rerank)比「塞更多內容」重要。
- 附上來源引用:讓答案可查證,也壓抑幻覺。
先試 RAG,通常比微調更快、更便宜、更好維護(知識更新只要換文件)。
🧪 我實際套用的紀錄
- 2026-07-15:(待填)
⚠️ 注意
- 塞越多 context 不一定越好(會稀釋、變貴、變慢);檢索的「準」比「多」重要。
🔗 相關工具
- 工具-提示工程 —— 上一段手段,成本更低;很多以為要 RAG 的問題其實調 prompt 就解決
- 工具-微調與RAG的取捨 —— 下一段的分岔點:缺知識走 RAG、缺風格與格式才考慮微調,這張講怎麼判
- 工具-AI系統評估 —— 沒有它就不知道 RAG 到底有沒有讓答案變準,檢索品質要能量化
- 工具-LLM安全防護 —— RAG 的暗面:檢索進來的文件正是間接提示注入的主要載體,接外部來源前先看它
🎯 什麼情境該想到我
當提示工程與 RAG 都試過還不夠,開始考慮「要不要微調一個模型」時。
⚙️ 怎麼用(先分清問題屬於哪一類)
- 缺「知識/事實」 → 用 RAG(換文件即可更新,別微調)。
- 缺「行為/風格/格式」(要固定語氣、特定輸出樣式、遵循領域慣例)→ 微調較合適。
- 順序:提示工程 → RAG → 微調。越後面越貴、越慢、越難維護。
- 微調前提:要有足量、高品質的標註資料 + 可靠的 工具-AI系統評估 來證明它真的更好。
🧪 我實際套用的紀錄
- 2026-07-15:(待填)
⚠️ 注意
- 微調不會「教模型新事實」得可靠(仍會幻覺);事實類需求優先 RAG。微調也會綁死模型版本、增加維運負擔。
🔗 相關工具
- 工具-提示工程 —— 三段順序的第一段,成本最低;多數「模型不聽話」的問題到這裡就解決了,不必走到微調
- 工具-RAG檢索增強生成 —— 判定屬於「缺知識/事實」時的正解:換文件就能更新,別為了灌事實去微調
- 工具-AI系統評估 —— 微調的硬前提,沒有可靠評估集就無法證明微調後真的比較好,只是換個貴的方式瞎調
- 工具-LLM微調實作路線 —— 判定「該微調」之後的下一步:Full/LoRA/QLoRA 怎麼選、要多少顯存
📏 評估:核心難題 沒有評估就是盲目開發
🎯 什麼情境該想到我
當你「改了 prompt/模型/RAG,卻不知道到底變好還變壞」——這是 AI 工程最核心也最被低估的能力。
⚙️ 怎麼用
- 先建一組評估集:代表性的輸入 + 你要的判準(正確性、相關性、格式、無害…)。
- 選評估方法:
- 有標準答案 → 用自動指標(精確比對、相似度)。
- 開放式輸出 → LLM-as-judge(用另一個模型當評審)+ 人工抽檢校準。
- 每次改動都跑同一評估集,比較分數再決定要不要採用(別憑一兩個例子的感覺)。
- 上線後持續監控:抽樣真實流量做線上評估,抓退化。
🧪 我實際套用的紀錄
- 2026-07-15:(待填)
⚠️ 注意
- LLM-as-judge 本身也有偏誤,要用人工樣本校準它;沒有評估的迭代=盲調。
🔗 相關工具
- 工具-提示工程 —— 評估發現品質不佳時,這是成本最低的第一個調整手段,先試它再考慮更貴的路
- 工具-RAG檢索增強生成 —— 評估若指出問題是「缺知識/講錯事實」,正解是接 RAG 而不是調 prompt
- 工具-微調與RAG的取捨 —— 微調的硬前提就是這張卡:沒有可靠評估集,微調完也無法證明真的變好
- 工具-LLM微調實作路線 —— 微調後有沒有變好,只能靠這裡的評估集回答,不能靠感覺
- 工具-偏好對齊方法選擇 —— 對齊調的是語氣與有用程度,最需要評估集把「主觀變好」變成可驗收的數字
- 工具-模型量化格式選擇 —— 量化號稱只掉 3–5%,實際掉多少要用自己的評估集量過才算數
🤖 Agent 規劃 × 工具 × 記憶
🎯 什麼情境該想到我
當你想讓模型「自己規劃步驟、呼叫工具、完成多步任務」(而非一問一答)時。
⚙️ 怎麼用
- 三要素:規劃(把目標拆成步驟)+ 工具使用(呼叫 API/函式取得能力)+ 記憶(跨步驟保留上下文)。
- 把工具定義清楚:每個工具的用途、參數、回傳都要明確,讓模型知道何時用哪個。
- 給護欄:限制可用工具、步數上限、危險動作要人工確認、對輸出做驗證。
- 可觀測:記錄每一步的決策與工具呼叫,方便除錯與評估。
🧪 我實際套用的紀錄
- 2026-07-15:(待填)
⚠️ 注意
- Agent 強大但難控、易失控、成本高、錯誤會累積放大。能用簡單流程(提示+RAG)解決就別上 agent。
🔗 相關工具
- 工具-提示工程、工具-AI系統評估、工具-服務容錯設計(給 agent 加護欄與限流)
- 工具-LLM安全防護 —— Agent 的風險放大在這裡:能呼叫工具代表注入成功的後果從「說錯話」升級成「做錯事」
⚡ 推論最佳化 與資料工程
延遲 × 成本 × 品質 的三角取捨 (本書關鍵重點,尚無獨立工具卡)