Каков общий результат при создании продуктов машинного обучения (ML) для достижения следующих трех целей Agile?

  1. Создавайте быстро
  2. Создавайте вещи правильно
  3. Создавайте правильные вещи

Ответ: Полезная и многоразовая модель.

Нет MVP без модели в производстве. И производство — это не последний простой шаг после доказательства ценности модели в ноутбуке. Это не просто автоматическое копирование и вставка файла модели в ваш локальный облачный провайдер. Это важная часть создания продукта машинного обучения. Начало производства должно быть частью процесса с самого начала.

Может быть, у вас нет команд размером с Google и систем машинного обучения с тысячами моделей, автоматически обучаемых на огромных наборах данных, развертываемых через гладкие конвейеры, дающие ценные прогнозы каждую секунду.

Но вам все равно нужно поддерживать и развертывать свою модель где-то, чтобы она была полезной. Однако запуск моделей для разных людей означает совершенно разные вещи. В зависимости от вашей роли и опыта вы можете использовать очень разные подходы.

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

  1. Эксперт в предметной области: скопируйте и вставьте неверсионный код эвристической модели с важными соответствующими функциями в скрипт на локальном компьютере и настройте параметры на лету, вручную отправляя данные и результаты по электронной почте туда и обратно конечным пользователям.
    "Да, у нас есть что-то "в производстве" на моей машине, но это кошмар для отладки, обслуживания, повторного использования, и это не работает надежно или автономно".
  2. Инженер-программист: напишите общий код, в котором концепция модели абстрагируется с помощью миллиона вложенных методов вплоть до хорошо документированного класса под названием TheUniverse(). Отклоняйте все изменения кода в длинных проверках кода, которые 1) не имеют 100% покрытия кода юнит-тестами, 2) не применяют наиболее оптимальный шаблон проектирования программного обеспечения передовой практики для варианта использования, 3) не были автоматически очищены от конечных пробелов средство форматирования, установка которого в конвейере CI/CD заняла неделю.
    «У нас не было времени на создание моделей. Но, по крайней мере, конвейер обучения и потенциальные артефакты автоматически тестируются и упаковываются. Мы также хорошо обработали все конфликты слияния git, и репозиторий выглядит действительно структурированным».
  3. Ученый по данным: «Просто дайте мне последнюю версию сети глубокого обучения с параметрами объемом 1 ТБ и графическим процессором для обучения, и я дам вам ноутбук Jupyter, на котором может работать модель — по крайней мере иногда, если данные ведут себя или не меняются. Но также и документ с хорошими результатами, который будет представлен на конференции через 6–12 месяцев».
    Модель является современной, соответствует передовым принципам моделирования в соответствии с теорией. Он показывает низкие показатели ошибок и высокую производительность, даже если смотреть на ключевые показатели эффективности бизнеса. Но он работает только в одной экспериментальной среде на одной конкретной машине.
    «Вы никогда не сможете воспроизвести мою сверхсовременную архитектуру модели, пользовательские пакеты Python или функции со странным масштабированием. Никогда! МУХАХАХА!»

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

Итак, какой подход к запуску моделей подходит вам лучше всего? Как вы думаете, что сделали бы другие стереотипные роли? Инженеры данных? UX?