6 февраля 2023 года два землетрясения магнитудой 7.8 и 7.5 разрушили обширные районы на юго-востоке Турции и севере Сирии. Погибли десятки тысяч человек, миллионы остались без крова. В первые часы после катастрофы появился хаотичный поток сообщений от пострадавших: скриншоты с адресами под завалами, голосовые с просьбами о еде и воде, тексты на турецком, арабском, курдском и английском. Волонтёры физически не успевали обрабатывать эти данные вручную. На этот вызов отреагировала распределённая команда ML-инженеров: за несколько дней они развернули пайплайн на открытых моделях, который извлекал адреса и телефоны, классифицировал потребности и помогал оценивать ущерб по спутниковым снимкам. Этот кейс показывает, как open-source экосистема и коллаборация сообщества работают в экстремальных условиях, когда счёт идёт на часы.
Ключевой принцип был один: скорость развёртывания важнее идеальной точности. Команда сознательно выбирала готовые модели с Hugging Face Hub, дообучала их на минимальных наборах данных и сразу выкатывала в прод. Никаких длительных циклов разработки. Никаких закрытых enterprise-платформ. Только открытые инструменты, которые можно форкнуть, адаптировать и запустить за один вечер.
Похожий подход к быстрой оценке моделей и безопасной работе с ними мы разбирали в статье про чтение model card и расхождение safety-метрик между бенчмарком и продом. Там же есть практические чек-листы для инженеров, которые внедряют AI в production.
Введение: вызов землетрясения и роль ML
Землетрясения затронули 10 провинций Турции с населением около 13.5 миллиона человек. Связь работала нестабильно, но сообщения всё равно шли: через WhatsApp, Telegram, Twitter, Instagram. Люди писали из-под завалов, сообщали координаты родственников, просили палатки, лекарства, тёплую одежду. Координационные центры тонули в этом потоке. Ручная сортировка одного сообщения занимала от 30 секунд до нескольких минут, а сообщений были сотни тысяч.
Волонтёрская команда сформулировала три задачи: извлечь структурированные данные из неструктурированных сообщений, классифицировать потребности и оценить масштаб разрушений. Для первой задачи использовали связку OCR и NER. Для второй - zero-shot классификацию на базе NLI. Для третьей - детекцию и сегментацию спутниковых снимков моделями YOLO и SegFormer. Вся инфраструктура развернулась на Hugging Face Hub: Spaces для интерфейсов, Inference API для обработки запросов, CI-боты для автоматической проверки моделей.
Важно понимать контекст: у команды не было доступа к мощным локальным GPU в первые дни. Облачные ресурсы предоставлялись волонтёрами и частично самим Hugging Face. Это накладывало ограничения на размер моделей и батчей, но не на скорость итераций.
Обработка сообщений пострадавших: извлечение адресов и номеров телефонов
Сообщения приходили в виде скриншотов переписок, фотографий рукописных записок, текстовых постов. Часто с опечатками, смешанными языками и обрезанными краями. Задача извлечения адресов и телефонов решалась в два этапа: сначала OCR переводил изображение в текст, затем NER-модель вычленяла нужные сущности.
OCR: распознавание текста со скриншотов
Для OCR выбрали комбинацию Tesseract и облачных API. Tesseract работал офлайн и не зависел от внешних сервисов, что критично при нестабильном интернете. Облачные API давали лучшее качество на сложных изображениях, но требовали стабильного соединения. На практике использовали гибрид: Tesseract для быстрого первого прохода, облачный OCR для спорных случаев.
Главная проблема - языковая поддержка. Турецкий алфавит содержит символы ç, ğ, ı, ö, ş, ü, которые Tesseract часто путал с похожими латинскими буквами. Арабский текст в сообщениях сирийских беженцев распознавался с ошибками из-за сложной вязи. Решение: предобработка изображений, повышение контраста, обрезка лишних элементов, а также постобработка текста с учётом частотности турецких слов и типичных ошибок распознавания. Это подняло качество OCR на 15-20% по символьной точности.
Ограничения были честными: рукописный текст распознавался плохо, особенно на фотографиях с низким разрешением. Такие сообщения отправляли волонтёрам на ручную проверку через интерфейс на Spaces.
NER на базе BERT: точное извлечение адресов и телефонов
Для извлечения адресов и номеров телефонов использовали предобученную модель bert-base-NER с Hugging Face. Базовая модель уже умела находить локации, организации и персон, но не была адаптирована под турецкие адреса и специфику кризисных сообщений. Команда быстро разметила около 2000 примеров и дообучила модель за несколько часов на одной GPU.
Формат адресов в Турции специфичен: район (mahalle), улица (sokak/cadde), номер дома, иногда ориентиры вроде «рядом с мечетью» или «за школой». Телефоны записывались в разных форматах: с кодом страны +90, без него, с пробелами и дефисами. NER-модель после fine-tuning достигла recall 0.89 и F1 0.87 на тестовой выборке. Этого хватало для автоматической обработки большинства сообщений, остальное уходило на ручную проверку.
Пример извлечения: из сообщения «Мы под завалами на Atatürk Caddesi 45, рядом с банком, позвоните +90 532 123 45 67» модель корректно выделяла адрес «Atatürk Caddesi 45» и телефон «+90 532 123 45 67». Ошибки возникали на неполных адресах и сообщениях без чёткой структуры.
Классификация потребностей: zero-shot с NLI
После извлечения адреса нужно было понять, что именно требуется: кров, еда, вода, медикаменты, эвакуация, логистика. Размечать тысячи сообщений по категориям не было времени. Поэтому выбрали zero-shot классификацию на базе Natural Language Inference.
Модель BART-large-MNLI оценивает, насколько гипотеза «Человеку нужен кров» следует из текста сообщения. Для каждой категории задавалась гипотеза, модель выдавала вероятность entailment. Если вероятность превышала порог 0.7, сообщение относили к категории. Одно сообщение могло попасть в несколько категорий.
Почему zero-shot: преимущества в условиях ограниченных данных
Традиционная классификация требует размеченного датасета и времени на обучение. Zero-shot позволил запустить систему за несколько часов: определили категории, написали гипотезы, подключили модель. Когда появлялась новая потребность, например «детское питание», достаточно было добавить новую гипотезу без переобучения.
Точность zero-shot была ниже, чем у обученного классификатора: F1 около 0.7-0.75 на основных категориях. Но выигрыш во времени запуска перевешивал. Волонтёры проверяли сомнительные случаи вручную, а модель быстро отсеивала очевидные сообщения.
Организация пайплайна через Hugging Face Hub
Hugging Face Hub стал центральным узлом всей системы. Здесь хранились модели, датасеты, демо-интерфейсы и скрипты автоматизации. Открытость платформы позволяла любому волонтёру подключиться к работе: форкнуть репозиторий, улучшить модель, отправить pull request.
Spaces и Inference API: быстрый прототип и масштабирование
Spaces на базе Gradio использовались для создания интерфейсов проверки. Волонтёр вставлял текст сообщения или загружал скриншот, система показывала извлечённые сущности и предсказанную категорию. Это ускорило ручную верификацию в несколько раз.
Inference API обеспечивал программный доступ к моделям для интеграции с другими системами: чат-ботами, формами ввода, дашбордами координаторов. Запросы шли по HTTP, что позволяло подключать любые клиенты без сложной настройки.
CI-боты: автоматизация проверки моделей
При частых обновлениях моделей важно было не допустить деградации качества. CI-боты автоматически запускали тесты на новых данных при каждом pull request. Если recall падал ниже порога, бот блокировал слияние и уведомлял автора. Это работало как страховка от случайных ошибок в спешке.
Настройка была простой: скрипт на Python с использованием evaluate и datasets, запуск через GitHub Actions. Никаких сложных оркестраторов. Всё прозрачно и воспроизводимо.
Управление дрейфом данных и метриками
Данные менялись быстро. В первые дни преобладали сообщения о спасении из-под завалов. Через неделю - запросы на еду, воду, медикаменты. Ещё позже - на эвакуацию и логистику. Формулировки тоже менялись: люди начинали использовать новые сокращения, появлялись сообщения на других языках.
Команда отслеживала распределение категорий и качество предсказаний ежедневно. При падении метрик запускалось дообучение на свежих примерах. Это был непрерывный цикл, а не разовая настройка.
Почему recall важнее precision в кризисной ситуации
Выбор метрики - это этическое решение. Пропущенный адрес человека под завалами мог стоить жизни. Ложное срабатывание означало лишь дополнительную проверку волонтёром. Поэтому recall был приоритетнее precision. Пороги уверенности намеренно занижали, чтобы модель захватывала больше потенциальных сообщений о помощи.
F1 использовался как балансирующая метрика, но при конфликте recall и precision выбирали recall. Это осознанный компромисс, который команда зафиксировала в документации.
Оценка ущерба по спутниковым снимкам
Параллельно с обработкой сообщений шла оценка разрушений по спутниковым снимкам. Это помогало координировать спасательные работы: определять наиболее пострадавшие районы, планировать маршруты, оценивать потребность в ресурсах.
Детекция повреждений с YOLO
YOLOv5 и YOLOv8 использовались для детекции повреждённых зданий. Предобученные веса на COCO не подходили напрямую, поэтому модели дообучали на небольшом наборе размеченных спутниковых снимков: около 500 изображений с bounding boxes вокруг разрушенных строений. Дообучение занимало несколько часов на одной GPU.
Скорость инференса YOLO позволяла обрабатывать большие территории за минуты. На одном снимке высокого разрешения модель находила десятки повреждённых объектов. Точность была не идеальной: recall около 0.8, precision около 0.7. Но для первичной оценки масштаба этого хватало.
Сегментация с SegFormer
SegFormer дополнял детекцию, выделяя точные границы зон разрушений. Это давало более детальную картину: не просто «здесь есть повреждения», а «разрушено 60% застройки в этом квартале». Сегментация помогала приоритизировать районы для спасательных работ.
SegFormer выбрали за баланс скорости и точности. Модель работала на средних GPU и давала качество, сравнимое с более тяжёлыми архитектурами. Сравнение с YOLO показало, что сегментация лучше подходит для оценки площади разрушений, а детекция - для быстрого поиска отдельных зданий.
Этика и ограничения: быстрые итерации в условиях хаоса
Система не была идеальной. Модели ошибались. Данные были неполными. Решения принимались в спешке. Команда честно признавала эти ограничения и строила процессы с учётом возможных ошибок.
Конфиденциальность данных пострадавших - отдельный вопрос. Сообщения содержали личную информацию: имена, телефоны, адреса. Доступ к данным имели только проверенные волонтёры. Данные не публиковались в открытом доступе. После завершения острой фазы датасеты были анонимизированы или удалены.
Предвзятость моделей тоже была проблемой. Модели, обученные на турецких данных, хуже работали с арабскими сообщениями. Это создавало риск, что часть пострадавших получит меньше внимания. Команда старалась компенсировать это ручной проверкой и привлечением волонтёров-носителей языка.
Быстрая итерация означала, что некоторые решения были временными. Код не всегда был чистым. Документация отставала. Но в условиях, когда каждая минута могла спасти жизнь, скорость была важнее аккуратности.
Уроки и выводы: open-source экосистема как ключ к спасению жизней
Опыт турецкого землетрясения показал: открытые модели и коллаборация сообщества работают в экстремальных условиях. Команда развернула полноценный ML-пайплайн за несколько дней без длительных закупок и согласований. Hugging Face Hub предоставил инфраструктуру, открытые модели - базовую функциональность, волонтёры со всего мира - дообучение и проверку.
Ключевые выводы для аналогичных ситуаций: выбирайте скорость, а не идеальную точность; используйте готовые модели и дообучайте их на минимальных данных; организуйте пайплайн через открытые платформы; отслеживайте recall как приоритетную метрику; привлекайте сообщество для ручной проверки и улучшения моделей.
Этот кейс перекликается с уроками из статьи про пять факторов успеха в ML за 8 лет. Терпение, дисциплина и команда, где не страшно ошибаться, решают больше, чем новый фреймворк. В кризисной ситуации эти принципы проявились особенно ярко.
Open-source экосистема доказала свою ценность не в лабораторных условиях, а в реальной катастрофе. Модели, которые кто-то выложил в открытый доступ, помогли спасать жизни. Коллаборация незнакомых людей из разных стран сработала быстрее, чем любая централизованная система. Это главный урок, который стоит запомнить.