https://yennj12.js.org/yennj12_blog_V4/tags/ai-eng-from-scratch/Recent content in Ai-Eng-From-Scratch on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 06:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase1-part1-linear-algebra-zh/Sun, 21 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase1-part1-linear-algebra-zh/大多數工程師：「我會呼叫 model.fit()，數學交給論文作者就好。」 資深 AI 工程師：「我需要知道梯度為什麼爆炸、Loss 為什麼不收斂、為什麼換個 optimizer 差了 3 倍速度。」 前者能跑範例，後者能解問題。 數學不是門檻，是你除錯和優化的第一把鑰匙。 工程情境 你正在為一個推薦系統訓練 Embedding 模型。訓練第 5 個 epoch 後 loss 突然從 0.8 跳到 NaN，GPU 使用率正常、資料沒問題。請問你會從哪些數學角度切入診斷？你會如何用線性代數和微積分的知識判斷根本原因並修復？ 一、核心問題：為什麼 AI 工程師必須懂數學 很多人進入 AI 領域的第一印象是：「PyTorch / TensorFlow 已經幫你做好了，直接呼叫 API 就好。」這個觀點在 demo 階段是對的，但在 production 階段會讓你的除錯能力幾乎為零。 現實場景中會遇到的問題： Loss 收斂到一個局部最小值，但業務指標沒有改善 → 你需要理解 Loss landscape 的幾何形狀 Gradient Explosion：第 N epoch 後 loss 變成 NaN → 你需要理解梯度的數值行為 模型推論速度比預期慢 10 倍 → 你需要理解矩陣運算的複雜度與硬體加速原理 換了一個 optimizer 後訓練曲線震盪變大 → 你需要理解各 optimizer 的動量機制 加了 L2 regularization 後模型卻更 overfit → 你需要理解正則化的數學含義 這些問題沒有辦法靠 Stack Overflow 直接解決，因為症狀背後的原因需要數學直覺才能定位。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase1-part2-probability-stats-zh/Sun, 21 Jun 2026 09:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase1-part2-probability-stats-zh/大多數工程師把機率當成「加個 softmax 就好」的細節。 真正理解機率的工程師知道：每一個損失函數、每一個正則化項、每一個模型假設， 背後都是一個機率故事。 你選的分佈，決定了你的模型相信什麼樣的世界。 工程情境 技術主管問：「你的分類模型在驗證集上 accuracy 已經 92%，但產品上線後客訴率比預期高出三倍。請問你會怎麼診斷這個問題？從機率與統計的角度，你會看哪些指標、做哪些檢定？」 一、核心問題：為什麼機率是 AI 的第一語言 AI 系統本質上是在處理不確定性。輸入有雜訊、標籤有錯誤、世界在變化——確定性的規則系統在這種環境下必然失敗。機率論提供了一套嚴謹的語言，讓我們能夠： 量化無知：我們不知道答案，但我們知道各種可能答案的相對可能性 更新信念：看到新資料後，理性地調整對世界的看法 做出決策：在不確定條件下，選擇期望效用最大的行動 評估模型：不只說「對或錯」，而是說「有多大把握」 許多工程師剛接觸機率時覺得抽象，但一旦你開始問「這個設計決策背後假設了什麼分佈？」，你會發現機率思維無處不在： Cross-entropy 損失：假設模型輸出是伯努利（二分類）或類別（多分類）分佈的參數 L2 正則化：等價於對權重施加高斯先驗（MAP 估計） Dropout：對神經元激活引入伯努利雜訊，是一種 ensemble 的近似 Batch Normalization：假設每一層的激活值服從近似高斯分佈 Attention 機制：softmax 把分數轉為機率分佈，讓模型「選擇」關注哪裡 當你不理解這些假設，你就不知道模型在什麼情況下會失效，也不知道如何針對性地改進。 工程師常犯的三個機率錯誤 錯誤一：把 accuracy 當成唯一指標 accuracy 是 0/1 損失的期望值，它假設所有錯誤的代價相同。在醫療診斷（漏診癌症 vs 誤診）、詐欺偵測（放行詐欺 vs 誤封帳號）等場景，這個假設完全不成立。正確做法是看 precision/recall/F1，甚至直接最佳化 AUC-ROC。 錯誤二：忽略分佈偏移（Distribution Shift） 訓練集和測試集來自不同分佈時，任何在訓練集上學到的統計量都可能失效。這是開頭那個問題的核心：92% 的 accuracy 是在某個分佈下測的，但產品用戶的輸入分佈可能完全不同。 錯誤三：過度自信的點估計 大多數模型給出點預測（「這張圖片是貓」），但沒有說明不確定性。一個能說「我有 51% 的把握認為這是貓，你最好再確認一下」的模型，在高風險場景下遠比只說「是貓」的模型有價值。 二、三個演進階段：機率應用如何隨系統規模演進 Phase 1：POC / < 10K 用戶 核心目標：能跑起來，能得到合理的預測結果 ╔══════════════════════════════════════════════════════════════╗ ║ POC 階段：機率應用 ║ ╠══════════════════════════════════════════════════════════════╣ ║ ║ ║ 輸入資料 模型 輸出 ║ ║ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ ║ ║ │ Raw CSV │───▶│ Sklearn │──▶│ 點預測（0 或 1） │ ║ ║ │ 或圖片 │ │ / PyTorch│ │ 或 softmax 機率 │ ║ ║ └──────────┘ └──────────┘ └──────────────────────┘ ║ ║ ║ ║ 評估：accuracy / loss curve ║ ║ 假設分佈：「系統預設的，沒有特別想過」 ║ ║ ║ ║ 可接受的捷徑： ║ ║ • 直接用 cross-entropy，不問為什麼 ║ ║ • 資料不平衡時用 class_weight='balanced' ║ ║ • 不做 calibration ║ ╚══════════════════════════════════════════════════════════════╝ 花費：工程師時間 1–2 週，算力 < $50/月 遺留問題：模型機率輸出未校準、對分佈偏移無感知、評估指標不夠完整https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase2-part1-classical-ml-zh/Sun, 21 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase2-part1-classical-ml-zh/「任何問題都用深度學習解決」 「Transformer 萬能，傳統模型已經過時」 ——這是 80% 初學者的第一直覺。 正確的工程師問的是：資料量多少？延遲需求是幾 ms？可解釋性重要嗎？預算有多少？ 再選模型。 工程情境 你的電商平台每天有 50 萬筆訂單，需要即時預測「這筆訂單是否為詐騙」，要求推論延遲 < 5ms、需要提供法務可稽核的決策理由、訓練資料有 200 萬筆歷史記錄（其中詐騙率 0.3%）。你會選擇哪種模型？為什麼？ 一、核心問題：深度學習時代為什麼還要學傳統 ML ChatGPT 問世後，LLM 成為媒體焦點。許多工程師開始質疑：傳統機器學習是否已成歷史？ 答案是：不，在結構化資料的生產系統（風控、廣告、推薦排序）中，傳統 ML 仍是主力。 原因很直接： 1. 資料量的現實 大多數企業的結構化資料集在 10 萬至 500 萬筆之間。神經網路在這個規模下通常不比梯度提升樹更好，卻需要 10–100 倍的計算資源。 2. 延遲的硬需求 金融風控、廣告競價、即時推薦的推論預算通常是 1–10ms。線性模型推論 < 0.1ms，決策樹 < 1ms。小型 MLP 本身在 CPU 上也能 < 1ms，但網路一旦加深、加寬或需要 GPU 批次化，延遲與服務成本就會快速上升。 3. 可解釋性的法規壓力 歐盟 GDPR、台灣個資法、金融監理機關都要求「自動化決策必須能解釋」。邏輯回歸的係數、決策樹的規則路徑可以直接呈給法務；神經網路的注意力權重不能。 4. 維護成本的差距 一個訓練好的 XGBoost 模型可以用 pickle 序列化，部署到任何有 Python 的環境。不需要 GPU，不需要特殊推論框架，oncall 工程師看得懂特徵重要性。 5. 過擬合風險https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase2-part2-ensemble-optimization-zh/Sun, 21 Jun 2026 10:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase2-part2-ensemble-optimization-zh/大多數工程師遇到瓶頸時，會去換一個更複雜的模型。 真正的做法是：把多個「夠好的模型」組合起來。 單棵決策樹 Accuracy 70%，一千棵樹投票後達到 91%。 集成不是魔法，而是偏差–變異數分解的數學必然。 工程情境 技術主管： 你們公司的信用風險模型已上線，目前用單一 XGBoost，AUC 0.84。產品希望 AUC 提升到 0.88 以上，但訓練資料不能增加、特徵工程已飽和。請說明你會採取哪些策略，並解釋為什麼選擇這些方法而非其他替代方案？推論延遲需維持在 50ms 以內，每日預測量約 500 萬次。 一、核心問題：單一模型的天花板與集成的突破 1.1 偏差–變異數困境 機器學習的核心矛盾可以用一個公式描述： 期望錯誤 = Bias² + Variance + 不可減少的噪音 高偏差（High Bias）：模型太簡單，欠擬合。線性回歸在非線性問題上的典型症狀。 高變異數（High Variance）：模型太複雜，過擬合。深度決策樹在小資料集的典型症狀。 單一模型在這條光譜上只能找到一個平衡點。你無法同時大幅降低偏差和變異數——除非你使用集成方法。 1.2 為什麼集成能突破天花板 Bagging（自助聚合） 降低變異數： 對同一資料集做多次 bootstrap 取樣 每個子模型看到不同的資料子集，學到不同的模式 N 個獨立模型的平均值，變異數是單模型的 1/N（若模型間相關性為 0） Boosting（提升法） 降低偏差： 序列訓練，每個新模型專注修正前一個模型的錯誤 把 N 個「弱學習器（Weak Learner）」串聯，逼近任意複雜的函數 Stacking（堆疊） 同時降低偏差與變異數： 不同類型的模型抓到不同的資料模式 Meta-learner 學習如何最佳組合這些互補的預測 1.3 實際數字 方法 典型 AUC 提升幅度 訓練時間倍增 推論時間倍增 單一決策樹 → Random Forest +0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase3-part1-neural-networks-zh/Sun, 21 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase3-part1-neural-networks-zh/大多數人學深度學習：model.fit() 呼叫一行，調調 learning rate，祈禱 loss 下降。 正確的方式是：從矩陣乘法開始，手算梯度，理解每個超參數的幾何意義—— 因為當模型在生產環境爆炸時，你唯一能依靠的，是對第一原理的理解。 框架可以抽象實作，但它無法替你理解為什麼。 工程情境 你正在設計一個即時推薦系統，模型需要在 < 20ms 內回應，訓練資料有 5 億筆互動記錄，特徵空間包含 1 萬維稀疏向量。技術主管問：「你會如何設計神經網路架構？選擇什麼激活函數、正則化策略、和最佳化器？當模型在驗證集準確率停滯在 78% 時，你的診斷流程是什麼？」 一、核心問題：為什麼要從第一原理理解神經網路 絕大多數工程師進入深度學習的路徑是：安裝 PyTorch，複製一段 ResNet 範例程式，調整幾個參數，模型能跑了就交差。這種「黑盒操作」在 Kaggle 比賽或 Demo 原型中勉強夠用，但在生產環境中，它會讓你付出慘痛代價。 真實問題是這樣出現的： 模型訓練時 loss 突然爆炸（NaN），你不知道是梯度消失還是梯度爆炸，因為你從未手算過梯度 推論延遲從 8ms 升到 150ms，但你不理解 BatchNorm 在推論階段的行為與訓練階段不同 模型在訓練集 95% 準確率，測試集 61%，你不知道該加 Dropout 還是 L2，還是兩者都要 換了 AdamW 替代 SGD 後，收斂快了但泛化變差，你不知道 weight decay 的幾何意義是什麼 從第一原理理解神經網路，解決的不是「能不能跑起來」，而是「出問題時能不能診斷並修復」。 本文的工程目標： 理解神經網路的數學本質，能手算任意小型網路的前向與反向傳播 能在沒有框架的情況下，用純 NumPy 實作一個可訓練的兩層網路 掌握每個設計決策（激活函數、正則化、最佳化器）的量化 tradeoff 能給出有數字支撐的架構決策，而非「視情況而定」 二、三個演進階段（POC / MVP / Scale） 神經網路的部署不是一蹴而就，從研究原型到生產規模，架構在每個階段都有根本性的不同。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase4-part1-cnn-image-fundamentals-zh/Sun, 21 Jun 2026 11:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase4-part1-cnn-image-fundamentals-zh/大多數工程師拿到影像分類任務，第一反應是直接 Fine-tune ResNet50。 但真正該回答的是：你為什麼選 ResNet？池化層存在的意義是什麼？ 當訓練資料只有 5,000 張時，Fine-tune 和 Feature Extraction 哪個對？ 能回答這三個問題，才算真正理解電腦視覺的工程基礎。 工程情境 技術主管問： 「你的團隊要為一個醫療 App 建立皮膚病灶分類模型，訓練集只有 8,000 張標注影像、7 個類別，部署目標是手機端推論延遲 < 200ms。請說明你的架構選擇、遷移學習策略，以及你會怎麼處理類別不平衡問題。」 一、核心問題：影像理解的本質挑戰 影像資料與結構化資料有三個根本差異，讓全連接網路（Fully Connected）幾乎無法直接勝任： 1. 維度爆炸 一張 224×224 RGB 影像 = 150,528 個像素值。若用全連接層，第一層就需要 150,528 × hidden_units 個參數。一個 512 hidden units 的層，光第一層就是 77M 參數——這還沒考慮過擬合。 2. 空間不變性缺失 全連接層把像素當作獨立特徵看待，完全忽略空間關係。一隻貓在左上角和右下角，對 FC 層而言是完全不同的輸入。 3. 局部結構的重要性 影像中有意義的特徵（邊緣、紋理、形狀）都是局部的、階層式的。邊緣 → 紋理 → 部件 → 物件，這個從低階到高階的特徵階層，正是 CNN 設計的出發點。 CNN 用三個核心機制解決上述問題： 局部連接（Local Connectivity）：每個神經元只看一小塊感受野 參數共享（Weight Sharing）：同一個卷積核在整張影像上滑動 階層式特徵提取（Hierarchical Feature Learning）：堆疊卷積層逐步抽象 二、三個演進階段（POC / MVP / Scale） Phase 1 — POC（< 1 萬張訓練影像） ┌────────────────────────────────────────────────────┐ │ Pre-trained Backbone (凍結所有權重) │ │ ┌──────────────────────────────────────────────┐ │ │ │ ResNet50 / MobileNetV2 (ImageNet weights) │ │ │ └──────────────────┬─────────────────────────┘ │ │ │ Feature Vector (2048-d) │ │ ┌──────────────────▼─────────────────────────┐ │ │ │ Global Average Pooling │ │ │ └──────────────────┬─────────────────────────┘ │ │ │ │ │ ┌──────────────────▼─────────────────────────┐ │ │ │ Linear Classifier (新增，只訓練這層) │ │ │ │ Dense(256) → Dropout(0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase4-part2-detection-segmentation-zh/Sun, 21 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase4-part2-detection-segmentation-zh/大多數人以為「目標偵測」只是把框畫出來， 用最新的預訓練模型跑一跑就算完成。 真正的工程挑戰是：在 10ms 內偵測 20 個物件、 同時讓精度在邊緣設備上不低於雲端 80%。 工程情境 你負責一套工廠自動化視覺系統，需要在產線 conveyor belt 上即時偵測瑕疵零件（< 1cm² 小缺陷），相機 30fps，邊緣 GPU 只有 RTX 3060（12GB VRAM），允許誤報率 ≤ 2%，漏報率 ≤ 0.5%。請說明你會選擇什麼模型架構、訓練策略與部署優化方案。 一、核心問題：分類 vs 偵測 vs 分割的本質差異 影像理解有三個遞進的問題層次，每一層的工程複雜度都數量級地跳升： 分類（Classification）：圖裡有什麼？ 輸出：一個類別標籤 + 信心分數 代表模型：ResNet、EfficientNet 瓶頸：無法回答「在哪裡」「有幾個」 偵測（Detection）：圖裡有什麼、在哪裡？ 輸出：N 個邊界框（bounding box）+ 類別 + 信心分數 代表模型：YOLO 系列、Faster R-CNN 瓶頸：需處理多尺度、密集排列、遮擋問題 分割（Segmentation）：每個像素屬於哪個類別/哪個實例？ 語義分割：每像素給類別標籤，不區分實例（FCN、U-Net） 實例分割：每個物件實例有獨立 mask（Mask R-CNN） 全景分割：語義 + 實例的聯集（Panoptic FPN） 瓶頸：標注成本高（偵測框 30 秒/張 vs 多邊形分割 10 分鐘/張） 工程上選擇哪個任務，核心取捨在於： 任務 標注成本 推論延遲（A100） 典型應用 分類 低（1 秒/張） 2–5ms 內容稽核、產品分類 偵測 中（30 秒/張） 5–30ms 車牌辨識、人流計數 語義分割 高（5 分鐘/張） 15–80ms 自駕車道路解析 實例分割 極高（10 分鐘/張） 30–150ms 機器人抓取、醫療影像 二、三個演進階段（POC → MVP → Scale） ╔══ Phase 1：POC / < 1K 張/天 ══╗ ┌─────────────────────────────────────────────────┐ │ 原始影像 │ │ │ │ │ ▼ │ │ ┌──────────────────────┐ │ │ │ YOLOv8n pretrained │ COCO 預訓練 │ │ │ (Ultralytics CLI) │ 直接 fine-tune │ │ └──────────┬───────────┘ │ │ │ │ │ ▼ │ │ JSON/CSV 結果輸出 → 人工審查 │ └─────────────────────────────────────────────────┘ 工具：Ultralytics yolo train CLI，Roboflow 標注 成本：單張 T4 GPU $0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase4-part3-vlm-3d-worldmodels-zh/Sun, 21 Jun 2026 12:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase4-part3-vlm-3d-worldmodels-zh/「大多數人用 2D 圖片分類解決視覺問題； 高手用視覺語言模型跨模態推理； 但真正的世界理解需要 3D 空間感知與時序動態模型。 從像素到世界模型，是從感知到智慧的本質躍升。」 工程情境： 你正在設計一個自動駕駛感知系統，需要整合街景攝影機（2D RGB）、LiDAR 點雲（3D）、以及自然語言指令（「前方有行人，請減速」）。技術主管問：你會如何架構視覺語言理解管線？在 10K 場景/天的訓練規模下，NeRF 重建和 3D Gaussian Splatting 各有什麼取捨？當系統需要預測「接下來 3 秒會發生什麼」時，你會引入什麼樣的世界模型？ 一、核心問題：從 2D 感知到 3D 世界理解的躍升 傳統電腦視覺的範式是：輸入圖片 → 抽特徵 → 輸出分類/框。這個方法在 ImageNet 時代表現出色，但遇到真實世界的複雜任務時，三個根本限制浮現： 限制一：模態孤島問題 視覺模型只能輸出類別 ID，語言模型只能處理文字。當使用者問「這張照片裡有幾個人戴了眼鏡？」，純視覺模型無法作答，純語言模型看不見圖片。視覺語言模型（VLM）的出現就是為了打破這道牆。 限制二：2D 投影丟失深度資訊 相機成像是 3D 世界投影到 2D 平面的過程，這個過程不可逆——除非你有多視角或深度先驗。自駕車需要知道「前方障礙物距離 4.2 公尺」而不只是「畫面中央有個人」。NeRF 和 3D Gaussian Splatting 嘗試從 2D 影像重建 3D 場景。 限制三：靜態感知缺乏因果推理 世界是動態的。「當前場景是什麼」和「接下來會發生什麼」是完全不同的問題。預測未來需要世界模型（World Model）——一個能模擬物理因果關係的系統。Sora 等影片生成模型被認為是早期世界模型的體現。 本文沿著這三個維度展開：VLM 打通語言與視覺、3D 重建恢復空間幾何、世界模型引入時序因果。 二、三個演進階段（POC / MVP / Scale） Phase 1：POC（< 1K 查詢/日） 目標： 最快驗證 VLM 可行性，不自訓練，全用 APIhttps://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part1-text-fundamentals-zh/Sun, 21 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part1-text-fundamentals-zh/大多數人處理文字時，直接把原始字串丟進模型，期待魔法發生。 正確做法是：先理解文字的統計結構，再選擇適合問題規模的表示法。 詞袋夠用的場景別用嵌入；嵌入必要的場景別省那筆運算。 表示法的選擇，決定了整個 NLP 系統 70% 的天花板。 工程情境 你被指派設計一個電商評論分析系統：每天新增 50 萬則中文評論，需支援情感分類（正/負/中性）、主題抽取（5 大類）、以及即時關鍵詞搜尋。系統目前是 POC 階段，但六個月後要上線服務百萬用戶。請說明你的 NLP 文字表示策略，以及各階段如何演進。 一、核心問題：文字為什麼難處理？ 文字是人類智慧的介面，卻是機器最難消化的資料形式。數字有大小關係，圖片有空間結構，文字呢？「蘋果」和「apple」語義相同，但在字元層面毫無關聯；「我愛你」和「你愛我」詞彙完全相同，語義卻截然不同。 三個根本挑戰： 稀疏性問題：一個詞彙表有 10 萬個詞，one-hot 向量就是 100,000 維的稀疏向量，99.999% 的維度是 0。相似度計算毫無意義。 語序問題：詞袋模型把「貓追狗」和「狗追貓」視為完全相同的文件。語序攜帶了大量語義資訊。 語境問題：「蘋果很好吃」和「蘋果發布新品」中，「蘋果」的語義完全不同。靜態嵌入無法處理這種多義性。 工程師的決策框架： 問題規模 × 語義複雜度 → 選擇表示法 ───────────────────────────────────────────────── 規模小 + 語義簡單 → TF-IDF + 邏輯回歸 (< 1ms, 低成本) 規模中 + 語義中等 → Word2Vec/FastText + SVM (< 5ms, 中成本) 規模大 + 語義複雜 → Transformer Embedding (10-50ms, 高成本) ───────────────────────────────────────────────── 這篇文章的目標：讓你能清楚說明為什麼在特定場景選擇特定表示法，而不只是背誦演算法。 二、三個演進階段 ╔══ Phase 1：POC（< 10K 用戶，< 5 萬則評論）══╗ 目標：2 週內驗證可行性，準確率 > 75% 即可。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part2-seq2seq-attention-zh/Sun, 21 Jun 2026 13:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part2-seq2seq-attention-zh/大多數人把 RNN 當作「處理序列的工具」，把 LSTM 當作「改良版 RNN」，就停在這裡了。 真正的工程師會問：為什麼固定長度的 context vector 是瓶頸？注意力機制解決了什麼具體問題？ Transformer 不是憑空出現的魔法，它是對 RNN 家族每一個痛點的系統性回應。 理解這段歷史，你才能真正讀懂「Attention is All You Need」。 工程情境：「你正在設計一個英中機器翻譯系統，句子長度最長 200 個 token。請說明你會選擇哪種架構，為什麼不直接用純 RNN，LSTM 與 GRU 在這個場景下如何選擇，以及如果引入注意力機制，架構上需要做哪些改變？」 註：這是 2014–2017 年的歷史情境。2026 年從零建構英中翻譯，預設答案是 Transformer——更常見的是微調預訓練模型或直接使用 LLM。本篇借這個情境說明注意力機制為什麼會被發明。 一、核心問題：序列資料的特殊挑戰 一般的前饋神經網路（Feedforward NN）假設輸入之間互相獨立，但語言、時間序列、語音等資料天生帶有順序依賴： 「我昨天沒有吃飯」與「我昨天沒有喝飯」—— 語義完全不同，差異在第五個字 翻譯「The animal didn’t cross the street because it was too tired」—— “it” 指的是 animal 還是 street？需要回顧前文 股票預測：今天的價格取決於過去 N 天的走勢 序列建模的三大工程挑戰： 挑戰 具體現象 工程代價 可變長度輸入 句子從 5 到 500 token 不等 固定大小向量無法直接處理 長程依賴 200 token 前的主語影響動詞 梯度消失導致無法學習 順序計算瓶頸 t 步必須等 t-1 步完成 無法並行，GPU 利用率低 這三個問題，RNN → LSTM/GRU → Seq2Seq+Attention → Transformer，每一步都是針對前一步遺留問題的工程解法。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part3-advanced-nlp-zh/Sun, 21 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase5-part3-advanced-nlp-zh/大多數人以為 NLP 就是把文字丟進模型等答案； 真正的工程師知道語言理解需要雙向上下文、任務特化微調、以及在延遲與準確率間反覆取捨。 問題不是「用哪個模型」，而是「這個系統在 P99 500ms 內能可靠回答什麼問題」。 從 BERT 到問答系統，進階 NLP 的核心是：為正確的任務選擇正確的架構。 工程情境： 你的團隊正在為一個法律文件平台建構問答系統。文件平均 50 頁，用戶問題如「這份合約的違約金條款是什麼？」。系統需在 2 秒內回答，準確率要求 > 90%，每月處理 50 萬筆查詢。請設計整體架構，並說明為何選擇 Extractive QA 而非 Generative QA，以及如何在規模下維持品質。 一、核心問題：語言理解 vs 語言生成的本質差異 NLP 工程中最常見的誤解是把「理解」和「生成」混為一談。這兩個任務在模型架構、訓練目標、推論策略上有根本差異。 語言理解（Understanding）的本質： 任務：分類、命名實體識別、關係抽取、問答中的答案定位 需要：雙向上下文（左邊和右邊的詞都重要） 代表架構：BERT（Encoder-only Transformer） 輸出：分類標籤、span 位置、相似度分數 語言生成（Generation）的本質： 任務：文字摘要、機器翻譯、對話回覆、程式碼生成 需要：自回歸解碼（autoregressive decoding） 代表架構：GPT 系列（Decoder-only）、T5（Encoder-Decoder） 輸出：Token 序列 為什麼這個差異在工程上很重要？ 面向 理解任務 生成任務 推論延遲 10–50ms（一次 forward pass） 200ms–5s（逐 token 生成） 輸出確定性 高（span 位置或分類） 低（temperature 影響大） 可審計性 高（可追蹤到原文哪句話） 低（hallucination 風險） GPU 記憶體 BERT-base: 440MB GPT-3.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part1-asr-zh/Sun, 21 Jun 2026 14:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part1-asr-zh/大多數人以為語音辨識就是「把錄音丟給 API 拿文字」。 但真正的工程挑戰是：如何在 300ms 內完成辨識、處理口音與噪音、控制串流延遲？ 不懂聲學特徵與解碼策略，你只是在呼叫別人的黑盒子。 理解 ASR 架構，才能在延遲、準確率、成本之間做出有根據的取捨。 工程情境 你正在設計一個線上教育平台的即時字幕系統，需要支援 10,000 位同時在線的學生。系統要求：辨識延遲 < 500ms、WER < 10%、支援中英文混合語音。請說明你的 ASR 架構選擇，以及如何在 POC 到 Scale 的過程中演進這個系統。 一、核心問題：語音辨識的工程挑戰 語音辨識（Automatic Speech Recognition，ASR）聽起來簡單：輸入聲音、輸出文字。但工程上的挑戰遠比想像中複雜。 三大核心張力 準確率 vs 延遲：離線 batch 辨識可以拿到最好的準確率（Whisper large-v3 在 LibriSpeech test-clean 上 WER 約 2.7%），但需要等音訊結束後才能處理。串流辨識要求 < 300ms 的 partial result，但準確率可能下降 15–30%。 通用性 vs 領域適應：預訓練模型在 clean speech 上表現優秀，但在特定領域（醫療術語、程式碼朗讀、帶口音的中文）WER 可能飆升至 30%+。Fine-tune 需要標注資料，成本每小時約 $50–200。 成本 vs 自建：呼叫雲端 ASR API 每分鐘約 $0.006–0.024，自建 Whisper 在 GPU 上每分鐘約 $0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part2-tts-audio-models-zh/Sun, 21 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part2-tts-audio-models-zh/大多數工程師把 TTS 當成「呼叫 API、播放音訊」的黑箱。 真正的 AI 工程師理解聲學模型與聲碼器的分工、延遲來源、以及為何同一句話用不同架構品質差距達 0.8 MOS。 他們能設計零樣本語音克隆系統、控制情感韻律、並在 200ms 內完成整條推論鏈。 本文帶你從模型架構到線上服務，逐層拆解語音合成工程的每一個決策點。 工程情境 你的公司要推出有聲書朗讀功能，支援繁體中文與英文雙語、使用者可上傳 30 秒聲音樣本克隆自己的聲音、整體端對端延遲需低於 300ms。請說明你會如何設計這套 TTS 系統，包含模型選型、聲碼器、語音克隆架構、以及上線後如何持續改善音質。 一、核心問題：語音合成的工程挑戰 語音合成表面上是「文字轉音訊」，但工程挑戰遠比想像中複雜： 三大矛盾張力 維度 極端 A 極端 B 工程取捨 自然度 vs 延遲 Tortoise-TTS（MOS 約 4.2）推論 30s FastSpeech2 < 50ms 互動場景選速度，有聲書選品質 個人化 vs 資料量 傳統 clone 需 1 小時錄音 XTTS v2 只需 6 秒樣本 零樣本 clone 改變商業模式 表達力 vs 穩定度 情感模型偶爾產生雜音 平坦語調安全但無趣 情感強度需可調參數 延遲分解（300ms 預算） 文字前處理（正規化/分詞）： ~10ms G2P（字素轉音素）： ~15ms 聲學模型（Mel 頻譜生成）： ~80ms ← 最大瓶頸 聲碼器（Mel → 波形）： ~60ms 音訊編碼/傳輸： ~30ms 緩衝播放首包： ~20ms ───────────────────────────────── 總計： ~215ms ✓ 低於 300ms 核心工程問題清單https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part1-transformer-architecture-zh/Sun, 21 Jun 2026 15:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part1-transformer-architecture-zh/大多數人覺得 Transformer 就是「注意力機制加上前饋網路」，說完就結束了。 真正的工程師知道：矩陣分塊如何影響 GPU 記憶體帶寬，KV Cache 如何讓每個 decode 步驟不必重算整段前文（首 token 延遲則由 prefill 決定）， 為什麼 GQA 能在保持 95% 品質的前提下省掉 75% 的快取記憶體。 架構不是魔法——它是一系列在硬體限制下做出的工程取捨。 工程情境：「你負責將一個 7B 參數的 LLM 部署到生產環境，P99 首 token 延遲必須 < 500ms，批次吞吐量 > 200 req/s，GPU 記憶體預算 40GB。請說明你會在 Transformer 架構層面做哪些優化決策，以及你如何取捨精度與速度。」 一、核心問題：為什麼 Transformer 取代了一切 1.1 RNN/LSTM 的根本瓶頸 在 Transformer 出現之前，序列模型靠 RNN 與 LSTM。它們有一個無法繞開的硬傷：序列依賴（sequential dependency）。 時間步 t=1 → t=2 → t=3 → ... → t=n 每步必須等上一步完成，無法並行 後果： 訓練速度隨序列長度線性增長 梯度消失導致長距依賴難以學習 GPU 大量計算資源閒置（利用率 < 30%） 1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part2-training-variants-zh/Sun, 21 Jun 2026 16:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase7-part2-training-variants-zh/大多數人認為：Transformer 就是 attention + FFN，照抄論文程式碼就能訓練起來。 真實情況是：沒有 LR warmup 模型在第 100 步就 loss 爆炸；沒有梯度裁剪 NaN 讓你懷疑人生。 進階工程師知道：訓練策略與架構選型決定了 90% 的成敗，程式碼只佔 10%。 本文要解決的是：為什麼這些技巧存在、何時用哪個、以及三個演進階段的工程落地路徑。 工程情境 技術主管問：「你要為一個電商平台設計一套 NLP 系統，需要同時支援商品描述生成（生成任務）、評論情感分析（分類任務）、以及跨語言商品搜尋（語義匹配）。你會選擇哪種 Transformer 架構？訓練時的學習率策略和精度選擇是什麼？如果預算只有 $50K，怎麼做？」 一、核心問題：Transformer 訓練為什麼這麼難 Transformer 訓練困難的根源不在於架構複雜，而在於多個不穩定因素的耦合： 問題 1：參數初始化 vs 梯度流 Transformer 在初始化時，attention 層的 softmax 容易輸出接近均勻分佈（對梯度無貢獻）或接近 one-hot（梯度消失）。用過大的學習率，前幾步梯度就會爆炸；用過小的學習率，前幾千步幾乎不學習。 問題 2：不同層的梯度尺度差異 淺層（embedding 附近）和深層（最後幾個 block）的梯度尺度可以相差 100 倍以上。固定學習率對一部分層太大、對另一部分太小。 問題 3：浮點精度的精度懸崖 FP16 的最大值約 65504，一旦梯度超過就 overflow 變 NaN，整批訓練廢掉。BF16 範圍更大但精度更低，小 loss 差異可能被截斷。 問題 4：任務與架構的阻抗失配 用 Decoder-only 做分類：浪費計算，需要特殊 pooling；用 Encoder-only 做生成：無法自回歸，強行做需要 mask 技巧。錯誤的架構選型讓精度天花板提前到來。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase8-part1-diffusion-models-zh/Sun, 21 Jun 2026 16:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase8-part1-diffusion-models-zh/大多數人認為擴散模型「就是反覆去雜訊」。 真正的關鍵是：你能說明前向過程的閉合解、DDIM 的隱式馬可夫假設、以及為什麼潛在空間能讓 1024×1024 生成在消費級 GPU 上跑起來。 差距不在知道有 Stable Diffusion，而在能精確量化每個設計決策的成本與效益。 本文帶你從數學推導到生產部署，一次打通。 工程情境：你負責為一個電商平台設計商品圖片自動生成系統，需要在 3 秒內生成 512×512 的商品展示圖，每日峰值 10 萬張，成本預算每張 $0.002。請描述你選擇的模型架構、推論優化策略，以及如何處理風格一致性問題。 一、核心問題：生成模型的本質——學習資料分佈 生成模型的核心目標是學習一個隱含的資料分佈 $p_{data}(x)$，然後從中採樣出新的樣本。這個問題有三條路： GAN（對抗生成）：訓練一個生成器欺騙判別器。快、生成品質高，但訓練不穩定（模式崩潰），很難控制生成內容。 VAE（變分自編碼器）：學習潛在空間分佈，生成多樣但往往模糊，因為優化的是像素級 L2 loss。 擴散模型（Diffusion Model）：將資料生成過程建模為逐步去雜訊的馬可夫鏈。訓練穩定、生成品質極高、天然支援條件控制——但推論慢。 關鍵張力：生成品質 vs. 推論速度 vs. 條件可控性。三者難以同時最優。擴散模型在品質和可控性上勝出，工程挑戰集中在速度。 二、三個演進階段（POC → MVP → Scale） ╔══ Phase 1：POC（< 1K 日生成量）══╗ 目標：驗證生成品質，選型，跑通 pipeline。 ┌─────────────────────────────────────────────────────┐ │ Phase 1 架構 │ │ │ │ 使用者 Prompt ──▶ HuggingFace Diffusers API │ │ │ │ │ ▼ │ │ Stable Diffusion v1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase8-part2-gan-video-generation-zh/Sun, 21 Jun 2026 17:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase8-part2-gan-video-generation-zh/大多數人以為 GAN 是「讓兩個神經網路互相競爭」。 正確答案是：GAN 是一個精心設計的賽局均衡問題—— 訓練的藝術在於讓 Generator 和 Discriminator 以恰好正確的速度成長， 任何一方跑太快，整個系統就會崩潰。 工程情境： 你的團隊需要為電商平台建立「商品圖片風格轉換」系統，目標是把用戶上傳的素人照自動轉成專業棚拍風格，日處理量 50 萬張，延遲要求 < 200ms。請問你會選 GAN 還是擴散模型？架構如何設計？ 一、核心問題：對抗訓練的本質與脆弱性 GAN（Generative Adversarial Network）由 Ian Goodfellow 於 2014 年提出，核心概念極為優雅：一個 Generator（偽造者）和一個 Discriminator（鑑別者）相互對抗，在賽局均衡中收斂到完美生成能力。 理論之美與工程之痛的落差： 理論上，當 Generator 生成的分佈完全匹配真實資料分佈時，Discriminator 的最優策略是輸出 0.5（無法分辨）。這個均衡點在數學上可以被證明存在，且對應的 Generator 是完美的。 然而工程現實截然不同： 模式崩潰（Mode Collapse）：Generator 學會只生成幾種「能騙過 Discriminator」的樣本，多樣性消失。FID（Fréchet Inception Distance）飆升至 100+ 而訓練 loss 看起來正常。 梯度消失（Vanishing Gradient）：Discriminator 太強時，Generator 收到的梯度趨近於零，學習停滯。 訓練震盪：兩者的 loss 呈鋸齒狀，沒有明確的收斂信號。 超參數敏感性：學習率差距 10x 即可讓整個訓練崩潰。 這些不是 GAN 的「缺陷」，而是對抗訓練本質的體現——兩個玩家的賽局均衡遠比單一損失函數的最佳化複雜。 GAN 仍值得學習的理由： 推論速度：單次前向傳播，A100 上 512×512 圖片 < 15ms，Diffusion 需要 50–200 步去噪，約 1–5s 潛在空間可插值：StyleGAN 的風格空間允許精確控制人臉年齡、表情、髮型 訓練資料效率：CycleGAN 無需配對資料，只需兩個域的圖片集合即可訓練 特定任務 SoTA：pix2pix 在語義分割→照片轉換任務上 FID 仍優於早期 Diffusion 二、三個演進階段（含 ASCII 架構圖） ╔══ Phase 1：POC / < 10K 樣本 ══╗ 目標：驗證 GAN 能否學到目標分佈的基本形狀。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase9-part1-rl-fundamentals-zh/Sun, 21 Jun 2026 17:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase9-part1-rl-fundamentals-zh/大多數人以為強化學習只是遊戲 AI 的黑魔法； 實際上，RLHF 是讓 LLM 從「會說話」進化到「說對話」的核心技術。 大多數人以為 PPO 太複雜所以跳過； 實際上，理解 clip ratio ε=0.2 背後的直覺，才能真正設計對齊系統。 工程情境： 你是某家 AI 新創的首席工程師。產品已用 SFT 微調出一個能回答問題的 LLM，但用戶反映模型有時給出危險建議、有時過度冗長、有時迴避有用資訊。CTO 要求你在六週內讓模型「更符合人類期望」。你會設計怎樣的對齊訓練流程？請從框架選擇、資料收集、訓練穩定性、評估指標四個維度說明。 一、核心問題：為什麼 LLM 需要強化學習 1.1 Supervised Fine-Tuning 的天花板 SFT（Supervised Fine-Tuning）本質是「模仿學習」——模型學習複製人類示範的文字。這個方法有三個根本限制： 限制一：示範資料的稀缺性 高品質的完整對話示範成本極高（每條 $5–50 美元標注成本） 1M 條示範資料 ≈ $5M–50M，難以覆蓋所有場景 限制二：偏好無法直接最大化 人類知道「哪個回答更好」，但無法輕易寫出「最好的回答」 SFT 學的是「做什麼」，而非「為什麼這樣做最好」 限制三：分佈外泛化失敗 SFT 模型在訓練分佈外的 prompt 上容易退化 模型無法自主探索比示範更優的解答 強化學習解決的核心問題是：讓模型在與環境（或人類偏好模型）互動的過程中，學習最大化長期獎勵。 1.2 RL 在 AI 對齊中的角色 傳統訓練流程（純 SFT）： 人類寫示範 ──▶ MLE 損失 ──▶ 模型複製行為 問題：模型學的是「平均人類行為」，非「最優人類行為」 RLHF 訓練流程： 人類比較偏好 ──▶ 獎勵模型 ──▶ PPO 最大化獎勵 優勢：模型學的是「人類偏好的方向」，能超越示範品質 InstructGPT（ChatGPT 前身）論文的核心數字：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase10-part1-tokenization-zh/Sun, 21 Jun 2026 18:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase10-part1-tokenization-zh/大多數人以為 Tokenization 只是「把文字切成小段」，隨便選一個 tokenizer 接上模型就好。 現實是：詞彙表大小決定了模型容量與訓練成本，token 邊界影響了推理能力， 多語言效率直接決定非英語使用者的 API 費用與延遲， 一個錯誤的 tokenization 決策，可以讓整個預訓練白費。 工程情境 你的團隊正在從零預訓練一個 30B 參數的多語言 LLM，目標語言包含英文、繁體中文、日文與 Python/SQL 代碼。 技術主管問：「你會如何設計這個模型的 tokenizer？詞彙表要多大？選哪種演算法？中文效率問題怎麼處理？」 一、核心問題：Tokenization 為什麼是 LLM 的第一道關卡 Tokenization 是 LLM pipeline 的第一步，也是最容易被低估的一步。它做的事情看似簡單：把原始文字轉換成整數序列（token IDs），讓模型能夠處理。但這個轉換過程中埋藏了大量工程決策，每一個都有深遠影響。 為什麼 Tokenization 很重要？ 模型容量分配：詞彙表大小直接決定 Embedding 層的參數量。vocab_size=50K、embedding_dim=4096 時，Embedding 層就佔了 50K × 4096 × 2 bytes ≈ 400MB，相當於整個模型參數的 5–10%。 序列長度放大器：同樣一段中文，GPT-4 的 tokenizer（cl100k_base；GPT-4o 之後的 OpenAI 模型改用約 200K 詞彙的 o200k_base）平均每個漢字消耗約 1.5 tokens，而設計不良的 tokenizer 可能消耗 3–4 tokens（逐字節切割）。context window 128K tokens，有效利用率差了 2–3 倍。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase10-part2-pretraining-zh/Sun, 21 Jun 2026 18:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase10-part2-pretraining-zh/大多數人以為預訓練只是「把資料丟進去跑就好」。 現實是：70% 的工時花在資料清洗，20% 花在除錯 Loss Spike， 只有 10% 是真正的訓練時間。 預訓練是 LLM 工程中最貴、最脆弱、也最決定性的一步。 工程情境： 假設你是某 AI 新創的基礎架構工程師，團隊計畫訓練一個 7B 參數的 LLM，預算 $500K，目標是在 3 個月內完成預訓練。請說明你會如何規劃資料管線、選擇分散式訓練策略，以及如何監控並從 Loss Spike 中恢復？ 一、核心問題：預訓練為什麼是 LLM 最貴的一步 預訓練（Pretraining）是 LLM 生命週期中的「原始碼編譯」——一旦做錯，後續的 Fine-tuning、RLHF、RAG 全都是在一個有缺陷的基礎上打補丁。 成本規模感： 模型 參數量 訓練 Token GPU 小時 估計成本 GPT-3 175B 300B ~3.5M A100 小時 ~$4.6M LLaMA-2 7B 7B 2T ~180K A100 小時 ~$240K LLaMA-2 70B 70B 2T ~1.7M A100 小時 ~$2.3M Mistral 7B 7B 未公開 未公開 未公開 一次「失敗的」預訓練跑到 80% 才發現資料有問題，等於直接燒掉 $100K–$3.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase10-part3-finetuning-zh/Sun, 21 Jun 2026 19:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase10-part3-finetuning-zh/大多數人認為微調就是「把 LLM 在自己的資料上再跑幾個 epoch」。 真正的答案是：選錯策略會讓 70B 模型比 7B 更差，燒掉 $50,000 的 GPU 時間還讓對齊崩潰。 差距在於你是否理解 LoRA 降低了哪 99.85% 的參數、QLoRA 如何在 48GB 記憶體訓練 65B，以及為什麼 1,000 條高品質資料勝過 100 萬條雜訊。 這篇文章帶你從數學原理到生產工程，建立完整的微調決策框架。 工程情境： 你負責一個醫療文件摘要產品，基礎模型在通用任務表現良好，但在臨床術語和 SOAP 格式輸出上錯誤率高達 34%。你的 GPU 預算是 2 台 A100 80GB，資料團隊提供了 8,000 條標注好的醫生對話。你會選擇 Full Fine-tuning、LoRA 還是 QLoRA？如何評估微調後的對齊品質？ 一、核心問題：預訓練模型為什麼需要微調 1.1 預訓練的本質局限 預訓練（Pre-training）讓 LLM 學到了語言的統計規律與世界知識，但它優化的目標是下一個 token 預測（next-token prediction），而非「照我說的做」。這個差距在三種場景下最為明顯： 格式遵從性：預訓練模型傾向續寫，而非回答。給它 「請列出三個優點：」，它可能輸出 「...這個問題的三個優點分別是...」 然後繼續產生隨機文本，而不是乾淨的清單。 領域術語精度：通用語料中醫療、法律、金融術語出現比例不到 2%，導致模型在這些領域的 token 機率分布偏移。Llama-3 8B 在 MedQA 上未微調的準確率約 58%，微調後可達 78–82%。 安全與對齊邊界：預訓練模型缺乏拒絕有害請求的能力，需要 RLHF 或 DPO 等對齊微調來建立邊界。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part1-inference-serving-zh/Sun, 21 Jun 2026 19:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part1-inference-serving-zh/大多數人把 LLM 推論想成「載入模型，呼叫 generate()，等結果」。 實際上，每個 token 都在搶 GPU HBM 頻寬，記憶體碎片化讓吞吐量砍半， 一個設計不良的 batch 策略讓 A100 的使用率停在 12%。 真正的推論工程是記憶體管理、排程策略、精度取捨三件事同時做對。 工程情境：「你的團隊剛把一個 70B 參數的對話模型從研究環境搬到生產，目前 p99 延遲 18 秒、GPU 使用率 15%、每千 token 成本 $0.04。CTO 要求三個月內把成本降到 $0.008、p99 降到 4 秒。你的架構計畫是什麼？」 一、核心問題：LLM 推論為什麼貴又慢 LLM 推論和傳統深度學習推論有本質上的差異。ResNet 做影像分類，輸入固定大小，一次 forward pass，批次容易排。LLM 是自回歸生成（autoregressive generation）：每個 token 依賴前面所有 token，必須一步一步產生。 三個根本瓶頸： 瓶頸一：記憶體頻寬牆（Memory Bandwidth Wall） 70B 模型 FP16 佔 140 GB。A100-80GB 只能塞下半個模型，必須 tensor parallel。每生成一個 token，模型的所有 140 GB 權重都要從 HBM 讀一次。A100 HBM 頻寬 2 TB/s，讀 140 GB 需要 70 ms——這就是單 token 延遲的硬下限，和計算無關。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part2-rag-evals-zh/Sun, 21 Jun 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part2-rag-evals-zh/大多數工程師遇到 LLM 幻覺，第一反應是把 Prompt 寫得更長、更詳細。 正確答案是：建立 RAG 管線讓模型說「我不知道」，而非瞎猜。 大多數團隊上線後才發現回答品質不穩，因為沒有評估管線。 正確答案是：在 CI/CD 中門控 Faithfulness ≥ 0.80，讓壞版本無法部署。 工程情境 你們公司的法律文件問答系統上線三個月，客服每週回報大約 15% 的回答「聽起來合理但內容有誤」。CTO 要你在四週內把幻覺率降到 5% 以下，且 P95 延遲不能超過 2 秒。請說明你會怎麼診斷現況、選擇改進方向，以及如何證明改善確實發生了。 一、核心問題：LLM 幻覺與知識截止日期的工程解法 LLM 有兩個先天限制，工程師必須正視： 幻覺（Hallucination） — 模型會以高信心度生成看起來合理但事實上錯誤的內容。根源在於訓練目標是「預測下一個 Token」，而非「陳述事實」。當問題超出訓練分布，模型不會說「我不確定」，而是繼續生成流暢但錯誤的文字。 知識截止日期（Knowledge Cutoff） — 模型訓練資料有時間邊界。2024 年底截止的模型不知道 2025 年的法規修訂、產品更新、或內部文件。無論 Prompt 寫得多好，模型都無法回答它從未見過的資訊。 RAG（Retrieval-Augmented Generation） 是主流工程解法：把外部知識庫的相關片段即時檢索出來，附加在 Prompt 中，讓模型「有所依據地回答」而非憑空捏造。 但 RAG 帶來新問題：檢索品質如何保證？回答是否忠實於檢索內容？這需要評估管線來量化和監控。 二、三個演進階段（POC / MVP / Scale） ╔══ Phase 1：POC / < 1K 文件 ══╗ 目標：兩週內驗證 RAG 在這個領域是否可行。 ┌─────────────────────────────────────────────────────┐ │ Phase 1 RAG 架構（POC） │ │ │ │ PDF / Markdown ──▶ 固定 512 Token Chunking │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Chroma / SQLite │ (本機) │ │ │ Dense Vector │ │ │ └────────┬─────────┘ │ │ │ Top-K ANN │ │ ▼ │ │ ┌──────────────────┐ │ │ │ LLM（API） │ │ │ │ GPT-4o / Claude │ │ │ └──────────────────┘ │ └─────────────────────────────────────────────────────┘ 項目 數值 文件量 < 1K docs 向量 DB Chroma（本機，免費） Embedding text-embedding-3-small（$0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase12-part1-vit-fusion-zh/Sun, 21 Jun 2026 20:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase12-part1-vit-fusion-zh/大多數工程師認為：「把 CNN 的特徵向量和 BERT 的文字向量拼在一起就是多模態了。」 正確的架構師思維是：「視覺與語言的對齊是訓練目標問題，不是拼接問題； 選 Early/Late/Cross-Modal Fusion 取決於任務延遲容忍度與標注成本， 而 CLIP 的零樣本能力來自 4 億圖文對的對比訓練，不是模型架構的魔法。」 工程情境 你正在為一家電商平台設計「以圖搜商品」加「文字描述精化」的多模態搜尋系統。目前日均查詢量 800 萬次，P99 延遲要求 < 200 ms，標注預算有限。技術主管問：「你會選 CLIP zero-shot、fine-tuned ViT+BERT Late Fusion、還是 Cross-Modal Attention？各自的 tradeoff 是什麼？當查詢量成長到 5000 萬時，架構需要哪些改變？」 一、核心問題：視覺與語言如何在一個統一模型中對齊 人類理解世界時，視覺與語言天然交織：看到一張「紅色跑車」的圖片，腦中立刻關聯「Ferrari」「速度」「豪華」等語意概念。然而傳統深度學習把圖片分給 CNN、把文字分給 RNN/Transformer，兩條流水線各自訓練，只在最後 MLP 層做粗粒度合併。 這帶來三個核心工程痛點： 語意對齊缺失（Semantic Gap）：CNN 輸出的 2048 維特徵空間與 BERT 的 768 維文字空間沒有共同原點，直接拼接會導致模態間干擾。 弱監督瓶頸：傳統多模態需要人工對齊的圖文標注（Image Captioning 資料集），規模上限約 300 萬對；CLIP 透過網路爬取 4 億弱標注對突破此瓶頸。 計算圖割裂：Early Fusion 讓梯度可以跨模態流動但記憶體開銷 3–5×；Late Fusion 延遲低但跨模態推理能力弱。 Vision Transformer（ViT）的出現是關鍵：它把圖片當成 patch 序列，與文字 token 序列在同一個 Transformer 計算圖中處理，從根本上統一了兩個模態的計算路徑。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase12-part2-agents-computer-use-zh/Sun, 21 Jun 2026 21:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase12-part2-agents-computer-use-zh/大多數人把多模態 Agent 想像成「截一張圖，讓 AI 看一下，再點按鈕」。 真正的系統設計者問的是：感知、規劃、行動、驗證 四個迴圈如何在 latency、cost 與安全邊界之間取得平衡？ 初學者相信截圖就等於理解；資深工程師知道 UI 狀態是動態的、DOM 是脆弱的、截圖是時間切片。 架構的差距，在於你能不能在每一個行動之後，確保系統仍處於可預期的狀態。 工程情境 你的公司正在開發一個企業級 RPA Agent，能自動完成跨系統的報表匯出與郵件歸檔任務。目前系統在 POC 階段成功率約 62%，但 PM 要求上線後達到 90%+。請設計一個多模態 Computer Use Agent 架構，說明你如何提升可靠性、如何控制成本，以及如何在不破壞生產環境的前提下安全執行自動化操作。 一、核心問題：從感知到行動的多模態 Agent 傳統 RPA 工具（UiPath、Selenium）依賴固定選擇器：XPath、CSS selector、元素 ID。當應用升版、DOM 結構改變，自動化腳本立刻失效，維護成本以指數成長。 多模態 Agent 的出現改變了遊戲規則：它透過截圖理解 UI 語意，而非解析 DOM 結構。這讓自動化腳本對前端變動具有天然的韌性。但這只是第一步。 真正的挑戰在四個層次： 感知層（Perception）：截圖解析度、遮擋、動態載入元素、多螢幕佈局 理解層（Comprehension）：VLM 對 UI 語意的理解精度，圖示 vs 文字按鈕的辨識差異 規劃層（Planning）：多步驟任務的拆解、回溯、錯誤恢復 行動層（Action）：座標精度、點擊時機（元素是否已載入）、鍵盤輸入的上下文狀態 每一層都有獨立的失敗模式。系統設計的核心問題是：如何在每一層建立可觀測的錯誤信號，並設計對應的重試與降級策略？ 此外，文件理解（PDF 報表、圖表截圖）與 UI 操作共享同一個底層能力：視覺語意理解。但它們的精度要求、延遲容忍度和成本模型截然不同。一個設計良好的多模態 Agent 平台需要統一的 VLM 推理層，同時為不同場景提供差異化的 SLA。 二、三個演進階段（POC / MVP / Scale） ╔══════════════════════════════════════════════════════════╗ ║ Phase 1：POC / < 500 自動化任務/日 ║ ╚══════════════════════════════════════════════════════════╝ 目標：驗證可行性，快速迭代，容忍較高錯誤率（~30%）。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part1-mcp-apis-zh/Sun, 21 Jun 2026 21:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part1-mcp-apis-zh/大多數人把 LLM 接上 API，然後祈禱模型不要亂呼叫。 正確做法是：設計工具邊界，讓模型只能做它該做的事。 差別不在「能不能呼叫」，而在「呼叫錯了有沒有圍欄」。 工具整合的本質，是在 LLM 的智能與外部世界的副作用之間建立可審計的閘門。 工程情境：你正在設計一個 AI 客服代理，需要讀取訂單資料庫、發送退款請求、查詢物流狀態。系統每日處理 5 萬通查詢，P99 回應要在 3 秒內。你怎麼設計工具層的架構，同時確保安全性與可觀測性？ 一、核心問題：LLM 如何安全地操作外部世界 純語言模型是無狀態的文字轉換器，它不知道今天幾號，不知道訂單狀態，也無法真正寄出一封信。但產品需求要求 AI 能夠「做事」，不只是「說話」。 這個落差催生了工具使用（Tool Use）這個範式。但工具使用帶來的不只是能力擴展，更帶來三個深層工程挑戰： 挑戰一：副作用不可逆性 模型呼叫 send_email() 後，信就出去了。模型呼叫 delete_record() 後，資料就消失了。不像純 LLM 呼叫可以重試，帶有副作用的工具呼叫必須有 idempotency 保護和操作審計。 挑戰二：工具定義爆炸 一個企業 AI 代理可能需要整合 30+ 個內外部 API。每個工具的參數 Schema 、認證方式、錯誤處理各不相同。沒有標準化協議，工具層會變成難以維護的義大利麵程式碼。 挑戰三：提示注入攻擊 當工具的輸出結果（如網頁內容、資料庫紀錄）重新進入 LLM 上下文時，惡意內容可以偽裝成工具結果，誘導模型執行非預期的指令——這是 AI 系統特有的 injection 攻擊面。 MCP（Model Context Protocol）的出現，正是為了系統性地解決這三個問題。 二、三個演進階段 Phase 1：POC（< 5K 用戶，單一工具） ╔══════════════════════════════════════════╗ ║ Phase 1：直接呼叫 API（POC 階段） ║ ╚══════════════════════════════════════════╝ 用戶輸入 │ ▼ ┌────────────┐ Function ┌──────────────────┐ │ LLM API │─────Calling────▶│ 直接呼叫外部 API │ │ (GPT-4o) │◀────結果────────│ (requests 庫) │ └────────────┘ └──────────────────┘ │ ▼ 回應輸出 特徵： - 工具定義寫死在 system prompt - 無認證管理，API key 硬編碼 - 無錯誤重試，失敗直接拋例外 - 無日誌，難以除錯 適合場景：內部 Demo、單一 API 的 Chatbothttps://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part2-orchestration-zh/Sun, 21 Jun 2026 22:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part2-orchestration-zh/大多數人第一次接觸 LLM 應用，寫的是一個 openai.chat() 呼叫。 但到了生產環境，你需要的是：步驟間傳遞上下文、錯誤自動重試、中間結果快取、非同步平行執行。 單次呼叫處理不了這些；你需要的是一條管線，而不是一個函式。 本文從框架比較到生產監控，完整解析 AI 工作流程編排的每一個決策點。 工程情境：你的團隊要上線一個 RAG 客服機器人，需要：查詢改寫 → 向量檢索 → 文件重排序 → 生成答案 → 品質過濾。QA 反映目前有 15% 的查詢因為某一步失敗而整條管線崩潰。架構師問你：如何設計這個管線的錯誤處理策略，以及你會選哪個編排框架？請解釋你的技術決策。 一、核心問題：單次 LLM 呼叫為什麼不夠 1.1 真實 AI 應用的複雜度 想像你在構建一個智慧文件問答系統。用戶問：「上個季度我們在亞太區的收入是多少？」 一個 openai.chat() 能回答嗎？不行。你需要： 查詢理解：識別出「上個季度」和「亞太區」是關鍵限定詞 查詢改寫：展開成「Q3 2025 Asia Pacific revenue」等多個搜尋變體 向量檢索：從數千份財報文件中找出相關段落 重排序：用 Cross-Encoder 重新對候選段落評分 上下文組裝：把最相關的段落和對話歷史組成 Prompt 生成：呼叫 LLM 生成答案 品質驗證：確認答案有引用來源，沒有幻覺 這是 7 個步驟、至少 4 個外部服務呼叫、數個狀態轉換。這就是工作流程編排要解決的問題。 1.2 沒有編排框架時的痛點 痛點 具體表現 影響 錯誤傳播 步驟 3 失敗 → 整條管線崩潰 15–30% 請求失敗率 重複程式碼 每個專案重寫 retry / logging 開發速度 -40% 測試困難 無法對單一步驟做單元測試 Bug 定位時間 3× 無可觀測性 不知道哪個步驟慢 P95 延遲難以優化 狀態管理 中間結果存在記憶體，重啟即失 長任務無法恢復 1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part1-loop-memory-zh/Sun, 21 Jun 2026 22:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part1-loop-memory-zh/大多數人把 AI Agent 當成「會呼叫工具的 ChatBot」， 以為加幾個 function call 就完成了； 真正的 Agent 工程需要持久記憶、確定性狀態機、可觀測的思考迴圈， 差距不在 LLM，在你能不能讓它在第 20 步還知道自己在做什麼。 工程情境： 你是某電商平台的 AI 基礎設施 Lead。PM 要求將現有的「單次 GPT 呼叫客服」升級為「可自主完成退款、查單、更換地址」的 Agent，日均對話量 80K，P99 回應時間需在 8 秒以內。請問你如何設計 Agent 迴圈、記憶系統與上下文管理策略，並說明在 MVP 和 Scale 兩個階段的架構差異？ 一、核心問題：什麼是真正的 AI Agent 單次 LLM 呼叫（stateless call）與真正的 Agent之間有一道本質的鴻溝。 前者每次呼叫都是白紙一張，不知道剛才做了什麼，也不知道任務完成到哪裡；後者具備三個關鍵能力： 自主決策迴圈：在沒有人類介入的情況下，重複「感知→思考→行動→觀察」直到任務完成或確認無法完成。 跨步驟記憶：第 15 個步驟還能記得第 1 個步驟收集的用戶資料，不會重複詢問相同問題。 工具組合能力：可以依情境選擇不同工具，並根據工具回傳結果調整下一步計畫。 為什麼這很難？ LLM 本身是無狀態的（stateless）。每次 API 呼叫都是獨立的 HTTP 請求，沒有跨請求的記憶。Agent 框架必須在應用層解決： 上下文視窗有限：GPT-4o 128K tokens，換算約 96K 中文字。長任務無法全塞。 幻覺累積問題：步驟越多，錯誤累積越嚴重，必須設計檢查點。 成本爆炸：每步驟都傳完整歷史，128K token × $5/1M input = 每步 $0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part2-planning-zh/Sun, 21 Jun 2026 23:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part2-planning-zh/大多數人讓 Agent 直接呼叫工具，期待 LLM 自己想出下一步。 正確答案是：把規劃與執行分開，先產出可驗證的計畫，再逐步執行並動態修正。 差別不是「能不能完成任務」，而是「失敗時能不能恢復，成功時能不能解釋」。 規劃層是 Agent 系統從玩具走向生產的分水嶺。 工程情境：你的 AI Agent 需要完成一個多步驟任務：先查詢資料庫、再呼叫外部 API、最後產出報告。目前用 ReAct 架構，任務完成率只有 62%，主要失敗原因是中途走錯路、無法回頭。你的架構師問你：要如何重新設計規劃層，把完成率提升到 90% 以上？ 一、核心問題：為什麼 Agent 需要明確的規劃層 1.1 ReAct 的天花板 ReAct（Reason + Act）是目前最普遍的 Agent 架構。模型每次都先思考（Thought），再行動（Action），再觀察（Observation），循環直到任務完成。 這個架構對簡單任務效果不錯，但在複雜任務上暴露出結構性缺陷： 問題一：局部最優陷阱 每一步只看到當前狀態，無法預見三步後的死路。走進死路後，大多數 ReAct 實作只會繼續往前走，而非回頭。 問題二：無法並行 ReAct 是嚴格序列執行：Thought → Action → Observation。即使兩個子任務完全獨立，也必須依序完成，浪費延遲。 問題三：失敗後沒有恢復策略 工具呼叫失敗時，模型只能靠 prompt 裡的指示決定要不要重試。沒有系統性的回滾（rollback）或替代路徑（fallback path）機制。 問題四：無法事前驗證 計畫執行到一半才發現前提條件不成立（例如：所需的 API key 不存在），已經消耗了大量 token 和時間。 1.2 規劃層解決什麼 明確的規劃層把「想清楚要做什麼」和「真正去做」分開，帶來四個核心收益： 問題 規劃層的解法 局部最優 先展開搜尋樹，評估多條路徑後再執行最優解 無法並行 計畫產出 DAG，識別可並行的子任務 無法恢復 計畫有版本，失敗後 replan 而非從零開始 無法事前驗證 pre-condition 在執行前檢查，不滿足就不執行 關鍵數字：在 WebArena benchmark 上，純 ReAct 完成率約 14%；加入規劃層（Plan-and-Execute）後可達 26–35%；加入動態重規劃後可達 40–50%。複雜度越高的任務，規劃層的收益越大。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part3-frameworks-zh/Sun, 21 Jun 2026 23:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part3-frameworks-zh/大多數工程師的選擇：「先裝一個框架，之後再說。」 有經驗的工程師的選擇：「先定義 Agent 的交互模式，再選能支撐它的框架。」 框架給你速度，但也給你它的限制；抽象層降低入門門檻，但隱藏了你最需要控制的細節。 正確的問題不是「哪個框架最好」，而是「這個框架的抽象層，跟我的問題邊界對不對齊」。 工程情境 你的團隊正在構建一個客服自動化系統，需要協調「意圖分類 Agent」、「知識庫查詢 Agent」、「回應生成 Agent」與「品質審核 Agent」四個角色。技術主管問：「你會選 AutoGen、CrewAI 還是 LangGraph？為什麼？如果規模到每日 50 萬次對話，架構需要如何演進？」 一、核心問題：框架選型的本質是什麼 Agent 框架的選型問題，表面上是技術選擇，本質上是控制權與抽象層的交換。 每個框架都做了一組隱性決策： 執行模型：對話驅動 vs. 圖驅動 vs. 任務佇列驅動 狀態管理：記憶體內 vs. 持久化 vs. 外部化 Agent 通訊：廣播 vs. 點對點 vs. 中介者模式 錯誤恢復：重試策略、fallback 路徑、人工介入點 選錯框架的代價不是「換框架」這麼簡單。當你的 Agent 邏輯與框架的執行模型深度耦合後，重構成本等同於重寫。 框架的三個本質問題 問題 1：誰決定下一步由誰執行？ ├── 框架決定 → 高度結構化，靈活性低 ├── LLM 決定 → 靈活但不可預測 └── 工程師的程式碼決定 → 可控但需要更多開發工作 問題 2：狀態存在哪裡？ ├── 對話歷史 (messages list) → 簡單，但 token 成本高 ├── 結構化狀態物件 → 可查詢，但需要 schema 設計 └── 外部資料庫 → 持久化，但增加延遲 問題 3：出錯時怎麼辦？ ├── 讓 LLM 自己決定 → 彈性，但不可靠 ├── 框架的重試機制 → 簡單，但缺乏語意 └── 工程師的顯式錯誤處理 → 精確，但需要更多程式碼 理解這三個問題的答案，才能判斷一個框架是否適合你的用例。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part4-production-zh/Mon, 22 Jun 2026 00:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part4-production-zh/大多數團隊把 Agent 推上生產後就等著看它出問題； 正確的做法是在部署前設計可觀測性、預算上限、Guardrails； 差別不在於 Agent 多聰明，而在於系統多可靠； 沒有監控的 Agent，是一顆定時炸彈，不是產品。 工程情境 「你們的 AI Agent 在 staging 表現很好，但上線兩週後 token 費用暴增 400%，還出現幾次無限迴圈。你作為 tech lead，怎麼設計一個生產級的 Agent 系統架構來防止這些問題？請從可觀測性、成本控制、安全護欄三個維度說明，並說明你會如何科學地評估新 Agent 策略的效果。」 一、核心問題：Agent 生產化為什麼比模型部署難十倍 一般的 API 服務失敗模式很簡單：請求進來、計算、回應。延遲 p95 > 500ms 就告警，error rate > 1% 就回滾。背後的心智模型是「函數式」的：相同輸入，相同輸出，相同成本。 Agent 的失敗模式完全不同，它是「狀態機式」的：每一步的輸出決定下一步走哪條路。 問題一：非確定性執行路徑。 同一個輸入，Agent 可能走 3 步或 15 步。一個客服 Agent 回答「退貨政策」應該 2 步搞定，但如果 LLM 判斷需要查訂單狀態再查庫存再查物流，就變成 12 步、花了 $0.08 而非 $0.01。乘以每天 5,000 個請求，這個差距是 $350 vs $50，每月差 $9,000。 問題二：無限迴圈風險。 Agent 的 ReAct 迴圈沒有硬性上限時，一個錯誤的工具呼叫結果可能讓 Agent 不斷重試同一個動作。真實案例：一個資料分析 Agent 因為 SQL 工具回傳空結果，誤判為「需要更多查詢」，觸發 87 次 LLM 呼叫，花費 $23 才被手動停止。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part1-long-horizon-zh/Mon, 22 Jun 2026 00:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part1-long-horizon-zh/大多數人把 Agent 設計成「一問一答」的延伸版本——輸入一個任務，等待一個輸出。 長時程任務打破了這個假設：任務可能跨越數小時、數天、數十個 LLM 呼叫。 短時程 Agent 的容錯率是 5%，長時程 Agent 的錯誤會複利累積，每步 98% 成功率，五十步後完成率只剩 36%；每步 95%，更只剩 7.7%。 真正的長時程 Agent 工程，是在不確定性中建立可恢復、可審計、可協作的執行系統。 工程情境 你的團隊正在建構一個自動化程式碼審查 Agent，需要在 72 小時內分析一個大型 monorepo 的 3000 個 PR，並針對每個 PR 產出安全性報告、效能建議與合規性評估。這個 Agent 在執行到第 800 個 PR 時崩潰重啟，你如何設計系統確保任務能從斷點繼續、不重複分析已完成的 PR、且最終報告的品質不會因為長時間執行而漂移？ 一、核心問題：為什麼長時程任務對 Agent 是質的挑戰 1.1 短時程 vs 長時程的根本差異 大多數 LLM Agent 的設計假設是「無狀態、單輪、短暫」：使用者提問，Agent 在一個 context window 內完成推理，回傳答案，會話結束。這個模型在 RAG 問答、程式碼補全、單步工具呼叫等場景運作良好。 長時程任務打破了所有這些假設： 時間跨度：任務可能需要 2 小時、2 天、甚至 2 週才能完成 狀態複雜度：中間狀態數量可達數千個節點，無法全部放入 context window 錯誤複利：每一步有 2% 的錯誤率，50 步後完成率僅剩 36%（0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part2-self-improvement-safety-zh/Mon, 22 Jun 2026 01:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase15-part2-self-improvement-safety-zh/大多數工程師把安全當成事後的 checklist。 真正的 AI 工程師在架構第一行就把安全嵌入設計核心。 自我改進讓模型更強大；安全技術棧讓這份強大不會反噬使用者。 兩者缺一，你只是在玩一把沒有安全裝置的槍。 工程情境 你的公司正在部署一個能夠自主執行程式碼、搜尋網路、並呼叫內部 API 的 AI Agent。產品 VP 問你：「如果這個 Agent 被攻擊者注入惡意指令，最壞的情況是什麼？你會怎麼在不犧牲能力的前提下設計防禦架構？」 一、核心問題：自我改進的工程機會與安全風險 1.1 為什麼自我改進讓工程師又期待又害怕 2025 年末到 2026 年，生產環境中的 AI Agent 已從「問答機器」進化為「能夠修改自身行為的系統」。Self-Refinement 讓模型在推論時迭代改寫輸出；Constitutional AI 讓模型以原則自我審查；RLVR（Reinforcement Learning from Verifiable Rewards）讓模型從可驗證的結果信號中自我強化。 這三項技術加在一起，意味著一件事：模型的行為邊界不再是靜態的。這對工程師是機會，也是惡夢。 機會在於：系統可以越用越精準。但要分清兩種機制：Self-Refinement 與 Constitutional 式的自我審查發生在推論時，只改寫當次輸出，不會更新模型權重；真正讓模型「學到」東西的是 RLVR 這類訓練時的更新，需要離線收集資料、重新訓練並重新部署。 惡夢在於：如果攻擊者能夠注入惡意目標函數，系統會自我強化朝錯誤方向走，而且速度比你想像的快。 1.2 2026 年三大安全威脅面 威脅類型 典型攻擊向量 最壞後果 2026 發生率 提示注入（Prompt Injection） 惡意使用者輸入覆蓋系統提示 資料外洩、未授權操作 高（無公開可靠比例） 越獄（Jailbreak） 繞過安全訓練的對話技巧 有害內容生成 歸在 OWASP LLM Top 10 的 LLM01（Prompt Injection，第一位）之下 行動劫持（Action Hijacking） 透過 RAG 文件注入惡意工具呼叫 刪除資料、外部 API 濫用 2026 Q1 新興威脅 這篇文章的核心主張：自我改進機制與安全防禦必須共設計（co-designed），不能分開考慮。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part1-coordination-zh/Mon, 22 Jun 2026 01:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part1-coordination-zh/大多數人看到多 Agent 系統，第一反應是「多幾個 Agent 就能平行加速」。 工程現實卻是：沒有協調機制的多 Agent，比單 Agent 更慢、更貴、更難除錯。 正確答案是：先確定協調模式，再決定幾個 Agent——而不是反過來。 協調成本才是多 Agent 系統的真正瓶頸，比 LLM token 更貴。 工程情境 你負責設計一個研究助理平台：使用者輸入一個複雜問題，系統要自動拆解子任務、分派給不同專業 Agent（搜尋、摘要、數據分析、引用驗證），最後整合回一份報告。規模目標是 2,000 個並發研究任務，每個任務平均涉及 8 個子 Agent。請說明協調架構如何設計，以及當兩個 Agent 搶同一份外部資源時你怎麼處理衝突？ 一、核心問題：多 Agent 協調比單 Agent 難在哪裡 1.1 單 Agent 的極限在哪裡 單一 LLM Agent 在以下情境開始出現瓶頸： 情境 問題 數字 超長 context 精度隨 token 數下降 > 32K tokens 後 recall 掉 15–30% 串行任務鏈 無法利用並行，延遲線性增長 10 步 × 3s = 30s 異構技能需求 同一 Agent 無法同時是程式碼專家與法律專家 prompt 膨脹、精度下降 長時間運行 上下文視窗耗盡，需要切割狀態 超過 4 小時任務必須外化記憶 多 Agent 解決了以上問題——但引入了一整類新問題：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part2-emergence-collective-zh/Mon, 22 Jun 2026 02:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase16-part2-emergence-collective-zh/大多數工程師遇到複雜問題，第一直覺是「換一個更大的模型」。 真正懂系統設計的人知道：讓十個中等模型彼此辯論，往往比一個頂尖模型獨自思考更準確。 湧現不是魔法，是可以設計的協作協議。 問題不是「能不能湧現」，而是「湧現後你有沒有辦法控制它」。 工程情境： 你的團隊正在構建一個醫療診斷輔助系統，需要在 99.5% 準確率與 < 3 秒延遲之間取得平衡。單一 GPT-4 只能達到 94% 準確率，且有時會「幻覺」出不存在的藥物交互作用。請設計一個多 Agent 集體推理架構，說明如何透過湧現行為提升準確率，同時保持可控性與可解釋性。 一、核心問題：湧現智慧的工程機會與不可控性 湧現（Emergence） 是系統層級的性質，無法從單一元件預測。一個 Agent 讀文件，十個 Agent 互相辯論，系統的行為質量不是線性疊加，而是非線性躍升。 為什麼湧現在 LLM 多 Agent 系統中特別有價值？ LLM 的認知偏差問題： 問題類型 單一 LLM 表現 多 Agent 集體推理 確認偏誤 容易強化初始假設 反對 Agent 強制挑戰 幻覺 4–8% 幻覺率（GPT-4） 辯論後降至 1–2% 知識盲點 受限於訓練資料 不同模型互補不同知識 複雜推理 單次 context 限制 分工後各擅勝場 湧現的工程挑戰： 不可預測性：5 個 Agent 的交互可能產生 120 種路徑排列 放大效應：一個 Agent 的錯誤可能被其他 Agent 強化而非糾正（Echo Chamber） 成本爆炸：N 個 Agent 互相溝通 = O(N²) token 消耗 延遲累積：串行辯論每輪加 2–5 秒，3 輪 = 6–15 秒額外延遲 工程師的任務不是「讓系統湧現」，而是設計湧現發生的條件，並在湧現失控前有干預能力。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part1-serving-zh/Mon, 22 Jun 2026 02:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part1-serving-zh/大多數人：把 torch.load() 包一層 Flask，貼上 /predict 就叫「部署」。 真正的做法：從服務框架選型、GPU 共享策略、冷啟動預熱到多租戶隔離，每一層都有可量測的 SLO。 差距不在演算法，而在系統設計——單機 GPU 使用率 23% vs 叢集使用率 78%，成本相差 3.4 倍。 本文從 POC 到全球部署，逐層拆解 AI 推論服務的工程決策。 工程情境 你的電商平台每天有 500 萬次商品推薦請求，目前用一台 A100 跑 PyTorch 模型，P99 延遲 1.2s，GPU 使用率只有 23%。CTO 說三個月後要支援 10 倍流量，同時把 P99 壓到 200ms 以內，預算只能增加 2 倍。你會如何重新設計推論服務架構？請解釋你在服務框架選型、擴縮容策略、GPU 共享、以及多租戶隔離四個面向的決策依據。 一、核心問題：AI 推論服務與傳統 Web 服務的本質差異 AI 推論服務並不是「把模型包一個 HTTP 端點」這麼簡單。它在資源模型、延遲特性、擴縮容行為上，與傳統 Web 服務有根本性差異。 資源模型的差異 傳統 Web 服務以 CPU 為主，水平擴展幾乎無代價——增加一台虛擬機需要 30 秒，成本線性增加。AI 推論服務以 GPU 為主，GPU 節點冷啟動需要 45–120 秒（含驅動初始化、CUDA context 建立、模型載入），每台 A100 機器成本約 $3–6/hour，是 CPU 機器的 15–30 倍。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part2-observability-zh/Mon, 22 Jun 2026 03:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part2-observability-zh/大多數工程師把 LLM 呼叫當成黑箱：記錄 HTTP 狀態碼、回應時間，然後就沒了。 正確的做法是：追蹤每一個 Prompt 版本、每一次工具呼叫、每一個 Token 成本，並量化模型行為漂移。 傳統 APM 只告訴你系統「掛了沒」；AI 可觀測性要告訴你模型「答得好不好」。 沒有這層監控，你永遠不知道提示更新讓答案品質下降了 12%，還是模型供應商悄悄換了版本。 工程情境 技術主管問：「你們的 RAG 問答系統上線後，客服主管反應『最近答案怪怪的』，但 p99 延遲和錯誤率都正常。你身為 SRE/AI 工程師，會怎麼設計可觀測性系統來定位這類問題？請說明你的 Traces 設計、漂移偵測機制，以及如何在成本和覆蓋率之間取得平衡。」 一、核心問題：AI 系統的可觀測性為什麼與傳統系統不同 傳統服務的可觀測性三支柱——Metrics、Logs、Traces——在 AI 系統上全都「不夠用」，但原因各不相同。 傳統系統的失敗模式是二元的：請求成功或失敗，HTTP 200 或 500，延遲高或低。失敗有明確的邊界。當資料庫 query 耗時 800ms，你知道哪裡壞了。 AI 系統的失敗模式是漸進的、語意的： 模型回傳 HTTP 200，但答案從準確滑向「有點對但不夠精確」 Prompt 被改了一個詞，召回率悄悄下降 8% 供應商在 2AM 更新基礎模型，語氣風格改變，用戶滿意度在 48 小時後才反映在 CSAT Token 用量因為對話上下文累積，每週成本靜靜地增長 15% 這就是為什麼 AI 可觀測性需要新的維度： 維度 傳統系統 AI 系統 品質訊號 Error rate, p99 latency 語意相似度、答案忠實度、幻覺率 版本追蹤 Code git SHA Prompt version + Model version + RAG index version 成本單元 CPU/Memory/Network Input tokens + Output tokens + Embedding calls 漂移型態 無（確定性系統） 概念漂移、分佈漂移、模型版本漂移 告警閾值 靜態（> 500ms alert） 動態（品質分數 7 日移動平均下降 > 5%） 開頭提到的「答案怪怪的」就是典型的語意品質退化。系統層面一切正常，但輸出品質已悄悄崩潰。沒有 AI-native 可觀測性，這種問題的 MTTR 往往超過 3 天。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/Mon, 22 Jun 2026 03:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase17-part3-cost-scale-zh/大多數團隊看到 AI 帳單飆升，第一反應是「換便宜的模型」。 但換模型只是換藥不換病：根本問題是沒有成本工程的思維。 正確答案是把 AI 推論視為可測量、可分解、可優化的工程系統—— 從 Token 單位經濟學到快取命中率，每個數字都是槓桿點。 工程情境 你的 RAG 系統每月 AI API 費用從 $3,000 暴增到 $47,000，只花了 90 天。VP 問你：「不砍功能、不降品質，能把成本壓回 $15,000 以內嗎？」你會從哪裡下手？ 一、核心問題：AI 成本為什麼是工程問題而不是採購問題 1.1 成本爆炸的根因 AI API 成本爆炸通常不是因為「用太多功能」，而是因為工程決策累積的結構性浪費： 重複計算：相同或語義近似的 prompt 反覆打到 API，沒有任何快取層 模型過配（Over-provisioning）：用旗艦大模型處理「幫我把這段文字轉成 JSON」這種任務 無邊界的 Context Window：每次請求塞入整個對話歷史，Context 長度隨時間線性增長 同步阻塞推論：本可批次離線的任務強行走即時路徑，佔用高單價的即時算力 1.2 成本的三個維度 成本 = Token 數量 × 單價 × 請求頻率 ─────── ──── ──────── 工程可控 模型選擇 業務需求 採購談判只能影響「單價」，而且通常邊際效益有限（折扣上限約 20–30%）。 真正的槓桿在「Token 數量」和「請求頻率」——兩者都是純工程問題。 1.3 為什麼 FinOps 思維不夠用 傳統雲端 FinOps 的核心是「Resource Right-sizing」：把過大的 VM 換小。 但 AI 成本的結構完全不同：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part1-technical-safety-zh/Mon, 22 Jun 2026 04:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part1-technical-safety-zh/一、核心問題：技術安全是工程問題，不是哲學問題 大多數人以為：AI 安全是倫理學家的工作，工程師只需要把模型做準確就好。 但實際上：安全失效有明確的技術根源、可量化的失效率、可工程化的防禦架構。 常見錯誤：把「拒絕有害請求」當作安全的終點，忽略 reward hacking、提示注入、後門攻擊等系統性威脅。 正確做法：把技術安全當作 SRE 問題——定義 SLO、量測失效率、建立防禦層、持續紅隊測試。 工程情境： 你的公司剛完成一個面向消費者的 LLM 聊天產品，DAU 達 50 萬。安全團隊發現有使用者透過角色扮演場景讓模型輸出有害內容，失效率約 1.8%。CTO 問你：「我們現在該做什麼？下個季度的架構長什麼樣？」請說明你的診斷、優先順序與技術路線圖。 這道題考的不是你背得出多少防禦技術，而是你是否理解：安全工程需要層次化防禦（defense in depth）、可量測的指標、以及與產品、法務、合規的協作架構。 為什麼安全問題是工程問題？ 當 LLM 進入生產環境，它面對的不是教科書上的良性使用者，而是： 惡意行為者嘗試繞過護欄（越獄成功率業界平均：3–15%，視模型與攻擊方式） 非惡意使用者意外觸發危險輸出（佔有害輸出的約 40–60%） 供應鏈攻擊——被毒化的訓練資料或第三方工具輸出注入惡意指令 每一類失效都對應具體的技術根因與可量化的後果： 法遵成本：GDPR 違規罰款可達全球年營收 4% 用戶流失：一次重大安全事件後，30 日留存率平均下降 12–18% 品牌損傷：媒體曝光後客服工單量暴增 300–500% 二、三個演進階段（含 ASCII 架構圖） Phase 1：POC / < 10K 用戶 ╔══════════════════════════════════════════════╗ ║ Phase 1：POC / < 10K 用戶 ║ ╚══════════════════════════════════════════════╝ 核心思路： 用最低成本先擋住最明顯的風險，快速驗證產品可行性。 ┌──────────────────────────────────────────────────────┐ │ 使用者請求 │ └──────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────┐ │ 關鍵字黑名單過濾（硬編碼規則） │ │ 延遲：< 1ms │ └──────────────────┬───────────────────────────────────┘ │ 通過 ▼ ┌──────────────────────────────────────────────────────┐ │ LLM 推論（系統提示包含基本安全指令） │ └──────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────┐ │ 輸出長度/格式驗證 │ └──────────────────┬───────────────────────────────────┘ │ ▼ 回傳使用者 新增元件 vs 前一階段： 從零開始，建立基線。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part2-governance-zh/Mon, 22 Jun 2026 04:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part2-governance-zh/大多數工程師把 AI 治理當成法務部門的事，等監管機關發函才開始補文件； 正確答案是：治理是系統設計的一等公民，在模型進 production 的第一天就必須量測公平性、記錄資料來源、控制隱私洩露量。 不做治理不是「省力」，是把合規風險、偏見訴訟、資料外洩的成本推遲到最貴的時間點——上線之後。 工程師不需要成為法律專家，但必須懂得把監管義務翻譯成系統元件和可量測的指標。 工程情境 你的團隊正要在 EU 市場推出一個信用評分 AI 系統，PM 說「先上線再合規」，CTO 問你：從工程架構角度，最低限度需要做哪些治理元件才能在 EU AI Act 生效後合法營運？如果資料集中有性別和種族代理變數，你打算怎麼處理偏見？隱私工程用什麼機制確保 GDPR 合規？ 一、核心問題：AI 治理為什麼是工程師的問題 AI 治理在過去五年從「道德宣示」進化為「法律義務」。EU AI Act 在 2024 年 8 月正式生效，禁止條款自 2025 年 2 月起適用、通用目的 AI（GPAI）模型義務自 2025 年 8 月起適用，高風險系統原定 2026 年 8 月進入強制合規期；NIST AI RMF 則是美國最常被引用的自願性風險框架。其他地區路線不一：中國已推出生成式 AI 管理辦法，英國採取由既有監管機關執行的原則式路線、沒有專門的 AI 法，加拿大的 AIDA 法案則隨 C-27 法案於 2025 年初失效。 工程師為什麼不能把這件事推給法務？ 合規義務落在系統層：EU AI Act Article 9 要求「risk management system」必須以技術文件佐證，不是 policy PDF，是可追溯的程式碼和日誌 偏見來自資料 pipeline：統計公平性的破壞點在特徵工程、訓練集採樣、評估集分割——法務無法在那裡插手 隱私洩露是技術問題：差分隱私的 epsilon 預算、聯邦學習的梯度聚合——這些是數學和工程，不是合約條款 稽核需要系統支撐：監管機關要看 model card、訓練資料來源、版本歷史、A/B 決策記錄——這些必須在 CI/CD 裡自動生成 信用評分這個域的具體風險：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part1-capstone-rag-system-zh/Mon, 22 Jun 2026 05:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part1-capstone-rag-system-zh/大多數工程師看到 RAG 就直接 pip install langchain，把 PDF 切成 512 token，塞進 ChromaDB，呼叫 GPT-4o，然後跟老闆說「系統做好了」。 真正的答案是：RAG 是一個系統，不是一個腳本。你需要解析管線、混合索引、重排序、評估框架，以及一套讓你在生產環境裡活下去的可觀測性架構。 腳本在 demo 時可以運作。系統在三個月後的週一早上凌晨兩點還能運作。 這篇文章記錄的是後者。 工程情境 技術主管：「假設你加入一家 500 人的科技公司，負責從零打造內部知識庫問答系統。有 5 萬份文件（PDF、Word、HTML 混雜），200 位同時在線用戶，SLA 要求 P95 < 3 秒，預算每月 $3,000 以內。你的第一個月怎麼規劃？第 4 週的架構長什麼樣子？最大的技術風險在哪裡？」 一、專案目標：企業知識庫問答系統的真實需求 1.1 為什麼這個題目值得深挖 這不是一個玩具問題。企業內部知識庫是 RAG 應用最高頻、也最容易出錯的場景。文件格式雜亂、安全等級各異、查詢意圖模糊、幻覺率要求嚴格——每一個細節都可以把一個「能動的 demo」變成「生產事故」。 本文以參考設計的形式呈現：規模與數字取自典型的企業知識庫情境，屬示意估算，而非某個真實專案的量測結果；重點在每個技術決策背後的取捨理由。 1.2 業務需求清單 維度 需求 文件規模 5 萬份（PDF 60%、Word 25%、HTML 15%） 並發用戶 200 人同時在線，峰值 QPS 約 40 延遲 SLA P95 < 3 秒（端對端，含 LLM 生成） 幻覺率上限 < 8%（由法務部門要求，涉及合規文件） 多租戶隔離 3 個部門，各自的文件不可互相查詢 語言 繁體中文為主，英文文件占 30% 預算 每月 $3,000（含 LLM API、向量資料庫、運算） 安全等級 L1（公開）/ L2（內部）/ L3（機密）三級 1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part2-capstone-agent-product-zh/Mon, 22 Jun 2026 05:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part2-capstone-agent-product-zh/大多數人做法：把 ChatGPT API 包一層 wrapper，加幾個 if-else，叫它「AI 客服 Agent」。 正確答案：ReAct 迴圈 + 工具安全閘 + 對話記憶 + Guardrails + 完整可觀測性， 缺少任何一層，上線兩週後你就會收到第一封「Agent 幫客戶退了根本沒問題的訂單」的事後報告。 本文以一個 4 週 Sprint 的參考設計呈現，紀錄哪些設計決策能讓系統撐過 80K sessions/day 的峰值。 工程情境 你的公司想把電商客服從人工轉為 AI Agent，日均客服量約 30K sessions，高峰期（雙 11）可能到 80K。客服範圍包含訂單查詢、退換貨申請、產品推薦以及升級至人工。請描述你會如何設計這個系統，從 MVP 到可以承受 80K sessions/day 的生產架構，並說明關鍵的工程決策與取捨。 一、專案目標：AI 客服 Agent 的真實產品需求 這個 Capstone 是一個電商平台改造案的參考設計（情境與數字為示意，非真實專案資料）。業務背景很清楚： 現狀：人工客服 45 人，平均回應時間 4.2 分鐘，CSAT 3.7/5，月薪資成本 $180K USD 目標：AI 處理率 ≥ 70%，平均回應時間 < 8 秒，CSAT ≥ 4.0/5，月 AI 成本 < $35K 風險底線：不能有金融損失（錯誤退款、錯誤折扣），不能有個資外洩 拆解需求後，Agent 需要具備五種能力：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part3-capstone-multimodal-app-zh/Mon, 22 Jun 2026 06:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part3-capstone-multimodal-app-zh/大多數人：把 GPT-4V 的 API 呼叫包一層，傳圖片進去，輸出文字就叫「多模態應用」。 真正的做法：從模態路由、串流融合、延遲預算分配到降級策略，每一層都有可量測的 SLA。 差距不在模型能力，而在系統設計——隨機拼接各模態模型的 P99 延遲 8.4s vs 精心設計的多模態管線 1.9s，用戶留存率相差 2.7 倍。 本文是 AI 工程從零開始系列的 Capstone 收官之作，從 POC 到 Scale，完整走完多模態 AI 平台的工程之路。 工程情境 你負責一個 B2B SaaS 的商業智慧平台，客戶需要一個 AI 助理能同時分析：PDF 財務報告中的圖表、上傳的截圖、語音指令，以及結構化的 Excel 數據。目前你們每月有 50K 活躍用戶，高峰期同時在線 3,000 人，計劃六個月後擴展到 500K 用戶。請設計端對端的多模態 AI 系統架構，說明你如何處理不同模態的延遲差異（文字 200ms、圖片 800ms、語音 1200ms）、模態融合策略選擇依據、以及當某個模態服務降級時整個系統如何維持可用性。 一、專案目標：多模態商業智慧分析平台需求 這個 Capstone 專案整合了本系列所有核心技術：Transformer 與 LLM（Phase 7、10）、推論與 RAG（Phase 11）、Agent 與工具整合（Phase 13–14）、推論服務與成本優化（Phase 17）、語音處理（Phase 6）、視覺與多模態理解（Phase 4、12），最終構建一個真實可用的多模態商業智慧分析平台。 1.1 功能需求 輸入能力 模態 具體場景 典型檔案大小 預期延遲 文字 問題查詢、上下文指令 < 4KB 200ms 圖片 截圖、圖表、掃描文件 100KB–5MB 600–1200ms PDF 財務報告、合約文件 1–50MB 2000–8000ms 語音 口頭指令、語音備忘 10–120 秒音訊 800–2000ms 結構化資料 Excel/CSV 數據 < 10MB 300–600ms 輸出能力