🚀 成為 LLM OS 應用工程師：從 Bot 到 Agent 的開發實戰指南

🚀 成為 LLM OS 應用工程師：從 Bot 到 Agent 的開發實戰指南
Ian Chou
Ian Chou•

深入探討如何成為能獨立開發 LLM OS 應用的工程師。從 Prompt 管理到產品上線，涵蓋 8 個核心模組與實戰專題，讓你掌握 Bot、Copilot、Agent 開發的完整技能，成為市場急需的 LLM OS 應用工程師。

LLM OS應用工程師AI 開發Bot 開發Agent 開發Prompt EngineeringRAGLLM APIUX 設計成本優化產品思維工作流程可觀測性部署指南職涯發展技術指南2025

前言：90% 的 LLM 專案為何停在 POC 階段？

根據 Gartner 與 McKinsey 的觀察，超過八成的 LLM 專案停留在概念驗證（POC），從未進入正式生產環境。

原因不在技術不可行，而在於：

  • 缺乏穩定性設計（non-deterministic output）
  • 成本不可預測（token usage 波動大）
  • 無法與現有系統整合（data pipeline, auth, audit log）
  • 缺少監控與除錯工具

換句話說：我們擅長「展示能力」，但不擅長「工程建構後交付」。

這門課的目標，是填補這道鴻溝—— 讓你從「會用 Token API 的開發者」，轉型為「能交付穩定 LLM OS 應用的系統設計者」。

💡 定位明確：你不需要理解 Transformer 的數學原理，也不需要會訓練模型。你需要的是把 LLM OS 當作「新時代的 API」，並用工程化的方式打造應用。

📊 LLM OS 應用工程師 vs 系統工程師

面向系統工程師應用工程師
關注重點底層架構、模型優化產品體驗、業務價值
核心技能RAG 原理、向量資料庫、模型部署Prompt 版本管理、UX 設計、成本控制
工作內容建構 LLM 基礎設施開發 Bot、Copilot、Agent
市場需求每家公司 1-2 位每家公司 5-10 位
學習曲線陡峭（6-12 個月）適中（2-3 個月）

🎯 學習目標與能力出口

完成這個課程後，你將能夠：

✅ 核心能力

  • 把一個 LLM OS 應用從設計 → API → UX → 上線
  • 處理 80% 的產品問題（不穩定、成本高、體驗差）
  • 具備產品思維，知道何時該用/不該用 LLM

🚀 可開發的應用類型

  1. 對話與互動應用
  • 智慧客服：處理複雜詢問、多輪對話、情緒管理
  • 企業內部 Copilot：幫助員工快速查詢文件、操作系統
  • 多語翻譯與文化轉換助手

👉 用到的模組：System Prompt、上下文管理、Function Calling

  1. 文件與知識應用
  • 文件助手：摘要、問答、比對、法規檢索
  • 研究助理：文獻搜尋、比較、生成研究筆記
  • 會議/合約助理：自動生成摘要、風險提示、重點標註

👉 用到的模組：RAG、進階 Context Engineering、Plan→Solve→Verify

  1. 數據與分析應用
  • 報告生成器：輸入數據，自動產出決策報告
  • 財務分析助手：KPI 分析、異常檢測、決策建議
  • 行銷數據助理：從 GA/CRM 撈數據 → 分析 → 生成 insights

👉 用到的模組：Function Calling、Chain-of-Thought、成本工程

  1. 開發者工具
  • Coding Copilot：程式碼生成、解釋、重構建議
  • 測試案例生成器：根據需求自動產出測試案例
  • Pipeline Debugger：輔助排查數據流程或 API 連動問題

👉 用到的模組：LLM 選型、進階 Prompt 工程、自檢 / 自一致性

  1. 商務與生產力
  • 銷售助理：自動生成銷售話術、郵件回覆
  • 專案助理：追蹤進度、生成週報、風險預警
  • 行銷內容工廠：自動產生廣告文案、標題、社群貼文

👉 用到的模組：成本工程、上下文管理、可觀測性

  1. Agent 與自動化
  • Workflow Agent：自動完成多步驟任務（如搜尋 → 分析 → 報告）
  • 多 Agent 協作：分工完成複雜專案
  • 系統自動化：串接 ERP / CRM / 工單系統，減少人工流程

👉 用到的模組：Agent 架構、ReAct、工具路由、進階 RAG

學完這些模組，您不只是能做一個聊天機器人，而是能：

  • 讓 LLM 穩定輸出（可控 / 可驗證）
  • 把 LLM 嵌入不同業務流程（文件、數據、客服、開發）
  • 設計長期可用的框架（成本、觀測、流程管理）

👉 這就是 LLM OS 應用工程師的核心價值：把 LLM OS 當作「新一代 API」，應用到各種產品與產業場景。

📈 職涯發展路徑

🚀 LLM OS 應用工程師職業發展路徑

從初級開發者到專業 LLM OS 應用工程師的發展方向

🏗 完整課程架構（8 週速成）

📚 課程設計理念

  • 70% 應用實作：直接動手做產品
  • 30% 系統必修：理解必要的底層概念
  • 100% 實戰導向：每個模組都有實際產出

🏗 LLM OS 分層架構視角

🏗 LLM OS 分層架構

從上到下：體驗層 → 平台層 → 編排層 → 數據層

在深入各個模組之前，讓我們建立一個完整的架構觀點。LLM OS 應用的核心挑戰不在於選擇特定工具，而在於理解系統的分層架構，並學會判斷問題出現在哪一層：

🎨

體驗與產品層

核心職責：UX設計、Prompt工程、Context管理
代表工具：自建UI、Prompt版本管理
關注重點：本課程主要焦點
🚀

行業平台層

核心職責：業務邏輯、工作流程編排
代表工具：Unleash、Gemini Agent Builder
關注重點：工作流設計、業務整合
🔗

應用編排層

核心職責：Agent協作、複雜任務編排
代表工具：LangGraph、Semantic Kernel、AutoGen
關注重點：多步驟任務、Agent設計
💾

數據層

核心職責：向量搜尋、長期記憶、資料處理
代表工具：LangChain、LlamaIndex、Pinecone
關注重點：RAG實現、數據管道

💡 工程師思維要點：框架會變，但分層思路長期穩定。無論工具更迭，工程師需要掌握的是：如何判斷應用是卡在數據層、編排層、行業平台層，還是體驗層，並挑選最合適的解決方案。

🔮 未來觀察點：標準化趨勢

  • Agent Protocol 標準化：類似OpenAPI對REST API的影響，Agent間的互通標準正在形成
  • AI Gateway 普及：統一的LLM API閘道將簡化多模型管理和成本控制
  • 工具生態整合：預期這些分層工具將有更深度的整合，降低跨層溝通成本

📘 模組 1：Prompt for Applications（第 1 週）

🎯 學習目標

從「寫 Prompt」升級到「管理 Prompt 資產」

📚 核心內容

在這個模組中，我們將深入探討如何將 Prompt Engineering 從一門藝術轉化為一門科學。您將學習如何系統化地管理、優化和測試您的 prompts，確保它們在實際應用中能夠發揮最大效用，並為您的產品或服務帶來可預測、可依賴的成果。

1.1 Prompt 版本管理：從開發到部署的雙循環

為什麼版本管理至關重要？ 因為在 AI 應用中，每一條 Prompt 都是一個直接影響用戶體驗和商業成果的「產品功能」。

想像一下，您是一家運動品牌的電商，正在使用 LLM 為新上架的跑鞋自動生成行銷文案。

  • 初始版本 (Prompt A - by 產品經理): 產品經理設計了一個穩定、中性的 Prompt，專注於準確描述跑鞋的功能和規格。這個版本上線後，產品頁面的購買轉換率穩定在 2%。

  • 新版實驗 (Prompt B - by 行銷團隊): 為了迎接夏季促銷，行銷團隊提出了一個更具創意、更富煽動性的 Prompt，希望能激發消費者的購買慾望。新版本上線後，團隊發現廣告的點擊率 (CTR) 明顯上升，看似是個好消息。

這時，問題出現了：

一週後，數據分析師發現，雖然點擊率變高了，但最終的購買轉換率卻從 2% 下滑到了 1.5%。團隊推測，可能是過於誇大的文案風格，反而讓進入頁面的訪客產生了不信任感。

現在，整個產品和行銷團隊都面臨著一系列緊急問題：

  1. 如何快速反應？ 我們能立刻將文案切換回表現更穩定的 Prompt A 嗎？還是只能等工程師緊急加班重新部署？

  2. 如何驗證假設？ 我們能不能設計一個 A/B 測試，讓 50% 的用戶看到 Prompt A 的文案，另外 50% 看到 Prompt B 的文案，用真實數據來驗證我們的猜測？

  3. 如何追蹤與學習？ Prompt B 到底在哪一天上線的？它的完整內容是什麼？我們從這次失敗的實驗中學到了什麼，如何記錄下來以避免未來再犯？

如果沒有一個好的版本管理系統，上述問題的答案將是災難性的。團隊會陷入混亂：手忙腳亂地尋找舊的 Prompt 文字、無法進行科學的 A/B 測試來指導決策、也無法系統性地從昂貴的失敗中積累經驗。

這就是為什麼版本管理至關重要。 它不僅僅是為了防止工程師的「失誤」，更是為了賦能「產品和業務團隊」，讓他們能夠安全、高效地進行商業實驗，用數據驅動決策，並最終找到能夠最大化商業價值的溝通方式。

1.1.1 版本控制 (Version Control) - 您的 Prompt 開發與品管中心

版本控制不僅僅是為 prompt 加上 v1, v2 的標籤。一個專業的流程需要一個中央化的平台來管理、評估和迭代。

  • 集中式管理：除了使用 Git，更專業的做法是將所有 Prompts 存放在專為 LLM 應用設計的平台上，例如 LangFuse 或 Pezzo。

    • 優點：這些平台提供了 UI 介面，讓團隊（包括非工程師）可以輕鬆查看、比較和管理所有 Prompts。您可以為每個 Prompt 附加元數據(metadata)，如作者、目標、以及版本說明。

  • 明確的命名與註釋：在 LangFuse/Pezzo 這類工具中，您可以為每個 Prompt 創建不同的版本 (e.g., v1, v2)。這些版本不僅僅是文本不同，它們是您可以獨立追蹤和評估的對象。

  • 與程式碼分離 (Decoupling)：

    • 這是 LangFuse/Pezzo 的核心優勢之一。您的應用程式程式碼不再寫死 Prompt 內容，而是透過 SDK 向這些平台請求特定版本的 Prompt (langfuse.get_prompt("marketing-copy", version=2))。這使得 Prompt 的更新和程式碼的部署完全分離。

1.1.2 Feature Flag - 您的 Prompt 線上策略部署中心

當您在 LangFuse 或 Pezzo 中擁有了幾個經過測試、品質優良的 Prompt 候選版本後，下一個問題是：如何策略性地將它們部署到線上，並衡量其商業影響？這就是 Feature Flag 工具 LaunchDarkly 或 Flagsmith 發揮作用的地方。

  • 整個工作流程是：

    1. 開發階段：在 LangFuse/Pezzo 中創建和版本化您的 Prompts (e.g., product-description-v1, product-description-v2)。

    2. 部署階段：在 LaunchDarkly 中創建一個名為 productDescriptionPrompt 的 Feature Flag，並設定兩個變體 (variants)：一個返回字串 "v1"，另一個返回字串 "v2"。

    3. 應用程式邏輯：您的程式碼首先訪問 LaunchDarkly 得到當前用戶應該使用哪個版本 ("v1" 或 "v2")，然後拿著這個版本號去 LangFuse/Pezzo 獲取對應的 Prompt 內容來執行。

  • Feature Flag（功能旗標）的主要功能：

    • 動態切換 Prompts：想像您有一個 greeting_prompt。透過 Feature Flag，您可以設定一個參數，讓系統根據不同的條件（例如：使用者地區、會員等級、或是一個開關）來決定要使用 greeting_prompt_v1 還是 greeting_prompt_v2_formal。

    • 灰度發布 (Canary Release)：當您開發了一個全新的、更強大的 prompt v3.0，您可能不想立刻將它推送給所有使用者。利用 Feature Flag，您可以先將 v3.0 開放給 1% 的內部員工或測試用戶，觀察其表現。如果效果良好，再逐步擴大到 5%、20%，最終全面上線。這個過程能大幅降低因新 prompt 表現不佳而導致的大規模負面影響。

    • 緊急回退 (Kill Switch)：如果在全面上線後，發現新版的 prompt 在某些邊界情況下會產生有害或不當的內容，您可以立即透過 Feature Flag 將其關閉，讓系統瞬間切換回上一個穩定的版本，而不需要緊急進行程式碼的重新部署。

1.2 核心 Prompt 技術的應用場景 (Few-shot, CoT, ReAct)

了解了如何管理 prompts 之後，我們來深入探討三種能顯著提升 LLM 表現的核心技術。了解它們各自的適用場景，是成為高級 Prompt Engineer 的關鍵。

1.2.1 Few-shot Learning - 給模型幾個範例，讓它學得更快

  • 核心思想：在您的問題之前，提供幾個完整的「問題-答案」範例。這就像是給模型一個小型的「速成班」，讓它在回答您真正的問題之前，先理解您期望的格式、風格和邏輯。

  • 應用場景：

    • 格式化輸出：當您需要模型以特定的格式（如 JSON、Markdown 表格、特定 XML 結構）回覆時，提供幾個範例是最高效的方式。

    • 特定風格的文本生成：例如，要求模型撰寫一封正式的商業郵件。您可以先提供一兩個符合公司風格的範例郵件，模型就能更好地模仿該語氣和用詞。

    • 複雜分類任務：假設您要將用戶評論分為「正面」、「負面」、「中性」和「建議」。您可以給出幾個典型評論及其分類的範例，幫助模型更精準地進行判斷。

    • Zero-shot vs. Few-shot：Zero-shot (零樣本) 是指不給任何範例，直接提出問題。當任務非常簡單或模型已經非常熟悉時，可以使用。但只要任務稍微複雜或需要特定格式，Few-shot 的效果通常會遠勝於 Zero-shot。

1.2.2 Chain of Thought (CoT) - 引導模型「思考」而不是「猜測」

  • 核心思想：不僅僅給模型答案，而是向模型展示「如何一步步推導出答案」的思考過程。這會激發模型內部的推理能力，使其在處理複雜問題時，表現得更像一個真正的思考者。

  • 應用場景：

    • 數學與邏輯推理：這是 CoT 最經典的應用。例如，在解決一個數學應用題時，您會先列出已知條件，然後寫下計算步驟，最後得出答案。將這個過程展示給模型，它解決類似問題的準確率會大幅提升。

    • 多步驟指令的任務規劃：例如，「幫我規劃一個週末去陽明山的行程，需要包含午餐地點，並且考慮到下午可能會下雨。」使用 CoT，您可以引導模型先思考：1. 選擇陽明山景點。2. 查詢天氣預報。3. 根據天氣推薦上午的戶外景點和下午的室內備案。4. 推薦午餐地點。

    • 根本原因分析 (Root Cause Analysis)：當面對一個複雜的問題（例如：「為什麼我的電商網站上個月的轉換率下降了？」），您可以透過 CoT 引導模型從數據、市場、產品等多個角度進行逐步分析，而不是直接給出一個猜測性的答案。

