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系統評估），別憑感覺調。

★ 書中的五條最佳實踐（《AI 工程》第 5 章）

書說這些是從 OpenAI、Anthropic、Meta、Google 的提示指南以及成功上線的團隊經驗中提煉出來、對大多數模型都有效的通用技巧；早期那些「寫 Q: 而不是 Questions:」「承諾給 300 美元小費」的招數，會隨著模型變強而失效。

實踐	具體做法
寫清楚明確的指令	無歧義地說明要做什麼（例：評分標準是 1–5 還是 1–10？遇到不確定時怎麼辦？）；請模型扮演角色；給範例；指定輸出格式
提供足夠的脈絡	把需要的資料放進提示；需要時限制模型只能用提供的資訊回答
把複雜任務拆成簡單的子任務	例：先分類客服問題的類型，再依類型用不同的提示處理
給模型時間思考	要求逐步推理（chain-of-thought）或自我批判
迭代提示	每次修改都用同一組測試比較

書也提醒拆解與 CoT 的代價：更多次模型呼叫、更多 token → 延遲與成本上升。

★ 拆解的好處不只是準確度

書列出拆解提示的其他好處，工程上特別重要的是：

• 監控：可以分別看每個子任務的表現，知道是哪一步出錯。
• 除錯：失敗時可以定位到具體的子提示。
• 平行化：互不依賴的子任務可以同時送出。
• 省力：寫簡單的提示比寫複雜的提示容易。

缺點是使用者感受到的延遲可能增加，尤其是使用者看不到中間輸出的任務。

★ 把提示當成程式碼管理

書建議把提示和程式碼分開：放在獨立的檔案（或提示目錄），程式碼用名稱引用。好處包括：

• 多個應用可以重用同一個提示。
• 提示可以獨立測試。
• 非工程人員（領域專家）可以參與修改提示，而不用碰程式碼。

更進一步，書建議為每個提示附上中繼資料：適用的模型、建立日期、用在哪個應用、建立者；提示模板也可以記錄理想的取樣參數（temperature、top-p）與輸入／輸出的 schema。記錄模型特別重要——同一個提示換了模型，行為可能完全不同。在 Go 裡可以用 embed 把提示檔在編譯時嵌入二進位檔，版本跟著程式碼一起走：

//go:embed prompts/classify_ticket.v3.md
var classifyTicketPrompt string

★ 提示修改的評估流程

1. 建一組固定的測試案例（包含典型案例與過去出錯的案例）。
2. 修改前跑一次，記錄結果。
3. 修改提示。
4. 再跑一次，比較整體分數，也看個別案例的變化——改善了 5 個案例、弄壞了 2 個，要知道是哪 2 個。

沒有評估集就改提示，就像沒有測試就重構（見 工具-AI系統評估、工具-AI改動的AB對照評測）。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

• 提示是攻擊面：使用者輸入和檢索進來的文件都可能包含「忽略前面的指令」這類注入。系統提示不是安全邊界，權限控制要在程式碼層做（見 提示注入與分層防禦）。

• 長而固定的系統提示可以利用前綴快取降低成本與延遲：把不變的部分放在最前面，變動的部分放在後面（見 前綴快取 Prompt Caching）。

🔗 相關工具

• 工具-AI系統評估 —— 提示改一點行為就大變；沒有固定評估集比較版本，你只是在瞎調
• 工具-RAG檢索增強生成 —— 提示調到頂還是答錯事實時的下一步：把知識餵進上下文，而不是繼續改字
• 工具-上下文學習的示例怎麼挑怎麼排、工具-思維鏈的變體怎麼選 —— 範例怎麼挑、什麼時候該或不該叫模型一步一步想（含「對話模型加了反而變差」的反向條件）

工具-RAG檢索增強生成

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

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

★ 答錯的時候，先分清是哪一段壞了

RAG 有兩段：檢索和生成。答錯時要先判斷是哪一段：

檢查	結果	問題在
正確答案所在的文件片段，有沒有被檢索回來？	沒有	檢索：切塊、檢索方法、查詢改寫
有被檢索回來，但排在後面（例如第 15 名，只取前 5）	排名問題	重排序或 top-k 設定
有在提供給模型的內容中，但模型沒有用它	生成問題	提示、脈絡太長導致重點被淹沒、模型能力
模型用了它，但答案還是錯	來源本身有問題	文件過時、互相矛盾

