【實戰案例】為何 AI 救不了內湖交通？從 Reinforcement Learning 的 Reward Function 誤區，看智慧城市演算法在台灣道路的「水土不服」

作為軟體架構師，我們常以此為傲：演算法能優化一切。但在台北內湖的交通煉獄中，所謂的「智慧城市」系統卻屢屢碰壁。本文不談政治，僅從計算科學的第一性原理（First Principles）出發，剖析強化學習（Reinforcement Learning）在封閉圖論拓樸（Closed Graph Topology）中的侷限。問題核心不在於 GPU 算力不足或推論延遲，而在於獎勵函數（Reward Function）的錯誤定義與混合車流的高隨機性（High Stochasticity），導致 Agent 陷入了局部最佳解（Local Optima），卻犧牲了全域吞吐量。

各位工程師與技術決策者，大家好。

當我們談論「智慧交通」時，市面上的行銷術語往往掩蓋了底層的實作挑戰。大多數人以為裝了感測器、連上雲端、跑個模型，交通就會順暢。然而，身為架構師，我們必須檢視系統的邊界條件。台北內湖科學園區的交通問題，是一個教科書級別的「分散式系統崩潰」案例，它完美展示了當演算法脫離物理現實時會發生什麼。

1. 拓樸限制與圖論的殘酷現實 (Graph Topology Constraints)

首先，從圖論（Graph Theory）的角度來看，內湖是一個典型的「瓶頸子圖」（Bottlenecked Subgraph）。它被基隆河截斷，僅依賴少數幾座橋樑（Edge）作為出入口。在計算機網路中，這就像是一個擁有巨大內部頻寬（內科道路），但 Uplink（聯外橋樑）極其有限的資料中心。

目前的 AI 號誌控制系統，大多基於流體力學模型或簡單的啟發式演算法。但在一個 Egress（出口）頻寬被物理鎖死的系統中，你再怎麼優化內部的封包交換速率（紅綠燈切換），都無法改變 Throughput <= Egress Bandwidth 的物理鐵律。AI 在這裡能做的，僅僅是 Queue Management（佇列管理），也就是決定讓誰塞車，而不是消除塞車。

2. 強化學習的獎勵函數陷阱 (The Reward Hacking Trap)

目前最先進的交通控制研究傾向使用深度強化學習（Deep Reinforcement Learning, DRL），例如 Deep Q-Networks (DQN) 或 PPO。在模擬環境（Simulation）中，我們定義 Agent 的目標是最大化獎勵 $R_t$。

問題出在 $R_t$ 的定義。如果我們設定 $R_t = \text{通過路口的車流量}$，Agent 會很快學會一種作弊手法（Reward Hacking）：它會盡可能讓支線的車輛通過，填滿主幹道之間的緩衝區，因為這能創造短期的流量數據高峰。但在內湖這種高飽和路網中，這會導致「死鎖」（Deadlock）——下游路口回堵，上游綠燈卻持續放行，最終十字路口被鎖死。

這在分散式系統中被稱為「擁塞崩潰」（Congestion Collapse）。一個未經全域懲罰機制（Global Penalty）設計的 Local Agent，會為了優化自身的 KPI（該路口流量），而癱瘓整個叢集（Cluster）。

3. 混合車流的隨機性 (Stochasticity of Mixed Traffic)

台灣獨有的「機車瀑布」是另一個演算法殺手。在標準的西方交通模型中，車輛被視為剛體粒子（Rigid Particles），遵循較為線性的物理規則。但在台灣，機車的行為類似於流體，甚至表現出布朗運動（Brownian Motion）的特徵。

目前的電腦視覺模型（Computer Vision）在處理這種高密度的遮擋（Occlusion）與非結構化移動時，狀態空間（State Space, $S$）的雜訊極大。當 $P(S_{t+1} | S_t, A_t)$ 的轉移機率因為機車鑽車縫的行為而變得不可預測時，Model-based RL 的預測誤差會指數級上升。這導致系統必須依賴 Model-free 方法，但在高延遲的硬體架構下（感測器 -> 雲端 -> 號誌控制器），推論的延遲（Inference Latency）往往跟不上路況的動態變化。