使用机器学习援助幸存者并与时间赛跑

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 支持。