1.2.3 ReAct (Reasoning and Acting) - 讓模型成為一個會使用工具的智慧體

  • 核心思想：結合了 CoT 的「思考」(Reasoning) 和與外部工具「互動」(Acting) 的能力。這讓 LLM 不再只是一個封閉的知識庫，而是一個可以主動獲取最新資訊、執行程式碼、與 API 互動的智慧代理 (Agent)。

  • 運作流程：思考 (Thought) -> 行動 (Action) -> 觀察 (Observation) -> 思考 (Thought) ...

  • 應用場景：

    • 需要即時資訊的問答：例如，「Google 最近的股價是多少？並分析一下近期的趨勢。」模型會 思考 到需要查詢股價，於是 行動 (呼叫一個股票查詢 API)，得到 觀察 (股價數據)，然後再 思考 如何基於這些數據進行分析。

    • 與外部服務互動：建立一個能幫您預訂餐廳、查詢訂單狀態或是在您的行事曆上新增活動的 AI 助理。模型會根據您的指令，思考需要呼叫哪個 API (行動)，並根據 API 的回傳結果 (觀察) 進行下一步。

    • 自動化研究與報告生成：給定一個主題，ReAct 框架可以讓模型主動上網搜尋資料 (行動)，閱讀並總結搜尋結果 (觀察 & 思考)，最終生成一份結構完整的報告。

💡 教學提示：「當您在設計這些不同策略的 Prompt 時，最佳實踐是將它們作為不同的版本保存在您的 Prompt 管理平台（如 LangFuse）中。例如，您可以有一個 baseline 版本、一個 few-shot 版本和一個 CoT 版本，這樣便於後續進行系統化的測試和比較。」

1.3 Prompt 測試與 A/B 比較：從實驗室到真實世界的雙層次評估法

一個好的 Prompt 不是憑感覺想出來的，而是需要經過科學驗證。這個驗證過程就像新藥上市，需要經過兩個核心階段：實驗室裡的嚴格品管，和真實世界裡的臨床試驗。

1.3.1 層次一：上線前的「品質檢驗」(The "Lab Coat" Phase)

在這個階段，我們像科學家一樣在控制環境中做測試。我們的目標不是看它能不能賺錢，而是回答一個更基本的問題：「這個 Prompt 安全、穩定、正確嗎？」

  • 由誰主導？ 主要由工程師和 AI 團隊主導。

  • 測試方法：黃金測試集 (Golden Set)

    • 我們會準備一個包含數十到數百個「考題」的測試集 (e.g., 不同的產品名稱、用戶問題)。

    • 用這個測試集去執行我們的 Prompt 新版本，確保它不會產生有害內容、不會跑出奇怪的格式、並且答案品質在一個基本水準之上。

  • 評估指標： 這時我們關注的是客觀指標和主觀指標。

    • 格式符合率：輸出的 JSON 是否總是合法？

    • 安全性：是否會生成不當言論？

    • 準確率：對於某些任務，回答是否正確？

  • 核心工具： 這就是 LangFuse, Pezzo, LangSmith 這類 LLMOps 平台發揮巨大價值的地方。它們能幫助我們管理黃金測試集，自動化地運行測試，並記錄下每個 Prompt 版本在這些品質指標上的表現（例如成本、延遲、評分）。

一句話總結： 在這個階段，我們淘汰掉那些「不及格」的 Prompt，篩選出幾個品質優良的「候選版本」進入下一輪。

1.3.2 層次二：上線後的「市場驗證」(The "In the Wild" Phase)

當一個 Prompt 通過了品質檢驗，證明它是一個「好」的 Prompt 後，我們還需要將它放到真實的市場中去驗證，回答一個商業問題：「這個 Prompt 能為我們帶來商業價值嗎？」

  • 由誰主導？ 主要由產品經理和行銷團隊主導。

  • 測試方法：A/B 測試 (A/B Testing)

    • 我們將通過品質檢驗的「候選版本」（例如，舊的穩定版 vs. 新的優化版）同時推送給線上用戶。

    • 透過隨機分流，讓一部分用戶看到 A 版本，另一部分看到 B 版本。

  • 評估指標： 這時我們關注的是業務指標。

    • 轉換率：哪個版本的文案帶來了更多的銷售？

    • 用戶滿意度：哪個版本的客服機器人收到了更多的好評？

  • 核心工具組合：

    1. 功能旗標服務 (LaunchDarkly/Flagsmith)：用它強大的後台來設定流量分配規則（例如 50% vs 50%），並可以隨時調整或關閉實驗，而不需要工程師修改程式碼。

    2. 數據分析工具 (Google Analytics, Mixpanel 等)：用來衡量和比較不同組別在業務指標上的表現。

一句話總結： 在這個階段，我們用真實的市場數據，從幾個「候選版本」中找出最終的「冠軍版本」。

實作 Lab：模擬一個從開發、品管到線上測試的完整工作流程 現在，讓我們透過為「Aura 智慧香氛機」設計行銷文案這個場景，來走一遍上面提到的完整流程。

情境 我們的目標是為新產品找到最佳的社群媒體文案。團隊已經腦力激盪出三版 Prompts，現在需要透過科學的方法來決定最終要用哪一版。

步驟 1：開發與版本定義 (Development & Version Definition)

這一步對應的是 Prompt 的開發階段。在真實世界中，這三版 Prompt 會被儲存在 LangFuse 或 Pezzo 中進行集中管理，並賦予明確的版本號。

  1. v1_baseline (基礎版)

  • Prompt: "為「Aura 智慧香氛機」寫一段社群媒體的行銷文案。"

  • 目的：這是一個最簡單、最直接的 prompt，作為我們比較的基準。

  1. v2_few_shot (範例學習版)
  • Prompt:

為產品寫一段吸引人的社群媒體行銷文案。

範例1：
產品：SleekPods 無線藍牙耳機
文案：🎶 告別纏線，擁抱自由！SleekPods 帶來沉浸式音質與全天候舒適配戴感。#無線自由 #音樂隨行

範例2：
產品：Zenith 手沖咖啡壺
文案：☕️ 每個早晨，都值得一杯完美的咖啡。Zenith 手沖咖啡壺，精準溫控，釋放咖啡豆的極致風味。#手沖咖啡 #生活美學

現在，請為「Aura 智慧香氛機」寫一段社群媒體的行銷文案。
  • 目的：使用 Few-shot learning，提供範例來引導模型生成包含 Emoji 和 Hashtag 的、更符合社群媒體風格的文案。
  1. v3_optimized (優化版)
  • Prompt:
你是一位頂尖的社群行銷專家。你的任務是為新產品「Aura 智慧香氛機」撰寫一段引人入勝、不超過150字的 Instagram 貼文。

**產品核心賣點**:
1.  可透過 App 遠端遙控，並設定排程。
2.  能與智慧家庭系統（如 Google Home）連動。
3.  使用天然植物精油，安靜運作。

**寫作要求**:
- 開頭要能立刻抓住眼球。
- 文案中需自然地融入至少兩個核心賣點。
- 語氣需溫暖、有質感，能喚起放鬆和科技感。
- 結尾必須包含一個行動呼籲 (Call to Action)。
- 最後附上 3-4 個相關的 Hashtag。
  • 目的：這是一個更精緻的 prompt，明確定義了角色 (Persona)、上下文 (Context)、任務細節 (Task Specifics) 和輸出格式 (Output Format)，期望能生成質量最高的文案。

步驟 2：(模擬) 品質檢驗 (Simulated QA) 在真實場景中，工程師會用一個包含 50 個不同產品名稱的「黃金測試集」來測試這三版 Prompt。他們可能會得出以下結論：

  • v1_baseline：輸出品質普通，但格式非常穩定。(通過品管)

  • v2_few_shot：風格討喜，但偶爾會模仿範例到忘記產品本身，導致文案不相關。(品管不通過)

  • v3_optimized：輸出品質高，且嚴格遵循所有寫作要求，表現最穩定。(通過品管)

基於品管結果，團隊決定淘汰 v2，讓表現穩定的 v1 和 v3 進入下一階段的真人 A/B 測試，來看看用戶到底更喜歡哪一種。

步驟 3：用 Feature Flag 實現線上 A/B 測試 (Implementation)

我們將使用 Python 偽代碼來模擬這個過程。

import random

# --- 步驟 1: 在 Prompt 管理平台 (如 LangFuse/Pezzo) 中定義好的 Prompts ---
# 在真實應用中，這些內容是透過 API 從 LangFuse/Pezzo 獲取的，而不是寫死在本地。
PROMPT_REPOSITORY = {
    "v1_baseline": "為「Aura 智慧香氛機」寫一段社群媒體的行銷文案。",
    "v3_optimized": """你是一位頂尖的社群行銷專家... (省略如上) ..."""
}

# --- 步驟 2: 連接 Feature Flag 服務 (如 LaunchDarkly) 來決定使用哪個版本 ---
# 產品經理可以在 LaunchDarkly 的儀表板上設定 A/B 測試，例如各分配 50% 的流量。
def get_prompt_version_from_feature_flag(user_id):
    """
    模擬從 LaunchDarkly 獲取決策。
    這個函式決定了特定用戶應該看到哪個實驗版本。
    """
    # 簡單的 50/50 分流邏輯
    if user_id % 2 == 0:
        return "v3_optimized"  # 偶數 ID 的用戶看到優化版
    else:
        return "v1_baseline"   # 奇數 ID 的用戶看到基礎版

# --- 應用程式主邏輯 ---
def generate_product_copy(product_name, user_id):
    """
    一個完整的請求流程：
    1. 詢問 Feature Flag 我該用哪個版本。
    2. 根據版本號去 Prompt 平台拿對應的 Prompt。
    3. 執行 Prompt 並返回結果。
    """
    # 1. 從 LaunchDarkly 獲取版本決策
    version_to_use = get_prompt_version_from_feature_flag(user_id)
    
    # 2. 從 LangFuse/Pezzo 獲取對應的 Prompt 內容
    prompt_template = PROMPT_REPOSITORY.get(version_to_use)
    
    print(f"--- User {user_id} 正在參與 A/B 測試，分配到的版本是: {version_to_use} ---")
    
    # 3. (模擬) 呼叫 LLM API
    # response = call_llm_api(prompt_template.format(product_name=product_name))
    # print(response)
    
    return f"用戶看到的文案將由 {version_to_use} 版本生成。"


# --- 模擬兩個不同用戶的請求 ---
user_a = 101  # 奇數 ID
user_b = 202  # 偶數 ID

print("處理 User A 的請求:")
generate_product_copy("Aura 智慧香氛機", user_a)

print("\n" + "="*50 + "\n")

print("處理 User B 的請求:")
generate_product_copy("Aura 智慧香氛機", user_b)

Lab 總結與討論

完成這個 Lab 後，請思考：

  1. 我們為什麼在 A/B 測試前要先進行「品質檢驗」？如果直接把 v2_few_shot 版本也加入 A/B 測試，可能會帶來什麼風險？

  2. 在 A/B 測試進行中，產品經理發現 v3_optimized 版本的轉換率遠超預期。她應該如何使用 Feature Flag 系統來結束實驗，並將 100% 的流量都切換到 v3 版本？這個過程需要工程師介入嗎？

  3. 請描述在這個完整的流程中，LangFuse (或 Pezzo) 和 LaunchDarkly 是如何協同工作的？它們分別解決了哪個階段的核心問題？

📘 模組 2：LLM API 與 UX 整合（第 2 週）

🎯 學習目標

本模組將帶領學員跨越單純的 Prompt Engineering，進入應用開發的實務層面。學員將學習如何根據不同的使用者情境，選擇最適合的 API 呼叫模式，並設計出符合使用者直覺的對話體驗。最後，我們將探討如何建立一道「信任層」，確保從 LLM 獲得的輸出是可控、可靠且能被後端系統使用的。

📚 核心內容

2.1 LLM API 呼叫模式的影響與策略

核心問題： 我們該如何與 LLM API 溝通？不同的溝通方式會如何影響應⽤的效能和使⽤者體驗？

2.1.1 Completion 模式（一次性完成模式）

  • 定義： 這是最基礎的互動模式。你送出一個完整的提示 (Prompt)，API 回傳一個完整的答案。這是一種「一次性請求-回應」的無狀態 (Stateless) 互動。

  • 比喻： 就像寫一封 Email，你把所有問題寫完寄出，然後等待對方完整的回覆。

  • 優點：

    • 實作簡單、直觀。

    • 適合不需要上下文記憶的單次任務。

  • 適用情境：

    • 內容生成： 寫一篇文章、產生一首詩、草擬一封郵件。

    • 文本摘要： 給定一篇文章，生成其摘要。

    • 簡單問答： 「法國的首都是哪裡？」

  • 範例程式碼 (概念)：

    Python

    response = llm.complete(
    prompt="請為一家新開的咖啡店想三個有創意的名字。"
)
print(response.text)
# >> 1. 啡語流光 2. 城市焙思 3. 滴答手沖

2.1.2 Chat 模式（對話模式）

  • 定義： 專為多輪對話設計的模式。API 不只接收當前的問題，還會接收過去的對話歷史紀錄。這是一種有狀態 (Stateful) 的互動。

  • 比喻： 就像使用 LINE 或 Messenger，每一句話都建立在前文的基礎上，形成連續的對話。

  • 關鍵概念：

    • 角色 (Roles)： 通常包含 system (設定 AI 的行為準則)、user (使用者輸入)、assistant (AI 的回覆)。

    • 對話歷史 (History)： 每次請求都必須附上之前的對話內容，AI 才能「記住」上下文。

  • 優點：

    • 能處理複雜、有上下文關聯的任務。

    • 提供更自然、更具互動性的使用者體驗。

  • 適用情境：

    • 聊天機器人 (Chatbot)： 客服、個人助理。

    • 逐步引導任務： 「幫我規劃一趟去東京的五日遊。」 -> 「第一天想去哪些地方？」

    • 程式碼協作： 「寫一個 Python 函式...」 -> 「不錯，現在幫我加上錯誤處理。」

  • 範例程式碼 (概念)：

    Python

    messages = [
    {"role": "system", "content": "你是一位友善的旅遊規劃助理。"},
    {"role": "user", "content": "我想去一個溫暖的海島國家，有推薦嗎？"},
    {"role": "assistant", "content": "當然！泰國的普吉島和印尼的峇里島都是很棒的選擇，您對哪個比較感興趣呢？"},
    {"role": "user", "content": "那先介紹一下峇里島吧。"}
]
response = llm.chat(messages=messages)
print(response.text)

