使用機器學習援助倖存者並與時間賽跑

2023 年 2 月 6 日，土耳其東南部發生里氏 7.7 級和 7.6 級地震，影響了 10 個城市，截至 2 月 21 日，已造成超過 42,000 人死亡和 120,000 人受傷。

地震發生後數小時，一群程式設計師啟動了一個 Discord 伺服器，以推出名為 _afetharita_ 的應用程式，字面意思為“災難地圖”。該應用程式將為搜救隊和志願者提供服務，以尋找倖存者併為他們提供幫助。倖存者在社交媒體上釋出包含其地址和所需物品（包括救援）的簡訊截圖後，產生了對這種應用程式的需求。一些倖存者還在推特上釋出了他們所需物品，以便他們的親屬知道他們還活著並需要救援。為了從這些推文中提取資訊，我們開發了各種應用程式，將其轉換為結構化資料，並爭分奪秒地開發和部署這些應用程式。

當我被邀請加入 Discord 伺服器時，關於我們（志願者）如何運作以及我們將做什麼，存在相當多的混亂。我們決定協作訓練模型，因此我們需要一個模型和資料集註冊表。我們開了一個 Hugging Face 組織賬戶，並透過拉取請求進行協作，以構建基於機器學習的應用程式來接收和處理資訊。

其他團隊的志願者告訴我們，需要一個應用程式來發布螢幕截圖，從螢幕截圖中提取資訊，對其進行結構化，並將結構化資訊寫入資料庫。我們開始開發一個應用程式，它將獲取給定影像，首先提取文字，然後從文字中提取姓名、電話號碼和地址，並將這些資訊寫入將移交給當局的資料庫。在嘗試了各種開源 OCR 工具後，我們開始使用 easyocr 進行 OCR 部分，並使用 Gradio 構建此應用程式的介面。我們還被要求構建一個獨立的 OCR 應用程式，因此我們從介面中開放了端點。OCR 的文字輸出使用基於 transformers 的微調 NER 模型進行解析。

為了協作和改進應用程式，我們將其託管在 Hugging Face Spaces 上，並獲得了 GPU 撥款以保持應用程式的執行。Hugging Face Hub 團隊為我們設定了一個 CI 機器人，使我們能夠擁有一個臨時環境，這樣我們就可以看到拉取請求將如何影響 Space，這在拉取請求審查期間幫助了我們。

後來，我們從各種渠道（例如 Twitter、Discord）獲得了帶有幸存者求助原始推文的標註內容，以及從其中提取的地址和個人資訊。我們開始嘗試對閉源模型進行少量提示和對我們自己的基於 Transformer 的標記分類模型進行微調。我們使用 bert-base-turkish-cased 作為標記分類的基礎模型，並提出了第一個地址提取模型。

該模型後來被用於 `afetharita` 以提取地址。解析後的地址將傳送到地理編碼 API 以獲取經度和緯度，然後地理位置將顯示在前端地圖上。對於推理，我們使用了推理 API，這是一個託管模型用於推理的 API，當模型推送到 Hugging Face Hub 時會自動啟用。使用推理 API 進行服務使我們免於拉取模型、編寫應用程式、構建 docker 映象、設定 CI/CD 以及將模型部署到雲實例，這對於 DevOps 和雲團隊來說都是額外的開銷工作。Hugging Face 團隊為我們提供了更多的副本，以確保沒有停機時間，並且應用程式能夠抵禦大量流量。

後來，我們被問到是否可以從給定的推文中提取地震倖存者的需求。我們得到的資料包含給定推文中多項需求的多個標籤，這些需求可能是避難所、食物或物流，因為那裡非常寒冷。我們首先嚐試了在 Hugging Face Hub 上使用開源 NLI 模型進行零樣本實驗，以及使用閉源生成模型端點進行少量樣本實驗。我們嘗試了 xlm-roberta-large-xnli 和 convbert-base-turkish-mc4-cased-allnli_tr。NLI 模型特別有用，因為我們可以直接使用候選標籤進行推斷，並在資料漂移發生時更改標籤，而生成模型可能會編造標籤並在向後端提供響應時導致不匹配。我們最初沒有標註資料，所以任何方法都可以。

