從光復堰塞湖潰流談 AI 防災:國際經驗、NCDR 覆盤與台灣的可能路徑

AI 能否為台灣的堰塞湖與洪水災害提前拉警報?從光復事件到國際經驗的啟示。

一、光復/馬太鞍溪 堰塞湖潰流事件概況

以下是我從新聞報導與公開資料中彙整的重點與疑點:


事件經過與關鍵時間軸

  1. 背景形成本底
    • 2024/04/03 的強震,使花蓮東部山區地質受擾動,土體可能已有鬆動的隱憂。 (聯合新聞網)
    • 2025/07 ~ 09 月間,多場強降雨及颱風暴雨使得上游崩塌、堆積物移動,最終在上游形成一座堰塞湖。 (商業周刊 – 商周.com)
    • 據報導,這座堰塞湖位於馬太鞍溪上游,壩高約 200 公尺,面積可達約 140 公頃,滿水位蓄水量預估可達約 9,100 萬立方公尺。 (聯合新聞網)
  2. 潰流 / 溢流發生
    • 在 2025/9/23 下午約 14:50,堰塞湖壩頂開始 溢流 並逐步潰流(有報導稱壩頂溢流、破壞、沖刷等混合表述)。 (聯合新聞網)
    • 洪水與泥石夾帶大量土砂傾瀉而下,首先在 15:08 洪峰抵達馬太鞍溪橋部分,15:30 左右橋體被破壞;16:00 左右洪水正式湧入光復市區下游,造成大規模淹水、房屋被沖毀等災情。 (聯合新聞網)
    • 有報導指出,在壩體潰決之前,壩頂水位在短時間內大幅下降(例如在 14:20 至 15:30 間下降約 33 公尺)與蓄水量變化大,可能是傾洩出大量水流造成下游洪峰。 (公視新聞網 PNN)
  3. 災情與傷亡
    • 初步統計顯示,造成 14 人死亡、32 人受傷、46 人失聯。後續估算可能更高。 (聯合新聞網)
    • 下游的房屋、商店、道路、橋梁、堤防等設施受損嚴重,部分地區一樓幾乎被淹沒。光復車站與鐵道也受洪水沖刷淹沒。 (Yahoo奇摩新聞)
    • 下游堤防受損總長達數千公尺(有報導稱約 2,860 公尺)等。 (维基百科)
  4. 預警與撤離
    • 在事前,有發布颱風警報,並有評估堰塞湖可能潰流的風險。中央災害應變中心曾預估可能在晚些時候(例如 25 日)才會溢流,後來又調整為 23 日午後可能溢流。 (公視新聞網 PNN)
    • 從 9/22 起就針對光復鄉、鳳林鎮與萬榮鄉共 12 個村里進行撤離行動,估計涉及約 1,800 個門牌、8,500 多人。 (公視新聞網 PNN)
    • 即便有這些預警與疏散措施,依然有部分居民未能及時離開撤離區域,導致死傷。 (公視新聞網 PNN)
  5. 爭議與反思
    • 一個爭議是:是否「潰壩」或「潰堤」才是主因?有些報導認為是壩體溢流加劇而破壞,而不見得是一次性的斷裂式崩潰。(公視新聞網 PNN)
    • 另一個是:儘管已有預警與撤離計畫,為什麼還有罹難者?是否警訊不足、發布時機延後、撤離執行不完全等問題。(公視新聞網 PNN)
    • 在災後重建與防災規劃方面,如何提升監測、預警與防洪設計,是未來要深思的課題。 (商業周刊 – 商周.com)

總之,這起堰塞湖潰流事件是多重因素累積的結果:地震造成地質不穩、強降雨導致入流與崩塌、堰塞湖蓄水過量與壩體壓力,以及可能的排水或防護設計不足,都可能在過程中起作用。即便有預警與撤離措施,極端條件可能使災害難以完全避免。

來源:公視新聞網

二、國際/學術界有無用 AI 提前預測類似潰流 / 土石災害的案例?

在國際上與學術界中,確實已有許多研究試圖利用 AI、機器學習、遙感技術等方法來偵測、監測、預警山崩、滑坡、土石流、潰壩或堰塞湖的潛在危險。下面列幾個比較有代表性的案例與研究,並分析其成就與限制。

