Собственная методология разработки R&D-проектов в AI, от идеи до создания

Разработка R&D-проектов в сферах машинного обучения и искусственного интеллекта — задача, к которой следует подходить основательно, используя эффективную и проверенную схему работы. Рассказываем, какую методологию использует команда MIL team (среди клиентов — Huawei, Сбербанк, Ростелеком и другие) и как здесь помогут решения от Selectel.

Для начала стоит определиться, чем является R&D-проект. Это проект, в котором очень много работы с кодом, а инфраструктуре уделяется намного меньше внимания. Стратегия следующая: в основном концентрироваться на разработке самих моделей и их дальнейшей работе. При этом используется мало инструментов, чтобы поставлять и поддерживать решение. Как правило, все проекты имеют три ограничения:

• Время. Нужно выполнить поставку в указанные сроки.
• Стоимость. Важно уложиться в озвученные цифры.
• Объем работ. Качество должно быть фиксированным, чтобы заказчик смог пользоваться нашим продуктом.

Инструменты разработки:

• библиотеки для нейросетевого моделирования, Tensorflow, PyTorch;
• domain-specific-библиотеки для особых областей машинного обучения, BigARTM, openCV и другие;
• для написания кода используется Python и C++.

Для организации инфраструктуры предназначены репозитории, системы поддержки версионности моделей, для поставки же используются стандартные библиотеки Python или Docker-контейнеры.

Типичный клиентский запрос: для экономии средств и ускорения обработки данных нужно провести компрессию данных без потери качества. Для этого берется модель на вход, с ней проводятся определенные операции, и она возвращается клиенту. В результате модель будет работать оптимальнее. Эти задачи могут относиться к разным сферам — машинному зрению, обработке естественного языка, обработке сигналов и другим.

Необходимо выстроить работу через понятные итерации и блоки, чтобы снизить риски и ответить на вопросы. Одна из реалий — методологии, представленные на рынке, не очень подходят для R&D-проектов. Основная причина этого — достаточно непрогнозируемый результат тестируемых идей. Никогда не известно наверняка, какое именно количество идей нужно проверить и какая именно сработает. При этом есть требования рынка и заказчиков — они хотят, чтобы разработка двигалась понятными для них итерациями и выдавала прогнозируемый результат в конце каждого спринта.

Где возникают похожие сложности? В построении продуктов. Когда команда работает над новым продуктом, у них есть очень много гипотез, заранее предсказать успешность которых практически невозможно. При этом у команды есть ограничения: время, финансирование, целевой результат.

Хотите больше реального опыта представителей индустрии, регистрируйтесь на митап Selectel ^[1], где соберутся лидеры MLOps-комьюнити.

Популярное решение — одна из моделей создания продукта, Triple Diamond ^[2] от компании Zendesk. Здесь есть этапы работы с проблемой и решением, а также реализации всего этого в продукте.

Этапы Triple Diamond в визуальном виде

В подобных командах есть разделение R&D-работы на два процесса — Discovery и Delivery.

Discovery-трек — это зона полной неопределенности: открытие чего-то нового, подтверждение своих идей и гипотез, подтверждение того, что они работают, проверка их работоспособности.

Delivery-трек — зона определенности, когда команда уже занимается реализацией идей.

Два этих трека существуют и работают параллельно. Delivery всегда двигается прогнозируемыми итерациями, потому что точно известно, что нужно делать. А цель Discovery — проверить в единицу времени максимальное число гипотез и выбрать те, которые с наибольшей вероятностью дадут результат. По сути, это генерация, приоритизация и проверка идей.

Как генерируется идея, которая сработает? Для этого нужно следующее.

• Работа с открытым кодом разных исследователей.
• Брейнштормы.
• Проверка приоритетных идей.
• Анализ ошибки после проверки.
• Трекинг экспериментов.
• Работа с данными.
• Ревью экспериментов для проверки существующих результатов.

Сформулируем ответ на вопрос: какая существует понятная работа, которую можно прогнозировать и которая дает понятные итерации в определенный срок?

• Проектирование библиотеки для клиента.
• Интеграция успешно проверенных идей в работу пайплайна.
• Создание пайплайнов для обработки данных или анализа результатов.
• Code Review и рефакторинг кода.
• Работа с инфраструктурой.
• Упаковка финального результата для заказчика.

К созданию своей методологии MIL Team подошла с постановки целей. Нужно было, чтобы схема включала и ролевую, и функциональную модель проекта, для понимания того, кто и чем занимается. Также было необходимо, чтобы этапность спринта и проекта была понятной, так методологию реально масштабировать на несколько проектов.

Команда MIL Teам проанализировала свою обычную работу над проектами, выписала 50 процессов внутри команд, сгруппировала их до 4 уровней и сделала первую версию. Она состоит ^[3] из следующих блоков: management, vision, development, capitalisation. Они хорошо описывали актуальный способ работы, учитывали риски ожидания и видение решения. Это был итеративный, понятный и измеримый процесс. Но он не позволял продвинуться вперед, привнести что-то новое и решить те проблемы, которые есть.

Поэтому была создана вторая, более сложная версия. Озвучим основные особенности:

• Появились концепции «баз». Это хранилища информации, которые позволяют нам следить за существующими идеями. Есть база кода (то есть репозиторий) и появилась база тестов.
• Больше внимания уделено итерациям, а также работе в начале и конце спринта.
• Выделен отдельный блок с тестированием, потому что очень много ошибок проходит в финальное решение из-за отсутствия тестов.
• Выделены основные роли, которые занимаются треками. Для Discovery это исследователи, а для Delivery — ML-инженеры.

Но все еще не хватало практик, которые были заимствованы у процесса создания продукта. Поэтому была взята модель Triple Diamond и на нее была нанесена методология ^[4]. Здесь тоже есть блок с анализом и определением проблем, которые проводятся на основе анализа ошибок, ТЗ от клиентов и обратной связи от заказчиков. Также есть блоки с генерацией и проверкой идей. Идеи берутся из статей, результатов брейнштормов, общих практик в глубоком обучении и сработавших ранее гипотез.

Существует и блок с Delivery, где реализуется определенная функциональность для библиотеки. Здесь внедряются результаты проверки идей, либо формируется набор требований для тех функций, которые есть в технических заданиях, в стандартных практиках software engineering или же на основе рефакторинга кода для его оптимизации.

Как понять, что работа идет хорошо? Для этого нужно наложить на процесс определенные метрики, чтобы он стал более прозрачным. Нужно сформулировать критерии, которые могли бы сигнализировать о проблемах.

Вот три метрики, с помощью которых команда MIL Team оцифровала процесс:

• 1 метрика. Количество идей из базы, которые готовы для работы.
• 2 метрика. Число идей, которые полностью завершены, проверены, а результату можно доверять.
• 3 метрика. Идеи, которые завершены, проверены и успешны.

Остальные метрики можно посмотреть в материалах презентации ^[5]. Эти метрики позволяют понимать, что уже сделано, оценить ритм работы команды и качество исследовательского процесса, который идет внутри проекта. Метрики измеряются с помощью специального фильтра в базе идей в Notion.
Если в базе есть 10 готовых идей для работы, то это нормально. Если за спринт проверяются три идеи и одна из них успешна, это хорошо. Если у этих метрик низкие значения, становится ясно, что ритм работы достаточно низкий и, возможно, отсутствует общая актуальная база кода. Что можно сделать, чтобы исправить ситуацию? Можно провести брейншторм с генерацией дополнительных идей и сразу же провести их приоритизацию.

Помимо этапов методологии и метрик, с помощью которых отслеживается качество работы, есть также список артефактов, которые позволяют смотреть на проект. Это данные, которые в любом случае генерируются в ходе проекта и которые позволяют понять, какая работа проделана, какие результаты достигнуты и прочее.

Каких результатов помогает достичь методология?

• повысить прозрачность R&D-команды в области AI;
• измерить эффективность команды исследователей;
• увеличить результативность собственной команды.

Реализацию методологии в деле можно посмотреть в workspace ^[6] в Notion. Здесь же вы можете отправить свои вопросы и предложения через специальную форму. Также вы можете написать Алексею Гончарову напрямую в Telegram ^[7] или же посетить сайт ^[8]. Вебинар с рассказом о методологии можно посмотреть здесь ^[9].

Вот какие элементы вычислительной инфраструктуры можно использовать:

• Выделенный сервер с GPU ^[10], который будет готов к работе в течение 30 минут после заказа. Мощный графический ускоритель — ключевой элемент сервера для решения задач Machine Learning. Обучать модели на машине с производительным GPU можно даже в домашних условиях.
• PaaS-продукты ^[11], чтобы упростить развертывание набора сервисов ML. В частности, полноценный Managed Kubernetes, с помощью которого можно запускать задачи по управлению моделями, инференсы, обучение и так далее.
• Упрощенные платформенные сервисы для data-scientist и ML-разработчиков. Это DSVM ^[12] (Data Science Virtual Machine) и DSDC ^[13] (Data Science Data-Container). Здесь вы получаете предустановленный набор библиотек на запущенной виртуальной машине с выбранным GPU или же data-science docker-контейнер, в котором есть необходимые библиотеки. Его можно запустить на той же виртуальной машине (docker) либо в Kubernetes, тем самым изолировав выполнение конкретных операций. Эти сервисы дают вам возможность получить уже установленные фреймворки и инструменты, с помощью которых можно сразу разрабатывать сервисы или же анализировать данные. Среди доступных фреймворков: Keras, TensorFlow, jupyter, PyTorch, OpenCV, pandas, NumPy, XGBoost.

И несколько анонсов.

• В четвертом квартале этого года появится возможность взять на тест в Selectel суперсистему Nvidia DGX, с восемью самыми мощными видеокартами в мире NVIDIA DGX A100. Это первая в мире универсальная система для задач в области искусственного интеллекта и машинного обучения. Архитектура системы спроектирована так, чтобы вы могли настроить ее за один день и создать первый проект за неделю.
• В четвертом же квартале Selectel планирует ввести в работу MLOps-платформу полного цикла работы с ML. Она позволит решать разные задачи: агрегацию данных, обучение моделей на данных, мониторинг метрик и деплой моделей. Первоначально платформа будет запущена на VMware, в 1-м квартале 2022 года добавим Kubernetes.

Чтобы не пропустить релиз этих (и многих других) продуктов, подписывайтесь на наш блог ^[14] и оставайтесь в курсе всех новостей.