最終，我們決定微調我們自己的模型，因為在單個 GPU 上微調 BERT 的文字分類頭大約需要三分鐘。我們進行了一項標註工作，以開發用於訓練此模型的資料集。我們將實驗記錄在模型卡的元資料中，以便以後可以建立一個排行榜，以跟蹤哪個模型應該部署到生產環境。對於基礎模型，我們嘗試了 bert-base-turkish-uncased 和 bert-base-turkish-128k-cased，並發現它們的效能優於 bert-base-turkish-cased。您可以在此處找到我們的排行榜。

考慮到手頭的任務和資料類的不平衡，我們專注於消除誤報，並建立了一個 Space 來基準測試所有模型的召回率和 F1 分數。為此，我們向所有相關模型倉庫添加了元資料標籤 deprem-clf-v1，並使用此標籤自動檢索記錄的 F1 和召回分數並對模型進行排名。我們有一個單獨的基準測試集，以避免洩露到訓練集並持續基準測試我們的模型。我們還基準測試了每個模型，以確定每個標籤的最佳部署閾值。

我們希望對我們的 NER 模型進行評估並進行眾包，因為資料標註人員正在努力為我們提供更好和更新的意圖資料集。為了評估 NER 模型，我們使用 `Argilla` 和 `Gradio` 設定了一個標註介面，人們可以在其中輸入一條推文並將輸出標記為正確/不正確/模糊。

隨後，資料集經過去重，並用於進一步實驗的基準測試。

機器學習團隊的另一個小組與生成模型（在受控 API 之後）合作，以自由文字的形式獲取具體需求（因為標籤過於寬泛），並將文字作為附加上下文傳遞給每個帖子。為此，他們進行了提示工程，並將 API 端點封裝為單獨的 API，並將其部署到雲端。我們發現，在資料漂移快速發展的情況下，使用 LLM 進行少量提示有助於調整細粒度需求，因為我們只需要調整提示，而不需要任何標註資料。

這些模型目前正在生產中使用，以在下面的熱圖中建立點，以便志願者和搜救隊可以為倖存者提供所需物品。

我們意識到，如果沒有 Hugging Face Hub 及其生態系統，我們將無法如此快速地協作、原型設計和部署。以下是我們的地址識別和意圖分類模型的 MLOps 管道。

這個應用程式及其各個元件背後有數十名志願者，他們不眠不休地工作，在如此短的時間內完成了這些工作。

遙感應用

其他團隊則致力於遙感應用，以評估建築物和基礎設施的損壞情況，旨在指導搜救行動。地震發生後的最初 48 小時內，電力和穩定的行動網路缺乏，加上道路坍塌，使得評估損失程度以及哪裡需要幫助變得極其困難。搜救行動也受到通訊和交通困難導致的虛假報告（關於建築物倒塌和損壞）的嚴重影響。

為解決這些問題並建立未來可利用的開源工具，我們首先從 Planet Labs、Maxar 和 Copernicus Open Access Hub 收集了受災區域的地震前後衛星影像。

我們最初的方法是快速標註衛星影像，用於目標檢測和例項分割，只設置一個“建築物”類別。目的是透過比較同一區域地震前後影像中倖存建築物的數量來評估損壞程度。為了更容易訓練模型，我們首先將 1080x1080 衛星影像裁剪成更小的 640x640 塊。接下來，我們微調了 YOLOv5、YOLOv8 和 EfficientNet 模型用於建築物檢測，以及一個 SegFormer 模型用於建築物的語義分割，並將這些應用程式部署為 Hugging Face Spaces。

數十名志願者再次參與了標註、資料準備和模型訓練工作。除了個人志願者，Co-One 等公司也自願標註衛星資料，對建築物和基礎設施進行更詳細的標註，包括“無損壞”、“已毀壞”、“已損壞”、“損壞設施”和“未損壞設施”標籤。我們目前的目標是釋出一個廣泛的開源資料集，以便未來加速全球範圍內的搜救行動。

總結

對於這種極端情況，我們必須迅速行動，並最佳化分類指標，即使是百分之一的改進也至關重要。在此過程中，有許多倫理討論，因為甚至選擇要最佳化的指標本身就是一個倫理問題。我們已經看到開源機器學習和民主化如何使個人能夠構建拯救生命的應用程式。我們感謝 Hugging Face 背後的社群釋出這些模型和資料集，以及 Hugging Face 團隊提供的基礎設施和 MLOps 支援。