只看時鐘，不看路況
固定班距依計時器發車，忽略路線上既有車輛的即時分布。
返回專案列表
Bus Bunching 強化學習調度最佳化
台北市公車 Bus Bunching 偵測與預警系統：以敦化幹線為例
以臺北市敦化幹線為案例，透過強化學習最佳化發車調度，在降低公車串車的同時兼顧乘客等候時間與營運成本。
問題
固定班距看不見路上的即時狀況
公車扎堆（Bus Bunching）是臺北市高頻幹線長期存在的營運問題：前後兩班車距離過近而幾乎同時到站，後續站點的乘客卻要等上遠超過表定的時間。敦化幹線班距短、站點密集、號誌交織、車流複雜，這個現象特別明顯。根本原因在於固定班距的發車決策只以時間為觸發條件，完全不看路線上其他車輛此刻在哪裡。
延誤會自我放大
一旦某班車落後，就會載到更多累積的乘客而更加落後，後車也隨之追上。
不存在最佳的固定班距
班距調密可縮短等待，卻讓路上車輛變多而加劇扎堆；調疏則反過來惡化等待。
我們提出的解法
讓發車決策從真實路況中學出來
01
路線一維化投影
將公車 GPS 座標與站牌位置一併投影到路線的 WKT LineString 上，把二維經緯度轉成 0 至 1 的進度值，使任意兩車位置可直接比較，並以進度差判斷扎堆。
02
資料驅動模擬器
站段旅行時間不假設分布，而是依方向、平假日、尖離峰與雨量條件從歷史樣本池中抽樣；當特定條件樣本不足時，模擬器會逐步放寬條件而非中斷。
03
把發車視為序列決策
把起站發車控制建模為馬可夫決策過程：每 60 秒做一次「發車或不發車」的二元決策，reward 則同時權衡扎堆、班距變異、營運車輛數與乘客等待。
04
用消融實驗檢驗設計
逐一移除單個 reward 組件或 state 特徵群，證明每個元素各自約束了不同的失效模式，而不是只交出一個總分。
系統架構
調度策略如何被建立與驗證
四階段流程把原始 GPS 軌跡轉成模擬器，並將發車決策建模為馬可夫決策過程，讓 agent 能與它要取代的固定班距正面比較。
研究流程
從原始 GPS 軌跡到可比較的策略
階段 01
資料前處理
清洗、投影、切分
篩出正常營運的有效紀錄，將 GPS 投影到路線上轉成 0 至 1 的進度值，切分趟次，並以插值估算通過各站的時間。
階段 02
模擬環境
資料驅動模擬器
依方向、平假日、尖離峰與雨量條件抽取歷史站段旅行時間，再以 Leave-One-Day-Out 驗證還原度。
階段 03
強化學習
DDQN 發車 Agent
以三層全連接網路搭配 replay buffer 與 ε-greedy 衰減，每 60 秒決定一次是否要發車。
階段 04
策略評估
策略比較
在相同起始情境與隨機種子下，以 180 分鐘 episode 與固定班距比較，並進行 reward 與 state 的消融實驗。
決策建模
把起站發車控制寫成馬可夫決策過程
State 狀態
- 時間脈絡 —— 尖離峰、平假日、雨量
- 服務狀態 —— 路線上車輛數、距上次發車時間
- 車輛狀態 —— 扎堆數、班距、各站預估等待
Action 動作
- 二元決策：發車或不發車
- 每 60 秒重新評估一次
Reward 獎勵
- 懲罰項 —— 扎堆、班距變異、營運車輛數、等待超標
- 獎勵項 —— 等待落在目標內
- 目標：尖峰 8 分鐘、離峰 15 分鐘
我的負責範圍
把發車問題建模為 MDP、設計 reward 函數與各項權重、訓練 DDQN agent，並執行策略比較、敏感度分析與消融實驗。
實作與成果
從兩週 GPS 軌跡到經過驗證的調度策略
三類資料整合為一份資料集
TDX 提供站牌順序與路線幾何，臺北市公車 API 於 2026 年 4 月 22 日至 5 月 6 日間以每 30 秒一次的頻率爬取 GPS 軌跡，CODIS 則提供逐小時雨量；三者整合成以「站段 × 趟次」為觀察單位的樣本池。
趟次重建
先篩出正常營運的有效紀錄，依路線進度大幅後退或資料中斷超過 20 分鐘切分趟次；由於 GPS 每 30 秒才回傳一次、不會剛好落在站牌上，再以線性插值估算通過各站的時間，據此計算每個站段的行駛時間。
Leave-One-Day-Out 驗證
為確認模擬器是泛化而非死記歷史軌跡，模擬某日時會將該日所有紀錄自樣本池完全剔除，要求進行 Out-of-Bag 預測。四個時段的單趟 MAE 皆落在 6 至 10 分鐘內，晚尖峰因延誤累積而誤差最高。
DDQN 訓練與對等比較
以 PyTorch 建構三層全連接網路（輸入→128→128→2），搭配 Adam、replay buffer 與 ε 從 1.0 線性衰減至 0.05 的探索策略。驗證時以 180 分鐘為一個 episode，與比照實際服務標準設定的固定班距策略，在相同起始情境與相同隨機種子下比較。
- Bunching 總量
- −22.9%
- 相較尖峰 8 分鐘／離峰 15 分鐘的固定班距基準；bunching 發生步數同時下降 16.2%
- 模擬器單趟 MAE
- 6–10 分鐘
- 以 Leave-One-Day-Out 交叉驗證，涵蓋四個時段與去返程
- 等待超標比例（取捨）
- 37.9% → 42.1%
- agent 學到較保守的發車策略，扎堆下降但部分站牌等待變長
限制
仍待驗證的部分
本頁所有數字都來自以兩週 GPS 軌跡建立的模擬器，反映的是模擬營運而非實際上線結果。模擬環境尚未納入乘客上下車需求模型；雨天樣本相對稀少，使雨天情境成為還原度最低的一段；消融實驗也只使用單一 random seed。結果同樣不是全面勝出：agent 偏保守的發車策略讓等待超標的站牌比例從 37.9% 上升到 42.1%，問題指向 reward 權重而非方法本身。真正導入還需納入車輛庫位與駕駛排班約束，並為平日與假日設計不同的調度策略。