大多數人：把 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 專案整合了本系列所有核心技術：語言模型（Phase 7–9）、RAG（Phase 11）、Agent（Phase 13）、效能優化（Phase 17–18）、語音處理（Phase 6）、視覺理解（Phase 19 Part 1–2），最終構建一個真實可用的多模態商業智慧分析平台。
1.1 功能需求
輸入能力
| 模態 | 具體場景 | 典型檔案大小 | 預期延遲 |
|---|---|---|---|
| 文字 | 問題查詢、上下文指令 | < 4KB | 200ms |
| 圖片 | 截圖、圖表、掃描文件 | 100KB–5MB | 600–1200ms |
| 財務報告、合約文件 | 1–50MB | 2000–8000ms | |
| 語音 | 口頭指令、語音備忘 | 10–120 秒音訊 | 800–2000ms |
| 結構化資料 | Excel/CSV 數據 | < 10MB | 300–600ms |
輸出能力
- 文字回覆（Streaming）：P50 首字元 < 300ms
- 圖表生成：含數字標注，< 3s
- 語音回應（TTS）：P50 首音訊塊 < 600ms
- 引用來源：每個聲明標注文件頁碼與段落
1.2 非功能需求
- 可用性：99.9%（每月宕機 < 44 分鐘）
- 延遲 SLA：簡單文字查詢 P99 < 800ms；多模態複合查詢 P99 < 5s
- 安全：租戶數據完全隔離；PII 自動偵測與遮蔽
- 成本上限：每次多模態請求成本 < $0.08（含模型推論、儲存、頻寬）
二、三個演進階段含完整系統 ASCII 架構圖
Phase 1：POC（< 10K 用戶，1–2 個工程師，1–2 個月）
目標：驗證多模態理解的可行性，用 API 組合而非自建基礎設施。
┌─────────────────────────────────────────────────────────────┐
│ 用戶瀏覽器 / App │
└──────────────────────┬──────────────────────────────────────┘
│ REST API（同步）
▼
┌─────────────────────────────────────────────────────────────┐
│ FastAPI 單體應用 │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ 文字路由 │ │ 圖片路由 │ │ 語音路由 │ │
│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │
│ └───────────────┼───────────────┘ │
│ ▼ │
│ GPT-4o API（多模態） │
└─────────────────────────────────────────────────────────────┘
│
▼
S3 / 本地磁碟（暫存）
新增組件：FastAPI、GPT-4o API 呼叫、S3 檔案暫存、Whisper API（語音轉文字）
成本估算：
- 開發成本：2 人月
- 運算：$200–500/月（API 費用為主）
- 基礎設施：$50/月（1 台 t3.medium）
Phase 1 解決的問題：
- ✅ 驗證多模態理解品質（GPT-4o 對圖表分析準確率 ~82%）
- ✅ 端對端流程可跑通
- ✅ 快速收集用戶回饋
Phase 1 遺留的問題：
- ❌ 同步 API，大檔案（50MB PDF）會 Timeout（30s 上限）
- ❌ 所有模態走同一個 GPT-4o 端點，成本難以控制
- ❌ 無佇列緩衝，突發流量直接打垮後端
- ❌ 無降級策略，API 限速時全站報錯
Phase 2：MVP（10K–200K 用戶，4–8 工程師，3–4 個月）
目標：生產就緒，異步處理長任務，分離不同模態的處理路徑。
┌──────────────────────────────────────────────────────────────────┐
│ 用戶瀏覽器 / App │
└──────────────┬───────────────────────────────────────────────────┘
│ WebSocket / SSE（Streaming）
▼
┌──────────────────────────────────────────────────────────────────┐
│ API Gateway（Kong/Nginx） │
│ 認證、Rate Limiting（1000 req/min/租戶） │
└──────────────┬───────────────────────────────────────────────────┘
│
┌───────┴──────────┐
▼ ▼
┌──────────────┐ ┌───────────────────────────────────────────┐
│ 同步文字 │ │ 任務佇列（Redis / SQS） │
│ LLM 服務 │ │ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ (FastAPI) │ │ │ 圖片佇列│ │PDF 佇列 │ │語音佇列 │ │
│ P99: 600ms │ │ └────┬────┘ └────┬────┘ └────┬─────┘ │
└──────────────┘ └───────┼───────────┼─────────────┼────────┘
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────────┐
│Vision │ │Document │ │Speech Worker │
│Worker │ │Worker │ │(Whisper) │
│(GPT-4V) │ │(PDF→RAG) │ │ASR P99: 1.8s │
└──────────┘ └──────────┘ └──────────────┘
│ │ │
└───────────┴─────────────┘
▼
┌───────────────────────┐
│ 結果聚合服務（Redis │
│ Pub/Sub + WebSocket）│
└───────────────────────┘
新增組件：Redis 佇列、Worker 分離（Vision/Document/Speech）、WebSocket/SSE Streaming、PostgreSQL（任務狀態）、向量資料庫（Qdrant，PDF RAG）
成本估算：
- 開發成本：6 人月
- 運算：$2,000–5,000/月
- 基礎設施：$800/月（EKS 叢集 + RDS + ElastiCache）
Phase 2 解決的問題：
- ✅ 異步佇列解決 PDF 大檔案 Timeout 問題
- ✅ 各模態獨立擴縮，圖片 Worker 可跑 4 個並發，語音 Worker 跑 2 個
- ✅ SSE Streaming 讓文字回覆首字元延遲從 600ms → 180ms
- ✅ 向量 RAG 讓 PDF 分析成本從 $0.12/次 降到 $0.04/次（減少 LLM token 輸入量 67%）
Phase 2 遺留的問題：
- ❌ Worker 固定數量，無法應對突發（高峰期佇列積壓 > 500 任務）
- ❌ 跨模態請求需要客戶端自行組合多個 API 呼叫
- ❌ 無統一的模態融合層，上下文在不同 Worker 之間難以共享
Phase 3：Scale（200K–1M+ 用戶，10+ 工程師，持續演進）
目標：企業級多租戶、自動擴縮、全域低延遲、智慧模態路由。
┌─────────────────────────────────────────────────────────────────────────┐
│ CDN + Edge Cache（CloudFront） │
│ 靜態資產 Cache-Hit-Rate: 94%，音訊串流邊緣節點 │
└────────────────────────────┬────────────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────────────┐
│ API Gateway（Kong Enterprise） │
│ JWT 驗證、租戶隔離、速率限制、請求 Tracing（Jaeger） │
└──────────────┬─────────────────────────────────────────────────────────┘
│
┌──────────────▼──────────────────────────────────────────────────────────┐
│ 模態路由器（Modal Router） │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ 輸入分析：偵測模態組合、預估成本、選擇處理路徑 │ │
│ │ 路由策略：文字優先、並行多模態、條件降級 │ │
│ └──────────────────────────────────────────────────────────────────┘ │
└────┬────────────┬────────────┬────────────┬────────────────────────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────────────────┐
│ 文字 │ │ 視覺 │ │ 語音 │ │ 文件理解 │
│ 服務 │ │ 服務 │ │ 服務 │ │ 服務 │
│ vLLM │ │ GPU Pod │ │ ASR+TTS │ │ PDF Parser + RAG │
│ 3副本 │ │ HPA:2-8 │ │ HPA:1-6 │ │ HPA:2-10 │
│ P99: │ │ P99: │ │ ASR P99:│ │ P99: 3.2s │
│ 180ms │ │ 900ms │ │ 1.1s │ │ │
└────┬────┘ └────┬────┘ └────┬────┘ └──────────┬───────────┘
└───────────┴───────────┴─────────────────┘
│
┌────────────────────────────▼────────────────────────────────────────────┐
│ 模態融合引擎（Fusion Engine） │
│ 並行結果收集 → Context 組裝 → LLM 綜合推理 → Streaming 輸出 │
└────────────────────────────┬────────────────────────────────────────────┘
│
┌───────────────────┴──────────────────────┐
▼ ▼
┌─────────────────┐ ┌──────────────────────┐
│ 文字 Streaming │ │ TTS 語音回應 │
│ SSE / WS │ │ Edge Delivery │
│ 首字 < 300ms │ │ 首音訊塊 < 500ms │
└─────────────────┘ └──────────────────────┘
新增組件：模態路由器、Fusion Engine、vLLM（文字服務）、HPA 自動擴縮、多租戶 Namespace 隔離、全域 Tracing
成本估算：
- 開發成本：20+ 人月（持續演進）
- 運算：$15,000–40,000/月（視流量）
- 基礎設施：$5,000/月（多 AZ EKS + Aurora + OpenSearch + Redis Cluster）
Phase 3 解決的問題：
- ✅ 模態路由器使簡單文字查詢繞過視覺/語音服務，P99 從 2.1s → 180ms
- ✅ Fusion Engine 統一管理跨模態上下文，不再由客戶端拼接
- ✅ HPA 使語音 Worker 在 90 秒內從 1 副本擴到 6 副本（應對早晨高峰）
- ✅ 租戶隔離使企業客戶數據零交叉風險
三、圖文理解管線：截圖/圖表/文件的多模態解析
3.1 視覺輸入的前處理管線
原始圖片在進入視覺模型之前需要一系列預處理步驟，每個步驟都影響最終理解品質與成本。
┌──────────────────────────────────────────────────────────────┐
│ 圖片輸入前處理管線 │
│ │
│ 原始圖片 │
│ │ │
│ ▼ │
│ ┌──────────────┐ 失敗 ┌─────────────┐ │
│ │ 格式驗證 │───────────▶ │ 錯誤回應 │ │
│ │ (MIME/大小) │ │ 413/415 │ │
│ └──────┬───────┘ └─────────────┘ │
│ │ 通過 │
│ ▼ │
│ ┌──────────────┐ │
│ │ 自動旋轉 │ EXIF Orientation 修正 │
│ │ + 去雜訊 │ 輕量 OpenCV 處理 ~15ms │
│ └──────┬───────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 場景分類 │ 圖表 / 截圖 / 文件 / 照片 │
│ │ (ViT-S/16) │ 延遲: 45ms，準確率: 91% │
│ └──────┬───────┘ │
│ │ │
│ ┌────┴────┬──────────────┐ │
│ ▼ ▼ ▼ │
│ 圖表場景 文件場景 截圖場景 │
│ ↓ ↓ ↓ │
│ 向量化 OCR增強 UI元素偵測 │
│ + 數值 + 版面分析 + 文字提取 │
│ 提取 (800ms) (400ms) │
│ (600ms) │
└──────────────────────────────────────────────────────────────┘
3.2 圖表專項理解
金融圖表（K線圖、趨勢圖、對比柱狀圖）是 B2B 商業智慧場景最常見的輸入，純 LLM 視覺模型在數值提取上準確率只有 58%，需要專項增強：
兩階段提取策略：
- 結構理解（GPT-4V）：識別圖表類型、軸標籤、圖例、趨勢 → 延遲 700ms，成本 $0.02
- 數值提取（專用 OCR + 座標回歸）：精確提取數值點 → 延遲 300ms，成本 $0.001
組合後準確率：92.4%（vs 純 GPT-4V 的 58.1%）
3.3 PDF 多層次解析
大型 PDF（50 頁財務報告）的處理是延遲最大的挑戰：
| 解析策略 | 延遲 | 成本 | 適用場景 |
|---|---|---|---|
| 全文 OCR + 逐頁分析 | 45–90s | $0.40 | ❌ 太慢太貴 |
| 智慧抽樣（每 5 頁取 1 頁） | 8–15s | $0.08 | 摘要理解 |
| 語意分塊 + RAG 檢索 | 2–4s（首次建索引後） | $0.015/查詢 | ✅ 生產環境 |
| 混合：結構頁全解析 + 內文 RAG | 3–6s | $0.025 | ✅ 最佳平衡 |
生產環境採用混合策略：封面頁、目錄頁、圖表頁全量解析並建立視覺索引，其餘文字頁切塊後存入向量資料庫（chunk size 512 tokens，overlap 64 tokens）。用戶查詢時 RAG 檢索 Top-5 段落，P99 回應時間 3.2s，token 成本減少 73%。
四、語音介面整合：ASR + LLM + TTS 的串流設計
語音是多模態應用中延遲最敏感的模態。用戶開口說完後等待 AI 回應，主觀感知的「可接受等待時間」上限約為 2.5 秒。
4.1 端對端延遲分解
用戶說話結束
│
│ ① 音訊傳輸到後端：100–300ms（取決於網路）
▼
┌─────────────────────┐
│ ASR（語音轉文字） │ ② Whisper-large-v3：P50 680ms，P99 1100ms
│ Whisper / 串流 ASR │ 串流 ASR（VAD 切句）：首句 P50 320ms
└──────────┬──────────┘
│ ③ 文字 → LLM 推理：P50 180ms（首 token）
▼
┌─────────────────────┐
│ LLM（語言理解） │ 使用 vLLM + Streaming
│ 文字生成 │ 首 token P50: 180ms
└──────────┬──────────┘
│ ④ 文字 → TTS 轉換：首音訊塊 P50 380ms
▼
┌─────────────────────┐
│ TTS（文字轉語音） │ 使用 Edge TTS 或自建 VITS
│ 語音合成 │ 首音訊塊 P50: 380ms，P99: 620ms
└──────────┬──────────┘
│ ⑤ 音訊回傳用戶：80–200ms
▼
用戶聽到回應
總端對端（P50）：100+680+180+380+80 = 1420ms
總端對端（P99）：300+1100+400+620+200 = 2620ms
P99 2620ms 仍在 2.5s 可接受範圍邊緣——需要優化。
4.2 三項串流優化
優化 1：串流 ASR（VAD + 增量識別）
不等語音說完再轉文字，使用 Voice Activity Detection (VAD) 偵測停頓，在用戶說話過程中即時輸出部分文字。當用戶說完最後一句，ASR 結果已接近完整。
節省：280ms（ASR 等待時間從 680ms → 400ms）
優化 2：投機性 LLM 推理（Speculative Prefill）
ASR 輸出第一個句子（~50ms 後）就開始 LLM Prefill，不等完整問題。若後續 ASR 結果與預期一致，直接繼續生成；若不一致，重啟推理。
命中率：約 71%，節省：~120ms
優化 3：TTS 並行生成
LLM 輸出第一個完整句子（通常 3–5 個中文字，~40ms 後）立即觸發 TTS 合成該句，不等完整回答。用戶聽到第一段語音時，LLM 還在生成後續文字。
節省：TTS 感知延遲從 380ms → 200ms（首段播放時間）
三項優化合計 P99 延遲：300+820+280+420+200 = 2020ms（降低 23%）
4.3 語音降級策略
當語音服務不可用（ASR 或 TTS 故障）：
| 場景 | 降級行為 | 用戶感知 |
|---|---|---|
| ASR 超時（> 3s） | 提示用戶改用文字輸入 | 輕微中斷 |
| TTS 故障 | 返回純文字回應 | 功能降級，不報錯 |
| 兩者均故障 | 靜默切換到文字模式，頁面提示 | 用戶可繼續使用 |
五、模態融合策略：並行 vs 串行 vs 條件路由
多模態請求的核心工程挑戰是：不同模態的處理時間差異達 5–10 倍，如何設計融合策略決定了整個系統的延遲與成本。
5.1 三種融合架構對比
┌──────────────────────────────────────────────────────────────────┐
│ 三種模態融合架構 │
│ │
│ 【串行融合】 │
│ 文字 ──▶ 視覺 ──▶ 語音 ──▶ LLM 綜合 │
│ 總延遲 = 200 + 900 + 1100 + 300 = 2500ms │
│ 優點：上下文完整；缺點：串行等待，延遲累加 │
│ │
│ 【並行融合】 │
│ 文字 ──────────────────────────┐ │
│ 視覺 ──────────────────────────┼──▶ LLM 綜合 │
│ 語音 ──────────────────────────┘ │
│ 總延遲 = max(200, 900, 1100) + 300 = 1400ms │
│ 優點：延遲取最長者；缺點：所有模態必須完成才能融合 │
│ │
│ 【條件路由融合（生產推薦）】 │
│ ┌─ 文字 ──▶ LLM（輕量確認）──▶ 已足夠回答？─▶ 是 ──▶ 直接回覆 │
│ │ │ │
│ │ 否 │
│ │ ▼ │
│ ├─ 視覺 ──────────────────────┐ │
│ │ ├──▶ LLM 融合推理 │
│ └─ 語音（若有）───────────────┘ │
│ │
│ 純文字查詢 P99: 180ms │
│ 需視覺 P99: 1100ms │
│ 全模態 P99: 1900ms │
└──────────────────────────────────────────────────────────────────┘
5.2 條件路由的決策邏輯
1class ModalRouter:
2 def route(self, request: MultiModalRequest) -> ProcessingPlan:
3 # 第一步：分析請求複雜度
4 modalities = request.detect_modalities()
5
6 if modalities == [TEXT]:
7 # 純文字，直走 LLM，P99 < 200ms
8 return TextOnlyPlan(fast_path=True)
9
10 if modalities == [TEXT, IMAGE]:
11 # 預估：圖片能回答這個問題嗎？
12 if self.is_chart_question(request.text):
13 return ParallelPlan(
14 stages=[VisionAnalysis(), TextGrounding()],
15 timeout_ms=1500
16 )
17
18 if AUDIO in modalities:
19 # 語音優先轉文字，再決定後續路由
20 return SequentialPlan(
21 first=ASRTranscription(), # 680ms
22 then=self.route_text_result # 遞迴路由
23 )
24
25 # 複雜多模態：並行處理 + 超時降級
26 return ParallelWithFallbackPlan(
27 parallel_stages=self.build_stages(modalities),
28 timeout_ms=3000,
29 fallback=TextOnlyFallback()
30 )
5.3 超時降級矩陣
| 視覺服務 | 語音服務 | 文件服務 | 系統行為 |
|---|---|---|---|
| 正常 | 正常 | 正常 | 全模態，P99 < 5s |
| 超時 | 正常 | 正常 | 跳過圖片，文字回覆，提示「圖片分析暫不可用」 |
| 正常 | 超時 | 正常 | 文字模式接受輸入，TTS 回覆不可用 |
| 正常 | 正常 | 超時 | 文件查詢降級為通用回覆，無 RAG 引用 |
| 全部超時 | 全部超時 | 全部超時 | 純文字 LLM，可用性維持 99.9% |
六、延遲優化：多模態管線的端對端延遲分解
6.1 延遲預算分配
總 SLA 目標：複合多模態查詢 P99 < 5000ms。逐層分配延遲預算：
| 層級 | 預算 | 實際 P99 | 優化前 P99 |
|---|---|---|---|
| 網路傳輸（上行） | 300ms | 220ms | 220ms |
| API Gateway 驗證 | 20ms | 12ms | 12ms |
| 模態路由決策 | 30ms | 18ms | 45ms |
| 視覺分析（含前處理） | 1200ms | 980ms | 1850ms |
| 文件 RAG 檢索 | 400ms | 310ms | 1200ms |
| LLM 融合推理（首 token） | 300ms | 210ms | 210ms |
| LLM 生成（完整回答） | 2000ms | 1680ms | 1680ms |
| 結果序列化 + 網路下行 | 200ms | 160ms | 160ms |
| 總計 | 4450ms | 3590ms | 5377ms |
視覺分析從 1850ms 優化到 980ms（-47%）是最大貢獻來源。
6.2 視覺服務延遲優化四招
招式 1：圖片快取（MD5 指紋）
相同圖片（同一張截圖被多個用戶上傳）直接返回快取結果，命中率在 B2B 場景達 34%（同公司員工上傳相同報告截圖）。節省 980ms 的視覺分析延遲。
招式 2：批次推理
等待最多 50ms 收集多個圖片請求後批次送入 GPU，Batch=8 時 GPU 吞吐提升 4.2 倍，平均延遲從 980ms → 720ms（但增加了 50ms 等待）。高峰期淨收益：-210ms。
招式 3：模型量化（INT8）
將視覺 Encoder 從 FP16 量化為 INT8：推理延遲 -28%（720ms → 518ms），準確率下降 < 1.5%（在可接受範圍）。
招式 4：Speculative Decoding（視覺部分）
使用小型視覺模型（ViT-B/32）先快速分類場景（45ms），再決定是否需要大模型（ViT-L/14）精細分析。簡單截圖（純文字截圖）只跑小模型，省去大模型調用，這類請求佔全量的 41%，平均延遲從 518ms → 220ms。
最終實測 P99（生產環境 3 個月平均）：
| 查詢類型 | 目標 P99 | 實際 P99 | 達標 |
|---|---|---|---|
| 純文字 | 800ms | 340ms | ✅ |
| 文字 + 截圖 | 3000ms | 2100ms | ✅ |
| 文字 + 圖表 | 3000ms | 2800ms | ✅ |
| 文字 + PDF（已索引） | 3000ms | 2400ms | ✅ |
| 語音 + 圖片 | 5000ms | 3900ms | ✅ |
| 語音 + PDF（首次） | 5000ms | 7200ms | ❌ 首次 PDF 超標 |
首次 PDF 上傳建索引（45–90s）需另外設計非同步流程，不計入即時查詢 SLA。
七、系列總結：19 個 Phase 的知識地圖與學習路線
我們來到了「AI 工程從零開始」系列的最後一站。從 Phase 1 的環境設置，走到今天的多模態 Capstone，這是一段真正的工程師成長旅程。讓我們做一次完整的知識地圖回顧。
7.1 完整知識地圖
AI 工程從零開始：19 Phase 知識地圖
════════════════════════════════════════════════════════════
╔══════════════════════════════════════╗
║ 【地基層】Phase 1–3：工程基礎 ║
║ ┌─────────┐ ┌─────────┐ ┌────────┐ ║
║ │Phase 1 │ │Phase 2 │ │Phase 3 │ ║
║ │環境設置 │ │Python │ │數學 │ ║
║ │Dev Loop │ │資料結構 │ │線代/ │ ║
║ │Docker │ │函數式 │ │機率/ │ ║
║ │Git/CI │ │程式設計 │ │最優化 │ ║
║ └─────────┘ └─────────┘ └────────┘ ║
╚══════════════════════════════════════╝
│
▼
╔══════════════════════════════════════╗
║ 【模型層】Phase 4–6：ML 基礎 ║
║ ┌─────────┐ ┌─────────┐ ┌────────┐ ║
║ │Phase 4 │ │Phase 5 │ │Phase 6 │ ║
║ │機器學習 │ │深度學習 │ │語音/ │ ║
║ │監督/非 │ │CNN/RNN │ │ASR/TTS │ ║
║ │監督學習 │ │訓練技巧 │ │聲學模型│ ║
║ └─────────┘ └─────────┘ └────────┘ ║
╚══════════════════════════════════════╝
│
▼
╔══════════════════════════════════════╗
║ 【LLM 層】Phase 7–9：大模型技術 ║
║ ┌─────────┐ ┌─────────┐ ┌────────┐ ║
║ │Phase 7 │ │Phase 8 │ │Phase 9 │ ║
║ │Transform│ │擴散模型 │ │強化學習│ ║
║ │架構原理 │ │GAN/影片 │ │RLHF/ │ ║
║ │注意力 │ │生成模型 │ │PPO/DPO │ ║
║ └─────────┘ └─────────┘ └────────┘ ║
╚══════════════════════════════════════╝
│
▼
╔══════════════════════════════════════╗
║ 【生產層】Phase 10–12：系統工程 ║
║ ┌─────────┐ ┌─────────┐ ┌────────┐ ║
║ │Phase 10 │ │Phase 11 │ │Phase 12│ ║
║ │API 設計 │ │RAG 架構 │ │評估體系│ ║
║ │版本管理 │ │向量索引 │ │Evals/ │ ║
║ │認證/限速│ │混合檢索 │ │基準測試│ ║
║ └─────────┘ └─────────┘ └────────┘ ║
╚══════════════════════════════════════╝
│
▼
╔══════════════════════════════════════╗
║ 【智慧層】Phase 13–15：Agent 技術 ║
║ ┌─────────┐ ┌─────────┐ ┌────────┐ ║
║ │Phase 13 │ │Phase 14 │ │Phase 15│ ║
║ │單一Agent│ │多 Agent │ │Prompt │ ║
║ │工具使用 │ │協調編排 │ │Engineering│ ║
║ │ReAct │ │通信協議 │ │CoT/Few │ ║
║ └─────────┘ └─────────┘ │Shot │ ║
║ └────────┘ ║
╚══════════════════════════════════════╝
│
▼
╔══════════════════════════════════════╗
║ 【維運層】Phase 16–18：生產維運 ║
║ ┌─────────┐ ┌─────────┐ ┌────────┐ ║
║ │Phase 16 │ │Phase 17 │ │Phase 18│ ║
║ │監控可觀 │ │推論服務 │ │安全 │ ║
║ │測性 │ │vLLM/ │ │對齊/ │ ║
║ │Tracing │ │Triton │ │防護欄 │ ║
║ └─────────┘ └─────────┘ └────────┘ ║
╚══════════════════════════════════════╝
│
▼
╔══════════════════════════════════════╗
║ 【整合層】Phase 19：多模態 Capstone ║
║ ┌─────────┐ ┌─────────┐ ┌────────┐ ║
║ │Part 1 │ │Part 2 │ │Part 3 │ ║
║ │視覺理解 │ │語音整合 │ │端對端 │ ║
║ │VLM/OCR │ │串流語音 │ │系統設計│ ║
║ │圖表分析 │ │多輪對話 │ │← 你在這│ ║
║ └─────────┘ └─────────┘ └────────┘ ║
╚══════════════════════════════════════╝
7.2 技能矩陣：每個 Phase 建立了什麼能力
| Phase | 技術領域 | 核心能力 | 關鍵輸出物 |
|---|---|---|---|
| 1 | 工程基礎 | 可重現的開發環境 | Dockerfile + CI Pipeline |
| 2 | Python 工程 | 生產級 Python 程式設計 | 類型安全的資料處理模組 |
| 3 | 數學基礎 | 理解梯度下降的直覺 | 從零手寫反向傳播 |
| 4 | ML 基礎 | 監督 / 非監督學習全貌 | 特徵工程 + 模型選型決策 |
| 5 | 深度學習 | CNN/RNN 架構設計 | 圖像分類 + 序列預測系統 |
| 6 | 語音模型 | ASR/TTS 端對端理解 | 語音識別系統 |
| 7 | Transformer | 注意力機制底層原理 | 從零實作 Transformer |
| 8 | 生成模型 | 擴散模型 / GAN 應用 | 圖像生成 Pipeline |
| 9 | RL / RLHF | 強化學習與 LLM 對齊 | PPO / DPO 訓練理解 |
| 10 | API 設計 | 生產級 LLM API 工程 | 版本化 API + Rate Limiting |
| 11 | RAG | 混合檢索增強生成 | 語意 + 關鍵字混合 RAG |
| 12 | 評估 | 系統性 Eval 框架 | LLM 評測基準 Pipeline |
| 13 | Agent | 工具使用 + ReAct | 能自主解決任務的 Agent |
| 14 | Multi-Agent | 多智慧體協調 | Supervisor + Worker 編排 |
| 15 | Prompt Eng. | 系統化提示工程 | CoT + Few-Shot 模板庫 |
| 16 | 監控 | LLM 系統可觀測性 | Tracing + 指標 + 告警 |
| 17 | 推論服務 | GPU 服務 + 自動擴縮 | vLLM 服務 + HPA 配置 |
| 18 | 安全 | LLM 安全與對齊 | 防護欄 + PII 偵測 |
| 19 | 多模態 | 端對端多模態系統 | 本文：完整 Capstone |
7.3 給每一位走到這裡的工程師
如果你從 Phase 1 跟著學到 Phase 19，你已經走過了一條許多工程師花了 3–5 年才走完的路。這條路不只是「學了很多技術」——你學到的是一種思維方式：
從單點技術到系統思考。Phase 1–6 讓你理解每個組件是什麼；Phase 7–12 讓你理解組件如何組合；Phase 13–18 讓你理解系統在真實負載下如何表現；Phase 19 讓你把所有東西組合成一個真實的系統。
從「能跑就好」到「可量測的 SLA」。當你知道 P99 延遲的意義、知道 GPU 使用率 23% vs 78% 意味著什麼成本差異、知道為什麼 RAG 的 chunk size 選 512 而不是 256——這些具體數字的背後是工程師的判斷力，不是憑感覺。
從學習者到決策者。每個「為什麼選 X 不選 Y」都在訓練你的決策肌肉。真實工程師的日常不是實現一個最優解，而是在無數個「還好」和「稍微差一點」之間，根據當前的約束條件（團隊規模、預算、時間）做出「現在最合理」的選擇。
這個系列不是終點，而是一個新起點。你現在有了足夠的基礎地圖，知道從哪裡出發去深挖。AI 這個領域每六個月就會出現讓你重新思考的東西——保持好奇心，保持那個「這個設計為什麼這樣，有沒有更好的方式」的質疑習慣，這才是一個 AI 工程師最重要的護城河。
八、為什麼選 X 不選 Y
決策 1：模態路由 vs 全模態直送 LLM
| 選擇 | 選 X（條件路由）的理由 | 不選 Y（全模態直送）的理由 |
|---|---|---|
| 條件路由 vs 全模態直送 | 純文字查詢（佔 58%）P99 從 4200ms → 180ms；成本節省 74% | 全部打包給 LLM：所有請求都付視覺 token 費用，$0.03→$0.12/次 |
翻轉條件：若 LLM token 成本降至 $0.0001/K（未來趨勢），全模態直送的成本差距縮小，可考慮簡化為單一路徑。
決策 2：異步佇列 vs 同步 API（長任務）
| 選擇 | 選 X（異步佇列）的理由 | 不選 Y（同步 API）的理由 |
|---|---|---|
| 異步 vs 同步 | PDF 處理 45–90s，HTTP 連接 30s 上限必然 Timeout；佇列天然提供削峰填谷 | 同步：僅適用於 < 5s 完成的任務；PDf 50 頁場景完全不可行 |
翻轉條件：若 PDF 處理可在 < 3s 完成（未來更快模型），且用戶可以同步等待，可回歸同步 API 降低複雜度。
決策 3：vLLM vs TGI（文字推論框架）
| 選擇 | 選 X（vLLM）的理由 | 不選 Y（TGI）的理由 |
|---|---|---|
| vLLM vs TGI | PagedAttention 使 KV Cache 記憶體效率提升 3x；Continuous Batching 吞吐高 40%；工業界採用率高、社群活躍 | TGI：Flash Attention 整合佳，但 KV Cache 管理較不靈活；Quantization 支援不如 vLLM 全面 |
翻轉條件：若使用 Mistral 系列模型且需要極致的量化效能，TGI 的整合深度有優勢。
決策 4：Qdrant vs Pinecone（向量資料庫）
| 選擇 | 選 X（Qdrant）的理由 | 不選 Y（Pinecone）的理由 |
|---|---|---|
| Qdrant vs Pinecone | 可自建（節省 $800–2000/月 Pinecone 費用）；支援 Payload 過濾（租戶隔離）；Rust 實作效能佳，P99 查詢 8ms | Pinecone：全託管無維運；但無法在 Pod 內部署，跨 VPC 延遲 +15ms；按向量數計費在大規模時昂貴 |
翻轉條件：< 5 人工程團隊、< 10M 向量、無自建能力時，Pinecone 的託管省心價值超過成本差距。
決策 5：串流 ASR（增量） vs 批次 ASR（完整音訊後識別）
| 選擇 | 選 X（串流 ASR）的理由 | 不選 Y（批次 ASR）的理由 |
|---|---|---|
| 串流 vs 批次 | 用戶說話過程中即時識別，總延遲節省 280ms；配合 Speculative LLM 可再省 120ms | 批次 ASR 準確率高 3–5%（無斷句錯誤）；實作複雜度低 10 倍 |
翻轉條件：若場景是長篇錄音分析（會議記錄、播客轉錄），延遲不重要，批次 ASR 的準確率優勢更重要，應選批次。
決策 6：自建 Fusion Engine vs LangChain/LlamaIndex 編排
| 選擇 | 選 X（自建融合引擎）的理由 | 不選 Y（LangChain）的理由 |
|---|---|---|
| 自建 vs 框架 | 完整控制超時、降級、模態權重；Debug 時堆疊追蹤清晰；無隱藏抽象層的延遲開銷（LangChain 每次 Chain 呼叫 +15–30ms overhead） | LangChain：快速 POC 很方便；但在高流量生產環境，抽象層的不透明性使效能調優困難，且版本升級常有 Breaking Change |
翻轉條件：POC 階段或 < 1000 QPS 的小規模部署，LangChain 的開發速度優勢遠超自建成本，應優先選用。
九、系統效應：多模態 vs 純文字系統的能力對比
9.1 功能覆蓋率對比
| 業務場景 | 純文字 LLM | 多模態系統 | 提升幅度 |
|---|---|---|---|
| 財務圖表解讀 | 0%（無法處理） | 82% 準確率 | ∞ |
| PDF 報告分析（含圖） | 僅文字部分（~60% 內容） | 全量（文字+圖表） | +40% 覆蓋 |
| 語音查詢支援 | 0% | 支援，首音訊 < 600ms | ∞ |
| 截圖問題排查 | 0% | 93% 識別率 | ∞ |
| 純文字 Q&A | ✅ P99 180ms | ✅ P99 180ms（路由優化後相同） | 持平 |
9.2 用戶體驗指標
| 指標 | 純文字系統 | 多模態系統 | 差異 |
|---|---|---|---|
| 用戶會話長度（平均） | 4.2 輪 | 7.8 輪 | +86% |
| 7 日留存率 | 31% | 54% | +74% |
| NPS 分數 | 38 | 67 | +76% |
| 每用戶月均使用次數 | 8.3 次 | 19.7 次 | +137% |
| 轉換率（Free → Paid） | 12% | 23% | +92% |
9.3 成本與效率
| 維度 | 純文字系統 | 多模態系統 | 備注 |
|---|---|---|---|
| 每請求平均成本 | $0.008 | $0.031 | 多模態高 3.9x |
| 每月基礎設施費用（50K MAU） | $2,200 | $8,400 | |
| 工程師人力（維運） | 0.5 人 | 2.5 人 | |
| 客戶 ARPU（月） | $45 | $112 | +149% |
| 邊際貢獻率 | 68% | 61% | 多模態略低 |
| 客戶 LTV（預估 24 個月） | $890 | $2,340 | +163% |
結論：多模態系統的邊際貢獻率略低（61% vs 68%），但客戶 LTV 高出 163%，在 B2B SaaS 場景下 ROI 非常顯著。
十、面試答題要點
「這個多模態 BI 平台我會用條件路由融合架構來設計，而非讓所有請求都走全模態管線。在 Phase 1（POC）直接用 GPT-4V API 驗證，月成本控制在 $500 以下；Phase 2（10K–200K 用戶）引入異步佇列分離視覺/語音/文件三條處理路徑，PDF 大檔案改為 RAG 策略後 token 成本降低 73%；Phase 3（500K+ 用戶）在模態路由器前加輕量分類器，58% 的純文字查詢直接走 vLLM 快速路徑，P99 從 4200ms 降至 180ms。語音的三項串流優化（增量 ASR + Speculative LLM + TTS 並行）使端對端語音回應 P99 從 2620ms 降至 2020ms。不選 LangChain 做融合編排，是因為在 5000 QPS 的生產環境，它的抽象層增加 15–30ms overhead 且難以精確控制降級邏輯；取而代之自建 Fusion Engine，讓每個模態超時都能精確降級而非全鏈路報錯。整個系統設計的核心原則是：讓 99% 的請求比用戶預期更快，讓剩下 1% 的慢請求也有可預期的降級體驗。」
十一、系列完結導航
← Phase 19 Part 2：語音介面與多輪多模態對話系統
🎉 「AI 工程從零開始」系列圓滿完結！
你已經走完了 19 個 Phase、63 篇文章的完整旅程。
← 回到 Phase 1：從零開始的 AI 工程環境設置 | 查看完整系列列表 →
本文為「AI 工程從零開始」系列第 19 Phase Part 3（系列終篇）。感謝每一位陪伴這段旅程的讀者——你們的好奇心與堅持，是這個系列最大的意義。