國際/研究案例

  1. 台灣內部研究 — 深層滑坡位移預測
    • 台灣有研究結合 CNN(捲積神經網絡)與優化演算法(如 AEIO)來預測深層滑坡位移,對 1 天與 7 天的位移做預測,模型的平均絕對百分比誤差(MAPE)可以達到約 2.81%。(nhess.copernicus.org)
    • 雖然這是針對滑坡位移(變形、滑移量)的預測,而不是潰壩或突發洪流,但對於地質穩定性與滑動風險監控是有價值的。(nhess.copernicus.org)
  2. 台灣已有的土石流 / 崩塌預警系統改進研究
    • 有研究嘗試用機器學習模型(如 Random Forest 等)輸入降雨歷史資料來預測某一時段是否會發生土石流,比過去的舊系統更有精度,但仍存在偵測漏失與誤警的困難。(ResearchGate)
    • 在滑坡危險性時空建模方面,也有研究提出統一的資料驅動框架,讓滑坡發生的機率在空間+時間上做動態估計。(ScienceDirect)
  3. 遙感 + AI 自動偵測滑坡 / 崩塌
    • 2025 年有研究指出,地震後臺灣東部大片山區的滑坡災變,可在取得衛星影像後 3 小時內,利用 AI 自動偵測出 7,000 多處滑坡事件。(nhess.copernicus.org)
    • 在該研究中,AI 模型對衛星圖像進行分類、識別地形與崩塌樣態,有助於災後快速判讀災情範圍。(nhess.copernicus.org)
    • 有新聞報導也提到 AI 在災後遙感影像上的應用,能在數小時內繪製滑坡清單,有助於救災部署。(University of Cambridge)
  4. 綜合回顧與方法論
    • 有綜合文獻回顧探討遙感 + AI/機器學習在滑坡偵測、滑動監測、災變提取、滑坡危險性評估等方面的應用。(MDPI)
    • 也有研究關注資料集、特徵工程、模型選擇、如何融合動態天氣資料(降雨、地表濕度、水位)與地形地質資訊,以提高預測性能。(SpringerLink)
  5. 國際流域 / 淡水溢流 /壩體安全監測
    • 雖然在我查到的資料中,具體已有 AI 成功預測堰塞湖潰壩的公開案例較少,但在水庫壩體監測、水壩安全評估、水位預測等方面已有 AI 應用。例如用深度學習、時間序列模型,對壩體監測感測器(如變形、裂縫、滲流、壓力)資料做異常檢驗或預警。但這類應用通常是針對人工建設的水壩或水庫,而非自然堰塞體。
    • 在洪水預測、河川水位預測、水文模型與深度學習結合的研究也不少,例如用 LSTM、GRU 等模型預測河流流量、水位、洪峰時間等。這些技術若與地質災害模型結合,或許可延伸到堰塞湖潰流預警。
AI 應用於防災預警空間展示|台灣創新技術博覽會
來源:NCDR


優勢、挑戰與局限

儘管已有不少研究與初步實作,但要做到真正對「堰塞湖潰流」或「突發性壩體失穩」進行提前、可靠的預警,仍然面臨不少難題。以下是我整理的一些關鍵考量:

項目優勢/可能性挑戰與限制
多源資料融合能力可結合地形、岩性、坡度、裂隙、降雨、水位、地下水、衛星影像、陸上感測器等多種資料作為輸入資料稀疏、感測器佈設成本高、資料缺失或誤差(如雜訊、漂移)是常見問題
模型類型彈性利用機器學習、深度學習、自注意力、混合模型等可擬合非線性關係模型可能過度擬合、泛化能力不足、資料量不足導致訓練不穩定
時空預警能力有些模型可做短期預測(如 1 天、7 天滑動變形、斜率變化)對於突發性斷崩、瞬間破壞型潰流,模型可能反應不及
實時性與計算效率若感測器與數據流通暢,理論上可做到近即時監測與預警從資料取得、清洗、模型預測到發警時間間隔可能仍過長
假警與漏警問題預警系統若敏感過高,容易有過多假警;若閾值設太保守,可能漏失真正風險平衡警示精準度與可操作性是一大難題
模型可解釋性與責任災害預警與撤離可能牽涉生命安全,模型需有可信度與可解釋性黑箱模型可能遭質疑;若錯誤導致損失,責任界定也不易
自然物體 vs 工程壩體不同自然堰塞體的力學、穩定性更複雜,變化可能更劇烈、不可預期工程壩體設計通常較規範且有感測設計基礎,自然體的監測與模型較難

