從資訊整理，到協助現場做出更好的決策

前幾篇談到救災現場的資訊問題。這篇想把視角拉回產品本身，討論如果真的建立一個救災協作平台，AI 在裡面究竟可以扮演什麼角色。

Day 20 談的是如何利用 AI 更快把產品做出來，今天則聚焦在 AI 如何成為救災協作流程的一部分。這個差異很重要，因為在高風險場域裡，AI 的價值往往來自它能否處理大量、混亂且持續變動的資訊，協助人快速理解情況，讓人的注意力可以放在真正需要判斷的地方。

救災現場每天都會產生大量資訊。LINE 群組裡有人說某個村落缺水，另一個人上傳一張淹水照片，志工回報某條道路已經無法通行，地方組織又提供了一份物資需求清單。這些資訊來自不同的人、不同的管道，也有不同的格式與可信度。對人來說,真正困難的是在有限時間裡把這些訊息拼成一張可以理解的「災情圖」。

01｜災情理解：讓 AI 把混亂資訊轉成可用的情境

AI 第一個可以發揮作用的地方，是把非結構化資訊轉換成結構化的災情資料。

例如一則志工回報:「花蓮某地目前有十幾戶家裡進水，需要抽水機跟人手，附近道路目前還可以通，但大型車輛進不來。」

對人而言，這是一段自然語言。對系統而言，它其實包含了很多重要欄位:地點、災害類型、受影響戶數、需求資源、需求數量、道路狀況與可能的運輸限制。透過 LLM，這些資訊可以被抽取成標準化資料，再進入平台的任務與資源管理流程。

這會讓平台從單純的「資訊展示工具」，逐漸具備理解資訊的能力。

另一個很重要的問題是資訊去重。大型災害發生時，同一個事件可能被不同人重複回報。A 志工說某個社區缺水，B 志工十分鐘後再次回報相同地點，C 志工又從另一個群組貼了一張照片。若系統把三筆資訊都視為三個獨立事件，很快就會造成需求數量膨脹，讓協調者誤以為某些區域的需求特別高。

AI 可以利用地點、時間、文字內容、圖片與其他 metadata 判斷不同回報是否可能指向同一事件，再交由協調者確認與合併。這種能力對救災平台非常關鍵，因為資訊量增加之後，「整理資訊」本身就會成為一項高負荷工作。

實際落地時，合併不建議由 AI 自動執行，而是提供「疑似重複」的候選清單，讓協調者一鍵確認。例如系統可以呈現:「這 3 則回報疑似指向同一事件（地點相符、時間相距 15 分鐘內、文字內容高度相似），是否合併為單一任務？」協調者確認後，原始的三筆回報仍會保留在合併後任務的紀錄中，作為佐證來源，而不是直接被覆蓋或刪除。這樣一來，即使合併判斷有誤，也能追溯回原始資訊重新拆分，避免因為錯誤合併而遺漏真正獨立的需求。

02｜資源媒合：理解需求，也理解手上的資源

當災情被整理成結構化資訊之後，下一個問題就會出現:誰可以處理這個需求?

傳統系統通常需要使用者自行搜尋。例如前線填寫「需要清淤」，後台協調者再去找有哪些志工、設備或民間組織可以支援。但救災資源的描述方式往往很不一致。

有人會寫「需要清淤人力」，有人寫「徵求三名鏟泥志工」，也有人說「我們有一台小山貓，可以支援土石清運」。這些文字表面上差異很大，背後卻可能存在高度相關的需求與供給。

語意模型可以在這裡建立一個中間層，把「需求」與「資源」轉換到共同的語意空間，再找出可能的匹配關係。例如「需要清淤人力」可能對應到「有三名具備清淤經驗的志工」，也可能對應到「提供小型挖土機與操作人員」。

救災媒合不能只看語意相似度。距離、道路狀況、交通時間、資源數量、志工技能、可支援時間，以及目前是否已經被其他任務占用，都會影響這個媒合是否真的可行。假設一台設備距離災區只有 20 公里，但中間道路已經中斷，這個「高相似度」的媒合其實沒有實際價值。

因此，AI 的角色可以設計成「候選方案產生器」。AI 快速掃描大量需求與供給，找出可能的配對，再把距離、道路、時間等 hard constraints 加入排序，最後呈現給協調者確認。

03｜任務分派：AI 可以幫忙排序，但最後的決策仍需要人

當平台開始累積大量待處理任務，下一個問題就是優先順序。

假設系統同時收到 100 個需求，協調者不可能按照收到的時間逐一處理。平台需要回答:現在最應該處理哪一件?

這裡可以建立一套任務優先級模型，綜合考慮災情急迫度、受影響人數、資源稀缺度、目前可行性，以及任務延遲可能造成的風險。

