神經網路不是一種模型：從前饋、CNN、RNN 到 Transformer 的選型指南

神經網路不是一種固定模型，而是一組用不同結構處理資料的方式。Wikipedia 的 Types of artificial neural networks 條目把前饋、卷積、循環、記憶、模組化與其他架構放在同一張地圖上；這張地圖適合用來建立詞彙，但企業真正要做的選擇，通常不是問「哪個模型最強」，而是問資料有沒有空間或時間結構、錯誤成本多高、延遲和預算多少，以及部署後誰負責維護。

同一個任務可以有多種可行架構。影像瑕疵檢測可能需要理解局部圖樣，語音或感測器資料可能需要處理順序，文件分類可能需要長距離的文字關係；如果先把模型名稱當成答案，就容易忽略資料品質、標註方式、評量指標、推論成本與人工覆核。選型應從問題的形狀開始，再用小規模實驗比較，而不是從排行榜倒推需求。

先用資料結構理解四種常見架構

架構	比較適合的資料特性	常見風險
前饋／多層感知器	固定欄位、表格與基本模式辨識	忽略空間或時間關係，特徵工程負擔變高
卷積神經網路 CNN	影像、局部訊號與具有鄰近結構的資料	對資料分布變化、裁切方式和標註品質敏感
循環神經網路 RNN	語音、感測器、文字等順序或時間序列	長序列訓練與平行化較困難，記憶範圍需實測
Transformer	需要比較長距離關係、可平行處理的序列任務	資源需求、上下文成本、資料洩漏與錯誤解釋

Sequential 與 Functional，不只是寫法不同

TensorFlow 的 Keras Sequential model 指南把線性堆疊的模型作為清楚的入門形式：一層接著一層，輸入和輸出路徑簡單，適合快速建立基線。Keras 的 Sequential 文件也把這種模型定位在單一輸入、單一輸出且層次線性排列的情境。對小型專案而言，這種簡單性本身就是優點，因為比較容易閱讀、測試、保存和交接。

當模型有多個輸入、多個輸出、分支、共享層或跳接，Keras Functional API提供更能表達資料流的方式。這不表示 Functional 一定比較好，而是結構要和問題相符。若只是把簡單任務寫成過度複雜的圖，除了解釋和測試成本上升，日後也更難判斷錯誤來自資料、前處理、模型、閾值還是部署環境。

模型選型要把「資料、指標、成本」放在同一張表

第一個問題是資料能否支持模型。影像任務要檢查解析度、類別平衡、拍攝條件和標註一致性；時間序列要檢查取樣頻率、缺測、延遲與時間切分；文字任務要檢查語言、領域、重複內容和個資。資料量少時，增加模型複雜度可能只是在記憶訓練樣本；資料量大時，若沒有清楚的驗證切分，較高的分數也可能只是洩漏。

第二個問題是指標是否和決策一致。分類器不一定只看 accuracy，還可能要看 precision、recall、不同群組的錯誤、校準、拒答率與人工覆核量。生成或排序任務也要把品質、延遲、成本和使用者回報一起觀察。第三個問題是服務能否承受模型：推論硬體、批次大小、快取、版本更新、監控、回退和資料保留政策，都應在 PoC 階段先留下基線。

決策問題	驗證證據	不能用什麼代替
模型是否學到真正訊號	時間或群組切分、錯誤案例、外部驗證	單次訓練的最高分
是否能上線	延遲、成本、容量、監控與回退演練	Notebook 可以跑完
是否適合不同使用者	分群指標、人工抽查、可申訴流程	整體平均值
是否能長期維護	資料漂移、版本、責任人與更新週期	一次性的 PoC 展示

從基線到架構比較，建立可回復的實驗流程