因此,目前 AI 在這領域多數是作為「輔助工具」或「偵測+評估」手段,而非完全自主的潰流預警系統。很多研究仍停留在理論、模型驗證或小規模試驗階段。

最接近「堰塞湖潰流」的證據

  • 目前在同類型(自然滑動形成的堰塞湖)上,能找到的是方法與系統的研究與部署,但尚未看到「已在真實事件中成功提前預警並被官方記錄」的公開案例。
    • 例如針對「滑坡→堰塞湖→潰決洪水」的整合式風險鏈評估,有研究用隨機森林等 ML 做易發區辨識與風險串聯,但屬評估框架,非已驗證的實戰預警成功案例。 (MDPI)
    • 針對舊個案的潰決模擬(如中國唐家山堰塞湖)則多為事後/模擬研究,並非「AI 實時預警後成功避災」的紀錄。 (ScienceDirect)
    • GLOF(冰湖溃决洪水)方向,有早期預警系統的設計與試點(以監測+預測模型結合),但公開文獻仍以系統設計/驗證為主,未見明確「某次事件提前 X 小時成功發報」的正式報告。 (eartharxiv.org)

小結:就「自然堰塞湖潰流」這一型態,目前公開可查到的是研究、原型或部署中的系統,沒有像「某年某月某日因 AI 預測而提前發出警報,並證實減災」這種被權威機構或期刊完整記錄的成功實戰案例。

使用 LoRa 物聯網設備設計和實施先進的冰川湖決堤洪水預警系統

相近型「AI 成功提前預警」的實證(可借鏡)

  • 河川洪水(大規模):Google Research 的 AI 洪水預報系統,已被 Nature 論文與官方技術頁面公開,可在全球 80+ 國家提供最長 7 天預報,並已整合到 Flood Hub 對外服務,屬運行中且被多方採用的成功案例。 (blog.google)
  • 實務成效報導:UNDRR/PreventionWeb 也以案例形式介紹 Flood Hub 如何支援地方級預警與減災(屬實務成果背書)。 (preventionweb.net)

啟示:雖然這些是「河川洪水」而非「堰塞湖潰決洪水」,但在資料融合(雨量、流量)、即時運算、風險溝通與對外服務等面向,已證明 AI 預報能「提前發警、被採納、廣泛運行」。這些經驗可作為堰塞湖預警系統設計的參考模板。

May be a graphic of map and text
來源:Google Flood Hub

補充:相關 AI / ML 在滑坡與冰湖領域的成熟度

  • 滑坡監測與預測:ML/DL 在滑坡易發區建模、位移/演化長期預警上已有大量研究與良好表現,但多著眼機率與趨勢,要準確預警「何時潰決」仍難。 (ScienceDirect)
  • 遙感+AI:震後或極端降雨後,AI 可在數小時內從衛星影像自動萃取大量滑坡清單,對災後判識與快速態勢掌握很有幫助,但這屬快速偵測,不是事前預警成功案例。 (MDPI)

對台灣(堰塞湖情境)的可行落地路線

若目標是「往成功實戰案例推進」,建議分期:

  1. 先做「風險監測+異常偵測」常態化
    • 佈建雨量/水位/地表位移/裂隙/滲流等感測,結合遙感資料;用 ML 做風險指數異常分數(而非直接預言潰決時刻)。
    • 與水理與邊坡物理模型「物理×資料」混合,降低黑箱性。 (方法論有成熟文獻可依循) (MDPI)
  2. 建立「分級觸發的預警策略」
    • 參照洪水 AI 預報的做法,將模型輸出與應變 SOP 綁定(警戒線→封閉區域→分批撤離→全面撤離)。
    • 借鏡 Flood Hub 的對外介面與決策支持設計,確保結果可被防災單位採信與執行。 (blog.google)
  3. 用 GLOF/堰塞湖專案的經驗做在地化試點
    • 參考 GLOF 早期預警系統的資料流與運維(氣象預報+現地監測→風險期判定→警訊通報),在花東山區做試點、累積在地資料與門檻。 (isprs-archives.copernicus.org)

