https://yennj12.js.org/yennj12_blog_V4/tags/multimodal/Recent content in Multimodal 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-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-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 專案整合了本系列所有核心技術：語言模型（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 PDF 財務報告、合約文件 1–50MB 2000–8000ms 語音 口頭指令、語音備忘 10–120 秒音訊 800–2000ms 結構化資料 Excel/CSV 數據 < 10MB 300–600ms 輸出能力