2.1.3 Completion / Chat 模式：從「暴力餵食」到「精準引導」

  • 新機會： 2025年之後可以將整份規格書、FAQ、長篇對話歷史直接放入上下文，減少了以往需要「先摘要再提問」的預處理步驟。

  • 新挑戰：

    • RAG 依然必要： 長上下文能「塞進去」，不等於模型會「精準引用」。單純塞入大量文本可能導致成本暴增、延遲過高，且模型可能引用不相關的資訊（幻覺）。

    • 「中段遺失 (Lost-in-the-Middle)」問題： 模型對上下文開頭和結尾的資訊最敏感，放在中間的內容容易被忽略。

  • 長上下文最佳實踐：

    • 混合式 RAG： 採用「檢索少量高相關片段 + 提供全局導覽」的策略。例如，將檢索到的 3-5 個最相關段落，連同整份文件的目錄（Table of Contents）和段落編號一起放入上下文。

    • 強化 Prompt 結構： 使用明確的區塊標記（如 XML tags）、目錄、分段編號（§1.1, §1.2）來組織上下文。並在指令中加入引用規則，例如：「你只能引用以 § 標示的內容，並在回答末尾附上來源段號列表，例如 [引用來源: §1.2, §3.4]」。

    • 策略性記憶管理： 對話歷史修剪的頻率可以降低，但依然必要。保留關鍵的決策點、參數和使用者意圖摘要，移除無關的寒暄與重複性對話。

2.1.4 Streaming 模式（串流模式）

  • 定義： API 不會等所有內容生成完畢才一次性回傳，而是以「字詞」或「Token」為單位，即時、逐字地將結果串流回客戶端。

  • 比喻： 像是觀看 YouTube 直播，畫面是即時傳送過來的，而不是等整部影片下載完才播放。也像看著真人在打字，一個字一個字出現。

  • 優點：

    • 大幅降低感知延遲 (Perceived Latency)： 使用者幾乎立刻就能看到回應，避免了漫長的等待焦慮。

    • 提升互動感： 感覺更像在與一個「正在思考並回應」的對象交流。

  • 適用情境：

    • 所有需要即時互動的 Chat 應用。

    • 生成長文或程式碼時，讓使用者能先看到開頭部分。

  • 挑戰： 前端需要實作對應的邏輯來接收和拼接這些串流的字塊。