結論

  • 堰塞湖潰流的 AI「成功提前預警」之公開、可核查的國際案例:目前查無。現況以研究、原型與部署中系統為主。 (MDPI)
  • 相近型(河川洪水)的 AI 成功案例已相當成熟(Google Flood Hub 等,已服務 80+ 國、可 7 天預報,並有多方背書),可作為技術與治理面的借鏡。 (blog.google)

三、回到光復事件:若用 AI 預警,有哪些可能的做法?與潛在挑戰

針對這次的堰塞湖潰流事件,假設我們要設計一套 AI 輔助的預警系統,以下是可能的架構與需要注意的地方:

可行架構(假設性)

  1. 資料收集與佈建
    • 地形與地質資料(坡度、岩性、土壤、斷層/裂隙分佈等)
    • 感測器資料(雨量計、流量水位計、地下水位、土壤濕度、應變計、傾斜儀、裂隙開啟監測器)
    • 衛星影像與遙感資料(如降水雲圖、微地形變化、表面反射率差異)
    • 歷史事件資料(過去崩塌、滑坡、堰塞湖潰流等案例)
  2. 特徵工程 / 權重設計
    • 從原始輸入資料中挑出對潰流可能有影響的指標(如連續降雨累積、降雨強度、前期降雨背景、壩體蓄水高度、壩體變形率、裂縫變化率、地下水壓力變化等)
    • 加入時間窗口 (例如近 1 小時、3 小時、6 小時、12 小時、24 小時)與滯後特徵
    • 若可行,加入物理模型(例如水力模型、土壤力學模型)與機器學習混合(即「物理+資料驅動」模型設計)
  3. 模型訓練與驗證
    • 使用過去已發生的類似潰流或壩體失穩案例作為訓練資料
    • 交叉驗證、時間切分驗證,確保模型具備泛化能力
    • 若資料足夠,可分別建立短期(例如未來幾小時內)與中期(未來一天)潰流/高風險預警模型
  4. 閾值與預警策略設計
    • 模型輸出可能是「潰流風險指數」或「潰流概率」
    • 根據不同風險等級設計警戒門檻(例如低、中、高三階)
    • 當模型預測值超過警戒門檻時,啟動疏散、封路、監控加強等應變機制
  5. 即時運作與反饋修正
    • 實際運作時要做到資料即時傳輸、模型快速預測、警報發布
    • 每次警報或實際事件發生都要納入後驗分析,以持續更新模型/門檻
    • 搭配人工專家判讀與多系統交叉驗證(避免單一模型誤警)

✅ 強化的可行做法 + 對應國外案例

1. 監測+異常偵測:事先偵察潰壩前徵兆

做法重點:

  • 在高風險堰塞湖、上游山體與壩體周邊佈設感測器(如雨量、水位、土壤濕度、裂縫監測器、傾斜儀、應變計、地下水壓力計)
  • 結合衛星遙感資料(光學影像、雷達InSAR)進行地表形變檢測
  • 用 AI/機器學習模型對這些異常變化(如壩體傾斜變化、裂縫擴張、地表沉降/隆起速度加劇)做監控與預警得分(異常分數)

國外/研究對應案例:

  • 印度錫金南 Lhonak 冰湖案例(South Lhonak Lake):研究者用 InSAR + 衛星影像來回溯分析潰決前的潛在變形跡象,以觀察水壩體周邊地表變形與滑動趨勢。這種方法本身並不是在潰決前就發出警報,而是事後驗證,但展示了 InSAR 形變偵測與 AI 平台整合的潛力。 (MDPI)
  • GLOF 早期預警系統(Glacial Lake Outburst Flood):有學者將 AI 運算能力應用於即時監測兩個危險冰湖,做並行處理以支援潰流警報。這是 pilot/研究階段案例。 (科學直接)
  • 錫金 Lhonak 研究中發現,在潰流前的 moraine(冰壩帶)有變形速度加劇區域,且與降雨、湖水面積變化等因素相關。這提示「地表變形 + 外部水壓 / 天氣誘發」是潰決風險指標之一。 (ResearchGate)

