共计 3436 个字符，预计需要花费 9 分钟才能阅读完成。
2023 年 2 月 6 日，土耳其东南部产生 7.7 级和 7.6 级地震，影响 10 个城市，截至 2 月 21 日已造成 42,000 多人死亡和 120,000 多人受伤。
地震产生几个小时后，一群程序员启动了一个 Discord 服务，推出了一个名为 afetharita 的应用程序，字面意思是 劫难地图。该应用程序将为搜救队和志愿者提供服务，以寻找幸存者并为他们提供帮忙。当幸存者在社交媒体上公布带有他们的地址和他们须要的货色 (包含救济) 的文本截图时，就须要这样一个应用程序。一些幸存者还在公布了他们须要的货色，这样他们的亲属就晓得他们还活着并且须要救济。须要从这些推文中提取信息，咱们开发了各种应用程序将它们转化为结构化数据，并争分夺秒的开发和部署这些应用程序。
当我被邀请到 Discord 服务时，对于咱们 (志愿者) 将如何运作以及咱们将做什么的问题弄得十分凌乱。咱们决定合作训练模型，并且咱们须要一个模型和数据集注册表。咱们开设了一个 Hugging Face 组织帐户，并通过拉取申请进行合作，以构建基于 ML 的应用程序来接管和解决信息。
其余团队的志愿者通知咱们，须要一个应用程序来公布屏幕截图，从屏幕截图中提取信息，对其进行结构化并将结构化信息写入数据库。咱们开始开发一个应用程序，该应用程序将拍摄给定图像，首先提取文本，而后从文本中提取姓名、电话号码和地址，并将这些信息写入将交给当局的数据库。在尝试了各种开源 OCR 工具之后，咱们开始应用 easyocrOCR 局部和 Gradio 为此应用程序构建界面。咱们还被要求为 OCR 构建一个独立的应用程序，因而咱们从界面关上了接口。应用基于 transformer 的微调 NER 模型解析 OCR 的文本输入。
为了合作和改良该应用程序，咱们将其托管在 Hugging Face Spaces 上，并且咱们取得了 GPU 赞助以放弃该应用程序的失常运行。Hugging Face Hub 团队为咱们设置了一个 CI 机器人，让咱们领有一个短暂的环境，这样咱们就能够看到拉取申请如何影响 Space，并且帮忙咱们在拉取申请期间审查。
起初，咱们从各种渠道 (例如 Twitter、Discord) 取得了带有标签的内容，其中包含幸存者求救电话的原始推文，以及从中提取的地址和个人信息。咱们开始尝试应用闭源模型的大量提醒和微调来自 transformers 的咱们本人的 token 分类模型。咱们应用 bert-base-turkish-cased 作为 token 分类的根底模型，并提出了第一个地址提取模型。
该模型起初用于 afetharita 提取地址。解析后的地址将被发送到天文编码 API 以获取经度和纬度，而后天文定位将显示在前端地图上。对于推理，咱们应用了 Inference API，这是一个托管模型进行推理的 API，当模型被推送到 Hugging Face Hub 时会主动启用。应用 Inference 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 的文本分类头大概须要三分钟。咱们进行了标记工作来开发数据集去训练该模型。咱们在模型卡的元数据中记录了咱们的试验，这样咱们当前就能够出一个 leaderboard 来跟踪应该将哪个模型部署到生产环境中。对于根本模型，咱们尝试了 bert-base-turkish-uncased 和 bert-base-turkish-128k-cased 并发现它们的性能优于 bert-base-turkish-cased。你能够在 上面的链接 找到咱们的 leaderboard。
思考到手头的工作和咱们数据类别的不均衡，咱们专一于打消假阴性并创立了一个 Space 来对所有模型的召回率和 F1 分数进行基准测试。为此，咱们将元数据标签增加 deprem-clf-v1 到所有相干模型存储库中，并应用此标签自动检索记录的 F1 和召回分数以及模型排名。咱们有一个独自的基准测试集，以防止透露到训练集，并始终如一地对咱们的模型进行基准测试。咱们还对每个模型进行了基准测试，以确定每个标签的最佳部署阈值。
咱们心愿对咱们的命名实体辨认模型进行评估，并发动了众包致力，因为数据标记者正在致力为咱们提供更好和更新的用意数据集。为了评估 NER 模型，咱们应用 Argilla 和 Gradio 搭建了一个标注界面，人们能够输出一条推文，并将输入标记为正确 / 不正确 / 含糊。
起初，数据集被去重并用于基准测试咱们的进一步试验。
机器学习团队中的另一个小组应用生成模型 (通过门控 API) 来获取特定需要 (因为标签过于宽泛) 的自在文本，并将文本作为每个帖子的附加上下文传递。为此，他们进行了提醒工程，并将 API 接口包装为独自的 API，并将它们部署在云端。咱们发现，应用 LLM 的少样本提醒有助于在疾速倒退的数据漂移存在的状况下适应细粒度的需要，因为咱们须要调整的惟一的货色是提醒，而且咱们不须要任何标记的数据。
这些模型目前正在生产中应用，以创立上面热图中的点，以便志愿者和搜救团队能够将需要带给幸存者。
咱们曾经意识到，如果没有 Hugging Face Hub 和其生态系统，咱们将无奈如此疾速地合作、制作原型和部署。上面是咱们用于地址辨认和用意分类模型的 MLOps 流水线。
这个应用程序及其各个组件背地有数十名志愿者，他们不眠不休地工作以在如此短的工夫内就实现了。
遥感利用
其余团队致力于遥感利用，以评估建筑物和基础设施的损坏状况，以领导搜寻和救济口头。地震产生后的最后 48 小时内，电力和挪动网络都没有稳固，再加上路线倒塌，这使得评估损坏水平和须要帮忙的中央变得极其艰难。因为通信和运输艰难，搜救口头也因建筑物倒塌和损坏的虚伪报告而受到重大影响。
为了解决这些问题并创立可在将来利用的开源工具，咱们首先从 Planet Labs、Maxar 和 Copernicus Open Access Hub 收集受影响区域的震前和震后卫星图像。
咱们最后的办法是疾速标记卫星图像以进行指标检测和实体宰割，并应用“建筑物”的繁多类别。目标是通过比拟从同一地区收集的震前和震后图像中幸存建筑物的数量来评估损坏水平。为了更容易训练模型，咱们首先将 1080×1080 的卫星图像裁剪成更小的 640×640 块。接下来，咱们微调了用于建筑物检测的 YOLOv5、YOLOv8 和 EfficientNet 模型以及用于建筑物语义宰割的 SegFormer 模型，并将这些利用部署到 Hugging Face Spaces。
同样，数十名志愿者致力于标记、筹备数据和训练模型。除了集体志愿者外，像 Co-One 这样的公司也被迫为卫星数据进行更具体的修建和基础设施正文标记，包含 无损伤 、 被捣毁 、 受损 、 受损设施 和 未受损设施 标签。咱们以后的指标是公布一个宽泛的开源数据集，以便在将来放慢寰球的搜救口头。
总结
对于这种极其利用案例，咱们必须迅速行动，并优化分类指标，即便 1% 的改良也很重要。在此过程中有许多伦理探讨，因为甚至抉择要优化的指标也是一个伦理问题。咱们曾经看到了开源机器学习和民主化是如何使集体可能构建解救生命的应用程序。
咱们感激 Hugging Face 社区公布这些模型和数据集，以及 Hugging Face 团队提供的基础架构和 MLOps 反对。
原文: https://hf.co/blog/using-ml-for-disasters
作者: Merve Noyan、Alara Dirik
译者: innovation64(李洋)
审校: zhongdongy (阿东)