一個「有 50 人等待飲水」的需求，可能比「某個公共空間需要清潔」更優先;一個距離前線只有 10 公里的物資需求，可能比一個距離 100 公里、交通又受到限制的需求更容易立即執行。

AI 可以根據這些條件協助產生排序與推薦，例如告訴協調者:「目前有 8 個高優先級任務，其中 3 個已有可用資源，建議優先確認這 3 個。」

這裡也會進入 Human-in-the-loop 的設計。

救災場景裡，AI 不會自己決定「派誰去、送什麼、什麼時候執行」。AI 可以提出建議，但任務執行仍需要由具備現場脈絡的人確認。系統可能沒有掌握最新的道路狀況，也可能無法知道某個志工目前已經疲勞、某個組織正在處理更緊急的任務，甚至可能遇到災情快速變化的情況。

一個比較合理的介面可能會長這樣:

「AI 建議:將任務 A 指派給志工團隊 B，預估距離 8.2 公里，具備相關技能，目前有 4 人可用。」

協調者可以接受、修改或拒絕這個建議，同時看到 AI 為什麼做出這個推薦。

這種設計讓 AI 負責大量資訊的搜尋與計算，人負責理解現場脈絡與承擔決策責任。

04｜高風險場域裡，AI 的錯誤需要被設計進系統

當 AI 開始參與災情理解與任務分派，風險也會跟著進入產品。

最直觀的問題就是 hallucination。假設 AI 從一段模糊的訊息中推測出一個災情地點，最後系統卻把它當成已確認事件，錯誤資訊可能進一步影響資源調度。

另一個問題是惡意或錯誤回報。如果有人故意提交假的災情，或者資訊來源本身就不可靠，AI 再精準地整理這些資料，也可能得到錯誤的結論。

平台需要建立資訊可信度與驗證機制。例如標示資料來源、回報時間、是否經過人工確認、是否有多個獨立來源交叉驗證，並且保留原始內容讓協調者可以回溯。

在介面設計上，這套可信度機制也應該轉換成明確的警示標籤，而不是只存在後台資料庫裡。例如:

• 「僅單一來源，尚未交叉驗證」— 提醒協調者這則回報還未被其他管道證實，調度資源前建議先確認。
• 「回報內容與地圖定位不一致」— 當文字描述的地點和照片 metadata 或使用者定位有落差時跳出提示，避免誤派任務到錯誤地點。
• 「短時間內同帳號／同來源大量回報」— 可能是熱心志工密集更新，也可能是異常灌單行為，系統應該標示出來讓人判斷，而不是自動採信或自動忽略。
• 「AI 信心度偏低」— 當抽取的地點、需求數量等欄位是模型推測而非明確寫在原文中時，明確標示「AI 推測」而非「已確認」，避免協調者誤以為是原始回報內容。

這些警示的目的不是阻止資訊進入系統，而是讓每一筆資料在被使用時，都附帶足夠的脈絡，讓協調者知道該用什麼態度看待它。

更重要的是 fallback。

當 AI 無法判斷時，系統應該允許它清楚地表示「目前無法確認」，並將案件交給人工處理。當 AI 的推薦與現場人員判斷衝突時，也應該保留人工覆寫的權限。當模型服務中斷時，核心任務流程仍然需要能夠運作。

這也呼應了前面醫療 AI 系列裡談到的概念:在高風險系統裡，AI 的能力越強，越需要清楚定義它的決策邊界。

05｜從資訊平台走向決策支援系統

把前面的能力串起來，可以看到一個更完整的流程:

前線產生大量原始資訊，AI 協助理解與結構化;系統將需求與資源建立關聯，AI 找出可能的媒合方案;當任務數量增加，AI 協助排序與推薦;最後由人確認、調整並執行。

這時候，平台的角色就開始改變。

它不只是讓大家「看到災情」，也開始協助協調者理解現在發生什麼、有哪些資源可以使用、哪些任務值得優先處理，以及不同決策可能帶來什麼結果。

這也是持續關注 Decision Support System 的原因。當 AI 進入高風險場域後，真正值得設計的問題會逐漸從「AI 能不能回答問題?」變成「AI 如何參與一個真實的決策流程?」

救災只是其中一個很典型的案例。

如果今天 AI 已經可以理解災情、媒合資源、協助分派任務，那下一個問題就會變得更有意思:當這些能力再往前一步，AI 能不能開始預測需求?能不能在災害發生前協助配置資源?不同組織的 AI Agent 能不能彼此溝通、協商與協作?

這會是 Day 22 要繼續往下探索的問題。

下一代救災 AI，可能會開始從「協助人處理災情」走向「協助整個救災網絡進行協作」。真正值得觀察的，也就從單一產品的功能，進一步變成整個救災系統的運作方式。