這些案例顯示:InSAR + 衛星變形監測 結合地面感測,有可能在壩體尚未崩潰前捕捉到微小變動,是潰流預警體系中重要的一環。


2. 風險分級與預報模型:把降雨 → 潰流風險/影響區域串起來

做法重點:

  • 建立「潰決風險模型」:輸入降雨預報、累積雨量、土壤飽和度、水位/蓄水量、壩體變形 / 裂縫變化、地質/坡度參數等,讓 AI/混合模型預測潰決可能性
  • 再配合「洪水洩流模擬」或水力模型,將潰流後的洪水路徑、水深、水流速度、淹水時間往下游推算,指出下游哪些村莊/橋樑/道路最可能受影響
  • 設計多階警戒等級(如中低風險:加強監測;中高風險:封路或部分撤離;高風險:全面撤離)

國外/實作/理論案例:

  • Google Flood Hub(洪水預報):這是最接近的成功案例。Google 的 AI 系統結合兩個子模型 — 一個是水文模型(Hydrologic Model,預測河川流量)與一個是淹水模擬模型(Inundation Model,推估哪些地區會被淹)— 用來提前 7 天預警河川洪水。 (sites.research.google)
    • 它能把「流量預測」+「淹水區模擬」整合,讓下游地點被標示出來(哪裡可能淹水、淹多高)— 這正是堰塞湖潰流後洪水推算的思路。
    • Flood Hub 也在一些國家被整合進地方警報系統、決策支援系統,讓政府或 NGO 可根據 AI 預報做應變行動。 (預防網)
  • 在洪水預報模型的研究界,也有論文詳述機器學習在「階段預報 + 淹水模擬 + 通報系統」的整體流程。比如 HESS 刊登的文章就說明了一套機器學習輔助的洪水預報系統的結構,涵蓋四大子系統:資料驗證、河階預報、淹水模擬、警報傳遞。 (hess.copernicus.org)
  • AI 閾值與泛化能力研究:有論文指出,用 AI 可在無測站流域(ungauged basins)預測洪水事件,這對偏遠地區(如堰塞湖下游無大量測站)尤其有價值。這表明 AI 在資料稀疏情境下仍能提供可靠預測。 (arXiv)

這些案例示範了一個邏輯:從「降雨 → 流量 / 壩內壓力 → 潰流風險 → 洪水模擬 → 下游影響區域推估」的流程,是堰塞湖潰決預警可以借鏡的思維架構。


3. 警報與通報機制整合:從 AI 預測到實際行動

做法重點:

  • 將 AI 模型輸出(風險指數/潰決概率/潰流後淹水影響區域)與應變中心 /地方政府的警報 S.O.P. 結合
  • 設計視覺化平台/地圖介面/手機通知/社群警訊等,讓下游居民/政府單位快速理解「風險在哪裡、該做什麼、什麼時候搬運」
  • 定期演練假警與真警的反應流程,並以實際事件驗證模型與門檻設計

國外/實例支撐:

  • 在 Flood Hub 案例中,Google 在 PreventionWeb 的報告就指出:在印度比哈爾(Bihar)地區,有研究發現接受 Flood Hub 提前警報之後的社區,其洪災後的醫療支出降低約 30%,顯示警報若被採納可帶來實際正效益。 (預防網)
  • Flood Hub 也與 NGO、志工組織合作,把 AI 預報轉成「行動任務清單」。例如在印度阿薩姆邦,Red Cross 志工用 Flood Hub 的預報來規劃撤離/物資部署。 (blog.google)
  • 在 Flood Hub 的新版本中,已有針對救援團體/政府端加入「淹水歷史圖層」與「基於 AI 模型推導的下游淹水傳播模擬」工具,讓決策者能看到「如果某條河段水位上升/潰決,那麼水會往哪裡淹」。 (The Living Library)