實務做法：為評估集中的每個問題標註「正確答案在哪個文件片段」，就可以分別量檢索的召回率（正確片段有沒有出現在前 k 名）和生成的正確率。兩個數字分開看，才知道該優化哪一段（見 RAG 評估與營運）。

★ 《AI 工程》的建議：先從簡單的檢索開始

書的建議是先用關鍵字檢索（如 BM25），不要一開始就上向量資料庫。理由：

• BM25 不需要 embedding 模型、不需要向量索引，建置與維運成本低很多。
• 對於專有名詞、產品型號、錯誤代碼這類精確比對的查詢，關鍵字檢索常常比語意檢索更準。
• 先有一個簡單的基準，才能量出換成向量檢索或混合檢索到底改善了多少。

兩種檢索各自擅長的情況與混合的方法 → 稀疏與密集檢索。

★ 切塊大小的取捨

片段太小	片段太大
失去上下文，片段本身看不懂（「它的上限是 50」——「它」是什麼？）	一個片段混了好幾個主題，embedding 變模糊，檢索不準
需要取更多片段才能湊齊資訊	塞進提示的無關內容變多，成本與延遲上升

常見做法：依文件結構切（標題、段落），而不是固定字數硬切；相鄰片段保留少量重疊；在每個片段前面加上它所屬文件與章節的標題。細節 → 切塊與文件解析。

★ 動手之前先問：這個知識庫還需不需要 RAG？

（補充自 https://juejin.cn/post/7690218295266066441，原始出處 Anthropic Introducing Contextual Retrieval，逐字查證 2026-09-28）

「If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt that you give the model, with no need for RAG.」

20 萬 token ≈ 500 頁是一條很實用的分界：低於它，全塞 Prompt ＋ 前綴快取 Prompt Caching 通常比維護一整條檢索管線划算。

但企業場景有三樣東西長上下文給不了，這三樣才是 RAG 真正不可取代的理由：

	為什麼長上下文做不到
權限隔離	「誰能看哪一部分」無法靠塞進同一個 prompt 解決 → 權限感知檢索與引用歸因
資料新鮮度	文件一直在變，全塞等於每次都要重灌
成本	每個請求都塞全庫，帳單隨流量線性成長

所以判準不是「庫有多大」，而是：小庫 + 無權限需求 + 不常變 → 別做 RAG。

★ 別追架構，先給問題分類（GraphRAG 值不值得交那筆稅）

同樣來源。GraphRAG 熱起來之後「上圖譜」一度變成政治正確，但不存在普適最優的 RAG 架構，存在的是「問題類型 → 架構」的路由表：

問題類型	誰比較行	為什麼
單跳事實（「XX 的營業時間」）	樸素 RAG + 重排就夠	答案就在某一塊裡，多繞路只是增加成本與延遲
多跳關聯（「A 的負責人審批的部署歸誰管」）	圖譜 / Agentic	這條關係鏈在向量空間裡根本沒有表示
全局歸納（「這批文件的主題是什麼」）	⚠️ 證據分歧，見下	切片檢索天然答不了全局歸納，但圖譜是否真的較好有爭議

先統計自己評測集裡的題型分布，再決定要不要交圖譜的稅——八成日常請求是單跳事實題。

⚠️ 「全局歸納該上 GraphRAG」這件事，2026 年的證據是分歧的，別當定論。
WildGraphBench（arXiv 2602.02053，2026-02，1,100 題涵蓋 single-fact / multi-fact / section-level summarization）的結論是：GraphRAG 在 multi-fact aggregation 有幫助，但
「may overemphasize high-level statements at the expense of fine-grained details, leading to weaker performance on summarization tasks」
——section-level summarization 正是「全局歸納」，而它在那一格是較弱的。

Do We Still Need GraphRAG?（arXiv 2604.09666，2026-04）則發現：agentic search 大幅拉抬 dense RAG、縮小與 GraphRAG 的差距，GraphRAG 的優勢集中在複雜多跳推理，且要「offline cost 被攤提之後」才划算。

