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



Каждая из этих профессий адаптировала общую структуру, чтобы помочь своим командам продуктивно работать в условиях неопределенности: Agile/Scrum для разработки программного обеспечения, бережливые стартапы и петля OODA ВВС США. MLE могут следовать аналогичной схеме, чтобы справляться с неопределенностью и быстро выпускать отличные продукты.

Agile, scrum, бережливые стартапы не являются чуждыми концепциями для многих разработчиков программного обеспечения, а как насчет инженерии данных? Ребята из Insight Data Science Fellows Program опубликовали рабочий процесс, который они называют ML Engineering Loop следующим образом:

1. Анализ

2. Выберите подход

3. Реализовать

4. Измерьте

Вот несколько цитат из статьи, если вы не уверены, стоит ли вам тратить время на ее прочтение, но я определенно рекомендую ее!

С точки зрения продукта, какой уровень производительности должен быть у услуги, чтобы быть полезной?

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

Учитывая этот критерий производительности и имеющиеся у вас данные, какую самую простую модель вы могли бы построить?

Начните с самого простого решения, чтобы протестировать сквозной рабочий процесс.

Чтобы запустить цикл, описанный ниже, вы должны начать с минимальной реализации, в которой очень мало неопределенности.

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

1. Настройка наборов данных для обучения, разработки и тестирования, а также

2. Заставить работать простую модель.

Не стремитесь к окончательному решению. Начать повторение!

Цель здесь не в том, чтобы решить проект за один раз, а в том, чтобы запустить итерационный цикл.

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

Определите узкое место производительности

Найдите, чтобы определить, связано ли ваше узкое место с этапом обучения, этапом настройки гиперпараметров или этапом тестирования.

Выберите подход: Найдите самый простой способ устранить узкое место

Следуйте принципу бритвы Оккама — самое простое решение часто бывает правильным!

Если у вас есть выбор между маркировкой 1000 точек данных или исследованием передового метода обучения без учителя, мы считаем, что вам следует собирать и маркировать данные.

А иногда не стесняйтесь делать ручную работу…

Стройте только то, что вам нужно, и делайте это быстро

Почему вы хотите сделать это быстро? Потому что вы хотите измерить это!

Цель этого этапа — быстро прототипировать, чтобы вы могли измерять результаты, извлекать уроки из них и быстро возвращаться к циклу.

Опять же, ручная работа может быть удивительно полезной. Помните, данные — это новая нефть!

Большинство людей переоценивают затраты, связанные со сбором и маркировкой данных, и недооценивают сложность решения проблем в среде с дефицитом данных.

Наконец, этап измерения:

Полезные метрики производительности включают в себя точность и потери для стороны ML, а также метрики ценности для бизнеса (как часто мы рекомендуем нужную статью среди наших лучших 5?) Помните, что последние метрики имеют значение, в конце концов, поскольку именно они определяют полезность того, что вы строите.

Вывод: сосредоточьтесь на постепенном прогрессе! Я сам «инкрементальный» человек, я предпочитаю небольшие инкрементальные коммиты Git во время разработки программного обеспечения, поэтому приятно, что теперь я изучил инкрементальный подход для управления своими проектами ML =)

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

Наконец, я хотел бы отметить, что инженерный цикл машинного обучения, описанный в этой статье, согласуется с идеей цикла обратной связи, которой 22 октября 2018 г. поделился специалист по данным Microsoft в статье «Как ИИ может помочь вам диагноз болезни?» событие, о котором я напишу позже. Я думаю, что отрасль пришла к единому мнению, что хороший проект по машинному обучению — это не просто использование самой передовой (или сложной) модели, а формирование цикла обучения для дальнейшего улучшения модели!