AI 工程 AI Engineering（Building Applications with Foundation Models）

📌 30 秒摘要（Layer 3）

過去做 AI 要先訓練模型；現在有了基礎模型（Foundation Models），重心轉為「如何用現成模型建出可靠的產品」。本書把 AI 工程拆成一條務實路徑：先用提示工程壓榨模型能力，不夠再用 RAG 補上外部知識，仍不夠才考慮微調；全程最關鍵、也最被低估的是評估（evaluation）——沒有可靠的評估，你根本不知道自己在進步還退步。最後談 Agent、推論最佳化與資料工程。

🗺 心智圖（Canvas）

AI工程

AI 工程

Chip Huyen｜用基礎模型建出可靠產品

🎛 調整手段的順序 提示 → RAG → 微調

工具-提示工程

🎯 什麼情境該想到我

當你用 LLM 但輸出不穩、不照指示、格式亂時——這是第一個、最便宜的調整手段。

⚙️ 怎麼用

1. 清楚具體的指示：說明角色、任務、限制、輸出格式；把「要什麼」講到不需要猜。
2. 給範例（few-shot）：示範幾組輸入→輸出，比純描述更有效。
3. 要求結構化輸出：指定 JSON/schema，方便下游程式解析、也減少亂答。
4. 引導推理：複雜任務讓它「先想再答」（分步/思考），別逼它一步跳到結論。
5. 迭代：用固定測試集比較不同版本（配 工具-AI系統評估），別憑感覺調。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 提示改一點行為可能大變 → 一定要有評估集把關，否則是在瞎調。

🔗 相關工具

• 工具-AI系統評估 —— 提示改一點行為就大變；沒有固定評估集比較版本，你只是在瞎調
• 工具-RAG檢索增強生成 —— 提示調到頂還是答錯事實時的下一步：把知識餵進上下文，而不是繼續改字

工具-RAG檢索增強生成

🎯 什麼情境該想到我

當模型「不知道你的私有/最新知識」、或你想讓它根據特定文件回答、並減少幻覺時。

⚙️ 怎麼用

1. 把知識切塊（chunking）並建索引：文件切成適當大小、轉成 embedding 存進向量庫。
2. 查詢時先檢索相關片段，再連同問題餵給模型：讓模型「有本可據」地回答。
3. 檢索品質決定成敗：好的 embedding、混合檢索（關鍵字 + 向量）、重排序（rerank）比「塞更多內容」重要。
4. 附上來源引用：讓答案可查證，也壓抑幻覺。

先試 RAG，通常比微調更快、更便宜、更好維護（知識更新只要換文件）。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 塞越多 context 不一定越好（會稀釋、變貴、變慢）；檢索的「準」比「多」重要。

🔗 相關工具

• 工具-提示工程 —— 上一段手段，成本更低；很多以為要 RAG 的問題其實調 prompt 就解決
• 工具-微調與RAG的取捨 —— 下一段的分岔點：缺知識走 RAG、缺風格與格式才考慮微調，這張講怎麼判
• 工具-AI系統評估 —— 沒有它就不知道 RAG 到底有沒有讓答案變準，檢索品質要能量化
• 工具-LLM安全防護 —— RAG 的暗面：檢索進來的文件正是間接提示注入的主要載體，接外部來源前先看它

工具-微調與RAG的取捨

🎯 什麼情境該想到我

當提示工程與 RAG 都試過還不夠，開始考慮「要不要微調一個模型」時。

⚙️ 怎麼用（先分清問題屬於哪一類）

• 缺「知識/事實」 → 用 RAG（換文件即可更新，別微調）。
• 缺「行為/風格/格式」（要固定語氣、特定輸出樣式、遵循領域慣例）→ 微調較合適。
• 順序：提示工程 → RAG → 微調。越後面越貴、越慢、越難維護。
• 微調前提：要有足量、高品質的標註資料 + 可靠的 工具-AI系統評估 來證明它真的更好。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 微調不會「教模型新事實」得可靠（仍會幻覺）；事實類需求優先 RAG。微調也會綁死模型版本、增加維運負擔。

🔗 相關工具

• 工具-提示工程 —— 三段順序的第一段，成本最低；多數「模型不聽話」的問題到這裡就解決了，不必走到微調
• 工具-RAG檢索增強生成 —— 判定屬於「缺知識/事實」時的正解：換文件就能更新，別為了灌事實去微調
• 工具-AI系統評估 —— 微調的硬前提，沒有可靠評估集就無法證明微調後真的比較好，只是換個貴的方式瞎調
• 工具-LLM微調實作路線 —— 判定「該微調」之後的下一步：Full／LoRA／QLoRA 怎麼選、要多少顯存