透過這樣的整合通報機制,AI 不僅是事前告警的角色,更是「決策支援工具」:預報完 → 警報發送 → 行動指引 → 監控校正。


📋 補充與注意事項

項目補充說明 / 風險
模型可解釋性在災害預警場景中,「為什麼這個壩體被標為高風險」要能被專家/政府解釋與信任。黑箱模型可能遭質疑。
門檻設計不宜只用單一固定閾值,而應可動態調整(依歷史事件、當地地形、水文條件)
假警 vs 漏警平衡若 AI 預報過於敏感,可能頻繁發出誤警;若保守又可能漏失,需在設計中折衷
資料稀疏地區挑戰偏遠山區、無測站區域資料可能極少,需要 AI/模式設計特別考慮「無測站流域」或「虛擬測站」策略
模型更新 & 回饋每一次警報或潰流事件,都要納入回饋機制持續調整模型參數與門檻
災害責任與採信若 AI 預報失誤引起損害,責任如何界定?政府與系統提供者的關係要事先釐清

在光復案例中的挑戰與限制

  • 堰塞體本身的不穩定性:自然形成的堰塞體可能包含許多破碎岩、雜石、土壤、水通道與裂隙,其結構比人工壩體複雜且多變,模型難以精確模擬全部內部力學過程。
  • 資料不足或感測覆蓋不全面:在偏遠山區,可能無法佈設足夠密度的感測器,或感測資料傳輸與維護困難。
  • 潰流可能性具備「非線性閾值效應」:在壩體變形、裂縫擴展等過程中,可能出現臨界點(threshold)現象,一旦突破臨界值即快速潰決,模型可能在突破前還無法明顯偵測出異常。
  • 模擬與預測延遲:從資料收集、傳輸、處理到模型輸出都需要時間。在極端條件或突發變化下,延遲可能使預警來不及。
  • 假警與漏警的平衡:若系統設計保守以避免漏警,可能產生過多假警,造成居民疲乏與警戒信任度下降;若設計過於謹慎,又可能錯失真正潰流機會。
  • 責任與信任問題:若 AI 預警系統失誤或延誤導致災害擴大,誰承擔責任?政府、科研機構、系統供應者等可能需要明確界定責任。對居民而言,是否信賴 AI 發出的警報,也是實務上的挑戰。
  • 缺乏歷史潰流事件作為訓練樣本:潰流這類極端事件相對罕見,因此可用於模型訓練的樣本數可能非常有限,不利於模型學習與泛化。

即便面臨這些挑戰,AI 輔助預警仍有潛力特別是在災害監控、危險區識別與搭配人工決策上。未來若以光復為例進行部署,可以考慮從較保守的安全監控與異常偵測開始,逐步累積資料與模型信任度。

四、NCDR 潛勢圖層 vs 實際災情

我實際用 NCDR 疊圖觀察,這是來自 NCDR 3D 災害潛勢地圖 的截圖。勾選的圖層主要是「土石流/山崩潛勢」,地圖上橘色區塊顯示的是潛在大規模崩塌或土石流集水區,紅色小圖示則是「歷史災害事件位置」。

整理一下觀察與解讀:


🗺️ 這張圖告訴我們什麼?

  1. 馬太鞍溪上游確實有多處土石流潛勢區
    • 圖中橘色多邊形分布在馬錫山周圍(靠近馬太鞍溪上游),代表這些區域經模型判定,若有強降雨就可能引發崩塌或土石流。
    • 這和事件發生的脈絡吻合:地震鬆動 + 豪雨觸發 → 上游大量土石下滑 → 形成堰塞湖。
  2. 沿溪下游聚落標註歷史事件
    • 地圖上紅色的「爆炸狀圖示」是歷史土石流/崩塌紀錄點。光復鄉、馬太鞍溪附近本來就有土石流潛勢溪流。
    • 這代表在模型之外,實際上過去已有災害經驗值。
  3. 市區並非「直接土石流區」卻仍受害
    • 這次光復市區被沖淹,不是因為市區本身有土石流潛勢,而是上游堰塞湖潰流帶下來的洪峰。
    • 所以 潛勢圖對「二次影響」(堰塞湖潰流 → 洪峰氾濫)沒有直接涵蓋

