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 проекта — при необходимости каждый сможет реализовать решение по нашему примеру.