2.1.5 Streaming 模式：從「逐字輸出」到「結構化串流」

  • 新機會： 2025年之後，對於需要生成長篇報告或複雜程式碼的任務，串流的價值更高，能顯著改善使用者體驗。

  • 新挑戰： 長時間的逐字串流可能讓使用者不耐煩，或在輸出結構化資料（如 JSON）時造成前端解析困難。

  • 長上下文最佳實踐：

    • 先骨架後細節 (Skeleton-First Streaming)： 對於長篇文章，先快速串流回傳文章的「大綱」或「段落標題」，讓使用者立刻看到整體結構，然後再非同步地將各段落的詳細內容填充進去。

    • 分塊/逐欄位串流 (Field-by-Field Streaming)： 對於大型 JSON 輸出，可以採用逐欄位串流的方式。例如，先串流回 {"status": "processing",，接著是 "customer_name": "John Doe",... 這樣前端可以邊接收邊渲染，而不是等待一個巨大的 JSON 物件。

模式核心概念使用者體驗適用場景
Completion一問一答，無記憶快速直接，但生硬內容總結、文案生成
Chat多輪對話，有記憶自然流暢，具互動性客服、虛擬助理、教學
Streaming即時逐字回傳低延遲、高互動感所有對話式應用

2.2 對話 UX 模式的演進

核心問題： 我們該如何設計對話的「流程」，讓使用者覺得 AI 是聰明且有幫助的？

2.2.1 Command (命令) 模式

  • 定義： 使用者給出明確、具體的指令，期望 AI 直接執行並給出結果。

  • 互動心態： 使用者把 AI 當作一個「高效率的工具」。

  • 設計重點：

    • 意圖辨識要精準： AI 必須準確理解使用者的指令。

    • 回應要簡潔： 直接給出答案或確認執行的結果，不多廢話。

  • 範例：

    • 使用者：「幫我設定明天早上 7 點的鬧鐘。」 -> AI：「好的，已設定明天早上 7 點的鬧鐘。」

    • 使用者：「查詢訂單 A12345678 的狀態。」 -> AI：「訂單 A12345678 目前狀態為：已出貨。」

  • 演進： 2025年之後，使用者可以一次貼上更複雜的指令，例如整份郵件串或會議記錄，要求模型總結或提取資訊。

  • 最佳實踐： 即使模型能處理長輸入，回覆時也必須引用來源。例如：「根據您提供的會議記錄第 52 行，我已將 Action Item 設定為...」。這能避免「黑箱式」回答，增加使用者的信任感。對於查詢型任務，仍堅持「檢索 → 精準上下文 → 回答」的路徑。

2.2.2 Clarification (澄清) 模式

  • 定義： 當使用者的指令模糊或資訊不足時，AI 主動提出問題，以澄清意圖、補足資訊。

  • 互動心態： 使用者把 AI 當作一個「細心的夥伴」。

  • 設計重點：

    • 識別模糊地帶： 知道何時該問問題，而不是猜測或直接拒絕。

    • 提問要聰明： 提出的問題應該是關鍵性的，最好提供選項。

  • 範例：

    • 使用者：「幫我訂一張去東京的機票。」

    • AI (澄清)：「好的，請問您預計的出發日期是什麼時候呢？」

    • 使用者：「我想退貨。」

    • AI (澄清)：「沒問題，請問您想退貨的是哪一筆訂單呢？可以提供訂單編號嗎？」

  • 演進： 2025年之後，由於上下文更豐富，AI 可以自行找到許多答案，從而降低了基礎追問的次數。

  • 最佳實踐： 將澄清的重點從「補足資訊」升級為「確認關鍵決策點」。可以將歷史互動、使用者資料，甚至相關的表單欄位定義一併放入上下文，讓模型判斷哪些關鍵欄位（如時間、地點、ID）缺失，並一次性、有條理地詢問。

2.2.3 Suggestion (建議) 模式

  • 定義： AI 在完成使用者的指令後，基於上下文，主動提供相關的、可能有幫助的建議或下一步操作。

  • 互動心態： 使用者把 AI 當作一個「有遠見的專家」。

  • 設計重點：

    • 建議要相關： 提供的建議必須與當前對話高度相關。

    • 時機要恰當： 在使用者完成一個主要任務節點後提出，避免打斷流程。

    • 不要強迫： 以提議的口吻呈現，讓使用者可以輕鬆接受或拒絕。

  • 範例：

    • AI：「您的訂單 A12345678 已成功取消並辦理退款。」

    • AI (建議)：「很高興為您服務。順帶一提，您上次購買的《原子習慣》同系列作者有本新書《高效人士的七個習慣》，需要為您介紹嗎？」

    • 使用者：「幫我查一下台北今天的天氣。」

    • AI：「台北今天天氣晴朗，氣溫 28-34 度。」

    • AI (建議)：「天氣炎熱，提醒您多補充水分。需要幫您查詢附近的飲料店嗎？」

  • 演進： 2025年之後，模型能「看到」更長期的使用者行為和偏好，使其建議更具個人化潛力。

  • 最佳實踐：

    • 嚴格的觸發規則： 必須用規則限制建議的時機，例如「僅在主要任務成功完成後」、「信心度高於 95% 時才提出」、「連續對話中最多提一次建議」，避免打擾使用者。

    • 標註建議來源： 建議時應說明理由，例如：「基於您過去的購買紀錄 [§4.1]，我推薦這項商品...」。這能讓建議顯得更透明、更可信，而不是空穴來風的猜測。

2.3 API 輸出信任層 (API Output Trust Layer)

核心問題： LLM 的輸出是不確定的，有時甚至是「胡說八道」或格式錯誤。如何確保我們從 API 得到的結果是結構化、可靠、且能被程式其他部分安全使用的？

這一層是介於「LLM 原始輸出」和「你的應用程式邏輯」之間的防護網和格式轉換器。

2.3.1 正則表達式 (Regex)

  • 用途： 當你需要從 LLM 回傳的一段自然語言文字中，抽取出特定格式的簡單資訊時。

  • 範例：

    • 任務： 從「我的訂單編號是 ORD-2025-08-23-001，請幫我查詢。」中提取訂單編號。

    • 作法： 使用正則表達式 ORD-\d{4}-\d{2}-\d{2}-\d{3} 來匹配並抽取出 ORD-2025-08-23-001。

  • 優點： 快速、輕量，適合處理格式固定的簡單字串。

  • 缺點： 對於複雜的巢狀結構（如 JSON）無能為力，且規則寫起來較為繁瑣。

  • 演進： 2025年之後，規則本身不變，但應用的範圍更廣、干擾更多。

  • 最佳實踐： 加上邊界/前後文錨點來提升精度。例如，用 \bORD-\d{8}\b（\b 是單詞邊界）來確保抽到的是完整的訂單號。更進一步，可以在 Prompt 中指示模型將特定資訊放在特定段落，然後限定正則表達式只在該段落中進行匹配。

2.3.2 Schema Validation (結構化驗證)

  • 用途： 當你要求 LLM 輸出一種複雜的、結構化的資料（最常見的是 JSON），用以驗證其格式是否完全符合預期。

  • 核心流程：

    1. 定義 Schema： 在 Prompt 中，明確指示 LLM 必須以 JSON 格式回覆，並提供 JSON 的結構範例。

    2. LLM 輸出： LLM 嘗試生成符合要求的 JSON 字串。

    3. 解析與驗證： 你的程式碼先嘗試將 LLM 回傳的字串 JSON.parse()。成功後，再用一個預先定義好的 Schema（例如 Pydantic、JSON Schema）去驗證這個 JSON 物件的欄位、型別是否都正確。

    4. 重試機制： 如果驗證失敗，可以將錯誤訊息連同原始請求再次發送給 LLM，要求它「修正錯誤並重新輸出」。

  • 範例：

    • 任務： 從「幫我預約一位叫 John Doe 的客戶，電話是 0912-345-678，時間是明天下午 3 點」中提取預約資訊。

    • Schema (Pydantic)：

      Python

      from pydantic import BaseModel
class Appointment(BaseModel):
    name: str
    phone: str
    time: str

    • 驗證： 程式會檢查 LLM 的輸出是否包含 name, phone, time 三個欄位，且其值是否為字串。

  • 進階概念： 現代的 LLM API（如 OpenAI 的 Function Calling）已經內建了類似的功能，能更可靠地強制 LLM 輸出符合特定結構的 JSON，這是 Schema Validation 的更穩健實踐。

  • 演進： 2025年之後，長上下文可能誘使模型輸出額外、冗餘或格式錯誤的 JSON 欄位。

  • 最佳實踐：

    • 啟用原生結構化輸出： 若 API 支援（如 OpenAI 的 Function Calling 或 Anthropic 的 Tool Use），務必啟用。這比單純讓模型「用文字寫出 JSON」要可靠得多。

    • 嚴格 Schema + 自動修復迴圈： 繼續使用 Pydantic 或 JSON Schema 進行嚴格驗證。當驗證失敗時，將錯誤訊息和原始輸出一起回饋給模型，並明確要求它「根據以下錯誤修正你的 JSON 輸出」。

    • 分段/分塊驗證： 對於複雜的長 JSON 回應，可以將其拆分為多個子任務。例如，先讓模型生成並驗證 customer_info，成功後再生成並驗證 items_list。

Lab (升級版)：打造一個支援長上下文的智慧客服 Bot

目標： 應用長上下文時代的最佳實踐，優化「智慧小舖」的客服 Bot。

  1. 查訂單 (Command)：

    • 任務： 在 Prompt 中放入一段混合了退貨政策、多筆訂單摘要、使用者對話歷史的長文本（並用 § 標號）。使用者的指令是：「幫我查一下 S20250823001 的狀況」。

    • 要求： Bot 必須準確地從 § 標記的訂單摘要中找到對應資訊，並在回覆時附上來源段號，例如：「訂單 S20250823001 目前狀態為【已出貨】 [引用來源: §4.2]」。

  2. 退貨 (Clarification)：

    • 任務： Prompt 上下文中除了對話歷史，還包含完整的退貨政策全文 (§1 - §3)。使用者說：「我想退貨」。

    • 要求： Bot 在提問時，能引用具體條款。例如：「好的，根據我們的退貨政策 §2.1，申請退貨需要提供訂單編號。請問您的訂單編號是？」

  3. 建議 (Suggestion)：

    • 任務： Prompt 上下文中包含使用者近三個月的購買紀錄 (§5)。

    • 要求： 在使用者完成查詢訂單任務後，Bot 根據購買紀錄提出一則高度相關的建議，並標明來源。例如：「很高興為您服務。注意到您先前購買了《高效能人士的七個習慣》[參考紀錄: §5.3]，我們認為您可能也會喜歡新上架的《原子習慣》，需要為您介紹嗎？」

  4. Bonus (Streaming & Validation)：

    • 任務： 設計一個「生成訂單摘要報告」的功能。

    • 要求：

      • 採用**「先骨架後細節」**的串流方式：先快速回傳 {"status": "已完成", "customer_name": "...", "total_amount": ...} 等關鍵欄位，然後再逐項串流 items 陣列的詳細內容。

      • 前端對串流回來的 JSON 進行即時逐字段驗證。

2.4 架構與工程層面的取捨 (實務重點)

  • 成本/延遲： 上下文每多 1 Token 都是錢和時間。在生產環境中，必須建立監控和預算上限。優先考慮「檢索/壓縮」，只將必要且可追溯的內容放入上下文。

  • 品質： 長上下文容易「資訊雜訊化」。利用導覽式提示（TOC、標記）和引用規則來抑制幻覺，確保輸出的品質。

  • 安全： 輸入的上下文越長，被植入 Prompt Injection 的風險就越高。務必對使用者提供的長文本進行過濾，並在 System Prompt 中設定嚴格的安全護欄。

  • 評測： 建立「長上下文壓力測試」基準：

    • 大海撈針測試 (Lost-in-the-Middle)： 將關鍵答案放在長上下文的中間，檢驗模型的召回率。

    • 抗干擾測試： 故意插入與問題相似但答案錯誤的干擾段落，檢驗模型是否能準確引用正確來源。

    • 效能門檻測試： 設定成本和延遲的上限，當請求預計超過門檻時，自動降級為「檢索 + 短上下文」的策略。

總結： 長上下文是一個強大的槓桿，但它需要更精巧的工程設計來駕馭。本模組教授的 API 呼叫模式、UX 設計和信任層，在長上下文時代不但沒有過時，反而成為了區分「AI 玩具」與「AI 產品」的關鍵。最佳實務是：小心翼翼地放入上下文、要求模型嚴格地引用、分階段地串流輸出、並用 Schema 強制驗證結果。

📘 模組 3：Context Engineering 必修基礎（第 3 週）

🎯 學習目標

歡迎來到第三模組！在本單元中，我們將深入探討大型語言模型（LLM）的「大腦」——Context（上下文）。Context 是我們與 LLM 溝通時提供給它的所有資訊，直接決定了模型的回應品質。

隨著像 Claude Sonnet 4 這樣支援高達 1M tokens 的模型問世，Context 管理的重心已經從「解決技術限制的必要手段」轉變為「追求效率與成本最佳化的策略選擇」。我們將學習如何在這個新時代中，設計出既智慧又經濟的 Context 管理策略。

📚 核心內容

3.1 Context 的核心組成：System, User & Memory

要讓 LLM 表現得像個專家，我們必須學會扮演好「導演」的角色。提供給模型的 Context 主要由這三部分組成：

  • System Prompt (系統提示詞)：AI 的「角色設定」與「核心指令」

    • 定義：在對話開始前，預先給予 LLM 的最高層級指令，用以定義 AI 的人格、角色、行為準則、技能及最終目標。

    • 作用：

      • 設定人設：例如，「你是一位資深的天文學家，請用淺顯易懂的方式回答問題。」

      • 規範行為：例如，「你的回答必須保持客觀中立，絕不帶有個人情感。」

      • 提供知識：可以放入特定的背景資料或指南，讓 AI 參考。

    • 2025 年新策略：得益於大幅增加的 Context Window，我們現在可以在 System Prompt 中放入更豐富的範例、更詳細的指南，甚至是完整的產品手冊或 API 文件，讓 AI 的專業能力提升到新的層次。

  • User Prompt (使用者提示詞)：當下的「對話」與「任務」

    • 定義：使用者在每次互動中輸入的具體問題或指令。

    • 2025 年優勢：現在可以在單次 Prompt 中包含更複雜的任務描述，甚至是多階段的指令序列，讓 AI 一次完成更具挑戰性的工作。

  • Memory (記憶)：對話的「歷史紀錄」

    • 定義：分為短期記憶（單次對話中能記住的內容）和長期記憶（需要外部儲存系統來實現跨對話的記憶）。

    • 2025 年變革：1M tokens 意味著絕大多數的對話都可以保留完整的歷史紀錄，而不需要頻繁地進行摘要壓縮，大幅提升了對話的連貫性與深度。

3.2 Context 長度的新現實：從「限制」到「優化」

  • 技術規格更新 (以 Claude Sonnet 4 為例)

    • Context 容量：

      • 標準版：200K tokens (~50 萬字)

      • 企業版：500K tokens (~125 萬字)

      • 長 Context 版 (Beta)：1M tokens (~250 萬字)

    • 成本結構 (範例)：

      • ≤ 200K tokens：$3/M 輸入 tokens, $15/M 輸出 tokens

      • > 200K tokens：$6/M 輸入 tokens, $22.50/M 輸出 tokens

  • 新的思維框架：三層策略

    過去，我們被迫壓縮 Context 以避免超出限制；現在，我們需要主動選擇最適合的 Context 長度來平衡性能與成本。

    1. 高效層 (< 50K tokens)：適用於日常對話、簡單問答等快速反應的任務。

    2. 標準層 (50K - 200K tokens)：適用於複雜分析、報告撰寫、中型專案的程式碼理解。

    3. 深度層 (200K - 1M tokens)：適用於大型 codebase 分析、多份研究論文的交叉比對、企業級的深度資料分析。

3.3 現代 Context 管理策略

  • A. 動態 Context 調整

    根據任務的複雜度，動態決定 Context 的大小。

    if (任務複雜度 === "簡單") {
    使用基本 Context (System + User + 近期歷史)
} else if (任務複雜度 === "中等") {
    使用擴展 Context (加入相關文件片段)
} else { // 複雜任務
    使用完整 Context (所有可用資訊)
}

  • B. 成本感知的 Context 設計

    • 預算導向：根據應用的成本預算，決定預設的 Context 策略。

    • 價值評估：評估額外的 Context 帶來的效益，是否值得加倍的 API 成本。

    • 動態縮放：在高價值任務（如產生最終報告）時使用長 Context，在日常互動時保持精簡。

  • C. Hybrid Memory Architecture (混合記憶架構)

    將 Context 視為一個分層的結構，按需載入。

    • Layer 1: 核心 System Prompt (常駐，定義 AI 角色)

    • Layer 2: 任務相關 Context (動態載入，如 API 文件、使用者資料)

    • Layer 3: 近期對話歷史 (滑動窗口，保持對話流暢)

    • Layer 4: 相關長期記憶 (透過 RAG 檢索，提供歷史洞見)

3.4 長期記憶管理的進化：RAG 2.0

  • 從「無所不包」到「聚焦重點」

    • 過去 (傳統 RAG)：因為 Context 太小，幾乎所有背景資料都要放進向量資料庫。

    • 現在 (RAG 2.0)：只有真正需要跨對話持久化的資訊才需要放入 RAG 系統。大部分的單次任務資料可以直接放入 1M Context Window。

  • 新世代 RAG 的適用場景

    1. 企業知識庫：處理超過 1M tokens 的大型文件集合。

    2. 個人化設定：儲存使用者的長期偏好、歷史互動模式。

    3. 動態更新資料：需要即時更新的資訊，如股價、新聞、庫存等。

3.5 2025 年的最佳實踐與決策框架

  • Context 設計四大原則

    1. 需求驅動：根據實際需求選擇 Context 長度，而非預設使用最大值。

    2. 成本意識：在性能與成本之間找到最佳平衡點。

    3. 性能監控：追蹤不同 Context 長度下的回應品質與延遲。

    4. 用戶體驗：注意！更長的 Context 可能帶來更慢的回應時間，需權衡取捨。

  • 實用決策框架 (範例)

    def choose_context_strategy(task_type, budget, quality_requirement):
    if task_type == "日常對話":
        return "標準 Context (< 50K)"
    elif task_type == "文件分析" and budget == "充足":
        return "長 Context (200K+)"
    elif quality_requirement == "最高" and task_type == "程式碼審查":
        return "超長 Context (1M)"
    else:
        return "動態調整 + 智能檢索"

Lab：建構智能 Context 管理系統

實驗目標：

打造一個能根據任務複雜度和成本預算，自動選擇最適合 Context 策略的系統。

  • Phase 1: Context 分析器

    • 建立一個 analyze_task_complexity 函數，根據使用者輸入的關鍵字或透過小型分類模型，將任務分為「簡單、中等、複雜」。

    • 建立一個 estimate_context_needs 函數，根據任務複雜度和對話歷史長度，估算出建議的 Context tokens 數量。

  • Phase 2: 動態 Context 組裝器

    • 實作一個 build_context 函數，根據預算（max_tokens）動態載入不同層次的資訊（核心 Prompt、相關文件、對話歷史）。

  • Phase 3: 成本監控與預算控制器

    • 開發 calculate_cost 函數，根據 Context 長度即時計算 API 成本。

    • 設計 optimize_for_budget 函數，當預估成本超過預算時，能自動壓縮或移除最不重要的資訊。

  • Phase 4: 效果驗證

    • 測試不同 Context 長度下的回應品質、速度與成本，建立適合特定應用場景的最佳實踐。

重要提醒

優秀的 AI 工程師會在性能、成本、用戶體驗三者間找到最佳平衡點。Context Engineering 在 2025 年更像是一門「資源配置的藝術」，而非單純的工程技術。

記住：更大的 Context Window 是強大的工具，但智慧的使用策略才是核心競爭力。

📘 模組 4：知識掛載與 RAG 基礎（第 4 週）

🎯 學習目標

隨著百萬級上下文窗口模型的普及，傳統的 RAG 架構面臨著機遇與挑戰。在本模組中，我們將不再將 RAG 視為一個單一流程，而是將其提升為一個智能決策系統。學員將學習如何建構一個能夠根據查詢的複雜度、成本考量和效能需求，動態選擇最佳檢索與生成策略的現代化 RAG 系統。我們將深入探討新興的 Chunking 技術、多層次檢索架構，並應對長上下文時代特有的失敗模式。

📚 核心內容

4.1 長上下文時代的 RAG 重新定義

教學目標：

理解長上下文模型（如 Gemini 2.5, Claude Sonnet 4）如何從根本上改變 RAG 的設計假設，並闡明為何「拋棄檢索，只靠長上下文」並非萬能解方，從而引出「分層式混合架構」的必要性。

4.1.1 RAG 範式的進化：從「書桌」到「會議室」

  • 第一代 RAG (2023前) - 精準檢索時代

    • 核心限制： 4K-8K 的狹小上下文窗口。

    • 核心策略： 將文檔切成極小的碎塊（~500字元），像拼圖一樣找出最相關的幾片（top-3），小心翼翼地放入 LLM 這個小空間中。

    • 比喻： 像在一個狹小的書桌上工作。桌面空間（上下文）非常寶貴，你必須精確地只拿出最重要的幾張A4紙來參考。

  • 第二代 RAG (2024-2025) - 混合檢索時代

    • 新能力： 128K 到 1M+ 的龐大上下文窗口。

    • 新策略： 我們不再只滿足於找到幾張紙，而是可以根據需要，選擇性地將整本書、整個章節攤開來參考。這催生了分層檢索、動態 Chunk 大小等更複雜的策略。

    • 比喻： 現在我們擁有了一張巨大的會議桌。可以輕鬆攤開整本百科全書，但問題變成了：如何在這片資訊海洋中快速找到重點，而不會迷失方向或耗費過多精力？

4.1.2 靈魂拷問：既然上下文這麼長，為何不直接拋棄 RAG？

簡單地將所有文件塞進長上下文，是一種誘人但天真的想法。原因如下：

  • 成本考量 (Cost)： 以 Gemini 2.5 Pro 為例，處理 1M token 的輸入成本可能高達 $7。如果每次查詢都如此昂貴，系統將不具備商業可行性。

  • 注意力問題 ("Lost in the Middle")： 研究表明，LLM 在處理長上下文時，對開頭和結尾的資訊記憶最清晰，中間的內容則容易被「遺忘」或忽略。這就像聽一場冗長的演講，中間部分很容易走神。

  • 處理延遲 (Latency)： 將海量文本餵給 LLM 需要顯著的處理時間（可能長達30秒至1分鐘），這對於需要即時互動的應用是無法接受的。

  • 效能瓶頸 (Performance Bottleneck)： 大多數模型在處理超過一定長度（如 32K token）的上下文後，回答的精準度和遵循指令的能力會開始下降。

4.1.3 現代 RAG 的核心思想：混合架構

結論是，我們需要一個智能調度中心。這個中心能夠：

  • 分層決策： 根據查詢的類型和複雜度，動態選擇最合適的工具。

  • 成本優化： 簡單問題走「傳統 RAG」路徑（低成本、快速）；複雜問題才啟用「長上下文」路徑（高成本、深度分析）。

  • 品質保證： 結合兩種方法的優勢——傳統 RAG 的精準性與長上下文的全面性——來提供最佳回答。

4.2 現代 Chunking 策略與多層檢索

教學目標：

掌握三種先進的 Chunking 技術，並學習如何設計一個能夠根據查詢意圖，在不同粒度的知識索引之間進行智能切換的多層檢索系統。

4.2.1 新一代 Chunking 策略：超越固定長度

  • 語意感知切割 (Semantic Chunking)

    • 原理： 不再依賴固定的字數，而是基於語意的連貫性來決定切割點。它計算相鄰句子間的向量相似度，當相似度突然下降時，意味著話題可能發生了轉變，此處即為一個理想的切割點。

    • 優點： 最大程度地保留了概念的完整性，避免一個完整的論述被硬生生切斷。

    • 適用情境： 技術文檔、學術論文、法律條文等邏輯性強、概念連貫的內容。

  • 文檔結構感知切割 (Document-Aware Chunking)

    • 原理： 利用文件本身固有的結構標記（如 Markdown 的 #、## 標題，HTML 的 <h1>, <p> 標籤，或 PDF 的段落佈局）作為天然的切割邊界。

    • 優點： 完美保留了文檔的邏輯層次，便於後續生成帶有引用來源的答案。

    • 適用情境： 說明手冊、公司政策文件、API 文件等結構化良好的內容。

  • 層次化 Chunking (Hierarchical Chunking)

    • 概念： 這是一種革命性的思想。我們不再只為文檔建立一種索引，而是同時維護多個不同粒度的索引，像地圖一樣可以縮放。

      • Level 1 (摘要級)： 每份文檔生成一個簡短摘要。

      • Level 2 (章節級)： 將文檔切成 1K-4K token 的大塊，代表主要章節或段落。

      • Level 3 (段落級)： 切成 200-800 token 的小塊，用於精準事實檢索。

    • 檢索策略： 先在摘要級或章節級進行粗略檢索定位，鎖定相關的大塊後，再深入其對應的細粒度段落進行精準查找。

4.2.2 動態檢索架構設計

這是一個決策流程圖：

智能查詢路由系統

使用者查詢
↓
查詢分析器：評估複雜度
↓
智能路由決策
↓

精準檢索路徑 (簡單查詢)

檢索小 Chunks (200-800 tokens)
Top-k = 3-5
傳遞給標準 LLM (低成本)
快速回應

豐富檢索路徑 (複雜查詢)

檢索大 Chunks (1K-4K tokens)
Top-k = 10-20
傳遞給長上下文 LLM (高成本)
深度分析與綜合回答

系統根據查詢複雜度自動選擇最適合的檢索和生成策略

4.2.3 查詢複雜度自動評估

查詢分析器是這個架構的大腦。它可以基於簡單的規則或更複雜的機器學習模型來實現：

  • 簡單查詢標識： 包含明確的實體詞（"客服電話"、"退貨地址"）、是否型問題、單一事實查詢。

  • 複雜查詢標識： 包含比較/分析詞（"比較 A 和 B"、"分析原因"）、開放式問題（"如何規劃..."、"為什麼會..."）、需要跨文件綜合資訊的查詢。

4.3 新世代 RAG 失敗模式與應對策略

教學目標：

識別並解決長上下文時代帶來的新型 RAG 挑戰，例如資訊過載和上下文污染，並學習設計更智能、更具彈性的降級與應對機制。

4.3.1 傳統失敗模式的演進

  • 情境一：資訊檢索失敗

    • 新挑戰： 問題不再只是「找不到」，而是「找到太多不相關但語意相似」的雜訊。

    • 新策略：

      • 漸進式檢索 (Progressive Retrieval)： 先用少量（如 top-3）的結果生成初步答案，若 LLM 判斷資訊不足，再自動進行第二輪、更大範圍的檢索。

      • 語意去重 (Semantic Deduplication)： 在將檢索結果送入 LLM 前，先對 chunks 進行一次相似度計算，過濾掉內容高度重複的部分。

  • 情境二：資訊過載與迷失 ("Lost in the Middle")

    • 新挑戰： 即使找到了正確的資訊，但如果它被淹沒在數十個其他 chunks 的中間，LLM 可能會忽略它。

    • 新策略：

      • 重要性加權 (Importance Weighting)： 將相似度分數最高、最關鍵的 chunks 策略性地放置在上下文提示的開頭和結尾。

      • 結構化呈現 (Structured Prompting)： 使用 XML 標籤或 Markdown 格式將不同的 chunks 包裹起來，並附上元數據（如來源、標題），引導 LLM 更有條理地閱讀。

      • 摘要前置 (Summary First)： 在所有詳細 chunks 之前，先放入一個由它們生成的簡短摘要，給予 LLM 一個「總覽圖」。

  • 情境三：成本與效能平衡

    • 新挑戰： 如何在不犧牲回答品質的前提下，最大限度地降低成本和延遲？

    • 新策略：智能降級機制 (Intelligent Fallback)

      IF 查詢簡單 AND 精準檢索的結果信心度高 (>0.85)
THEN 使用傳統 RAG (低成本、快速)

ELIF 查詢複雜 OR 精準檢索結果信心度低
THEN 啟用長上下文 RAG (高成本、深度)

ELSE (混合情況)
THEN 先用精準檢索結果生成草稿，再用豐富檢索的結果進行補充和驗證

4.3.2 新興失敗模式

  • 情境四：上下文污染 (Context Contamination)

    • 問題： 檢索到的一些 chunks 雖然相關，但包含了錯誤或過時的資訊，這些「污染物」會誤導 LLM 的判斷。

    • 解決方案：

      • 相關性過濾器 (Relevance Filter)： 在檢索後，再用一個 LLM call (Cross-Encoder) 來二次判斷每個 chunk 與原始問題的真正相關性，過濾掉雜訊。

      • 元數據標記： 在 chunking 時加入時間戳、版本號等元數據，讓 LLM 知道哪個資訊更新、更權威。

  • 情境五：多模態處理失敗 (Multi-modal Failure)

    • 問題： 傳統的文字 chunking 會破壞表格的結構、忽略圖片的內容。

    • 解決方案：

      • 模態感知 Chunking (Modality-Aware Chunking)： 採用專門的工具（如 unstructured.io）來解析文件，將文字、表格（轉為 Markdown 或 JSON）、圖片（轉為文字描述）分開處理，並保持其完整性。

Lab：建構智能 FAQ Bot 2.0

核心目標： 建立一個能根據查詢類型自動選擇檢索策略、處理多模態資料、並具備成本監控與失敗處理機制的現代 RAG 系統。

1. 準備多層次知識庫 (knowledge_base/)

  • 簡單事實庫 (quick_facts.md)： 用於精準檢索，如 "客服電話：0800-123-456"。

  • 政策文件庫 (policies/)： 包含 current_policy.md 和 historical_policy.md，用於測試版本控制和上下文污染。

  • 複雜指南庫 (guides/comprehensive_guide.pdf)： 長篇幅文件，用於測試長上下文分析。

  • 多模態資料庫 (multimedia/)： 包含 product_specs.xlsx (產品規格表) 和 process_diagram.png (流程圖)。

2. 實作步驟：從分析器到多模態處理

  • 步驟一：實作查詢分析器 (QueryComplexityAnalyzer)

    • 基於關鍵詞（"比較", "電話", "如何"）和問題結構，將查詢分類為 SIMPLE, COMPLEX, HYBRID。

  • 步驟二：實作多層次 Chunking 策略

    • 為 quick_facts.md 建立小粒度索引 (chunk_size=400)。

    • 為 policies/ 和 guides/ 同時建立大粒度 (chunk_size=2000) 和語意感知索引。

    • 為 multimedia/ 實作多模態 Chunking，將表格轉換為 Markdown 格式，圖片用視覺模型生成描述文字。

  • 步驟三：編寫智能檢索與生成邏輯

    • 根據查詢分析器的結果，調用不同的檢索器組合（小塊/大塊，top-k 數量）。

    • 設計不同的 Prompt 模板，一個用於快速問答，一個用於深度綜合分析（並指導模型注意開頭結尾的重要資訊）。

  • 步驟四：建構監控與 A/B 測試框架

    • 成本監控 (CostMonitor)： 記錄每次查詢的 token 使用量和預估費用。

    • 效能指標： 測量回應延遲、答案的歸因率（答案是否確實來自提供的上下文）。

    • A/B 測試： 設計一個框架，可以輕鬆比較不同檢索策略組合（例如，Semantic Chunking vs. Hierarchical Chunking）在同一組測試問題上的表現。

3. 新失敗處理機制測試

  • 測試 1 (成本優化)： 提問 "客服電話號碼是多少？"，驗證系統是否走低成本的精準檢索路徑。

  • 測試 2 (深度分析)： 提問 "比較新舊兩版退貨政策的差異，並分析對VIP會員的影響。"，驗證系統是否啟動豐富檢索模式，並綜合 current_policy.md 和 historical_policy.md 的內容。

  • 測試 3 (上下文污染處理)： 提問 "退貨政策是什麼？"，驗證系統是否能優先採用 current_policy.md 的內容，或明確指出存在多個版本。

  • 測試 4 (多模態查詢)： 提問 "比較 A 型號和 B 型號的電池續航力。"，驗證系統是否能正確解析 product_specs.xlsx 中的表格數據來回答。

4. 未來趨勢與最佳實踐

  • 2025年 RAG 發展趨勢：

    • 多代理協作檢索 (Multi-Agent Retrieval)： 針對一個複雜問題，分派出不同的 AI 代理（有的擅長檢索、有的擅長分析表格、有的擅長總結），協同工作得出答案。

    • 查詢感知動態 Chunking (Query-Aware Chunking)： 系統不預先切塊，而是在接收到查詢後，即時地、動態地決定最適合該查詢的文本切割方式。

  • 實務最佳建議：

    • 從混合架構開始： 不要陷入非黑即白的選擇，智能地組合不同策略。

    • 監控是第一要務： 建立儀表板，持續追蹤成本、延遲和回答品質。

    • 賦予使用者選擇權： 對於可能耗時較長的複雜查詢，可以提供一個「進行深度分析」的選項，讓使用者決定是否願意等待。

    • 設定成本上限： 為系統設定嚴格的每日/每月預算，並實作智能限流機制，防止成本失控。

模組總結與學習重點回顧：

完成本模組後，學員將深刻理解：

  • 混合思維： 長上下文模型並非 RAG 的終結者，而是強大的新工具。現代 RAG 的精髓在於如何將新舊工具智能地組合應用。

  • 智能決策： 現代 RAG 的核心競爭力，是從一個被動的「檢索-生成」管道，轉變為一個主動的、能夠根據情境進行「分析-決策-執行」的智能系統。

  • 成本意識： 在追求技術極致的同時，必須將成本和效能作為一等公民來考量，這才是構建可持續系統的關鍵。

  • 持續進化： RAG 系統不再是一次性的建構工作，而是一個需要持續監控、A/B 測試和優化的生命體。

📘 模組 5：產品思維 for LLM Apps（第 5 週）

🎯 學習目標

在本模組中，學員將學習在 2025 年的技術背景下，如何從產品經理和使用者的角度，思考並打造一個成功、可靠且體驗卓越的 LLM 應用。我們將探討百萬級上下文的應用邊界，如何在極低延遲的預期下權衡成本與模型能力，並設計出更精細、多層次的「優雅降級」策略。

📚 核心內容

5.1 何時該用 / 不該用 LLM (2025 年視角)

✅ 何時應該優先考慮使用 LLM？

  1. 處理非結構化數據 (Unstructured Data)：（核心價值不變）

    • 情感分析、主題提取、資訊擷取等依然是核心應用。

  2. 內容生成與創意發想 (Content Generation & Creativity)：（核心價值不變）

    • 從行銷文案到輔助程式碼，LLM 依然是強大的生產力引擎。

  3. 自然語言互動介面 (Natural Language Interfaces)：（核心價值不變）

    • 得益於大幅降低的延遲，對話式 AI 的體驗已從「可用」提升至「流暢」，應用場景更廣。

  4. 處理超長上下文與複雜推理 (Mega-Context & Complex Reasoning) - [重大更新]

    • 問題特徵：你的任務需要理解和分析遠超過幾十頁的龐大資料量，甚至整個知識庫。

    • 應用範例：

      • 一次性程式碼庫分析：像 Claude Sonnet 4 支援的百萬級 Token 上下文，可以直接讀取超過 75,000 行程式碼的完整專案，進行安全審查或重構建議，而無需複雜的分片處理。

      • 學術/法律文件整合：一次性將數十篇研究論文或一份完整的案件卷宗載入模型，進行跨文件的摘要、比較和矛盾點分析。

      • 個人化終身助理：模型可以記住與使用者數月甚至數年的對話歷史，提供極度個人化的建議。

    • 產品決策：這改變了過去的架構設計，開發者需要在「架構簡化帶來的高昂單次成本」與「分片處理的複雜性但較低成本」之間做出權衡。

❌ 何時不該使用 LLM（或需極度謹慎）？

這個清單的核心原則依然有效，但在 2025 年，我們需要用更嚴格的標準來看待：

  1. 需要 100% 精準與決定性的結果 (Deterministic Results)：（原則不變）金融計算、硬體控制等，依然是傳統程式碼的領域。

  2. 對「事實」有嚴格要求的領域 (Fact-critical Domains)：（原則不變，但風險更高）模型能力越強，其產生的「幻覺」也可能越逼真、越難分辨。對醫療、法律、新聞等領域，由人類專家最終審核的原則比以往任何時候都更加重要。

  3. 簡單、規則明確的任務 (Simple, Rule-based Tasks)：（原則不變）用 GPT-5 來驗證 Email 格式，依然是極大的浪費。

5.2 成本-延遲-體驗三角取捨 (2025 年新維度)

2025 年的技術進步，讓我們對這個三角關係有了全新的理解。

  • 成本 (Cost) - [重大更新]

    • 分層定價 (Tiered Pricing)：模型定價變得更精細。例如，Claude Sonnet 4 對於 200K Tokens 以下的上下文收取較低的費用（如 $3/$15 輸入/輸出），但一旦超過 200K，費用就會提升（如 $6/$22.50）。這要求產品設計時必須精確估算上下文長度。

    • 競爭格局：模型間的成本差異巨大。例如，在大量使用場景下，GPT-5 的成本可能僅為 Claude Sonnet 4 的三分之一。選擇哪個模型，直接影響產品的利潤模型和市場競爭力。

  • 延遲 (Latency) - [重大更新]

    • 期望值的巨變：使用者對「即時性」的期望已被拉高。過去 5 秒的等待是可接受的，現在超過 2 秒就會被認為是「卡頓」。

    • 新基準：頂級模型的「首個 Token 延遲 (Time to First Token, TTFT)」已降至 0.2-0.5 秒，後續生成速度高達 200-300 tokens/秒。這使得流暢的即時語音對話、程式碼即時補全成為可能。

    • 對產品的影響：降級策略的超時設定必須更加嚴格。過去的超時，現在可能已是服務不可用的指標。

  • 體驗 (Experience / Quality) - [重大更新]

    • 超越文本生成：模型的「體驗」不再僅限於回答品質。

    • 工具使用與擴展思考 (Tool Use & Extended Thinking)：如 Claude 4 系列，模型可以在內部推理過程中自主呼叫外部工具（如 API 查詢、程式碼執行），甚至平行處理多個工具呼叫。

    • 產品設計模式：這讓 LLM 從一個「聊天機器人」進化為一個能自主完成複雜任務的「智慧代理 (Agent)」。你的產品可以設計更複雜的工作流，交由 LLM 自主規劃和執行。

5.3 優雅降級策略 (2025 年精細化版)

鑑於極低的延遲和多樣化的模型選擇，2025 年的降級策略應該是一個多層次的模型級聯 (Model Cascade)，而非簡單的二元切換。

策略核心

目標是在成本、速度和品質之間動態找到最佳平衡點，永遠優先保證使用者的基本體驗不中斷。

多層級聯策略範例

一個先進的系統不會只有一個備用選項，而是像瀑布一樣逐級嘗試：

  1. 第 1 層：頂級模型 (Top-Tier Model)

    • 模型：claude-sonnet-4 或 gpt-5-pro

    • 目標：提供最佳品質的回應。

    • 觸發條件：超時（例如 2 秒），或 API 返回錯誤。

  2. 第 2 層：中階平衡模型 (Mid-Tier Balanced Model)

    • 模型：gpt-5-mini 或 gemini-2.5-flash

    • 目標：在品質和速度/成本之間取得平衡，維持良好的互動體驗。

    • 觸發條件：超時（例如 1.5 秒），或 API 錯誤。

  3. 第 3 層：開源/高速模型 (Open-Source / Speed-focused Model)

    • 模型：本地部署的 Llama-3.3 或專門的低延遲 API。

    • 目標：速度是第一優先，確保系統總有回應。品質可能較低，但足以應付簡單請求。

    • 觸發條件：超時（例如 1 秒）。

  4. 第 4 層：快取回覆 (Cache Reply)

    • 目標：對於常見問題，直接返回之前由高品質模型生成的標準答案，成本最低、速度最快。

  5. 第 5 層：模板回覆 (Template Reply)

    • 目標：在所有 AI 模型都失效的極端情況下，給出友善的引導性回覆，並觸發監控警報。

  6. （並行策略）人工介入 (Human-in-the-Loop)

    • 在任何一層，如果模型回覆的信心度低，或使用者觸發了特定關鍵字（如「客訴」、「找真人」），都應立即通知人工團隊。

Lab (2025 更新版)：設計一個多層級聯降級策略

目標

透過撰寫 Python 腳本，模擬一個實現了精細化、多層模型級聯降級策略的現代聊天機器人。

情境

假設我們要建構一個服務，它需要快速回應，但對複雜問題又能提供高品質的解答。我們將設計一個包含頂級、中階、開源和模板回覆的四層降級策略。

實驗代碼

Step 1: 定義我們的模型級聯策略

我們將策略定義在一個列表中，方便管理和擴展。

Python

# 2025 年的多層降級策略
MODELS_CASCADE = [
    {"name": "claude-sonnet-4", "timeout": 2.0, "cost_level": "high", "quality": "premium"},
    {"name": "gpt-5-mini", "timeout": 1.5, "cost_level": "medium", "quality": "balanced"},
    {"name": "your-local-llama-3.3", "timeout": 1.0, "cost_level": "low", "quality": "basic"},
]

Step 2: 更新 Bot 函式以實現級聯邏輯

ask_my_bot 函式將會遍歷我們的策略列表，直到獲得成功的回應。

Python

import openai
import os
import time

# 建議使用環境變數來設定你的 API Key
# os.environ["OPENAI_API_KEY"] = "sk-..."
client = openai.OpenAI()

# 假設的函式，用於呼叫本地模型
def call_local_model(prompt, timeout):
    # 這是一個模擬函式，實際應用中你會在這裡連接到你的本地模型服務
    print(f"--- 正在嘗試使用本地模型 (超時設定: {timeout}秒) ---")
    time.sleep(1.2) # 故意讓它有時會超時
    if timeout < 1.1:
        raise TimeoutError("本地模型處理超時")
    return f"來自本地模型的快速回答：關於 '{prompt[:20]}...' 的答案。"


def get_llm_response(prompt, model_config):
    """通用 LLM API 呼叫函式，根據配置操作"""
    model_name = model_config["name"]
    timeout = model_config["timeout"]

    try:
        if "your-local" in model_name:
             # 處理本地模型呼叫
            response_content = call_local_model(prompt, timeout)
        else:
            # 處理 OpenAI API 呼叫
            print(f"--- 正在嘗試使用雲端模型: {model_name} (超時設定: {timeout}秒) ---")
            response = client.chat.completions.create(
                model=model_name,
                messages=[{"role": "user", "content": prompt}],
                timeout=timeout,
            )
            response_content = response.choices[0].message.content

        print(f"✅ {model_name} 成功回應！")
        return response_content

    except Exception as e:
        print(f"❌ {model_name} 發生錯誤或超時: {e}")
        return None


def ask_my_bot_2025(user_query):
    """
    實作了2025年版多層級聯降級策略的 Bot
    """
    final_response = None
    
    for model_config in MODELS_CASCADE:
        print(f"\n>> 進入降級層級: {model_config['quality']} ({model_config['name']})")
        final_response = get_llm_response(user_query, model_config)
        if final_response:
            break  # 如果成功獲得回應，就跳出循環
    
    # 如果遍歷完所有模型都失敗，返回最終的模板回覆
    if final_response is None:
        print("\n>> 降級策略最終層：返回模板訊息。")
        final_response = "非常抱歉，我們的智慧助理目前遇到了一些困難。我們的團隊已收到通知，請您稍後再試。感謝您的理解！"
        
    return final_response

Step 3: 測試與觀察

Python

# --- 測試開始 ---

print("【測試案例：一個需要高品質答案的複雜問題】")
query = "請從產品經理的角度，分析百萬級 Token 上下文對 RAG (檢索增強生成) 架構的顛覆性影響，並考量其分層定價帶來的成本挑戰。"
final_answer = ask_my_bot_2025(query)
print("\n🤖 最終回覆:\n", final_answer)
print("-" * 40)

思考題 (2025 年版)

  1. 上下文與成本的權衡：一個使用者上傳了一份 500 頁的 PDF 報告（約 250K tokens）。你應該選擇用 claude-sonnet-4 一次性處理（進入高價區間），還是自己寫分片處理邏輯，讓 gpt-5-mini 在低價區間多次處理？你的決策依據是什麼？

  2. 動態超時設定：目前的 timeout 是固定的。我們能否根據使用者的問題類型（例如，判斷是簡單問候還是複雜分析）來動態調整每一層的超時時間？這會帶來什麼好處？

  3. 模型選擇的智慧化：除了失敗降級，我們能否在第一時間就做出更智慧的選擇？例如，設計一個輕量級的「路由模型 (Router Model)」，它的唯一工作就是判斷使用者的問題應該直接交給哪個層級的模型處理最有效率？

📘 模組 6：應用級 Workflow（第 6 週）

🎯 學習目標

本模組旨在讓學員掌握設計與建構「應用級」大型語言模型（LLM）工作流程的關鍵技術。我們將跳脫單純的「一問一答」，學習如何打造能夠處理複雜、真實世界任務的 AI 系統。學員將學習如何引導模型進行多步驟思考、如何應對不完美的用戶輸入，並探索如何利用長上下文的優勢，設計出高效、可靠的 AI Agent，最終透過實作一個現代化的訂單查詢助理來鞏固所學。

📚 核心內容

6.1 多步驟任務設計（Chain 思維的演進）

6.1.1 核心概念：從「API 鏈」到「指令鏈」

過去，由於模型上下文視窗的限制，處理複雜任務需要將其拆解成多個步驟，並透過多次 API 呼叫來串連，每一步的輸出成為下一步的輸入。這就是傳統的「Chain 思維」。

Chain 思維的演進：

隨著模型上下文長度的飛躍性增長，我們現在可以在單一的 API 請求中，給予模型一套包含多個步驟的複雜指令集。Chain 的概念依然存在，但它從一個外部的「API 鏈」，內化成了一個 Prompt 內部的「指令鏈」。

  • 教學比喻：過去，你像是在對一位記憶力有限的助理下達指令，必須說完一步，等他做完回報後，再告訴他下一步。現在，你可以把一份包含所有步驟的完整「待辦清單」直接交給一位能過目不忘的超級助理，讓他一次性規劃並執行。

6.1.2 設計模式的轉變

這種轉變極大地改善了效率和狀態保持能力：

  • 延遲與成本的權衡變化：過去多次 API 呼叫意味著高延遲和高成本。現在，雖然單次請求的處理時間可能稍長，但總體延遲和成本都顯著降低。

  • 更好的狀態保持：在單一請求中，模型能看到完整的上下文，從用戶的原始輸入到每一步指令，大幅減少了資訊在步驟間傳遞時的損耗或扭曲。

範例：從多步驟到單一指令

# 過去：需要分開呼叫，容易出錯且耗時
step1_result = llm("校正錯字: " + user_input)
step2_result = llm("提取意圖: " + step1_result)
step3_result = llm("選擇工具: " + step2_result)

# 現在：在長上下文環境下，可以一次完成
prompt = f"""
請處理以下用戶輸入，並依序執行這些步驟：
1. 校正所有錯別字和語法錯誤。
2. 提取用戶的核心意圖和所有關鍵資訊（如訂單號）。
3. 根據意圖，從可用工具列表中選擇最合適的一個。

用戶輸入: {user_input}

請以 JSON 格式回傳你的分析結果。
"""
result = llm(prompt)

第二部分：髒資料處理（整合式前處理）

1. 核心概念：前處理內化

過去，「髒資料」的清理（錯字、多語、情緒）通常作為獨立的「前處理」環節。現在，得益於長上下文和更強的指令遵循能力，這些清理步驟可以直接整合進主要的任務 Prompt 中，成為「指令鏈」的第一環。

6.2 處理策略

我們的策略從「分步清洗」轉變為「一次性指令清洗」。在主 Prompt 中明確指示模型：在進行核心任務（如意圖分析、工具選擇）之前，必須先完成數據的校正、翻譯和標準化。

  • 問題：「搞什麼東西！我的貨到現在還沒收到，爛透了！快告訴我 order 12345 在哪！」

  • 現代化處理 Prompt：

    「你是一個客服助理。請分析以下用戶輸入。首先，修正錯字並將內容標準化為繁體中文。然後，忽略情緒性發言，提取出用戶的核心請求和訂單號碼。最後，選擇合適的工具。用戶輸入：[...]」

6.3 簡單 Agent-like Flow（工具選擇的現代化）

6.3.1 核心概念：從單一決策到綜合分析

Agent 的核心依然是賦予 AI 「思考」與「行動」的能力。但在長上下文時代，這個「思考」過程變得更加全面。模型不再僅僅是根據（可能已經被處理過的）輸入來選擇工具，而是被要求同時完成從清理到分析再到決策的全過程。

6.3.2 現代化的 Agent 決策 Prompt

我們不再需要一個只專注於工具選擇的簡單 Prompt。取而代之的是一個更全面的任務型 Prompt，它要求模型輸出一份結構化的執行計畫。

  • 現代化 Agent 的決策 Prompt：

    「你是一個客服助理。分析以下用戶輸入，並以 JSON 格式輸出一個行動計畫。這個計畫必須包含：1. cleaned_input: 校正和標準化後的用戶請求。2. intent: 用戶的核心意圖。3. entities: 提取出的關鍵實體（如 order_id）。4. suggested_tool: 你建議呼叫的工具名稱。5. response_tone: 根據用戶情緒建議的回應語氣。可用工具：[...] 用戶輸入：[...]」

6.4 進階 Agent 設計 — 階層式規劃與新框架

6.4.1 階層式規劃的再思考

階層式規劃（分解、解決、組合）的核心思想依然至關重要。但長上下文改變了其實作的粒度。過去需要 Agent 框架（如 LangChain）透過多次 LLM 呼叫來完成的「思考 -> 行動 -> 觀察」循環，現在有越來越多的部分可以被一個更強大的 LLM 在單次呼叫中完成。

6.4.2 實作框架的演進與權衡

  • 框架發展：

    • LangChain：依然是主流，但其使用模式正在演變。新的工具如 LangGraph 允許開發者建立更複雜、有狀態、可循環的 Agent 工作流，而不僅僅是線性的鏈條，這更好地適應了需要多次與外部世界互動的複雜任務。

    • 新興框架與原生能力：OpenAI 的 Responses API 和 Anthropic 的 tool_use 等功能，將 Agent 的許多核心邏輯（如工具選擇、狀態管理）直接內建到模型 API 中。這簡化了開發，但也可能犧牲部分客製化的彈性。

  • 現實的權衡：新瓶頸的出現

    • 延遲瓶頸：雖然減少了 API 呼叫次數，但包含複雜指令和長篇上下文的單次請求，其「思考時間」（Time to First Token）可能會變長。瓶頸從「網路往返次數」轉向了「單次推理的複雜度」。

    • 可靠性瓶頸：模型能否在一個超長的 Prompt 中，穩定地、準確地遵循所有指令，成為了新的挑戰。一個步驟出錯，可能會影響後續所有指令的執行，這被稱為「注意力渙散」問題。

結論：理解階層式規劃的思維，並學會利用現代化的工具（長上下文、Function Calling、LangGraph），在「單次請求的效率」和「多步互動的可靠性」之間找到最佳平衡，是從「建構 AI 應用」邁向「建構高階 AI Agent」的關鍵。

💡 架構診斷思維：當你的Agent系統出現問題時，先診斷是哪一層的問題：

  • 數據層問題：檢索品質差、向量相似度不準 → 改善 Embedding 策略或 Chunking
  • 編排層問題：Agent間協作混亂、任務分派不當 → 重構工作流邏輯
  • 平台層問題：業務規則執行錯誤、狀態管理失序 → 檢查業務邏輯設計
  • 體驗層問題：用戶體驗差、回應不符預期 → 優化 Prompt 工程和 UX 流程

Lab：訂單查詢助理（2025 現代化版）

目標

利用長上下文和結構化輸出能力，打造一個高效、單次呼叫即可完成分析的訂單查詢助理。

功能要求

助理的核心是一個能夠接收原始用戶輸入，並一次性返回一個包含所有分析結果和行動建議的結構化物件（JSON）的函式。

現代化的實作方式

我們將設計一個函式 order_assistant(user_input)，其核心是向 LLM 發送一個綜合性的 Prompt。

# 現代化的實作方式
def order_assistant(user_input):
    # 這個 Prompt 是整個 Lab 的核心
    prompt = f"""
    你是頂尖的訂單查詢助理。請對用戶的輸入進行全面的分析，並嚴格按照以下 JSON 格式輸出你的結論。

    分析流程：
    1. 清理和標準化輸入：修正所有錯別字，並將語言統一為繁體中文。
    2. 提取訂單號碼和查詢意圖：意圖應為 "查詢訂單狀態" 或 "查詢物流進度"。
    3. 選擇合適的工具：從 'get_order_status' 或 'get_shipping_details' 中選擇。
    4. 分析用戶情緒：情緒應為 "正面", "中性", 或 "負面"。

    可用工具：
    - get_order_status(order_id): 查詢訂單的處理狀態（例如：處理中、已出貨）。
    - get_shipping_details(order_id): 查詢包裹的物流進度（例如：已交給司機）。

    用戶輸入：
    "{user_input}"

    輸出格式（僅輸出 JSON，不包含任何額外文字）：
    {{
      "cleaned_input": "...",
      "intent": "...",
      "order_id": "...",
      "selected_tool": "...",
      "user_sentiment": "..."
    }}
    """
    # 在實際應用中，這裡會呼叫 llm(prompt) 並解析返回的 JSON
    # llm_response_json = llm(prompt)
    # return llm_response_json
    print(prompt) # 教學時，我們先印出 Prompt 來分析

# 範例 1 (錯字 + 混合)
order_assistant("我想查一下我的 order, 編號是 111-222-333，現在ㄉㄠˋ哪了？")

# 範例 2 (情緒化 + 核心指令)
order_assistant("氣死我了，等了好幾天都沒消息，我的訂單 987654321 到底處理好了沒？")

預期輸出 (JSON):

  • 範例 1 會輸出:

    {
  "cleaned_input": "我想查一下我的訂單，編號是 111-222-333，現在到哪了？",
  "intent": "查詢物流進度",
  "order_id": "111-222-333",
  "selected_tool": "get_shipping_details",
  "user_sentiment": "中性"
}

  • 範例 2 會輸出:

    {
  "cleaned_input": "我的訂單 987654321 到底處理好了沒？",
  "intent": "查詢訂單狀態",
  "order_id": "987654321",
  "selected_tool": "get_order_status",
  "user_sentiment": "負面"
}

後端系統在收到這個 JSON 後，就可以非常清晰地知道接下來該執行哪個函式，以及在回應客戶時應該使用什麼樣的語氣。

📘 模組 7：可靠性與可觀測性（第 7 週）

🎯 學習目標

本模組旨在讓學員掌握在長上下文（Long Context）時代，如何建構和維護穩定、高效且具成本效益的 LLM 應用。我們將揚棄過去以 Token 限制為核心的舊思維，轉向以「最大化任務價值」為導向的新工程典範，學習如何駕馭龐大的上下文窗口，並透過數據驅動決策，確保系統的卓越表現。

📚 核心內容

7.1 成本工程 (Cost Engineering) 的新現實

核心概念： 在長上下文時代，成本考量從「如何節省每一個 Token」轉變為「如何用好每一個 Token 以最大化單次呼叫的價值」。關鍵在於計算每任務的投資回報率 (ROI)，而非僅僅是每 Token 的成本。

1. 長上下文經濟學 (Long Context Economics)

  • 2025 年的新的成本思維：

    • 從「節省 Tokens」到「最大化上下文價值」： 過去，我們為了塞進有限的上下文窗口，需要對 Prompt 進行極致壓縮。現在，我們可以提供更豐富、更完整的背景資訊，讓模型做出更高品質的判斷和生成。

    • 從「每 Token 成本」到「每任務 ROI」： 一個昂貴但能一次性完美解決複雜任務的長上下文呼叫，其總體成本和使用者體驗，可能遠勝於多次廉價但效果不佳的短上下文呼叫。

  • 實例分析：多文件分析任務

    • 想像你需要分析一個包含 20 份研究報告的數據集。

    Python

    # 舊方法：多次短請求，受限於上下文長度
# 缺點：無法進行跨文件比較，資訊孤立，總體成本可能更高
def traditional_analysis(documents):
    summaries = []
    # 因上下文限制，只能處理前 5 份文件
    for doc in documents[:5]:
        # 每次呼叫都只看到一份文件的內容
        summary = llm.summarize(doc, max_tokens=4000)
        summaries.append(summary)
    return " ".join(summaries) # 最終結果是零散摘要的拼湊

# 新方法：單次長上下文請求，釋放模型潛力
# 優點：模型能看到全局，進行交叉引用和深度分析，一次性產出高價值洞察
def long_context_analysis(documents):
    # 將所有文件一次性放入上下文中
    comprehensive_analysis = llm.analyze_all_documents(
        documents=documents, # 可以包含所有 20 份文檔
        analysis_depth="comprehensive",
        instructions="""
        Analyze all provided documents. Identify the core recurring themes,
        point out any contradictions between documents, and synthesize a
        high-level executive summary with key action items.
        """
    )
    return comprehensive_analysis

2. Batching 策略的重新思考

  • 傳統 Batching 仍然適用： 對於大量、獨立、簡單的請求（如關鍵字提取），將多個小請求批次處理以降低網路開銷依然有效。

  • 新的「上下文即批次」策略 (Context as a Batch)： 長上下文窗口讓我們能將一個複雜任務所需的所有資訊（多輪對話歷史、多份文件、資料庫查詢結果）視為一個「批次」，在單一請求中處理。

    Python

    # 舊策略：傳統的請求級批次處理
def old_batching(requests):
    batch = []
    for req in requests:
        if len(batch) < 10: # 傳統批次大小
            batch.append(req.prompt)
    return process_batch(batch)

# 新策略：利用長上下文處理單一複雜任務
# 這裡的 "batch" 指的是資訊的批次，而非請求的批次
def new_context_strategy(complex_task):
    # complex_task 包含了一個用戶的所有相關數據
    # 這是一次呼叫，但處理了 "一批" 資訊
    return process_with_full_context(
        documents=complex_task.all_documents,
        conversation_history=complex_task.full_history,
        analysis_requirements=complex_task.comprehensive_requirements
    )

3. 模型路由的新考量

  • 路由維度增加： 除了成本和任務複雜度，「是否需要長上下文推理能力」 成為了關鍵的路由決策點。

  • 更新的路由邏輯：

    • 意圖分析器 (Intent Classifier) 應該首先判斷任務類型。

    Python

    def updated_model_routing(request):
    # 1. 判斷任務是否需要長上下文
    if request.requires_long_context_reasoning:
        # 例如：需要分析超過 50 頁的 PDF，或超過 100 輪的對話
        return "claude-3-sonnet-35" # 或 Gemini 1.5 Pro，善用長上下文能力

    # 2. 如果不需要，再根據複雜度判斷
    elif request.is_simple_classification_or_extraction:
        # 例如：情感分析、提取地址
        return "claude-3-haiku" # 快速、便宜的選擇

    # 3. 處理需要高品質生成但上下文不長的任務
    elif request.needs_high_quality_generation:
        # 例如：撰寫一封重要的行銷郵件
        return "gpt-4o" # 平衡性能與成本的強大模型

    else:
        # 預設或更複雜的路由邏輯
        return "claude-3-sonnet-35"

7.2 可觀測性 (Observability) 的新維度

核心概念： 系統的可觀測性讓我們能夠量化長上下文帶來的影響，尤其是在延遲和性能表現上。

1. Logging 與錯誤分析 (無重大變化，但記錄內容更龐大)

  • 挑戰： 輸入的 Prompt 和輸出可能非常長，對日誌儲存和分析帶來壓力。

  • 策略： 需要更高效的日誌系統，並可能需要對超長日誌進行摘要或結構化提取後再儲存。

2. 延遲分析的新維度 (New Dimension in Latency Profiling)

  • 舊的延遲模型已不完整。 我們必須加入一個關鍵的新變數：上下文載入時間。

  • 更新的延遲分析公式：

    $$T_{\text{total}} = T_{\text{network}} + T_{\text{queue}} + T_{\text{processing}} + T_{\text{context_loading}} + T_{\text{TTFT}} + T_{\text{generation}}$$

  • 新增的關鍵考量：

    • T_textcontext_loading (上下文載入時間): 模型在生成第一個 Token 之前，需要花費時間來讀取和理解整個龐大的上下文。這個時間是非線性的，上下文越長，此時間也越長。

    • 長上下文下的 TTFT (Time to First Token): 由於 T_textcontext_loading 的存在，長上下文請求的 TTFT 必然會更長。這是一個必須接受的權衡。

    • 決策關鍵： 我們追求的不是最低的 TTFT，而是最高的總體價值。多等待幾秒鐘，換來一個全面、準確、無需返工的答案，對使用者來說體驗更好。

7.3 新增！上下文管理策略 (Context Management Strategy)

核心概念： 即使上下文窗口有百萬 Tokens，它依然是有限的，且模型對資訊的注意力並非均勻分佈（「迷失在中間」問題）。有效的上下文管理是釋放長上下文模型全部潛力的關鍵。

Python

class ContextManager:
    def __init__(self, max_context_length: int = 1_000_000):
        self.max_length = max_context_length

    def build_context_for_task(self, conversation_history, documents):
        """
        智能地選擇、排序和組織上下文內容，
        而不是單純地拼接和截斷。
        """
        return self._strategic_context_selection(conversation_history, documents)

    def _strategic_context_selection(self, history, docs):
        # 1. 相關性排序：使用 embedding 或關鍵字匹配，將最相關的文檔片段放在前面。
        ranked_docs = self._rank_documents_by_relevance(docs)

        # 2. 位置策略：將最重要的指令或問題放在上下文的開頭或結尾。
        #    研究表明模型對這兩端的信息最敏感。
        final_prompt = f"""
        [BEGIN CRITICAL INSTRUCTIONS]
        Your primary goal is to answer the user's final question based on the
        provided documents and conversation history.
        User's final question is: {history[-1]['content']}
        [END CRITICAL INSTRUCTIONS]

        [BEGIN CONVERSATION HISTORY]
        {self._format_history(history)}
        [END CONVERSATION HISTORY]

        [BEGIN RELEVANT DOCUMENTS - HIGHEST RELEVANCE FIRST]
        {self._format_documents(ranked_docs)}
        [END RELEVANT DOCUMENTS]
        """
        return final_prompt

  • 核心策略：

    • 相關性排序 (Relevance Ranking): 在將文件放入上下文之前，先用輕量級模型或 embedding 對其與當前問題的相關性進行打分排序。

    • 位置工程 (Positional Engineering): 確保最關鍵的指令（如 "You MUST answer in JSON format"）和最新的使用者問題被放置在上下文的起始或結束位置。

    • 上下文壓縮 (Context Compression): 對於較早的、不那麼重要的對話歷史，可以使用一個小模型先進行摘要，再將摘要放入長上下文中。

7.4 Lab 實驗更新：Long Context vs. Traditional Approach

實驗目標： 量化比較「單次長上下文請求」與「傳統多次短請求」在成本、延遲和輸出品質上的差異，並根據數據做出架構決策。

實驗設定：

  1. 場景： 根據一份 100 頁的 PDF 財報，回答一個需要整合報告中多個章節資訊的複雜問題（例如，“分析第三季度的市場行銷支出與銷售額增長的關係，並與前一季度的表現進行比較”）。

  2. 建立兩個處理流程：

    Python

    import time

# 方法 A：傳統多次請求 (簡化 RAG)
async def traditional_approach(full_document_text, question):
    start_time = time.time()
    # 1. 將文檔切片
    document_chunks = split_into_chunks(full_document_text, chunk_size=3000)
    # 2. 找到相關的切片 (簡化版，真實世界會用 embedding)
    relevant_chunks = find_relevant_chunks(document_chunks, question)
    # 3. 多次呼叫 LLM
    results_traditional = []
    for chunk in relevant_chunks:
        prompt = f"Context: {chunk}\n\nQuestion: {question}\n\nAnswer:"
        result = await llm_call(prompt, model="claude-3-haiku")
        results_traditional.append(result)
    # 4. 最後可能還需要一次呼叫來綜合答案
    final_answer = await llm_call(f"Synthesize these answers: {results_traditional}", model="claude-3-haiku")
    traditional_time = time.time() - start_time
    return {"answer": final_answer, "time": traditional_time, "cost": calculate_cost(multiple_calls)}

# 方法 B：長上下文單次請求
async def long_context_approach(full_document_text, question):
    start_time = time.time()
    prompt = f"Document: {full_document_text}\n\nQuestion: {question}\n\nAnswer based on the full document:"
    result_long_context = await llm_call(prompt, model="claude-3-sonnet-35")
    long_context_time = time.time() - start_time
    return {"answer": result_long_context, "time": long_context_time, "cost": calculate_cost(single_call)}

  3. 比較指標：

    • 延遲 (Latency):

      • traditional_time vs. long_context_time。

      • 預期結果： 長上下文方法的總時間通常更短，因為它避免了多次網路來回和複雜的應用層邏輯。

    • 成本 (Cost):

      • 計算兩種方法總共消耗的 Token 成本。

      • 預期結果： 長上下文呼叫的單價更高，但傳統方法多次呼叫的成本累加起來可能不相上下，甚至更高。

    • 品質 (Quality) - (最重要的指標!)

      • 人工評估： 答案是否全面？是否發現了隱藏的關聯？是否產生幻覺？

      • LLM-as-a-Judge： 使用 GPT-4o 或 Claude 3 Opus 作為裁判，對兩個答案進行評分。

      • 預期結果： 長上下文方法因為擁有全局視野，其答案品質通常遠超傳統方法。

決策討論：

  • 如果長上下文方法的品質顯著更高，那麼它增加的成本和 TTFT 延遲是否值得？在什麼業務場景下是值得的？（例如：法律文件審查、醫療報告分析）。

  • 在成本極度敏感但對品質要求不高的場景下，傳統方法是否仍有一席之地？

  • 如何結合兩者？能否先用長上下文方法生成高品質的草稿，再用小模型進行格式化或微調？

📘 模組 8：應用落地與 UX 強化（第 8 週）

🎯 學習目標

歡迎來到第八個模組。在前面的課程中，我們專注於如何建構和優化 LLM 的核心功能。現在，我們要將目光轉向產品化的最後一哩路：如何將應用實際部署、衡量其成效，並打造讓使用者滿意且信賴的互動體驗。隨著模型上下文長度的飛速增長，我們面臨著新的成本挑戰和 UX 設計機會。一個功能強大的模型，必須搭配精細的指標追蹤、優雅的使用者體驗和智慧的成本控制，才能在真實世界中取得成功。

📚 核心內容

8.1 產品指標設計 (Product Metrics Design)

當我們的 LLM 應用上線後，我們需要一套客觀的指標來量化評估其表現。這些指標可以分為兩大類：系統效能指標和使用者體驗指標。

1. 系統效能指標 (System-Centric Metrics)

這類指標關注應用程式本身的技術表現、穩定性和成本效益。

  • 延遲 (Latency)

    • 定義：從使用者發出請求到系統完整回覆所需的時間 (ms)。

    • 為何重要：過長的延遲會嚴重影響使用者體驗。需要監控平均延遲與 P95/P99 延遲。

    • 追蹤方式：紀錄請求與回覆的時間戳，計算差值並匯總到監控系統。

  • 錯誤率 (Error Rate)

    • 定義：系統無法成功處理請求的比例（如 API 失敗、超時）。

    • 為何重要：衡量系統可靠性的核心指標。

    • 追蹤方式：捕捉程式中的例外狀況，計算 (失敗請求數 / 總請求數) * 100%。

  • Token 成本 (Token Cost)

    • 定義：每次與 LLM API 互動所消耗的 Token 數量，直接對應營運成本。

    • 新的考量：上下文長度增加使成本分析更複雜：隨著模型（如 Claude 3, GPT-4 Turbo）的上下文窗口動輒超過 100K Tokens，單次對話的潛在成本急劇上升。我們不能再只看單次呼叫的成本，而必須從整個對話生命週期的角度來評估。

    • 追蹤方式：累加 API 回傳的 usage 數據，分析單日成本、單一使用者平均成本、單次對話總成本等。

  • 新增指標：上下文利用率 (Context Utilization)

    • 定義：衡量我們的應用在多大程度上利用了模型提供的長上下文能力。

    • 為何重要：高昂的長上下文成本必須花在刀口上。此指標幫助我們了解使用者真實的對話模式，判斷是否需要為長對話優化，或是否可以透過更積極的上下文管理來降低成本。

    • 追蹤方式：

      • 上下文窗口使用率：追蹤每次 API 呼叫時，prompt_tokens 佔模型最大上下文長度的比例。

      • 對話長度分布：分析所有對話的總 Token 數分布，了解是短問答為主，還是深度長對話為主。

2. 使用者體驗指標 (User-Centric Metrics)

這類指標關注使用者對產品的真實感受和互動結果。

  • 顧客滿意度 (CSAT - Customer Satisfaction)：透過 👍/👎 或星級評分，直接了解使用者感受。

  • 問題解決率 (Resolution Rate)：衡量 Bot 成功解決使用者問題的比例，是其核心價值的體現。

  • 後援率 / 轉人工率 (Fallback Rate)：衡量 Bot 無法處理請求的比例，是模型或 Prompt 需要優化的信號。

8.2 LLM 特有的進階 UX 模式

我們需要一些特殊的 UX 設計模式來管理使用者的預期、建立信任感，尤其是在處理複雜任務時。

  • 思考過程可視化 (Visualizing Thought Process)

    • 目的：解決「空白等待」問題，讓使用者知道系統正在處理中。

    • 實現方式：

      • Typing 效果 / 流式輸出 (Streaming)：最基本也最有效的方式，即時顯示生成的文字。

      • 長文檔處理的進度指示：當處理需要數十秒的長文檔或複雜任務時，必須提供更詳細的狀態回饋。例如，可以依序顯示：

        • "正在分析文檔結構..."

        • "提取關鍵資訊中..."

        • "生成回覆中..."

        • "完成分析"

  • 信心度顯示 (Confidence Score Display)

    • 目的：管理使用者期望，告知模型對答案的確定程度。

    • 實現方式：附上資料來源連結、使用顏色或標籤標示信心等級。

  • 快速修正 (Quick Correction Mechanisms)

    • 目的：提供簡單途徑讓使用者修正不滿意的結果，並收集優化數據。

    • 實現方式：提供「重新生成」、「編輯問題」、「回報問題 (👍/👎)」等按鈕。

  • 新增 UX 模式：智能摘要與分段回覆 (Intelligent Summarization & Segmented Replies)

    • 目的：當模型針對複雜問題生成非常長的回覆時，避免使用者被資訊淹沒，提升內容的可讀性和可消化性。

    • 實現方式：

      • 智能摘要：在長回覆的頂部自動生成一個核心觀點的摘要（TL;DR），並提供「展開閱讀全文」的選項。

      • 分段式呈現：將長答案自動拆分為有標題的段落，使用者可以點擊各段落標題來閱讀詳細內容，類似可折疊的手風琴效果。

8.3 成本與上下文優化策略

由於上下文窗口變大，成本管理和對話歷史的處理變得空前重要。

  • 動態上下文管理 (Dynamic Context Management)

    • 問題：無限制地將所有對話歷史送入 Prompt，會導致 Token 成本迅速膨脹，且可能因為無關資訊過多而降低回覆品質。

    • 策略：與其在達到硬性上限時粗暴地截斷歷史，不如採用更智慧的策略。

    • 實現方式：

      • 智慧截斷 (Smart Truncation)：設計一個函式，當對話歷史接近成本或效能閾值時，自動進行優化。例如，可以保留對話的第一則（通常定義了任務目標）、最近的幾則（維持對話流暢性），並從中間的對話中提煉摘要或關鍵實體。

      • 範例邏輯：

        def optimize_context_window(conversation_history, max_tokens=50000):
    if calculate_tokens(conversation_history) > max_tokens * 0.8:
        # 演算法：保留第一則、最新的 N 則，並對中間部分進行摘要
        return smart_truncate(conversation_history)
    return conversation_history

8.4 Lab 升級版

在這個實作環節，我們將建立一個能應對長對話和長文檔處理的客服機器人。

  • 目標：建立一個具備進階產品思維的客服機器人，能夠監控成本、優雅地處理複雜任務，並智慧地管理對話歷史。

  • 步驟：

    1. 基礎部署：同前，使用 Streamlit 或 Flask/React 部署一個基本的問答機器人。

    2. 整合進階指標追蹤：

      • 上下文成本監控面板：在介面上（或至少在後端日誌中）顯示當前對話累計的 prompt_tokens 和 completion_tokens，以及佔模型最大上下文的比例。

      • 紀錄 Latency 和 Error Rate。

    3. 加上進階 UX 元件：

      • 實現流式輸出和 👍/👎 按鈕。

      • 模擬長文檔處理流程：新增一個功能，當使用者輸入特定指令（如 /process_doc）時，模擬一個耗時幾秒的處理過程，並在前端依序顯示處理進度（分析結構 -> 提取資訊 -> 生成回覆）。

    4. 實現智慧對話管理：

      • 在後端實現一個簡單的動態上下文管理函式。設定一個較小的 Token 閾值（例如 4000 Tokens），一旦對話歷史超過該值，就觸發截斷邏輯（例如，只保留第一則和最新的五則訊息），並在介面上提示使用者「為節省成本，部分較早的對話已被摘要」。

  • 預期成果：完成後，你將擁有一個更貼近真實產品需求的 LLM 應用。它不僅具備良好的互動體驗，還能在後端展現出對成本和效能的精細化考量。

🎓 終極專題：Capstone Project

🎯 專題目標

從零開始，設計並實作一個能解決特定問題、且具備良好使用者體驗的 LLM 應用程式。這不只是一個技術練習，更是一個完整的產品開發挑戰。你的目標是打造一個「能用、好用、甚至讓人驚豔」的 MVP (Minimum Viable Product)，並勇敢挑戰新世代大型語言模型（如 Claude 3, Gemini 1.5 Pro）的長上下文能力。

📝 專題選項

你可以選擇以下任一方向，或提出自己的創新想法。重點是鎖定一個具體的場景和目標使用者。

1. 智慧助理型

  • 個人化學習助手：使用者上傳課程講義（PDF/Text），App 能根據內容生成摘要、練習題，並回答相關問題。

  • 會議記錄 Copilot：整合語音轉文字 API，將會議錄音轉為文字稿，再利用 LLM 抓出會議重點、待辦事項 (Action Items) 和時程。

  • 求職面試教練：模擬特定職位（如軟體工程師、行銷經理）的面試，能提出專業問題、分析使用者的回答，並提供改進建議。

2. 內容創造型

  • 社群媒體文案產生器：使用者只需輸入產品名稱、目標客群和幾個關鍵字，App 就能生成適用於 Instagram、Facebook 等不同平台的行銷文案。

  • 個人化食譜規劃師：根據使用者現有的食材、飲食偏好（如素食、低碳）和烹飪時間，生成一週的創意食譜。

  • 兒童睡前故事產生器：讓家長輸入主角名字、場景和想傳達的寓意，動態生成一個獨一無二的短篇故事。

3. 資訊處理型

  • 論文/報告閱讀器：上傳一篇學術論文或市場報告，App 能快速提煉出其核心論點、研究方法和結論，並允許使用者針對圖表或特定段落進行提問。

  • 法律合約審閱助手：使用者上傳合約文件，App 能用白話文解釋複雜的法律條文、標示出可能存在風險的條款，並提醒缺少的關鍵要素。

  • 使用者回饋分析師：輸入一批來自 App Store 或電商的顧客評論，App 能自動分類、總結出主要的優點、缺點和改進建議。

🚀 4. 前瞻構想：挑戰長上下文極限

  • 完整書籍分析師：上傳整本教科書、小說或財報（例如《哈利波特》全集），App 能進行跨章節的角色關係分析、情節伏筆追蹤，或對財報進行跨年度的深度比較。

  • 大型專案文件整合器：讓使用者一次上傳一個軟體專案的所有技術文件（Spec, API Docs, Code Snippets），App 能成為該專案的專家，回答關於架構、函式用法等深入問題，甚至產生新的程式碼範例。

  • 長期對話記憶個人助理：打造一個能記住過去數週、甚至數月對話的個人助理。你可以問它：「我們三週前討論那個專案時，我提到最擔心哪個技術風險？」它能準確地從長期記憶中找出答案。

詳細評分標準

A. 技術面 (40%) - App 的骨架是否穩固？

  1. API 整合與穩定性 (15%)

    • 基本要求：成功且穩定地串接至少一個主流 LLM API (例如 Gemini, OpenAI API, Claude API)。

    • 加分項：是否整合了多個 API（如文字生成、圖片理解、文字轉語音等）來創造更豐富的功能？API 金鑰等敏感資訊是否有做基本的安全管理？

  2. 錯誤處理與使用者引導 (15%)

    • 基本要求：當 API 回應超時、失敗或回傳無效內容時，前端介面能給予使用者清晰的提示，而不是直接崩潰或卡住。

    • 加分項：對於使用者不恰當的輸入（例如：上傳了超大檔案、輸入空白內容），是否有做前端驗證和引導？

  3. 效能、成本與長上下文策略 (10%)

    • 基本要求：App 的回應速度在可接受的範圍內。能清楚說明自己選擇了哪個等級的 LLM 模型，並解釋原因。

    • 新思維：過去我們強調「精簡 Prompt 減少 Token」，但在長上下文時代，策略應轉變為如何最有效地利用龐大的上下文空間。

    • 加分項：是否有實作以下策略？

      • 豐富上下文：在 Prompt 中提供更豐富的背景資訊、範例 (Few-shot) 和詳細指令，以換取遠比以往更高品質的輸出。

      • 合併請求：將過去需要多次 API 呼叫才能完成的複雜任務（例如：先摘要、再分析、最後生成表格），整合到單一、包含完整思考鏈的長 Prompt 中處理，以提升效率和結果的連貫性。

B. 產品面 (40%) - App 的體驗是否流暢？

  1. 使用者體驗 (UX) 流暢度 (15%)

    • 基本要求：介面直觀、操作流程清晰。在等待 LLM 回應時，有明確的載入中提示。

    • 加分項：整體視覺設計有美感且風格一致。互動流程中是否有令人愉悅的小細節？（例如：有趣的載入動畫、漸進式顯示回應內容等）。

  2. 核心問題解決力 (15%)

    • 基本要求：App 是否真的解決了它聲稱要解決的核心問題？LLM 產出的結果品質是否穩定、符合預期？

    • 加分項：是否有針對失敗案例（LLM 回答不佳）的補救措施？例如讓使用者可以重新生成、或提供微調選項。

  3. 功能完成度 (10%)

    • 基本要求：所有宣稱的核心功能都能正常運作，沒有明顯的 Bug。

    • 加分項：除了核心功能，是否包含了一些輔助性的貼心設計？（例如：歷史紀錄、結果複製/匯出功能、簡易的個人化設定）。

C. 創新面 (20%) - App 是否有亮點？

  1. 應用場景或主題的創意 (5%)

    • 基本要求：應用場景定義明確，具有一定的實用價值。

    • 加分項：是否挖掘了一個尚未被大眾關注的獨特需求？或是用一種全新的方式來解決一個老問題？

  2. 充分利用長上下文能力 (5%)

    • 核心問題：你的 App 是否善用了長上下文來創造出短上下文模型不可能實現的功能？（例如：跨數百頁文件的問答）

  3. 智能化工作流程設計 (5%)

    • 核心問題：你的 App 是否不僅僅是一個工具，而是一個智能化的工作流程？它能否處理需要長期記憶、複雜推理或多步驟執行的創新應用？

  4. Prompt 設計巧思與 UX 差異化 (5%)

    • 基本要求：App 的 Prompt 不只是簡單地將使用者輸入的文字丟給 API。

    • 加分項：

      • 進階技巧：是否在 Prompt 中運用了進階技巧（如：角色扮演、Chain-of-Thought）來提升輸出品質？

      • 長上下文技巧：是否嘗試了更前瞻的 Prompt 設計，如在單一 Prompt 中包含多步驟推理指令、要求生成複雜的結構化輸出 (JSON)、或對同一份資料進行多角度分析？

      • UX 創新：使用者介面是否超越了單純的「一問一答」聊天框，設計了更結構化的互動方式來引導使用者、生成更精準的結果？

建議開發時程

  • Week 1-2：探索與定義

    • 腦力激盪，優先思考長上下文能帶來什麼破壞式創新，確定主題與目標使用者。

    • 定義核心功能與加分功能。

    • 規劃基本的使用者流程與介面草圖 (Wireframe)。

  • Week 3-4：核心開發

    • 建立開發環境，串接 LLM API（建議選擇支援長上下文的模型）。

    • 專注於實現最重要的核心功能，反覆測試與迭代你的長 Prompt 設計。

  • Week 5：優化與測試

    • 完善錯誤處理與邊界條件。

    • 優化 UI/UX 細節。

    • 找 3-5 位朋友或同學進行使用者測試，並根據回饋進行修改。

  • Week 6：準備發表

    • 完成 App 的最終打磨。

    • 準備專案簡報與 Demo 影片。

    • 撰寫專案文件，說明你的設計理念、技術架構與遇到的挑戰。

祝你好運，期待看到你們充滿創意的作品！

🚀 學習路徑總結

🎯 快速通道（4 週兼職學習）

Week 1-2: 基礎速成

  • Day 1-3: Prompt Engineering + 版本管理
  • Day 4-5: API 模式 + UX 基礎
  • Day 6-7: 簡單 RAG + Context 管理
  • 產出: 能對話的 Bot Demo

Week 3: 核心實戰

  • Day 1-2: 產品思維 + 成本優化
  • Day 3-4: Workflow 設計
  • Day 5-7: 可靠性基礎
  • 產出: 有 fallback 的穩定 Bot

Week 4: 專題衝刺

  • Day 1-5: 開發完整專題
  • Day 6-7: 部署與優化
  • 產出: 可部署的 MVP

🎓 完整通道（8 週深度學習）

按照完整 8 個模組循序漸進，每週一個模組，最後用 2 週完成專題。

💼 職涯發展建議

📈 技能成長路線圖

初級（0-6個月）
├── 掌握 Prompt Engineering
├── 熟悉主流 LLM API
└── 能開發簡單 Bot

中級（6-18個月）
├── 精通 RAG 和 Context 管理  
├── 設計複雜 Workflow
├── 優化成本和性能
└── 領導小型專案

高級（18個月+）
├── 架構大型 LLM 系統
├── 制定技術標準
├── 培訓團隊
└── 推動創新

專家（3年+）
├── 定義產品策略
├── 跨團隊協作
├── 開源貢獻
└── 行業影響力

🎯 立即行動計劃

今天就開始（Day 1）

# Step 1: 設定環境
pip install openai langchain pinecone-client

# Step 2: 第一個 Prompt Manager
class MyFirstPromptManager:
    def __init__(self):
        self.prompts = {
            "v1": "You are a helpful assistant.",
            "v2": "You are a helpful and empathetic assistant."
        }
        self.current = "v1"
    
    def get_prompt(self):
        return self.prompts[self.current]

# Step 3: 測試版本差異
manager = MyFirstPromptManager()
for version in ["v1", "v2"]:
    manager.current = version
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "system", "content": manager.get_prompt()},
            {"role": "user", "content": "I'm feeling stressed"}
        ]
    )
    print(f"{version}: {response.choices[0].message.content}")

