AI 工程從零開始｜Phase 19 Part 3：Capstone — 多模態 AI 應用端對端實作與系列總結

大多數人：把 GPT-4V 的 API 呼叫包一層，傳圖片進去，輸出文字就叫「多模態應用」。 真正的做法：從模態路由、串流融合、延遲預算分配到降級策略，每一層都有可量測的 SLA。 差距不在模型能力，而在系統設計——隨機拼接各模態模型的 P99 延遲 8.4s vs 精心設計的多模態管線 1.9s，7 日留存率相差 1.7 倍。 本文是 AI 工程從零開始系列的 Capstone 收官之作，從 POC 到 Scale，完整走完多模態 AI 平台的工程之路。

這篇給已經分別做過文字、視覺、語音服務，現在要把它們放進同一個產品的工程師看，也是整個系列的收官。全文用一個貫穿的參考專案：B2B SaaS 的商業智慧平台，AI 助理要同時分析 PDF 財務報告裡的圖表、上傳的截圖、語音指令與 Excel 數據；目前 50K 月活、高峰 3,000 人同時在線，六個月後要擴到 500K。讀完你會能為延遲差了一個量級的模態（文字 200ms、圖片 800ms、語音 1200ms）設計路由與融合策略、分配端對端延遲預算、在某個模態服務降級時維持整體可用性，並回頭看清 19 個 Phase 之間的關係。本文以參考設計呈現，規模與數字為示意估算，而非某個真實專案的量測結果。

一、專案目標：多模態商業智慧分析平台需求

這個 Capstone 專案整合了本系列所有核心技術：Transformer 與 LLM（Phase 7、10）、推論與 RAG（Phase 11）、Agent 與工具整合（Phase 13–14）、推論服務與成本優化（Phase 17）、語音處理（Phase 6）、視覺與多模態理解（Phase 4、12），最終構建一個真實可用的多模態商業智慧分析平台。

1.1 功能需求

輸入能力

輸出能力

• 文字回覆（Streaming）：P50 首字元 < 300ms
• 圖表生成：含數字標注，< 3s
• 語音回應（TTS）：P50 首音訊塊 < 600ms
• 引用來源：每個聲明標注文件頁碼與段落

1.2 非功能需求

• 可用性：99.9%（每月宕機 < 44 分鐘）
• 延遲 SLA：簡單文字查詢 P99 < 800ms；多模態複合查詢 P99 < 5s
• 安全：租戶數據完全隔離；PII 自動偵測與遮蔽
• 成本上限：每次多模態請求成本 < $0.08（含模型推論、儲存、頻寬）

二、何時該升級：從單體 API 組合到模態佇列、再到路由與融合層的觸發條件

最省事的起點是一個 FastAPI 單體，文字、圖片、語音三條路由全部打同一個多模態 API（圖片直送、語音先過 Whisper API），檔案暫存在 S3：一兩個工程師、一兩個月就能驗證多模態理解的品質、把端對端流程跑通並開始收用戶回饋。該升級的訊號有四個，任何一個成立就該動手：50MB 的 PDF 在同步 API 的 30 秒上限下必然 timeout；突發流量沒有佇列緩衝，直接打垮後端；所有模態走同一個端點，看不出哪個模態在燒錢；API 被限速時沒有降級路徑，全站報錯。這時把長任務改成 Redis / SQS 佇列加上按模態分離的 Worker（Vision / Document / Speech），文字回覆走 SSE 串流，PDF 改成語意分塊加 RAG 檢索（§三），任務狀態進 PostgreSQL；各模態從此可以獨立擴縮，首字元延遲與 PDF 分析成本都會明顯下降。

第二道門檻是跨模態的請求開始成為主流。症狀是：客戶端得自己組合多個 API 呼叫、上下文在不同 Worker 之間無法共享、固定數量的 Worker 在高峰期讓佇列積壓、而大半的純文字查詢卻在為視覺與語音服務的延遲買單。這時在入口加模態路由器（§五：偵測模態組合、預估成本、簡單文字查詢走快速路徑）、在出口加 Fusion Engine 統一收集並行結果與組裝 context，文字服務換成 vLLM 自建以守住首 token 延遲，各模態服務接上 HPA，並以 Namespace 做租戶隔離。這一層的工程量是前一層的數倍，只有在跨模態請求比例與租戶數都上來之後才值得。

三、圖文理解管線：截圖/圖表/文件的多模態解析

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%，需要專項增強：

兩階段提取策略：

1. 結構理解（GPT-4V）：識別圖表類型、軸標籤、圖例、趨勢 → 延遲 700ms，成本 $0.02
2. 數值提取（專用 OCR + 座標回歸）：精確提取數值點 → 延遲 300ms，成本 $0.001

組合後準確率：92.4%（vs 純 GPT-4V 的 58.1%）

3.3 PDF 多層次解析

大型 PDF（50 頁財務報告）的處理是延遲最大的挑戰：

生產環境採用混合策略：封面頁、目錄頁、圖表頁全量解析並建立視覺索引，其餘文字頁切塊後存入向量資料庫（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 → LLM → TTS 的串接架構。若延遲是第一優先、且可以接受把語音理解與生成交給同一個供應商，直接使用語音對語音（speech-to-speech）的即時模型 API，可省掉兩次模態轉換與中間的文字往返，是壓低 2.5s 預算最直接的手段；代價是較難插入文字層的 guardrails、RAG 與逐段稽核。