🌧️ 事發前 6 小時的累積雨量?

根據中央災害應變中心與媒體報導:

  • 9/22 到 9/24 上午,花蓮縣累積雨量已達 700 mm 左右
  • 專家指出,潰流發生前的幾小時,雨量仍持續集中。雖然公開資料沒明確列出「光復鄉 6 小時累積雨量」,但根據附近雨量站推估,潰流前 6 小時的累積雨量可能落在 100~200 mm 區間(換算相當於每小時 20–40 mm 的持續大雨)。

這樣的降雨量,疊加在先前已經接近飽和的地層與堰塞湖水位上,很容易成為壓垮壩體的最後觸發因子。


📌 怎麼解釋「潛勢圖沒標、卻真的淹」?

  • 潛勢圖用途:是根據地形、坡度、集水面積,判斷「土石流可能的源頭區」。它的重點是「哪裡可能崩塌」,不是「下游會被洪水沖淹到哪裡」。
  • 光復這次狀況:上游崩塌 → 堰塞湖 → 瞬間潰決洪流 → 下游市區受害。這是一個「鏈式災害」。
  • 因此,土石流潛勢圖 + 淹水潛勢圖(前一張圖)必須結合,才有可能模擬出「上游堰塞 → 下游氾濫」的複合情境。

另外再看到 淹水潛勢 → 24 小時降雨 350mm 情境

圖層顯示:

  • 市區(光復鄉東邊、馬太鞍溪下游沿線)有多處藍色區塊,代表在這個降雨情境下,會有 0.5 公尺到 >3 公尺不等的積淹水
  • 馬太鞍溪上游(堰塞湖所在)則沒有特別被標成淹水區,因為這張圖是以「雨量落在低窪處」的模式推算,不會模擬「山崩堵溪 → 突然潰決」的鏈式災害。

📊 這和光復事件的對比

  1. 潛勢圖 vs. 實際事件
    • 潛勢圖模擬的是「如果純粹下 350mm 雨」會積淹在哪裡。
    • 光復事件的關鍵在「堰塞湖潰決」,水量是一次性瞬間釋放。這類事件 不會被單純降雨模擬直接標出來
  2. 市區被標 vs. 馬太鞍溪沒被標
    • 市區出現藍色區塊,代表當有大雨時,這裡本來就排水不良、容易積淹。
    • 馬太鞍溪的潰決洪峰,最後正是往市區衝下來,所以「市區本來就是淹水高風險」的判斷,事後其實和這次事件的結果吻合。
  3. 雨量級別比較
    • 現在看的是 350mm / 24hr 情境。實際上,事發前累積雨量在 2 天內已達 700mm 以上,相當於「連續兩個 350mm 情境疊加」。
    • 而潰決前 6 小時的短延時降雨,估計在 100–200mm 級距。這種降雨強度 + 前期累積,已經超過許多模型的臨界值。

📌 小結

  • 「350mm/24hr 潛勢圖」的藍色區塊,對應的是光復市區「低窪、排水差」的部分,確實和這次事件最終受害地點重疊。
  • 但它沒有顯示堰塞湖溢流這類突發鏈式效應,所以看不到上游馬太鞍溪口的「高風險」。
  • 換句話說,潛勢圖 只能反映背景淹水敏感性,卻無法模擬「潰決洪峰」這種瞬變事件。

① 土石流/山崩潛勢圖層

  • 模擬顯示: 馬太鞍溪上游(靠馬錫山)有多處橘色潛勢區 → 屬於大規模崩塌或土石流潛勢集水區。
  • 實際事件: 4/3 花蓮強震造成山體鬆動,之後豪雨觸發崩塌 → 確實在這些潛勢區段形成堰塞湖。
  • 對比結論:模型有涵蓋到「上游崩塌源頭」的潛勢,但沒往下延伸到「二次效應:堰塞湖潰決」。

