RAILwAI

鐵路維修長年靠「時間表」——每隔多少天、多少通過噸數就檢修一次，不管實際狀態如何。這個做法安全但浪費：狀況好的設備被過度保養，狀況差的可能撐不到下次排程。RAILwAI 做的事就是把判斷基準從時間換成狀態。

它的核心是資料融合。鐵路資產的狀態資訊散在好幾個地方：軌道檢測車的量測、人工巡檢的表單、埋在道岔裡的感測器、還有溫濕度與降雨這類環境資料。RAILwAI 把這些接進同一個平台，用機器學習模型融合之後做預測。官網說法是自動化資料處理可省下最多 90% 的處理時間——這個數字其實反映了鐵路維修的現況：大量工程師時間花在把不同來源的資料整理成可比較的格式，而不是做判斷。

平台有六個針對特定鐵路維修流程設計的 AI 模組，可透過 API 對接主流 CMMS（電腦化維修管理系統）、自訂巡檢表單與嵌入式感測器。官網主張的效益是維修成本降低 15%、故障與中斷減少 30%。

公司位於法國蒙彼利埃的 CAP OMEGA 育成中心，目標客戶是基礎設施管理者、鐵路營運商、工程營造公司與感測器供應商。

功能特色與適用場景

「感測器供應商」被列為客戶類型這點值得注意——這暗示它的商業模式不只賣給鐵路公司，也可能作為感測器廠商的分析層。對只賣硬體的感測器公司來說，缺的正是這一層。

給台灣使用者的具體用法

台灣鐵道系統的資料現況其實很適合這類工具：台鐵、高鐵、以及台北、桃園、台中、高雄各捷運系統，都有多年的巡檢紀錄與感測資料，但多半分散在不同承包商與不同世代的系統裡。導入的第一個難題不會是模型，是資料串接——先把軌道檢測車資料、人工巡檢表單與既有 CMMS 對齊，這件事的工程量通常被嚴重低估。第二個要注意的是台灣的環境變數跟歐洲差異大：高溫高濕、颱風豪雨、地震，這些對軌道與道岔劣化的影響曲線跟法國不同，直接套用既有模型不會準，必須用本地歷史資料重訓。務實的起手式是選一段資料最完整的路線做試點，用已知的歷史故障回測模型，先證明它在台灣的條件下抓得到東西，再談擴大。