ML-технологии помогают значительно сократить ручной труд, повысить точность и скорость расчетов. Но, чтобы использование ML было результативным, важно правильно выстроить весь пайплайн работы с данными и развернуть его в удобной для пользования среде. Последнее особенно важно, если конечный пользователь продукта — человек без глубокой экспертизы в ИТ. В этом на своем опыте убедилась команда проекта «Сохранение кудрявого и розового пеликанов».
Рассказываем о проекте, сопутствующих проблемах пользователей, поиске вариантов решения и полученных результатах.
Проект и исходные трудности
«Сохранение кудрявого и розового пеликанов» — российская программа по изучению и защите популяции пеликанов в дикой природе, особенно вне заповедников. Одна из задач программы — мониторинг колоний и скоплений кудрявых и розовых пеликанов, которые в России находятся под угрозой исчезновения. Такой контроль нужен, чтобы поддерживать баланс хозяйственных и природоохранных интересов и защитить птиц от вымирания. Более того, пеликаны — индикаторный вид, то есть по состоянию колонии можно судить о вероятных экологических проблемах. При этом отслеживать птиц нужно практически в реальном времени — только так можно гарантировать достоверность результатов.
Основным источником данных для такого анализа являются фотографии, сделанные, например, квадрокоптером.
Проблема в том, что классически особей на фотографии считают вручную — «булавочным методом», когда в прямом смысле булавкой на снимке помечают каждую попавшую в кадр птицу. Очевидно, что у такого подхода есть недостатки:
- метод трудозатратный — на фото может быть до двух тысяч особей, поэтому на разметку всех птиц в кадре может уходить до недели;
- метод неточный — были случаи, когда птиц пересчитывали несколько раз и каждый раз получали новый результат.
Поиск решения и новые проблемы
Чтобы упростить работу орнитологов и избавить их от имеющихся трудностей, мы решили обучить нейронную сеть для поиска и подсчета пеликанов. Но уже на первых этапах проработки мы столкнулись с первыми «подводными камнями».
- Во-первых, данных было немного. Фактически все ограничивалось фотографиями, сделанных с одного пролета. Соответственно, данные были на вес золота, а разнообразия в них было минимум. Поэтому нейронная сеть плохо работала на изображениях, которые она не видела до этого.
- Во-вторых, нужно решение, интерфейс которого понятен и удобен орнитологам. Самым очевидным вариантом было Desktop-приложение, но тогда появлялся вопрос целевой платформы под него (Windows, Linux, MacOS). Мы начали рассматривать вариант с веб-сервисом, но открытыми оставались вопросы по поводу того, на чем его делать и где развертывать.
Так мы пришли к пониманию, что нам нужно двигаться в сторону полноценной архитектуры с MLOps и облаками. Но прежде мы хотели протестировать саму идею.
Прототип «на коленке»
Для проверки гипотезы мы решили не идти сложным путем и использовать для построения пайплайна обработки данных общедоступные инструменты. Так:
- для хранения фотографий мы выбрали Google Drive;
- для разметки фотографий использовали сервис CVAT.AI;
- модели обучали в kaggle kernel.
Так мы получили архитектуру примерно следующего вида.
Прототип позволил нам подтвердить гипотезу и жизнеспособность такого пайплайна в целом. Но он не подходил для практического использования орнитологам. Во-первых, орнитологам нельзя скинуть Jupyter Notebook в надежде на то, что они самостоятельно все освоят. Во-вторых, в такой реализации оставалось много рутины. Так, в случае появления новых данных надо было:
- загрузить фотографию в Google Drive;
- выгрузить изображения из Google Drive в CVAT;
- сделать разметку в CVAT;
- выгрузить изображения и разметку;
- собрать изображения и разметку в датасет для последующей отправки в Kaggle Datasets;
- обучить модель.
Причем каждую из операций приходилось выполнять вручную, что сказывалось на производительности и удобстве использования сервиса. Поэтому при реализации решения уже в облаке мы решили внести некоторые доработки.
Выбор платформы и реализация
При выборе облачного провайдера мы исходили из необходимости:
- получить все нужные сервисы в рамках одной платформы;
- добиться минимального порога входа в работу с инструментами поставщика;
- сократить затраты на администрирование.
После анализа рынка и сравнения предложений мы остановились на VK Cloud, у которого, к тому же действовала программа грантов для стартапов.
Итак, при переходе мы реализовали наш пайплайн с сохранением всех принципов, но уже на новом стеке. Так:
- Вместо Google Drive для хранения фотографий начали использовать объектное S3-хранилище Cloud Storage на платформе VK Cloud.
- Вместо использования серверов CVAT.AI, развернули в облаке собственный экземпляр инструмента.
- Загрузили разработанную нейросеть в свой экземпляр CVAT — теперь новые изображения размечает модель, а потом мы вручную только подправляем результат.
- Отказались от Kaggle Kernel в пользу платформы для полного цикла ML‑разработки Cloud ML Platform.
Дополнительно, чтобы взаимодействовать с выстраиваемой системой было удобно, мы сделали телеграм-бот, который выполняет задачи интерфейса для общения с нейросетью. Алгоритм прост: загружаем картинку — бот возвращает изображение с разметкой.
S3-хранилище было выбрано, поскольку его легко интегрировать с CVAT — достаточно передать CVAT ключ объектного хранилища, после чего CVAT получает возможность самостоятельно «подтягивать» нужные данные.
Переход с серверов CVAT на свой клиент в облаке VK Cloud мы выполнили по двум причинам:
- Версия на серверах CVAT изменяется принудительно — нас не спрашивают, хотим ли мы остаться на старой. Это создает проблемы, поскольку в новых версиях могут убирать фичи, менять интерфейс или даже логику работы с инструментом. Личный клиент решает эту проблему — у нас всегда та версия, которая нам нужна.
- Собственный экземпляр позволяет заниматься кастомизацией. Безусловно, CVAT — open-sources-проект, но ждать добавления новой фичи по запросу долго, даже если внедрить предложенную функцию согласятся.
Одна из причин выбора Cloud ML Platform — возможность получить доступ к ванильному JupyterLab, устанавливать расширения или запускать терминал (с чем, например, есть проблемы в Kaggle Kernel). К тому же JupyterLab в облаке может работать месяцами без отключения по таймауту — фактически для нас это стало аналогом локального решения, но с возможностью гибкого выбора мощностей.
Более того, использование JupyterLab избавило от необходимости ручной загрузки данных (как было в Kaggle Kernel) — сейчас данные подтягиваются прогоном одного Jupyter Notebook. Для этого используем обертку над Boto3 и CVAT SDK.
На данный момент без изменений остались только этапы обучения и деплоя модели. Поэтому в наших планах ввести в пайплайн MLflow, который позволит в несколько кликов выполнять нужные нам операции с сохранением данных о модели и параметрах обучения. После перехода на MLflow наш пайплайн будет полностью завершен.
Результаты работы с новым стеком
Построение архитектуры на основе такого стека существенно упростило работу системы. Так, при появлении новых данных вместо шести ручных операций (как в изначальной реализации) все сводится к нескольким этапам:
- выбираем данные из Cloud Storage для разметки в своем экземпляре CVAT (он сам их подгрузит);
- прогоняем модель на данных в CVAT и при необходимости вносим правки;
- загружаем изображение с разметкой и формируем датасет запуском двух Jupyter Notebook;
- обучаем модель.
Теперь нет ручных загрузок и выгрузок, кратно уменьшилось время на разметку изображений.
Что «под капотом» у ML-модели
Изначально мы использовали алгоритм Watershed. Но классическая модель компьютерного зрения плохо справлялась с сегментированием объектов (например, не всегда могла отделить пеликана от чайки или баклана) и уж точно не могла правильно посчитать каждую птицу при плотном гнездовании.
Поэтому мы перешли ко второй версии модели. За ее основу мы взяли нейросеть YOLOv5, реализованную на фреймворке Pytorch с архитектурой One-Stage Detector. Она предсказывает координаты рамок, описывающих объекты, а также выдает данные о вероятности нахождения объекта в указанной зоне и его принадлежности к определенному классу.
Для этой ML-модели мы написали алгоритм постобработки, который совмещает:
- NMS;
- метод скользящего окна;
- агрегации предсказаний.
Это принципиально позволяет распараллелить вычисления в облаке. При этом, управляя пороговыми значениями для NMS, мы смогли получить плавающую точность.
При дальнейшем дообучении модели на новых данных, мы потенциально сможем добиться не только повышения точности распознавания пеликанов, но и разделить класс «пеликан» на два подкласса: розовых и кудрявых.
В перспективе мы рассматриваем переход на новую версию YOLOv7 или YOLOv9. При этом мы хотим:
- внедрить техники ускорения модели для обработки видео;
- улучшить устойчивость модели и ее обобщающую способность, обучив модель на фотографиях пеликанов, сделанных с разных ракурсов.
Что в итоге
Наш опыт показал, что сферы использования ML на самом деле практически не ограничены и даже при минимальном датасете вполне можно выстроить работающий пайплайн, дающий корректные предсказания. Более того, мы убедились, что при правильной реализации решения на базе ML, администрировать и работать с ним будет просто — благодаря облаку и принятому стеку, мы делегировали инфраструктурные задачи и практически полностью ушли от ручных операций, долгих расчетов (больше не надо неделями изучать фотографии) и больших погрешностей.
Конечно, у нас еще остаются точки роста. Но мы не останавливаемся на достигнутом и продолжаем работу над пайплайном. О том, что получится в итоге, расскажем в следующей статье.
P.S. Мы стараемся делиться экспертизой и наработками. Поэтому выложили свой код и файлы readme с описанием настроек VK Cloud в Github проекта — при необходимости каждый сможет реализовать решение по нашему примеру.
