M07.10｜AI 應用技術選型指南：NLP、CV、多模態怎麼選
問題決定技術，不是技術決定問題
本講學習重點
技術選型的第一原則：先定義業務問題，再選技術——反過來必然失敗
NLP 適合：非結構化文字處理、情感分析、摘要、翻譯、意圖辨識、文件分類
CV 適合：圖片/影片中的物件偵測、分類、瑕疵偵測、人臉辨識、姿態估計
多模態適合：輸入包含多種資料形式、或問題需要跨模態推理才能解決
表格機器學習（Tabular ML）：結構化資料預測（欺詐偵測、信用評分）通常優先選 XGBoost 而非深度學習
自建：需要高度客製化、資料隱私敏感、長期核心競爭力、具備 AI 團隊能力
API：需快速驗證、問題通用、預算有限、長期不確定性高
TRL 1–3：基礎研究，技術風險極高；TRL 7–9：成熟部署，風險低
TCO 隱藏成本：資料標注、模型維護、效能監控、版本更新、失敗處理
整合複雜度：延遲要求、資料格式轉換、安全合規、現有系統相容性
🎙️ Podcast（中文）
一句話搞懂
AI 技術選型就像選手術工具：外科醫生不會因為機器人手術「很先進」就在所有手術都用它——要先看病人的狀況（業務問題）、手術的複雜度（任務需求）、醫院的設備能力（團隊和預算），然後選出最適合的工具；NLP、CV、多模態、傳統機器學習各有適用場景，問題決定技術，不是技術決定問題。
白話解說
選型失敗的常見起點：從技術出發而非問題出發
台灣企業在 AI 導入過程中，最常見的選型失敗模式不是「選了錯誤的演算法」，而是更根本的錯誤：從技術出發而非從問題出發。例如：「我們聽說 AI 影像辨識很厲害，要不要做一個？」然後花了三個月和幾百萬預算，才發現業務上真正的痛點其實是非結構化的客戶電話錄音分析，應該用 NLP 而非 CV；或者「我們要用最新的 GPT-4 API！」但評估後發現，80% 的業務問題只是結構化表格資料的分類預測，XGBoost 三天就能搞定，效果還更好。
技術選型的第一步是把業務問題翻譯成 AI 問題的規格書：
- 輸入是什麼類型的資料？（文字、圖片、聲音、影片、結構化表格、多種混合）
- 輸出是什麼？（分類標籤、連續數值、生成的文字、偵測框、結構化資料）
- 精度要求是什麼？（「差不多對就好」vs「一個字都不能錯」）
- 延遲要求是什麼？（使用者在線等待 vs 離線批次處理）
- 資料量有多少？（幾百筆 vs 幾百萬筆）
- 資料的隱私敏感度？（可以送上雲端 vs 必須在地部署）
把這些問題釐清後，才能進入技術方案的選擇。
四大 AI 技術類型的適用場景地圖
不同的 AI 技術類型有其最佳的適用領域，錯誤配對是選型失敗的主要原因。
自然語言處理（NLP） 的核心是處理人類的語言文字——理解語意、生成文字、分類文件、翻譯語言。適合 NLP 的業務問題特徵：輸入資料主要是非結構化文字（客服對話、合約、新聞、評論、電子郵件）；任務需要理解文字的語意和意圖（而非只是關鍵字搜尋）；需要生成流暢的文字輸出（摘要、回覆草稿、翻譯）。典型 NLP 任務：情感分析、意圖辨識、命名實體辨識、文件分類、自動摘要、機器翻譯、問答系統。
電腦視覺（CV） 的核心是讓機器從圖片和影片中「看懂」視覺資訊。適合 CV 的業務問題特徵：輸入資料是圖片、影片或視訊串流；任務需要辨識視覺中的物件、場景、姿態、異常；判斷依據是視覺特徵而非語言。典型 CV 任務：物件偵測（有沒有瑕疵？是什麼）、圖片分類、語義分割（圖中每個像素是什麼）、人臉辨識、姿態估計、影片行為識別。
多模態 AI 的核心是整合多種資料形式進行聯合理解和推理。適合多模態的業務問題特徵：問題的正確答案需要同時參考多種模態的資訊；單一模態的資訊對解決問題不充分；典型多模態任務：圖文混合問答（看著圖片回答問題）、多模態文件理解（同時理解文字和圖表）、視覺問答、影片理解與描述。
結構化資料機器學習（Tabular ML） 往往是被忽視但最務實的選項。當業務資料是有固定欄位的結構化表格（客戶資料、交易紀錄、感測器讀值、財務報表），任務是預測一個數值或類別（會不會流失、會不會詐欺、下個月的銷售量），這類問題通常不需要深度學習或大型語言模型——梯度提升樹（XGBoost、LightGBM） 在大多數結構化預測任務上仍是準確率高、速度快、可解釋的首選。台灣許多企業急著引入深度學習，卻忽略了業務上 80% 的預測問題其實是表格資料問題，傳統機器學習足以應付。
自建 vs 購買 vs API：三條路線的選擇框架
確定了技術類型後，下一個關鍵決策是：自行開發模型（Build）、購買商業 AI 軟體（Buy）、還是調用雲端 API（API）？這三條路線沒有普遍正確的答案，取決於四個核心維度。
客製化需求：如果業務問題高度獨特（如識別某個特定工廠的特定產品表面的特定類型瑕疵），通用的 API 或商業軟體可能無法滿足，需要自建客製化模型；如果業務問題是通用的（如英文情感分析、通用物件偵測），成熟的 API 和開源模型通常已足夠。
資料隱私與合規：如果業務資料包含個人敏感資訊（醫療記錄、財務資料）或商業機密（設計圖、未發布產品），不能傳送到第三方雲端 API，必須選擇在地部署（On-premise）方案——要麼自建模型、要麼購買支持本地部署的商業 AI 軟體。台灣個人資料保護法和 GDPR 在這方面的限制需要法遵部門確認。
預算與時間：自建需要 AI 工程師薪資、GPU 基礎設施、模型訓練電費、長期維護人力——前期投入高但長期邊際成本低；API 沒有前期固定成本，按使用量計費，適合驗證階段或使用量不穩定的場景；商業軟體通常是訂閱制（年費），介於兩者之間，但前期評估和整合成本不低。
團隊能力：自建需要具備 AI 工程師（懂模型訓練、部署、監控）；API 的門檻最低（有 API Key 即可），但整合進現有系統仍需要一般工程師能力；商業軟體通常提供培訓，但需要投入學習和維護成本。一個沒有 AI 工程師的中小企業，貿然選擇「自建」往往是最貴且最慢的路。
台灣中小企業的務實建議：以「API 先行，驗證後再決定是否自建」的策略，先用 Google Cloud、Microsoft Azure、AWS 的 AI API 快速驗證業務假設，確認這個 AI 能解決的問題有足夠商業價值，再評估是否值得投入自建成本。
技術成熟度：避免成為第一個吃螃蟹的人
每個 AI 技術都有其技術成熟度等級（Technology Readiness Level, TRL），從 TRL 1（基礎研究，只是論文上的概念）到 TRL 9（完全成熟，已在多個商業環境大規模部署）。選型時，TRL 等級決定了技術風險：
TRL 1–3（研究階段）：只存在於學術論文或實驗室原型，業務導入風險極高，通常不適合企業採用，除非是資源充足的大型企業的前瞻性研究投資。
TRL 4–6（概念驗證到試點）：有初步的概念驗證或小規模試點，但在真實商業環境的穩定性未完全確認。選型時需做好「不一定能成功」的心理和預算準備，建議做小規模試驗而非全面部署。
TRL 7–9（成熟部署）：已在多個真實商業環境驗證，有成熟的工具鏈、社群支援、明確的最佳實踐。GPT-3.5/4 的文字 API（TRL 9）、YOLOv8 物件偵測（TRL 9）、Whisper 語音辨識（TRL 8–9）都屬於這個等級。企業導入 AI 應以 TRL 7 以上的技術為主力，TRL 4–6 的技術只用於探索性試驗。
TCO 和整合複雜度：最常被低估的決策因素
技術選型文件中，總擁有成本（Total Cost of Ownership, TCO） 和整合複雜度（Integration Complexity） 是最常被低估的兩個因素，也是導致 AI 項目超預算和延期的主因。
TCO 的隱藏成本包括：資料收集和標注成本（高品質訓練資料往往比模型訓練本身更貴）、基礎設施成本（GPU 訓練費用、線上推理的 API 費用或自建 GPU 服務器的折舊和電費）、模型維護成本（資料分佈漂移時需要重新訓練、API 版本更新帶來的相容性問題）、失敗處理成本（模型出錯時的業務影響和修復成本）、人力成本（持續的模型監控、效能評估、版本管理）。台灣企業的 AI 預算規劃中，「第一年」通常只算了技術費用，忽略了「第二年開始的維護費用」往往是第一年的 50–70%。
整合複雜度的關鍵維度包括：延遲要求（AI 推理需要 5 秒，但業務要求 1 秒內回應，需要額外的快取、非同步設計或模型壓縮）、資料格式轉換（現有系統的資料格式和 AI 模型需要的輸入格式不一致，需要 ETL 工程）、安全合規（AI 模型的輸入輸出是否需要加密、稽核日誌、存取控制）、現有系統相容性（AI 服務如何整合進現有的 ERP、CRM 或資料庫架構）。一個業界常見的經驗法則：AI 模型開發只佔整個 AI 項目工作量的 20–30%，其餘 70–80% 是資料工程、系統整合、測試、部署和維護。
應用場景
| 業務問題類型 | 推薦技術 | 自建/買/API 傾向 | 注意事項 |
|---|---|---|---|
| 客服對話意圖辨識 | NLP（文字分類） | API 或買 | 台灣繁體中文支援品質需評估 |
| 工廠表面瑕疵偵測 | CV（物件偵測/分類） | 自建（高客製化）或買 | 需大量客製化標注資料 |
| 合約重點條款擷取 | NLP（資訊擷取）+ OCR | 自建或買 | 法律語言專業知識難用通用模型 |
| 電商商品圖文搜尋 | 多模態（CLIP 類） | API 或自建 | 台灣電商商品的中文描述搭配圖片 |
| 信用風險評分 | 表格 ML（XGBoost） | 自建（資料敏感） | 可解釋性要求（法規要求說明拒貸原因） |
| 影片內容安全審核 | CV + NLP（多模態） | API 或買 | 即時性要求高、規模大 |
| 醫療影像輔助診斷 | CV（醫療專用） | 買（需 TFDA 認證） | 監管要求極嚴，需臨床驗證 |
| 財報關鍵數字擷取 | NLP + OCR + 規則 | 自建或買 | 數字精確度要求高，幻覺不可接受 |
常見誤區
誤區 1：「最新的技術一定最好，選型就選最先進的」
技術選型的目標是用最適合的工具解決業務問題，而不是使用最先進的技術。這個誤區在台灣企業的 AI 導入專案中極為普遍：GPT-4 剛出來就要求用 GPT-4、Gemini Ultra 一出來就要換 Gemini Ultra，不管業務問題是否真的需要這個等級的模型。一個典型的反例：某製造業客戶要做「產品分類標籤是否完整」的自動化判斷，需要從產品圖片判斷是否有貼上特定格式的標籤。這個問題用 2018 年的 ResNet-50 配合幾百張訓練圖就能解決（準確率 98%），部署在邊緣設備上即時運行，成本接近零。如果選用 GPT-4V API，每次查詢費用是 ResNet 的數千倍，且需要連網路，在工廠網路受限環境下根本無法部署。選型的正確姿勢是從「能解決問題的最簡單技術」出發，在準確率不足時再逐步升級，而非一開始就選最複雜最貴的方案。
誤區 2：「API 費用就是 AI 導入的總成本，計算 ROI 只需要考慮 API 訂閱費」
這是最危險的預算誤估。API 費用只是 TCO 的冰山一角，在資料準備階段的成本往往遠超過模型本身：一個需要 10,000 張人工標注訓練圖片的 CV 專案，如果每張標注費用是 50 元（台灣外包標注的市場行情），光標注費用就是 50 萬元，還不包含標注品質管理、重工、和資料管理工程師的人力成本。整合工程也是隱藏大頭：讓 AI API 整合進現有 ERP 系統，往往需要 3–6 個月的工程開發，以一位工程師月薪 10 萬元計算，就是 30–60 萬元的工程成本，但預算提案中往往只寫了「API 月費 5,000 元」。正確的 TCO 計算應包含：資料收集標注（一次性）、模型訓練或整合工程（一次性）、API/基礎設施費用（每月持續）、模型維護和重訓（每季或每年）、效能監控工具（每月）、以及因 AI 錯誤導致的業務損失風險（需估計概率和影響）。
誤區 3：「選好了技術、上了雲端 API，就不需要 AI 工程師了」
雲端 API 確實大幅降低了「訓練模型」的門檻，但 AI 工程的複雜度並未消失，只是轉移了。使用 API 之後，企業仍然需要工程能力應對：Prompt 工程和維護（讓 API 產出符合業務需求的結果，需要持續調整和版本管理）；效能監控（定期抽查 AI 輸出品質，偵測資料分佈漂移——今天的客服對話主題和三個月前不同，情感分析的準確率悄悄下降了）；錯誤處理和回退機制（API 服務中斷、回應超時、或輸出不符格式時的備援設計）；API 版本升級管理（OpenAI 宣布 GPT-3.5-turbo-0301 在某日停止服務，需要遷移到新版本並重新驗證輸出品質）；成本控制（使用量暴增時的自動告警、Token 數控制、快取設計以避免重複呼叫）。現實中，企業選擇了 API 路線後，仍然需要至少一名懂 AI 工程的人員長期維護——只是從「訓練模型的 AI 科學家」變成「整合和維護 AI 系統的 AI 工程師」，需求性質改變，需求本身並未消失。
小練習
練習 1：技術選型決策樹
以下五個業務場景，請根據「輸入資料類型 → 任務性質 → 精度/延遲/隱私需求 → 選型建議」的決策框架，填寫推薦技術類型、部署方式，以及你最擔心的一個風險：
| 場景 | 推薦技術類型 | 部署方式（API/買/自建） | 最大風險 |
|---|---|---|---|
| A. 連鎖超商每日處理 5,000 張紙本發票，需自動擷取金額、日期、統編並匯入 ERP | ？ | ？ | ？ |
| B. 醫療院所監控 ICU 病患的呼吸節律，攝影機畫面每 100 毫秒偵測一次異常呼吸 | ？ | ？ | ？ |
| C. 線上零售商想為客戶提供「上傳照片找相似商品」的購物功能 | ？ | ？ | ？ |
| D. 銀行信用卡部門要預測每筆交易（結構化資料：金額、地點、時間、商戶類型）是否為詐騙 | ？ | ？ | ？ |
| E. 新創公司想做一個「幫使用者整理會議錄音並生成行動清單」的 SaaS 服務 | ？ | ？ | ？ |
查看答案
**A. 超商紙本發票處理** 推薦技術類型：OCR + NLP（鍵值擷取）+ 規則驗證 部署方式：**購買（Buy）或 API**。市面上有成熟的發票 AI 處理解決方案（如 Google Document AI、Microsoft Form Recognizer，或台灣本土的 iKala、91APP 等）。因為是通用的發票處理場景，不需要高度客製化，購買成熟商業解決方案比自建 ROI 更好；若有大量繁體中文發票且格式多樣，可選擇支援繁體中文的 API 服務先驗證，再決定是否轉為自建。 最大風險：**資料品質和格式多樣性**。全台各地供應商的發票格式不統一（傳統紙本、電子發票收據、收銀機紙捲），尤其是小供應商的手寫發票，OCR 準確率不穩定。建議先盤點發票種類分布，針對最大比例的格式做重點優化，不要期待一個方案 100% 處理所有格式。 --- **B. ICU 病患呼吸節律監控** 推薦技術類型：CV（即時姿態估計 / 呼吸節律偵測，邊緣部署） 部署方式：**自建或購買醫療專用系統**。絕對不能使用雲端 API，原因有二：**延遲要求**（100 毫秒的即時偵測無法容忍網路延遲）、**資料隱私**（ICU 病患的影像是最敏感的個人資料，不可上傳雲端）。應在 ICU 本地部署邊緣 AI 設備（如 NVIDIA Jetson 系列），模型在設備上本地推理。購買醫療級商業系統（如飛利浦、GE Medical 的 AI 監護系統）是較安全的路線，因為這些系統已通過 FDA 或 TFDA 醫療器材認證。 最大風險：**醫療法規認證**。台灣 TFDA 對醫療軟體有嚴格的認證要求，自行開發的 AI 監護系統必須通過「軟體醫材」審查（可能耗時 1–2 年、費用數百萬），缺乏認證的系統在醫院中根本無法合法部署，這是最大的進入障礙。 --- **C. 電商「上傳照片找相似商品」功能** 推薦技術類型：多模態視覺搜尋（CV + 圖片 Embedding + 向量資料庫） 部署方式：**API 或自建（中大型電商）**。若商品圖片數量在 10 萬件以下，可直接使用 Google Vision API 的相似圖片搜尋功能，或 Pinecone 等向量資料庫搭配開源圖片 Embedding 模型（CLIP）。若商品規模超過百萬件且需要高並發，應考慮自建 CLIP 模型微調（針對自家商品類別）加上高效向量索引。 最大風險：**商品類別分布不均**。電商平台的商品分類差異極大（服飾可能占 80% 的搜尋，但電子產品的「相似圖片搜尋」需求完全不同），通用的圖片相似度模型在特定類別上表現可能很差。建議先針對搜尋量最大的類別（如服飾）做重點優化和評測，再逐步擴展到其他類別，而非期待一個通用模型全部搞定。 --- **D. 信用卡詐騙交易偵測** 推薦技術類型：**表格機器學習（XGBoost 或 LightGBM）+ 規則引擎** 部署方式：**自建**（資料極敏感，絕不可上傳雲端；且交易資料是銀行最重要的資產和競爭優勢）。詐騙偵測是標準的表格資料二元分類問題（詐騙/非詐騙），XGBoost 在這類場景的準確率通常優於深度學習，且推理速度快（每筆交易毫秒級判斷）、模型可解釋性好（SHAP 值解釋每個特徵的貢獻，滿足金管會的可解釋性要求）。 最大風險：**類別不平衡和資料漂移**。真實詐騙案例在所有交易中占比極低（如千分之一），導致訓練資料嚴重類別不平衡；且詐騙手法持續演化，昨天的詐騙模式明天就可能失效，模型需要持續更新。建議每季評估模型的精確率（Precision）和召回率（Recall）變化，設定重訓觸發條件（如召回率跌破閾值）。 --- **E. 會議錄音整理 SaaS 服務** 推薦技術類型：ASR（語音辨識）+ NLP（摘要 + 行動清單擷取） 部署方式：**API 優先（快速驗證階段）**。使用 OpenAI Whisper API（語音轉文字）+ GPT-4 API（摘要和行動清單生成），可在幾週內上線一個 MVP 驗證市場需求，而不需要任何 AI 工程師。若驗證成功、使用者規模成長，再評估是否自建或使用更便宜的開源替代方案（本地部署 Whisper + 開源 LLM）來降低 API 費用。 最大風險：**資料隱私和法律風險**。企業會議的錄音往往包含商業機密、未公開財務資訊、甚至法律特權溝通（律師-客戶特權）。使用第三方 API（OpenAI）意味著這些敏感資訊需要上傳到境外伺服器，可能違反企業的資訊安全政策或台灣法規。建議在 ToS（服務條款）中明確告知使用者資料的處理方式，並提供企業版「自建部署」選項（不將錄音傳送到第三方），這對企業客戶銷售至關重要。練習 2：TCO 與整合複雜度評估
一家台灣保險公司（員工 800 人）正在評估導入 AI 的三個方案，用於自動審核汽車險理賠申請（客戶提交事故照片 + 書面說明，AI 初步評估損失金額）：
方案 A：調用 GPT-4V API（多模態）
- 每件估計 2,000 tokens，目前每日 200 件理賠
- GPT-4V 費用約 USD 0.01/1K tokens（輸入）
方案 B：購買一套商業車損估算 AI 系統（含本地部署授權）
- 年授權費用：TWD 300 萬
- 部署整合工程：估計 6 個月、2 名工程師
- 系統廠商聲稱準確率 90%
方案 C：自建（招募 AI 工程師自行開發）
- 招募 2 名 AI 工程師：月薪各 15 萬
- GPU 訓練伺服器租用：月費 TWD 5 萬
- 資料標注（3,000 份歷史案例）：每份 TWD 200
請計算各方案第一年的 TCO 概估，並分析各方案的最大整合複雜度風險：