一部影片看完 Stanford AI 系統課程，從 LLM 到 Agentic Workflow
三句話摘要
Stanford「Beyond LLM」課程精粹：如何通過工程技術系統地強化大型語言模型，從Prompt Engineering到Agentic Workflow的完整應用框架。 做AI產品的核心不是盲目跟風最新技術，而是從現實痛點出發，選擇合適的工程技術層層堆疊，通過系統化的評估確保穩定——從Prompt Chaining到Agentic Workflow再到Multi-Agent，每一層都要問自己真的需要嗎。 1. LLM強化的縱軸與橫軸
重點整理
重點- 1
1. LLM強化的縱軸與橫軸
- 2
橫軸是升級base model（OpenAI、Anthropic的工作），一般人無能為力；縱軸是在現有LLM上疊工程技術（Augmenting LLM），這才是實戰者能施力的地方。
- 3
2. Prompt Chaining是Prompt Engineering的關鍵
- 4
不是簡單的優化單一prompt，而是將複雜任務拆成多個獨立prompt，前一個output餵給下一個。這樣每步可獨立測試debug，獲得可觀測性，比黑盒子模式效果更好且更易維護。
- 5
3. Fine-Tuning通常不值得做
- 6
成本高（需大量標注資料）、容易overfitting、時效性差（新base model出現直接淘汰）、通常prompt engineering就能達到相同效果。只有在法律、科學等需要高精度重複輸出，或base model在特定domain吃力時才值得。
- 7
4. RAG是知識補充的標準方案
- 8
用embedding模型把文件轉成向量存入向量資料庫，使用者問題也embedding後進行語意匹配（非關鍵字）檢索，再將檢索結果加入system prompt組合成最終prompt。可搭配chunking和多層次儲存提高命中率。
- 9
5. Agentic Workflow需要思維翻轉
- 10
從deterministic engineering轉向fuzzy engineering：傳統軟體吃結構化資料、邏輯確定、精確控制；agentic系統吃自由文本、邏輯模糊、給目標和限制讓AI自決。工程師要像manager般思考方向和邊界。
實用技巧與重點
乾貨- LLM的四個限制
- 缺乏domain knowledge
- 資訊落後（無法實時更新）
- 控制困難（機率性輸出，同一prompt兩次結果可能不同）
- Context太長時表現退步（即使100萬token，仍存在「lost in the middle」現象）
- Prompt Engineering實踐
- 好prompt的三要素：給誰看、產出格式、重點是什麼
- 核心技巧：Prompt Chaining（非Chain of Thought）
- 不是Centaur vs Cyborg二選一，而是看任務類型：重複性高流程清楚→Centaur委派；需判斷創意校正→Cyborg高頻對話
- Fine-Tuning四大缺點
- 需要大量優質標注資料
- 容易overfitting，通用能力下降
- 時效性差，新base model淘汰投入
- 通常prompt engineering也能達到效果
- RAG的實作要點
- 用embedding模型轉向量，存入vector database
- 向量是把文字語意轉成數字陣列，語意相近距離近
- 用distance metric從vector database找最相近documents
- Prompt template：「根據以下documents回答，若無答案說『我不知道』」
- Chunking方式：基礎是固定大小片段；進階是多層次（整篇、章、段）
- 超長context時代RAG仍有價值：解決Latency（無法每次重讀整個資料庫）、檢索效率、即時更新
- Agentic Workflow三核心
- Prompts：定義AI角色、能力邊界
- Context Management：管理agent看得到的資訊（Working memory高頻如用戶名、Archival memory低頻如歷史紀錄）
- Tools：做事類（Flight Search、Payment）、查資料類（CRM、Database）
- Agent自主性三層
- 1級：Hardcoded steps（步驟全寫死，安全但僵硬）
- 2級：Hardcoded tools + agent決定步驟（最常見的production setup，推薦起點）
- 3級：Fully autonomous（風險最高，agent自己決定甚至創工具）
- MCP（Model Context Protocol）
- 不用替每個API單獨寫串接邏輯
- Agent只跟MCP server溝通，MCP負責後端服務
- 支援agent-to-agent communication（把別人的agent當工具呼叫）
- 評估框架三維度
- 第一維：End-to-End（整體滿意度） vs Component-based（拆開看每一步）
- 第二維：Objective（自動可驗證，如order ID正確性） vs Subjective（無標準答案，如語氣禮貌度）
- 第三維：Quantitative（改地址成功率、latency等數字） vs Qualitative（幻覺位置、語氣不一致等感覺）
- LLM-as-Judge四種玩法
- Pair-wise comparison（給兩答案問哪個好）
- Single-answer grading（直接打分）
- Reference-guided pair-wise（多給標準答案做對比）
- Rubric-based（自定義評分標準如「五分=100字內含三重點」）
- 客服Agent案例的五步拆解
- 第一步：抽出關鍵資訊（intent、order ID、新地址）→用LLM一次API呼叫
- 第二步：查改資料庫 → custom tool或MCP server
- 第三步：查政策 → RAG（因會更新、需快速檢索）
- 第四步：起草回信 → 根據前面資訊用LLM生成
- 第五步：送email → email工具
- Subjective Eval實戰四步
- 第一步：Error analysis（從1000對話抽20個人工讀，發現問題樣貌）
- 第二步：設計eval（用LLM-as-Judge + 自寫rubric翻譯問題成評分標準）
- 第三步：A/B test模型（固定prompt，換底層模型對比）
- 第四步：A/B test prompt（固定模型，改prompt詞彙對比）
- Multi-Agent協調模式
- Hierarchical（使用者只跟Orchestrator講話，它派工給下層agent）
- Flat（agent直接互通，無中間人）
- 智慧家庭例子：主要hierarchical，但某些agent間可水平溝通降低overhead
- 工程設計原則
- 能deterministic解就deterministic解，剩下fuzzy部分加護欄
- 不要試圖讓AI零錯誤，而是出錯時有人接得住（如Appeal機制）
- 先人工掃出問題，再設計自動化eval
- 模型跟prompt兩個變因一次只動一個，不然無法判斷差異來源
- 簡單就簡單，不要over design（如無需multi-agent就別硬上）
結論
結論“做AI產品的核心不是盲目跟風最新技術，而是從現實痛點出發，選擇合適的工程技術層層堆疊，通過系統化的評估確保穩定——從Prompt Chaining到Agentic Workflow再到Multi-Agent，每一層都要問自己真的需要嗎。”
完整解析
詳細這支影片來自Stanford大學「Beyond LLM」課程，系統化介紹了AI工程師在商業應用中如何強化大型語言模型的能力。講者開篇就區分了兩條強化LLM的路徑：橫軸是升級base model（如GPT-4到GPT-5），這是OpenAI、Anthropic等大公司的工作；縱軸是在現有LLM上疊工程技術（Augmenting LLM），這才是實戰者能施力的地方。
首先探討了base model的四大核心限制。第一是缺乏domain knowledge——比如農業病害資料集根本不存在於公開網路，公司內部資料模型也不知道。第二是資訊落後，新詞新事件新公司模型都不認識。第三是控制困難，LLM是機率性輸出，同一個prompt兩次跑可能結果不同，在生產環境中無法接受。第四是context太長時表現退步，即使支援100萬token，仍存在「lost in the middle」現象，把細節藏進大量文本中模型反而找不到。
針對這些限制，影片介紹了三個核心強化技術。Prompt Engineering 是成本最低的方案，但重點不在單純優化prompt詞彙，而在Prompt Chaining——把複雜任務拆成多個獨立prompt，前一個output餵給下一個，類似n8n的workflow概念。這樣做的好處是每步都能獨立測試debug，獲得可觀測性，而黑盒子模式會讓你不知道哪裡出問題。BCG的研究還發現了「Jagged Frontier」現象：AI不是在所有任務上都表現好，有些任務AI反而扯後腿。因此使用者要懂得「Centaur」（一次委派長prompt）和「Cyborg」（高頻對話協作）的區別，根據任務類型選擇。
Fine-Tuning 教授建議能不做就不做，原因有四：需要大量標注資料成本太高、容易overfitting讓通用能力下降、時效性差（新base model出現直接淘汰你的投入）、通常prompt engineering也能達到效果。只有在法律、科學等需要高精度重複輸出的domain，或base model在特定領域明顯吃力時才值得。
RAG（Retrieval-Augmented Generation） 是解決知識補充的標準方案。做法是先用embedding模型把文件轉成向量存入向量資料庫，使用者問題也embedding後進行語意匹配檢索（而非關鍵字），再將檢索結果加入prompt。這解決了context window限制和資訊時效性問題。可以搭配chunking（固定大小片段）和多層次儲存（整篇、每章、每段各自向量化）來提高大文件中的命中率。有人說長context模型成熟後RAG就沒用了，但教授認為理論上對、實務上錯，因為還要面對Latency問題——無法每次query都把整個資料庫重讀，就像搜尋引擎也要靠預先建好的索引。
從強化單一LLM進到系統設計，需要思維上的徹底翻轉。傳統軟體吃結構化資料、邏輯deterministic、工程師精確控制每一步；Agentic系統 則吃自由文本、邏輯fuzzy、工程師要像manager一樣給目標和限制讓AI自己決定。實戰的第一步是任務拆解——以客服改地址為例，分為抽資訊→查資料庫→檢查政策→起草回信→送email五步，每步決定用LLM、RAG、tool還是其他工具。打造agent的三核心是：定義角色和邊界的Prompts、管理可見資訊的Context Management（分高頻的Working memory和低頻的Archival memory）、以及Agent能呼叫的Tools（做事類和查資料類）。
評估系統 決定了agentic系統的穩定性。教授給了三維度評估框架：End-to-End看整體滿意度vs Component-based拆開看每步、Objective自動驗證vs Subjective靠人工或LLM評審、Quantitative看數字vs Qualitative看感覺。以客服禮貌度為例，先人工掃出問題（error analysis），設計基於rubric的LLM-as-Judge eval，再用A/B test對比模型和prompt的差異，一次只動一個變因。
最後是Multi-Agent 系統。單一agent已能拆步驟call tool做RAG，但multi-agent價值在平行處理（訂機票時同時找航班、飯店、天氣）和功能復用（design agent給多個團隊用）。協調模式分hierarchical（使用者只跟Orchestrator講話）和flat（agent直接互通），智慧家庭例子用主hierarchical但某些agent間水平溝通。核心心態：把agent當作tool，就跟把API當作tool一樣，對外暴露tool-like介面。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