本週目標（Week 1）

  • 完成模組 1-2 的學習
  • 實作 3 個不同的 Prompt 策略
  • 測試 3 種 UX 模式
  • 建立第一個帶驗證的 API 呼叫

本月目標（Month 1）

  • 完成模組 1-6
  • 開發一個完整的 FAQ Bot
  • 實現成本優化，降低 50% 開銷
  • 部署到測試環境

📚 學習資源推薦

📖 必讀資源

🎓 進階課程

🛠 開發工具架構對照

🎨 體驗與產品層工具

🚀 行業平台層工具

🔗 應用編排層工具

💾 數據層工具

🔍 可觀測性與監控

🏁 結語：成為市場需要的 LLM 應用工程師

還記得開頭提到的問題嗎？為什麼 90% 的 LLM 應用都只是「玩具」？

現在你有答案了：因為缺乏應用工程的系統化思維。

透過這 8 個模組的學習，你將掌握：

  • ✅ 如何管理 Prompt 資產，而不只是寫 Prompt
  • ✅ 如何設計降級策略，而不是祈禱 API 不會掛
  • ✅ 如何優化成本效益，而不是燒錢做 Demo
  • ✅ 如何打造用戶體驗，而不只是技術炫技

市場現狀：

  • 每家企業都想導入 AI，但缺乏落地能力
  • 大量職缺湧現，但合格人才稀缺
  • 薪資持續上漲，機會窗口正在開啟

你的機會：

  • 不需要 PhD，不需要懂模型原理
  • 只要 2-3 個月，就能掌握核心技能
  • 市場需求是系統工程師的 5-10 倍

🚀 最後的行動呼籲

不要再等了。 每天都有新的 LLM 應用上線，每天都有公司在找 LLM 應用工程師。

現在就開始：

  1. 今天：設定環境，寫第一個 Prompt Manager
  2. 本週：完成模組 1-2，做出 Demo
  3. 本月：開發第一個完整應用
  4. 三個月後：成為合格的 LLM 應用工程師

記住：在 AI 時代，應用層才是主戰場。

系統工程師建造引擎，但應用工程師開車上路。

問題是——你準備好上路了嗎？

最後更新：2025年8月
作者：Ian Chou
聯絡方式：[email protected]

🔗 相關文章推薦

🧩

Interactive Components

This post includes custom interactive components for enhanced experience

Thanks for reading!

Found this article helpful? Share it with others or explore more content.

More Articles
Published August 22, 2025•147 min read•17 tags