五、模態融合策略：並行 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 超時降級矩陣

六、延遲優化：多模態管線的端對端延遲分解

6.1 延遲預算分配

總 SLA 目標：複合多模態查詢 P99 < 5000ms。逐層分配延遲預算：

示意估算，非實測數據。

視覺分析從 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（參考設計的目標與估算，非實測）：

示意估算，非實測數據。

首次 PDF 上傳建索引（45–90s）需另外設計非同步流程，不計入即時查詢 SLA。

七、系列總結：19 個 Phase 的知識地圖與學習路線

我們來到了「AI 工程從零開始」系列的最後一站。從 Phase 1 的線性代數與機率，走到今天的多模態 Capstone，這是一段真正的工程師成長旅程。讓我們做一次完整的知識地圖回顧。

7.1 完整知識地圖

AI 工程從零開始：19 Phase 知識地圖（43 篇）
════════════════════════════════════════════════════════════

【地基層】Phase 1–3：數學與模型基礎
  Phase 1   數學：線性代數與微積分、機率與統計
  Phase 2   傳統機器學習、集成學習與最佳化
  Phase 3   深度學習核心：從第一原理構建神經網路
              │
              ▼
【感知層】Phase 4–6：視覺、語言、語音
  Phase 4   電腦視覺：CNN、偵測與分割、VLM / 3D / 世界模型
  Phase 5   NLP：文字基礎、Seq2Seq 與注意力、BERT 與問答
  Phase 6   語音：ASR、TTS 與音訊模型
              │
              ▼
【生成層】Phase 7–9：Transformer、生成模型、強化學習
  Phase 7   Transformer 架構、訓練策略與架構變體
  Phase 8   擴散模型、GAN 與影片生成
  Phase 9   強化學習基礎與 RLHF
              │
              ▼
【LLM 工程層】Phase 10–12：從頭構建到多模態
  Phase 10  從頭構建 LLM：Tokenization、預訓練、微調
  Phase 11  推論工程、RAG 系統與 LLM 評估
  Phase 12  ViT 與多模態融合、多模態 Agent 與電腦操作
              │
              ▼
【Agent 層】Phase 13–16：工具、Agent、自主、多 Agent
  Phase 13  MCP 與 API 整合、工作流程編排
  Phase 14  Agent 迴圈與記憶、規劃、框架、生產化
  Phase 15  長時程自主系統、自我改進與安全技術棧
  Phase 16  多 Agent 協調、湧現與集體智慧
              │
              ▼
【生產層】Phase 17–18：基礎設施、安全與治理
  Phase 17  推論服務架構、可觀測性、成本優化
  Phase 18  AI 技術安全、AI 治理與倫理
              │
              ▼
【整合層】Phase 19：三個 Capstone
  Part 1    企業級 RAG 知識庫系統
  Part 2    生產級 AI Agent 產品
  Part 3    多模態 AI 應用與系列總結  ← 你在這

7.2 技能矩陣：每個 Phase 建立了什麼能力

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

兩個選擇用文字交代。長任務走異步佇列而不是同步 API，§二 已經說清楚：PDF 處理 45–90 秒，HTTP 連線 30 秒上限必然 timeout，佇列還順便提供削峰填谷；只有任務能在幾秒內完成、而且用戶願意同步等待時，才值得為了簡單回到同步。向量資料庫選 Qdrant 而不是 Pinecone：可自建、Payload 過濾天然對應租戶隔離、Rust 實作的查詢延遲低；工程團隊 < 5 人、向量 < 10M、沒有自建能力時，Pinecone 的託管省心價值超過成本差距——完整比較見 Phase 19 Part 1 §八 決策一。下面四個決策才真的需要權衡。

決策 1：模態路由 vs 全模態直送 LLM

翻轉條件：若 LLM token 成本降至 $0.0001/K（未來趨勢），全模態直送的成本差距縮小，可考慮簡化為單一路徑。

決策 2：vLLM vs TGI（文字推論框架）

翻轉條件：若團隊已深度使用 Hugging Face 的模型託管與 Inference Endpoints，或主力模型剛好在 TGI 的優化清單上，TGI 的整合深度有優勢。

決策 3：串流 ASR（增量） vs 批次 ASR（完整音訊後識別）

翻轉條件：若場景是長篇錄音分析（會議記錄、播客轉錄），延遲不重要，批次 ASR 的準確率優勢更重要，應選批次。

決策 4：自建 Fusion Engine vs LangChain/LlamaIndex 編排

翻轉條件：POC 階段或 < 1000 QPS 的小規模部署，LangChain 的開發速度優勢遠超自建成本，應優先選用。

九、系統效應：多模態 vs 純文字系統的能力對比

9.1 功能覆蓋率對比

示意估算，非實測數據。

9.2 用戶體驗指標

示意估算，非實測數據。

9.3 成本與效率

示意估算，非實測數據。

結論：在這組示意數字下，多模態系統的邊際貢獻率略低（61% vs 68%），但客戶 LTV 高出 163%，在 B2B SaaS 場景下 ROI 非常顯著。

十、系列導航

本文為「AI 工程從零開始」系列 Phase 19 Part 3，也是系列終篇：19 個 Phase、43 篇文章到此走完。感謝每一位陪伴這段旅程的讀者。系列總覽：AI 工程從零開始 。