兩篇合起來的實務結論：GraphRAG 的明確主場是「多跳關係查詢」，不是「全局歸納」。
網路上流傳的「全局歸納 GraphRAG 顯著占優」附帶的精確百分比，我查了上述兩篇的摘要都找不到對應數字，無法定位出處，不要拿它做決策依據。

代價那一欄也要看：GraphRAG 的圖構建成本比一般 RAG 高出一到兩個數量級（每份語料要跑大量 LLM 呼叫抽實體與關係）。輕量化路線有 LightRAG（arXiv 2410.05779，雙粒度檢索）與 HippoRAG（arXiv 2405.14831，Personalized PageRank 一步多跳），但**「圖構建稅」這筆錢總是要交**。

★ 一句話：知道哪筆稅不用交，也是能力的一部分。 語料小、互動歷史短，就別為了架構時髦去付它。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

• 機制層深潛 → 切塊與文件解析、稀疏與密集檢索、Reranker 重排序、向量索引 ANN、查詢改寫與 HyDE、權限感知檢索與引用歸因、RAG 評估與營運
• 工具-提示工程 —— 上一段手段，成本更低；很多以為要 RAG 的問題其實調 prompt 就解決
• 工具-微調與RAG的取捨 —— 下一段的分岔點：缺知識走 RAG、缺風格與格式才考慮微調，這張講怎麼判
• 工具-AI系統評估 —— 沒有它就不知道 RAG 到底有沒有讓答案變準，檢索品質要能量化
• 工具-對話型AI的長期記憶分層 —— RAG 用在「對話記憶」的特例：摘要保大綱、向量找回被截掉的原文
• 工具-LLM安全防護 —— RAG 的暗面：檢索進來的文件正是間接提示注入的主要載體，接外部來源前先看它
• Agent 記憶設計 —— 「查靜態文件」與「記住互動歷史」是兩個物種，別用同一套解

工具-微調與RAG的取捨

🎯 什麼情境該想到我

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

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

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

★ 書中的一句話原則

《AI 工程》第 7 章：

「簡單說，微調是為了形式，RAG 是為了事實。」

• RAG 給模型外部知識，讓答案更準確、更有資訊量，可以緩解幻覺。
• 微調幫助模型理解並遵循語法與風格。書特別提醒：有足夠的高品質資料時，微調可能減少幻覺；但資料品質差時，反而會讓幻覺變嚴重。

★ 兩種問題都有時：先做 RAG

書的建議：模型同時有資訊問題和行為問題時，先從 RAG 開始。理由：

1. RAG 比較容易——不需要整理訓練資料，也不需要託管微調後的模型。
2. 做 RAG 時先從簡單的關鍵字檢索（如 BM25）開始，不要一開始就上向量資料庫。
3. RAG 的效果提升可能比微調更大：書引用 Ovadia 等人（2024）的研究，在 MMLU 的幾乎所有題目類別中，RAG 對 Mistral 7B、Llama 2-7B、Orca 2-7B 三個模型的表現都優於微調。

★ 兩者可以疊加，但不保證有效

同一份研究中，在微調過的模型上再加 RAG，只有 43% 的情況比單用 RAG 更好；另外 57% 的情況沒有改善。所以「兩個都上」不是預設答案，要用評估集驗證。

★ 什麼問題適合微調：書中的例子

問題	為什麼微調有用
輸出格式錯誤，例如產生的 HTML 無法編譯	模型在訓練資料中看到的 HTML 不夠，微調可以讓它接觸更多
語意解析：把自然語言轉成結構化格式	強大的現成模型處理 JSON、YAML、regex 這類常見語法沒問題，但對網路上範例很少的語法（小眾工具的 DSL、複雜語法）表現較差
輸出技術上正確，但缺少團隊需要的細節與風格	用符合要求的範例微調，讓輸出更貼近需求

★ 決策流程

問題是「模型不知道某些事」？
├─ 是 → RAG（先從 BM25 開始）
└─ 否，是「模型不照我要的方式回答」？
    ├─ 先試提示工程（加範例、指定格式、結構化輸出）
    ├─ 還是不行，而且有 ≥ 數百筆高品質範例 → 微調（先試 LoRA 這類參數高效方法）
    └─ 沒有足夠資料 → 回頭改善提示，或先蒐集資料

微調的具體技術選擇 → LoRA 與 QLoRA、PEFT 方法比較；微調的副作用 → 災難性遺忘。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

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

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

工具-AI系統評估

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 機制層深潛

• 沒有標註時怎麼建評估集 —— 沒有 ground truth 時的六層成本階梯與行為測試
• LLM-as-Judge —— 六種已知偏誤與怎麼驗證裁判本身
• 幻覺偵測 —— groundedness 怎麼算、怎麼分層歸因
• 上線閘門與線上評估 —— 把評估變成 CI gate 與線上 A/B
• Benchmark 污染與分數失真 —— 為什麼分數漲了體感反而掉
• Agent 評估 —— pass@k vs pass^k 與可重置的評估環境
• LLM 可觀測性 —— 評估所需的遙測基礎

🔗 相關工具

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

🤖 Agent 規劃 × 工具 × 記憶

工具-AI-Agent設計

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

★ 為什麼 agent 的要求比一般應用高：錯誤會累積

《AI 工程》第 6 章給出一個直接的計算：

如果模型每一步的正確率是 95%，走 10 步後整體正確率降到 60%，走 100 步後只剩 0.6%。

驗算：$0.95^{10}\approx 0.599$，$0.95^{100}\approx 0.0059$。

推論：

• 步數是 agent 的頭號風險。能用 3 步完成的設計，不要用 10 步。
• 每一步的正確率提升 1%，在長流程上的效果會被放大：$0.96^{10}\approx 0.66$，$0.99^{10}\approx 0.90$。
• 在關鍵的步驟之間加驗證（檢查工具回傳的結果、確認中間狀態），等於重設累積的錯誤。

書也指出第二個原因：風險更高——agent 能使用工具，所以能做更有影響的事，任何失敗的後果也更嚴重。

★ 規劃失敗的具體類型

書把最常見的失敗——工具使用失敗——分成三種：

失敗類型	例子	對策
不存在的工具	計畫中呼叫 bing_search，但工具清單裡沒有它	在執行前用工具清單驗證計畫；工具定義用結構化格式
對的工具，錯的參數	lbs_to_kg 只需要一個參數，卻傳了兩個	用 JSON Schema 驗證參數，錯了就把錯誤訊息回傳給模型重試
對的工具，錯的參數值	參數格式正確，但應該是 120 卻傳了 100	最難抓——需要業務層級的驗證或人工確認

另外兩種規劃失敗：

• 目標失敗：計畫沒有解決任務，或違反了限制。書的例子：要求規劃「預算 5,000 美元、舊金山到河內的兩週旅行」，agent 規劃成到胡志明市，或大幅超出預算。時間也是常被忽略的限制——截止日後才完成的計畫書沒有用。
• 反思錯誤：agent 以為完成了，其實沒有。書的例子：要把 50 個人分配到 30 間房間，agent 只分配了 40 人卻堅持任務已完成。對策是用程式碼檢查完成條件，而不是讓模型自己宣告完成（見 工具-防止agent造假通過驗收）。

★ 怎麼評估 agent：書中的指標

建立一組 (任務, 工具清單) 的資料集，對每個任務讓 agent 產生 K 個計畫，計算：

1. 所有計畫中，有效的比例。
2. 平均要產生幾個計畫才得到一個有效的。
3. 所有工具呼叫中，有效的比例。
4. 呼叫不存在工具的頻率。
5. 參數無效的頻率。
6. 參數值錯誤的頻率。

這六個數字告訴你該改哪裡：第 4 項高 → 工具描述不清楚或工具太多；第 5 項高 → schema 不夠明確；第 6 項高 → 需要更多脈絡或人工把關。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

• 機制層深潛 → ReAct 與 Agent Loop、Function Calling 與結構化輸出、工具集設計、Agent 記憶設計、多 Agent 編排與 Agent Drift、可逆性、審計與人類把關
• 工具-提示工程、工具-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 相關資源