📏 評估：核心難題 沒有評估就是盲目開發

工具-AI系統評估

🎯 什麼情境該想到我

當你「改了 prompt/模型/RAG，卻不知道到底變好還變壞」——這是 AI 工程最核心也最被低估的能力。

⚙️ 怎麼用

1. 先建一組評估集：代表性的輸入 + 你要的判準（正確性、相關性、格式、無害…）。
2. 選評估方法：
   • 有標準答案 → 用自動指標（精確比對、相似度）。
   • 開放式輸出 → LLM-as-judge（用另一個模型當評審）+ 人工抽檢校準。
3. 每次改動都跑同一評估集，比較分數再決定要不要採用（別憑一兩個例子的感覺）。
4. 上線後持續監控：抽樣真實流量做線上評估，抓退化。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• LLM-as-judge 本身也有偏誤，要用人工樣本校準它；沒有評估的迭代＝盲調。

🔗 相關工具

• 工具-提示工程 —— 評估發現品質不佳時，這是成本最低的第一個調整手段，先試它再考慮更貴的路
• 工具-RAG檢索增強生成 —— 評估若指出問題是「缺知識/講錯事實」，正解是接 RAG 而不是調 prompt
• 工具-微調與RAG的取捨 —— 微調的硬前提就是這張卡：沒有可靠評估集，微調完也無法證明真的變好
• 工具-LLM微調實作路線 —— 微調後有沒有變好，只能靠這裡的評估集回答，不能靠感覺
• 工具-偏好對齊方法選擇 —— 對齊調的是語氣與有用程度，最需要評估集把「主觀變好」變成可驗收的數字
• 工具-模型量化格式選擇 —— 量化號稱只掉 3–5%，實際掉多少要用自己的評估集量過才算數

🤖 Agent 規劃 × 工具 × 記憶

工具-AI-Agent設計

🎯 什麼情境該想到我

當你想讓模型「自己規劃步驟、呼叫工具、完成多步任務」（而非一問一答）時。

⚙️ 怎麼用

1. 三要素：規劃（把目標拆成步驟）＋ 工具使用（呼叫 API/函式取得能力）＋ 記憶（跨步驟保留上下文）。
2. 把工具定義清楚：每個工具的用途、參數、回傳都要明確，讓模型知道何時用哪個。
3. 給護欄：限制可用工具、步數上限、危險動作要人工確認、對輸出做驗證。
4. 可觀測：記錄每一步的決策與工具呼叫，方便除錯與評估。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• Agent 強大但難控、易失控、成本高、錯誤會累積放大。能用簡單流程（提示+RAG）解決就別上 agent。

🔗 相關工具

• 工具-提示工程、工具-AI系統評估、工具-服務容錯設計（給 agent 加護欄與限流）
• 工具-LLM安全防護 —— Agent 的風險放大在這裡：能呼叫工具代表注入成功的後果從「說錯話」升級成「做錯事」

⚡ 推論最佳化 與資料工程

延遲 × 成本 × 品質 的三角取捨 （本書關鍵重點，尚無獨立工具卡）

Link to original

🧰 這本書給我的工具

• 工具-提示工程 — 想讓模型輸出更準更穩時（第一手段）
• 工具-RAG檢索增強生成 — 模型缺你的私有/最新知識時
• 工具-AI系統評估 — 想知道 AI 系統到底好不好、有沒有變好時
• 工具-微調與RAG的取捨 — 提示與 RAG 都不夠、考慮微調時
• 工具-AI-Agent設計 — 要讓模型自主使用工具完成多步任務時

✨ 關鍵重點（Layer 1–2）

• 調整手段的順序：提示工程 → RAG → 微調（由便宜到昂貴、由快到慢）。
• 評估是核心難題：開放式輸出難評；用 AI 當評審（LLM-as-judge）、對照基準、人工抽檢並用。
• RAG：檢索品質（embedding + 檢索策略）決定成敗，不是塞越多越好。
• 幻覺（hallucination）：靠 RAG 接地、結構化輸出與評估來壓制。
• Agent：規劃 + 工具使用 + 記憶；強大但難控、成本高、要防失控。
• 推論最佳化與資料工程：延遲/成本/品質的三角取捨。

💬 金句原文（Layer 0）

• 「沒有評估，你就是在盲目地開發。」

🔗 相關

• 建 AI 應用時仍受用 工具-可靠可擴展可維護、工具-管理複雜度
• 產品化提示/工具定義的最佳實務見 Claude API 相關資源