1. 先做不用神經網路或最簡單 Sequential 模型的基線，確認資料管線和指標可以重跑。
2. 只改一個主要變因，例如把固定欄位改成 CNN、把短序列改成 RNN，避免同時換資料、模型和閾值。
3. 保留資料版本、程式碼、超參數、硬體、時間、模型檔和錯誤案例，讓結果可以被另一位同事重現。
4. 除了平均分數，檢查最常錯的樣本、不同群組、最慢請求、成本與人工覆核量。
5. 設定停止條件、回退版本和負責人，確認模型變差時服務可以先回到可用狀態。

Transformer 熱門，不代表每個專案都該從它開始

Transformer 的注意力結構讓模型能處理序列中的不同關係，並在許多語言、影像和多模態系統中成為重要工具；但「可用」和「值得使用」是兩個問題。小型內部分類、規則清楚的表格任務或對延遲極敏感的邊緣設備，可能更適合簡單模型。若使用大型模型，還要把提示、上下文、輸出驗證、供應商變更、成本上限與敏感資料邊界納入設計。

也不要把模型架構和產品能力混為一談。使用者看到的是一個工作流，背後可能同時有檢索、分類、生成、規則、人工審核與資料庫；其中任一層出錯，都不一定能靠換成更大的神經網路解決。先畫出輸入、處理、輸出、決策與回退的責任邊界，再決定需要哪一種架構，通常比先選模型名稱更接近可交付的工程問題。

比較模型時也要設計失敗案例，而不是只挑成功樣本展示。例如把光線、語氣、缺測、拼字、尖峰流量或新型態輸入放進測試集，觀察模型何時應該拒答、交給人處理或回退到規則。若一個較複雜的模型只在平均分數上多幾個百分點，卻讓延遲、成本和除錯時間大幅上升，團隊就需要把這些代價寫進決策，而不是只報一個漂亮的 benchmark。

給企業團隊的模型選型檢查表

• 需求：明確寫出使用者、決策、容錯、延遲、成本與不能做的事。
• 資料：標記來源、授權、個資、切分方式、缺漏、漂移與可用期限。
• 模型：從簡單基線開始，只有在錯誤證據支持時才增加結構複雜度。
• 評量：同時看品質、分群錯誤、延遲、成本、拒答與人工覆核量。
• 運維：保存版本、監控輸入輸出、設回退路徑，指定模型失效時的處理者。

如果要把模型選型接到企業 AI 工作流程，站內的AI Agent 導入說明可以先協助拆解角色、工具與人工接管；AI 工作流程健檢則適合檢查資料邊界、權限、來源、紀錄與回退。模型架構只是其中一個元件，能否被理解、驗收和安全地維護，才是能否長期使用的關鍵。

最後要把選型決策寫成可交接的紀錄：需求版本、候選模型、被淘汰的原因、測試資料、結果與已知限制都要留下。這份紀錄比一句「採用最佳模型」更能幫助下一位維護者理解當初的取捨。

結論：從問題的形狀開始，而不是從模型名單開始

前饋、CNN、RNN 與 Transformer 各自提供不同的資料處理假設，沒有一個架構能在所有任務、成本與風險下勝出。可靠的選型會把資料結構、錯誤代價、評量指標、部署條件與維護責任放在一起，從簡單基線逐步增加複雜度，並為每次變更留下可重現的證據。當模型不再符合需求時，團隊也應該能看懂原因、撤回版本並保護使用者，而不是只能重新訓練一次。

資料來源

• Wikipedia：Types of artificial neural networks（前饋、CNN、RNN、Transformer 與其他架構研究入口）
• TensorFlow：The Sequential model（Keras 線性堆疊模型官方指南）
• Keras：The Sequential model（單一輸入／輸出與線性層次模型文件）
• Keras：The Functional API（多輸入、多輸出、分支與共享層模型文件）

本文以 Wikipedia 架構索引與 TensorFlow、Keras 官方文件整理模型選型框架；實際模型、資料、硬體、指標與風險仍需依專案需求、授權、隱私和部署環境個別驗證。