使用机器学习来帮助幸存者并穿越时间
'应用机器学习帮助幸存者穿越时间'
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，并在拉取请求审查期间帮助我们。
后来，我们从各个渠道（如推特、Discord）获得了带有幸存者求助的原始推文的标记内容，以及从中提取出的地址和个人信息。我们首先尝试了使用开源NLI模型和transformers上的少量提示进行实验，然后对我们自己的标记分类模型进行微调。我们使用了bert-base-turkish-cased作为标记分类的基础模型，并开发出了第一个地址提取模型。
该模型后来被用于afetharita中提取地址。解析出的地址将被发送到一个地理编码API来获取经度和纬度，然后地理位置将在前端地图上显示出来。对于推理，我们使用了Inference API，这是一个用于托管推理模型的API，当模型被推送到Hugging Face Hub时，它会自动启用。使用Inference API进行服务可以节省我们从拉取模型、编写应用程序、构建Docker镜像、设置CI/CD以及将模型部署到云实例的工作量，这对于DevOps和云团队来说都是额外的工作量。Hugging Face团队为我们提供了更多的副本，以确保没有停机时间，并且应用程序能够抵御大量的流量。
后来，有人问我们是否可以从给定的推文中提取地震幸存者的需求。我们获得了包含给定推文中多个标签和多个需求的数据，这些需求可以是住所、食物或后勤支持，因为当时那里非常寒冷。我们首先尝试了在Hugging Face Hub上使用开源NLI模型的零-shot实验和使用闭源生成模型端点的少量-shot实验。我们尝试了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。您可以在这里找到我们的排行榜。
考虑到目前的任务和我们数据类别的不平衡，我们专注于消除假阴性并创建了一个空间，用于对所有模型的召回率和F1得分进行基准测试。为此，我们将元数据标签deprem-clf-v1添加到所有相关的模型仓库中，并使用此标签自动检索记录的F1得分和召回率，并对模型进行排序。我们还有一个单独的基准测试集，以避免泄漏到训练集，并始终对我们的模型进行基准测试。我们还对每个标签的每个模型进行基准测试，以确定部署的最佳阈值。
我们希望对我们的NER模型进行评估，并通过众包的方式进行努力，因为数据标注者正在努力为我们提供更好和更新的意图数据集。为了评估NER模型，我们使用Argilla和Gradio建立了一个标注界面，人们可以在其中输入一条推文，并将输出标记为正确/不正确/模糊。
随后，我们对数据集进行了去重，并用它来评估我们的进一步实验。
机器学习团队的另一个小组使用生成模型（在一个带门的API后面）来获取特定需求（因为标签过于宽泛）作为自由文本，并将文本作为附加上下文传递给每个帖子。为此，他们进行了提示工程，并将API端点封装为一个单独的API，并在云上部署。我们发现，在快速发展的数据漂移存在的情况下，使用少量提示与LLMs一起可以适应细粒度需求，因为我们唯一需要调整的是提示，而不需要任何标记数据。
这些模型目前正在生产中使用，以创建下面热图中的点，以便志愿者和搜救队能够将需求带给幸存者。
我们意识到，如果没有Hugging Face Hub和生态系统，我们将无法快速进行协作、原型设计和部署。下面是我们用于地址识别和意图分类模型的MLOps管道。
有数十名志愿者参与了这个应用程序及其各个组件的开发工作，他们为了在如此短的时间内完成这些工作而辛勤努力，几乎没有休息。
遥感应用
其他团队致力于遥感应用，以评估建筑物和基础设施的损坏程度，以便指导搜救行动。在地震发生的最初48小时内，由于电力和稳定的移动网络的缺乏，以及道路的倒塌，评估损坏程度和帮助的位置变得极其困难。搜救行动还受到错误报告倒塌和损坏建筑物的严重影响，这是由于通信和交通困难造成的。
为了解决这些问题并创建未来可利用的开源工具，我们首先从Planet Labs、Maxar和Copernicus开放获取中收集了受影响区域的地震前后卫星图像。
我们最初的方法是快速标记卫星图像以进行目标检测和实例分割，其中单一类别为“建筑物”。目的是通过比较来自同一区域的地震前后图像中幸存建筑物的数量来评估损坏程度。为了使模型训练更容易，我们首先将1080×1080的卫星图像裁剪成较小的640×640块。接下来，我们对建筑物检测进行了YOLOv5、YOLOv8和EfficientNet模型的微调，对建筑物进行了语义分割的SegFormer模型进行了微调，并将这些应用程序部署为Hugging Face Spaces。
再次，数十名志愿者参与了标注、准备数据和训练模型的工作。除了个人志愿者外，像Co-One这样的公司还自愿为卫星数据标注更详细的建筑和基础设施注释，包括无损坏、破坏、受损、受损设施和完好设施等标签。我们目前的目标是发布一份广泛的开源数据集，以便在未来加快全球搜救行动。
总结
对于这种极端用例，我们必须迅速行动，并优化分类指标，即使提升百分之一的改进也很重要。在进展中有许多伦理讨论，因为甚至选择要优化的指标也是一个伦理问题。我们看到了开源机器学习和民主化如何使个人能够构建拯救生命的应用程序。我们感谢Hugging Face社区发布这些模型和数据集，以及Hugging Face团队的基础设施和MLOps支持。