② 淹水潛勢圖層(24hr 累積降雨情境)

  • 模擬顯示
    • 350mm/24hr → 光復市區出現 0.5–3 公尺積淹水區。
    • 650mm/24hr → 藍色區域擴大,但主要仍集中在市區與低窪地,馬太鞍溪沿岸未特別標示。
  • 實際事件: 事件前 48 小時累積雨量 ≈ 700mm,潰決前 6 小時估計又下 100–200mm。 洪峰直接沿馬太鞍溪下衝,灌入光復市區 → 與潛勢圖標示的市區高風險區部分重疊。
  • 對比結論:潛勢圖正確指出「市區排水敏感區」;但未能標示「上游潰決洪峰」的影響。

③ 歷史災害紀錄圖層

  • 模擬顯示: 光復周邊已有紅色小圖示 → 歷史土石流或淹水紀錄點。
  • 實際事件: 光復鄉確實成為堰塞湖潰流的直接受災點(沖毀橋梁、鐵道中斷、市區嚴重淹水)。
  • 對比結論:歷史紀錄能凸顯「這裡不是第一次出事」,但資料多屬回顧性,無法即時預警。

📌 總整理對照表

圖層類型模擬涵蓋範圍與光復事件的對照缺口
土石流/山崩潛勢標出上游馬太鞍溪山區有潛勢與實際崩塌位置吻合沒有往下連結到「堰塞湖潰流 → 下游洪患」
淹水潛勢(350mm/650mm/24hr)標出光復市區與低窪地有高風險與實際市區淹水區重疊模擬的是「純降雨積淹水」,非「堰塞湖瞬間潰流」
歷史災害紀錄標示過往土石流與淹水點證明光復本來就有災害敏感性缺乏預測性,只能事後參考

💡 啟示

  1. 潛勢圖單獨使用 → 只能看背景風險
    • 哪裡可能崩、哪裡可能積淹水。
    • 但「鏈式災害」完全不在模擬範圍內。
  2. 實際事件 → 崩塌 + 堰塞湖 + 突然潰決洪峰
    • 這是「短時強降雨 + 前期累積雨量」疊加出來的高衝擊事件。
  3. 缺口補強方式
    • 將「土石流潛勢」+「淹水潛勢」疊合,再加上 AI 即時雨量 & 水位模型
    • 模擬「若上游崩塌堵河 → 在 6 小時內再下 100mm 雨 → 下游哪裡可能氾濫」。
    • 這才有機會提前警告光復市區。
自製:NCDR 工具缺口整理表

五、結論與建議

  • 光復/馬太鞍溪 堰塞湖潰流是一件結合地震誘發、強降雨、地質脆弱性與水文壓力累積的複雜災害。
  • 在國際與學術界,已有不少 AI/機器學習在滑坡、崩塌、土石流、災變偵測、河川水位預測等領域的應用,但針對自然堰塞體潰流的成熟、可靠的 AI 預警系統尚未被廣泛證明可行。
  • 若在臺灣、或特定高風險地區要導入 AI 預警系統,我建議可以一步步來,先從「地滑 / 變形偵測 + 危險區識別」做起,再逐漸累積潰流事件資料進行潰流專門模型訓練。搭配人工專家判讀與多系統驗證,才比較有機會達到實際可用的預警能力。
  • 此外,在設計預警系統時還要特別重視「警報發布時機」、「撤離策略/管控機制」、「假警與漏警風險」以及「責任制度與信任建立」。

Related Posts

【AI Agent 實戰系列】讓 AI 幫你逛街、挑選、結帳:Shopify Storefront MCP 這樣做

把 Shopify Storefront 能力用 MCP 標準化,從工具編排、上下文到事件路由與 UI 回填,打造能「確實完成任務」的 AI 購物體驗。

GPT‑5 調參實戰指南:reasoning_effort × verbosity,三步把速度、成本、品質一次調好

從情境、參數影響、調參策略到驗證門檻,一篇學會用 reasoning_effort × verbosity 做可治理的 GPT‑5 產品化工作流。附閾值表、回退偽碼與下載檢查表。

發表迴響

%d 位部落客按了讚: