目錄
上一篇講了怎麼決定該修哪一段 pipeline。這一篇把整條縱軸從 prompt 拉到 multi-agent。
本篇對應 Lecture 8: Agents, Prompts, and RAG（2025/11/11，Kian Katanforoosh 主講，1 小時 50 分）。
這是全系列流量最高的一講，46 萬觀看，是第二名的三倍。而且它在 2024 年還只是 Lecture 9 的一行標題「RAG and AI Agents」、沒有投影片；2025 年才擴成 110 分鐘的完整一講。這個變化本身就是這幾年重心移動的縮影。
（這一講和站上既有的 Agent 生產線、AI Agent 實戰、RAG 技法大全 三個系列有大量重疊。 本文照課堂內容完整寫，重疊的段落會在結尾指向站上更深的展開。）
開場：兩個軸
縱軸（工程）：prompt → chain → RAG → agentic workflow → multi-agent
橫軸（換模型）：GPT-3.5 Turbo → GPT-4 → GPT-4o → GPT-5「這一講講的是縱軸。」
（他對 GPT-5 的旁註：「那是另一個議題，因為它其實是把其他模型包在自己裡面。」）
為什麼 base model 不夠
學生答出來的：缺乏領域知識、真實資料品質不如訓練資料、資訊過期、廣度有餘但窄任務精度不足、模型太重（「你用了一個巨大的模型，但實際只用到它 2% 的能力」）。
Katanforoosh 補充：LLM 極難控制。他舉的例子——2016 年微軟的 Twitter bot 從使用者身上學習，16 小時後就變成種族歧視的混蛋，只好下架；以及 Sam Altman 與 Elon Musk 互相指責對方的 LLM 是宣傳機器：
「這件事告訴你——連 Grok 和 OpenAI 這兩支資金最充足、人才最多的團隊，都沒把控制 LLM 這件事做好。」
還有一個很好的 niche 例子：生技公司要分類使用者評論，但那個產業的 NPS 本來就低很多，所以在別的產業算負評的，在這裡其實是中評。
context window 與 needle in a haystack
「就算今天最好的模型，context window 大概就在幾十萬 token 的量級。給你一個感覺：200,000 token 大約是兩本書。」
needle in a haystack：在一大段語料（例如整本聖經）中間隨機插入一句話，然後問模型。
「這題複雜不是因為問題複雜，而是因為你要模型在巨大語料裡找到一個事實。」
RAG 會不會被長 context 取代
課堂上引了一個論證：理論上如果算力無限，RAG 就沒用了，因為你可以立刻讀完整個語料再回答。他給了三個反駁：
- 延遲：「想像每問一個問題，AI 都要把你整個雲端硬碟讀一遍。這不合理。」
- 來源標註：RAG 能給出處
- 搜尋引擎的類比（最好的一個）：「你在搜尋引擎上搜東西，背後有非常細緻的走訪與排序演算法。相對地，如果你每次搜尋都得把整個網路讀一遍，那同樣不合理。」
「社群裡永遠有這種辯論：某個方法是不是經得起未來。因為算力大概每年翻倍，我們現在學的某些方法三年後可能就不相關了，我們不知道。」
prompt engineering
BCG 的實驗：鋸齒狀邊界
研究把 BCG 的顧問分三組：無 AI／有 GPT-4／有 GPT-4 且受過 prompt 訓練。三個發現：
- 鋸齒狀邊界（jagged frontier）：有些任務在邊界內，AI 大幅提升速度與品質；有些在邊界外，AI 反而讓結果更差
- 「在方向盤上睡著」：人們在邊界外的任務上依賴 AI，因為沒有仔細審查輸出，結果更糟
- 受過 prompt 訓練那組表現最好
半人馬 vs 半機械人（很好用的二分）：
| 行為 | 誰比較像 | |
|---|---|---|
| 半人馬 Centaur | 切分並委派：寫一長段 prompt 交出去，讓它做完再回來收 | 企業裡想自動化流程時 |
| 半機械人 Cyborg | 不完整委派，和模型高速來回 | 「我發現學生大多是 cyborg」 |
他對這個職稱的看法值得引用：
「很多公司說他們在招 prompt engineer。**我不買單。**我認為那只是每個人都該有的技能。你不會靠 prompt engineering 做出一份職業生涯，但你大概會在職涯中把它當成一個很有力的技能來用。」
技巧本身
從「summarize this document」改成「用五個要點總結這篇十頁的再生能源論文，聚焦在關鍵發現與對政策制定者的意涵」——加上受眾、格式、焦點。學生再往上加：給範例、角色扮演（act as…）、反射（叫它批評自己的產出——「在這些技巧裡通常這個效果最好」）、chain of thought（拆成步驟，別跳步）。
prompt template 的價值是可以放進程式碼、規模化到每個使用者：HR 系統裡有「Jane 是 L3 產品經理、在美國、偏好英文」，這些 metadata 可以插進模板為 Jane 客製，Joe 偏好西班牙文就換一套。
零樣本 vs 少樣本：「這產品還行，但我期待更多」——這句是負評還是中評？可能因產業而異。用 few-shot 給幾個已標好的例子，就能把模型對齊到你的標準。
「AI 新創常常這樣做：使用者說了什麼，找人標一下，然後把它加進 codebase 裡相關 prompt 的 few-shot 例子。你可以想成在建資料集，但不用碰模型參數，改 prompt 就好。」
一個很具體的實務數字：Workera 的語音對話產品，
「我們知道八輪之後模型就會迷失自己，因為你每次都把前面的使用者回應貼上去。所以我們背後的做法是把對話切成章節——前八輪是一章，然後從新的 prompt 重新開始，把前半段摘要進去再繼續。」
（學生問「prompt 多長會壞掉有沒有研究」→「有，但那些研究每幾個月就過期。」）
chaining——他說這是最重要的一項
「**chaining 是我們看過的 prompt engineering 技巧裡最受歡迎的一個。**它不是 chain of thought。」
例子是客訴回信：單一 prompt（辨識問題＋說明原因＋提供解法）vs 拆成三個 prompt。
關鍵論點不是效果，是可除錯性：
「單一 prompt 也許能動，但很難控制。多個步驟全埋在同一個 prompt 裡，你想逐步除錯、想知道哪一步比較弱，你做不到。」
學生追問「三個分開都好，合成一個標明步驟不就好了？」他的回答很到位：
「中間輸出正是你想看的東西。第一種做法我只能收集端到端的回饋，我能優化那個 prompt，但我沒辦法回溯問題出在哪。第二種做法：如果大綱很普通，我知道優化大綱能拿到很多收益；如果大綱正是我要的、但最後一步翻成客戶信件時不符合我們內部用語，那我就知道第三個 prompt 才是收益最大的地方。」
（代價是延遲——某些應用不該用長 chain。）
LLM-as-judge 的四種形態
先講手動：人工評分。「有時間就先動手做，你會很快發現問題，也會對哪些微調有效培養出直覺。」
要規模化就自動化（他點名團隊用 Promptfoo，可一次跑五個 LLM 並排成表）：
- 成對比較：這兩份摘要哪份好
- 單一評分：這份摘要給 1–5 分
- 參考導向的成對比較
- 帶 rubric 的評分——他給的例子很具體：「五分是：摘要低於 100 字元、至少提到三個彼此不同的關鍵點、第一句是總覽再進入細節。零分是：模型沒摘要成功，反而變得非常冗長。」
而且可以疊技巧：對 rubric 做 few-shot，給五分、四分、三分的實例。
站上 RAG 的三種形態與 evaluator paradox 處理的是這套做法的根本限制：你的 judge 不會比你更懂什麼是好。
為什麼不要 fine-tune
「我不是 fine-tuning 的粉絲，我會盡可能避開它。」
理由：需要大量標註資料；可能 overfit 到特定資料而失去通用能力；時間與成本密集。而最有力的那個論證是：
「在 Workera 我們盡可能遠離 fine-tuning，因為等你 fine-tune 完，下一個模型出來了，而它打敗你 fine-tune 過的上一代版本。
prompt engineering 這些方法的優勢是——你可以把下一個最好的預訓練模型直接放進程式碼，一切立刻升級。fine-tuning 不是這樣運作的。」
什麼時候還是該做：任務需要反覆的高精度輸出（法律、科學說明），或通用模型對該領域的語言吃力。
Slack fine-tuning 的笑話
有人拿公司內部 Slack 訊息去 fine-tune，想做一個「講話像我們」的模型。結果：
- 「寫一篇 500 字關於 prompt engineering 的部落格文章」
- 「我明早會處理。」
- 「現在就是早上了。」
- 「我現在正在寫。這裡是早上六點半。」
- 「現在就寫。」…「拜託。」
- 「好吧我現在寫。其實我不知道你想讓我講什麼。我只能描述流程。」
「他本來是想讓模型講話像公司裡的人，結果它真的變得像人——而不是照指令做事。」
⚠️ 這個立場在下一篇會被正面挑戰。 Lecture 9 的客座講者 Laurence Moroney 說「未來兩三年開發者最需要的技能就是 fine-tuning」——兩人講的其實是不同市場，這條張力留到下一篇處理。
RAG
課堂先列了 standalone LLM 的問題：context window 小、大 context 裡難記住細節、知識截止、幻覺（醫療診斷、教育這類場景代價極高）、缺乏來源（「純 LLM 找來源會幻覺得很嚴重，它會編出完全假的論文」）。
vanilla RAG 的流程：文件用 embedding 壓成低維表示 → 存進向量資料庫 → 使用者的問題用同一個演算法 embed → 依距離檢索 → 把檢索到的文件連同 prompt template 一起送進 LLM。
兩個實務細節：
- embedding 維度的取捨：「太小會丟失資訊，太大會增加延遲。」
- prompt template 要寫「如果文件裡沒有答案就說我不知道」，並要求「告訴我確切是哪一頁、哪一章、哪一行，而且附連結」
他明確回指 Lecture 2：「我們一起看過很多 embedding 方法，triplet loss 之類的，你記得吧。」（就是本系列第 2 篇。）
改良方法：
- chunking：同時存整份文件的向量和章節層級的向量，檢索時兩層都取，來源標註就更精確
- HyDE（假設性文件嵌入）：使用者的問句和文件長得不像，所以先用問句生一份假的、幻覺的文件，embed 那份假文件再去比對
站上 RAG 系統模式完整指南 把這條演化線從 Naive 走到 Multi-Agent 排了十代，Hybrid Search 與 PageIndex 則各自處理了這裡沒展開的兩條路。
agentic workflow
為什麼 Andrew Ng 要造這個詞
「很多公司到處都在講 agent、agent、agent。你去這些公司工作會發現他們講的 agent 意思差很多：有些人有一個 prompt 就叫它 agent，有些人有一套很複雜的 multi-agent 系統也叫 agent。把所有東西都叫 agent 對它並不公平。」
還有第二個理由，站上少見：
「叫它 agentic workflow 也讓我們不會和上一講強化學習裡的 agent 搞混——在 RL 裡 agent 有非常明確的定義：與環境互動、從一個狀態轉移到另一個狀態、有獎勵、有觀察。」
（本系列第 5 篇就是那一講。站上 概念界線 那篇則把這組詞的邊界劃得更細。）
從單步到多步的對照：使用者問「我可以退款嗎」——RAG 版本回「購買後 30 天內可退款」並附政策文件；agentic 版本則是：檢索政策 → 反問訂單編號 → 呼叫 API 查訂單 → 確認符合資格、三到五個工作天入帳。
元件與自主程度
一個旅遊預訂 agent 有：prompts、context management（記憶）、tools（航班/訂房/租車/天氣/金流 API）、resources。
記憶分層的比喻很好用：
「不是每一段記憶都需要快速存取。第一個問題是『你叫什麼名字』——這會放在工作記憶，因為每次講話都會用到。第二個問題是『你生日是哪天』——每天都需要嗎？大概不用，那就放到長期／封存記憶。」
成本論證：「想像每次呼叫它都得把記憶讀一遍……如果查記憶要三秒，那你每次跟 LLM 講話都要等三秒。」
自主程度三級（比常見分法更乾淨）：
| 級別 | 硬編碼什麼 | 例子 |
|---|---|---|
| 最低 | 硬編碼步驟 | 先辨識意圖 → 再查客戶歷史 → 再呼叫 API… |
| 半自主 | 硬編碼工具，不編碼步驟 | 「你是旅遊顧問，這些是你能用的工具」 |
| 最高 | 自己決定步驟，而且能創造工具 | 給它程式編輯器，它能 ping 任何 API、寫程式算距離 |
MCP vs 直接接 API：直接接 API 你得一個一個把文件餵給模型、教它怎麼呼叫，不太能規模化；MCP 則是 agent 直接問「我要拿到航班資訊需要給你什麼」，對方回「起點、目的地、你的大方向需求」，來回幾次就談好。
（學生問「API 要改的時候 MCP 也要改，不是同樣的問題嗎？」他承認：「對，但至少它讓 agent 能來回問出需求。」問到安全性時他也直說「我不是這方面的專家」。）
站上 協定層 把 MCP、A2A、ACP、Skills 各解什麼問題分開了；Agentic Engineering 的記憶問題則把記憶的型別與擁有權拆得更細。
決定論 → 模糊：軟體工程的典範轉移
這是這一講最好的一段，而且站上沒有。
「最好的工程師能夠從決定論思維切換到模糊思維，並在兩者之間拿捏。」
| 傳統軟體 | agentic 軟體 | |
|---|---|---|
| 資料 | 結構化（JSON、資料庫、表單） | 自由格式文字、影像，需要動態詮釋 |
| 行為 | 決定性 | 模糊 |
| 架構思維 | 按技術職能切（資料工程一塊、UI/UX 一塊、商業邏輯一塊） | 像個主管一樣思考：這產品交給一群人做會有哪些角色？平面設計師 → 行銷經理 → 成效行銷 → 資料科學家 |
他對模糊工程的警告寫得很好：
「模糊軟體會製造非常多問題。想像你讓使用者在你的網站上問任何事。它壞掉的機率非常高。你被攻擊的機率非常高。這比 Twitter 上講得複雜太多了。模糊工程真的很難。
你可能因為某個使用者做了你授權他做的事、結果搞爛了資料庫而被公審——過去兩年我們在很多公司身上看過這種事。」
Workera 自己的解法：測驗裡有決定性的題型（單選、複選、拖拉排序——有唯一正確答案）和模糊的題型（語音角色扮演、語音加寫程式——評分演算法可能出錯，而且錯誤代價高）。他們的做法是human in the loop 的申訴功能：測驗結束後你可以挑戰 agent 的判斷，由人介入修正——「你剛剛對這個人的答案太嚴苛了。」
「如果你在創業，我會鼓勵你想：哪些事能用決定論做完，就先做完。模糊的部分我要做，因為它允許更多互動，但我需要在外面加護欄。」
（站上 模型只是元件，harness 才是系統 是同一個論點的工程版本。）
企業流程的實例
McKinsey 研究的一家金融機構，做一份信用風險備忘錄要一到四週：客戶關係經理從 15 個以上的來源收資料 → 與信用分析師共同分析 → 分析師花 20 小時以上寫備忘錄 → 退回給意見 → 再繞一輪。
加入 GenAI agent 後時間減少 20–60%：關係經理直接與 agent 系統合作，agent 把專案拆成任務指派給專門 agent、收集分析、起草，兩位人類再一起審閱給回饋。
⚠️ 這個案例是真的，但數字要小心。 McKinsey 確實有這個信用風險備忘錄的 agentic 案例， 不過它的網站擋掉我的擷取工具，我只能從轉述查到內容，無法核對原文。而轉述版本和課堂說法有兩處出入： 資料來源是**「至少十個」不是十五個以上；20–60% 是「生產力提升」**不是「時間減少」 （另有「信用周轉時間改善 30%」是分開的一個數字）。生產力提升 60% 和時間減少 60% 不是同一件事。
但他自己潑的冷水比案例本身更值得記：
「就算這件事成立，**最難的部分是改變人。**理論上很棒，但現在你試著把第二種流程套到一萬名信用風險分析師身上。我猜這會花 10 年、20 年才能在一個組織裡真正大規模落地，因為改變太難了——重新接線業務流程、職務說明、激勵制度、訓練人。」
eval 案例研究
情境：產品經理要你做一個客服 agent。他推薦的第一步不是選模型：
「去和一位人類客服坐一兩天，拆解他們在跑的流程，問他們哪裡卡、要花多久時間。」
任務拆解後逐行決定技術：抽取資訊 → 純 LLM 就夠；查與更新資料庫 → 工具（或 MCP）；起草回信 → LLM；寄信 → 工具。
一個很好的面試建議：
「如果你在面試一家 AI 新創，我建議你問他們：你們有 LLM traces 嗎？因為如果沒有 traces，要 debug 一個 LLM 系統非常困難——你看不到那串被呼叫的複雜 prompt 鏈、也不知道 bug 在哪。」
eval 的三個切分軸
| 軸 | 一端 | 另一端 |
|---|---|---|
| 範圍 | 端到端（使用者滿意度） | 元件層（哪個工具壞了） |
| 性質 | 客觀（抽錯訂單編號 → 寫 Python 直接比對就能抓） | 主觀（語氣、直飛 vs 轉機的取捨 → 人工評分或 LLM judge） |
| 型態 | 量化（更新成功率、各元件延遲） | 質性（幻覺在哪、語氣不符、使用者在困惑什麼） |
「元件層通常比端到端更容易 debug。你大概會兩種混著用。」
主觀項目的完整流程：先做 error analysis（一千個使用者裡撈 20 段互動讀過去，發現「這個 LLM 好像很沒禮貌」）→ 才建帶 rubric 的 LLM judge → 拿它做選型（GPT-4 / Grok / Llama 三個並排跑）→ 或固定模型改 prompt（把「act like a travel agent」改成「act like a helpful travel agent」，看那一個字的影響）。
multi-agent
他給的理由只有兩個，很收斂：
- 平行化——「這才是重點：有沒有什麼我希望能獨立平行跑的？」
- 可重用——公司裡有個設計 agent，行銷團隊和產品團隊都能用
一句很重要的話：
「當你讓 agent 之間互相對話，那基本上就是 MCP 協定。你就是把那個 agent 當成一個工具看待。」
課堂練習（智慧家庭）產出：氣候控制、照明、保全、能源管理、娛樂、通知、協調者。學生提的兩個很好：保全 agent 認出你是誰後給出不同權限（家長 vs 小孩，小孩不能開冰箱）、看冰箱裡有什麼（接冰箱相機）+ 知道偏好 + 接電商 API 提前訂貨。架構上以階層式為主（只跟協調者講話，UI/UX 比較好）。
收尾：他對 AI 下一步的看法
1. 是不是要撞牆了？
「scaling law 告訴我們，只要算力和能源持續提升，LLM 就該持續變好，但總有一天會 plateau。那什麼會帶我們到下一階段？大概是架構搜尋。」
「今天的 LLM 大多還是 transformer，但我們知道人腦不是這樣運作的。所以那些實驗室瘋狂招工程師一點也不奇怪：可能未來幾年會有數千名工程師在試各種架構搜尋，而其中一個人會突然找到下一個 transformer，把算力和能源的需求砍掉 10 倍。」
2. 多模態的外溢效果
「**擅長影像會讓整個模型在文字上也更好。**你懂一張貓的圖，你寫關於貓的文字就更好。再加上音訊或影片，整個系統又更好——你知道貓叫起來是什麼聲音，你寫貓就寫得更好。」
3. 各種方法會混在一起（用嬰兒當比喻）
「嬰兒怎麼學？DNA 裡的生存本能 = 元學習／預訓練；爸媽指著東西說好、壞 = 監督式學習；跌倒受傷 = 強化學習的獎勵訊號；觀察別人在做什麼 = 非監督式學習。」
4. 為什麼這門課只給廣度——這段直接解釋了整個系列的定位：
「我們在 CS230 給你廣度，是因為這些方法變化太快。我不想去教你 RAG 的第 17 種優化方法，因為兩年後你就用不到它了。
我寧願你去想：你想理解的東西的廣度是什麼，這樣當你真的需要時，你可以衝刺、更快地學會你確切需要的那個東西。因為技能的半衰期太短了。」
延伸：課堂教完之後剩下的
這一講把縱軸從 prompt 一路帶到 multi-agent，而站上那 21 篇處理的幾乎都是「課堂講完之後的下一步」：課堂說 chaining 讓你能除錯，站上的 harness 系列講的是那個除錯層要怎麼蓋；課堂說 memory 要分層，站上講的是記憶的擁有權與 context rot；課堂說 prompt injection 要小心，站上講的是為什麼只能在 harness 層做損害控制。
真正值得從這一講帶走、而站上沒有的，是三個判斷：
一、鋸齒狀邊界。 這是一個實驗結果，不是意見——AI 在某些任務上會讓結果更差，而且人們察覺不到，因為他們在方向盤上睡著了。任何「AI 提升生產力 X%」的說法，如果沒有區分邊界內外，都是在平均掉一個雙峰分佈。
二、「等你 fine-tune 完，下一個模型已經打敗你了」。 這是一個關於時間的論證，不是關於品質的論證。它會不會成立，取決於模型迭代速度和你的資料護城河的相對關係——而下一篇的客座講者會從另一個市場給出相反的結論。
三、「技能的半衰期太短，所以只教廣度」。 這句話如果是真的，那它同時也是對這整個系列的評價標準：這九篇如果只教你 2025 年秋天的做法，那它兩年後就沒用了。 值得留下的是那些不隨版本改變的東西——為什麼要 chain（可除錯性）、為什麼記憶要分層（存取成本）、為什麼要看中間輸出（不然無法回溯）。
參考資料
- Lecture 8: Agents, Prompts, and RAG — 2025/11/11，Kian Katanforoosh。全部課堂內容的出處。syllabus 上的標題是 "Beyond the model: Enhancing LLM applications"
- CS230 Lecture 8 投影片 — 目錄編號比講次少 1，是停課後講次順延但目錄沒改的痕跡
- RAG 系統模式完整指南 — 站上文章，RAG 十代演化
- 概念界線：agent、workflow、RAG、MCP 到底差在哪 — 站上文章
- 模型只是元件，harness 才是系統 — 站上文章，模糊工程的工程版本
- Navigating the Jagged Technological Frontier — Dell'Acqua et al., HBS Working Paper 24-013（2023/09，後刊於 Organization Science）。鋸齒狀邊界的原始研究：758 位 BCG 顧問、18 項任務；邊界內多完成 12.2% 的任務、快 25.1%、品質評分高 40%，邊界外用 AI 答對的機率反而低 19%
- Promptfoo — 課堂點名團隊在用的 LLM eval 工具
- Embracing generative AI in credit risk — McKinsey。信用風險備忘錄案例的出處。注意：mckinsey.com 擋掉我的擷取工具，我沒能核對原文數字，上面 ⚠️ 那段的出入是從轉述比對出來的
- Slack fine-tuning 那個笑話的出處：OpenAI DevDay 2023 上 John Allard 的演講 "Maximizing LLM Performance"，投影片內容是拿 14 萬則內部 Slack 訊息微調 GPT-3.5 的結果。同期另有一篇獨立實驗（Ross Lazerowitz，同樣是 14 萬則）得到類似結果
仍未附連結：關於長 context 取代 RAG 的那則討論——課堂只說「有這個論證」，沒有點名出處，我也無法定位到單一來源。
Loading...