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 支撑。
原文: hf.co/blog/using-…
作者: Merve Noyan、Alara Dirik
译者: innovation64(李洋)
审校: zhongdongy (阿东)
