Зачем ML нужен собственный стиль разработки. методологии и частичный проект предложения по такой методологии
TL;DR
- Команды машинного обучения, работающие над сложными проектами, должны бороться с внутренними проблемами машинного обучения, а также с трениями, возникающими из-за их междисциплинарного характера, затрудняющего принятие решений.
Надежная методология разработки может помочь командам улучшить выполнение. - Машинное обучение отличается от стандартного программного обеспечения уровнем неопределенности, а также тем фактом, что на модели влияют косвенно, а не спроектированы по дизайну.
- Agile не работает из коробки для машинного обучения, несмотря на то, что это полезный образ мышления. Например, он предполагает, что небольшие функции могут быть созданы по дизайну и плану с низким риском, что не работает для машинного обучения.
- Методы научных исследований предлагают методы преодоления неопределенности и получения знаний, но они не предназначены для реализации коммерческих программных проектов.
- Последовательный / конвейерный поток также не работает для машинного обучения, поскольку машинное обучение является итеративным по своей природе.
- Я предлагаю частичный черновик методологии разработки машинного обучения, в котором описывается процесс разработки, решения и артефакты, и я пытаюсь защитить это предложение, объясняя его обоснование.
- Было бы здорово, если бы некоторые из вас могли поделиться своим опытом в сложных проектах машинного обучения, какие методологии вы использовали, что сработало, а что нет, и прокомментировали черновик методологии, описанной в этом посте :-)
Вступление
Реализация сложных проектов машинного обучения требует правильного решения многих задач.
В предыдущем сообщении блога я попытался осветить некоторые причины, по которым для любого достаточно сложного проекта машинного обучения важно создать команду проекта и включить в нее людей с разным набором навыков.
Но формирование команд машинного обучения также сопряжено с новыми проблемами: заставить мультидисциплинарную команду, работающую над проектом с высокой степенью неопределенности, хорошо работать вместе, является большой проблемой, особенно перед лицом вопиющего отсутствия хорошо понятной методологии разработки.
В машинном обучении еще не наступил «момент гибкости» - когда появилась полная целостная методология, обеспечивающая обоснование, принципы, измерения, детали практической реализации, методы масштабирования для крупных организаций, а также примеры для различных вариантов и адаптации, которые команды могут выберите подать заявку.
Я бы сказал, что большинство команд пытается сделать одно из следующего:
- Крыло это
- Вставьте свой проект в любую методологию, которую наиболее влиятельные люди в команде знают лучше всего.
- Попробуйте объединить их индивидуальный опыт, внешние советы и все, что у них есть, в индивидуальный процесс.
На разных этапах моей карьеры я был виноват во всем этом; и компании, которым я помогаю как консультант, тоже относятся к этому спектру.
Вашему проекту нужна более совершенная методология разработки?
Во-первых, возможно, ответ отрицательный! точно так же, как некоторые программные проекты не оправдывают наличия полноценной Agile-команды и разработчика. процесс и все равно получится!
Не чините то, что не сломано. Если вы не чувствуете боли, возможно, потому, что ваш проект на самом деле не оправдывает команду или достаточно близок к методологии, которую вы достаточно хорошо понимаете.
Однако, если вы часто сталкиваетесь с командными спорами, неспособностью планировать, отсутствием согласия о том, что делать дальше, или часто чувствуете, что заинтересованные стороны не совсем понимают, каков реальный статус проекта, - вам, вероятно, будет полезно лучше определиться с Dev. Методология
Я считаю, что существует эвристическое правило для определения того, достаточно ли сложен ваш проект, чтобы оправдать команду и надежную методологию:
Верхняя строка представляет проекты, в которых есть ценность в уточнении поведения модели и адаптации ее к сложной проблеме предметной области. Если ваш проект находится в верхнем ряду, вам, вероятно, понадобится команда и методология, чтобы помочь процессу.
Почему некоторые существующие методологии не работают для машинного обучения
Понимание неопределенности и косвенного характера ML
Модели машинного обучения - это функция аппроксимации, используемая для генерации желаемых результатов (прогнозов) с учетом определенных входных данных (данных).
Мы используем ML, когда логика создания желаемого результата из наших входных данных не может быть явно закодирована инженерами. Поэтому вместо этого мы используем алгоритм (обучение модели) для создания этой логики (в форме модели машинного обучения).
Это имеет некоторые интересные побочные эффекты:
- Шаблоны в данных, которые будут влиять на правила прогнозирования, во многих случаях не известны нам заранее, и мы не можем спланировать их заранее. Чтобы их раскрыть, нужно потратить время на изучение данных, а новые идеи могут быть получены даже поздно.
- Процесс обучения представляет собой общий алгоритм оптимизации. Это не относится к предметной области, поэтому невозможно напрямую спроектировать функциональные требования как изменения в алгоритме обучения.
- У нас есть косвенный контроль над процессом обучения, который осуществляется методом проб и ошибок. Кроме того, каждый процесс переобучения может привести к некоторой регрессии, а также к прогрессу (например, модель начнет ошибаться в некоторых исходных данных, которые она ранее получила правильно).
- Модели по определению неверны на некоторых входных данных. Выяснение причин, по которым модель не работает на некоторых исходных данных, занимает очень много времени.
- Сама модель после обучения становится нечитаемой или понятной для людей. Итак, невозможно «отладить» модель, прочитав ее код или пошагово пройдя через нее, и, следовательно, инженеры не могут напрямую реализовать требования внутри модели.
- И еще несколько…
Другими словами, проекты машинного обучения вводят более высокий уровень:
Неопределенность - о том, что можно ожидать от модели для обучения, какие ошибки она может совершить и как ее поведение может измениться при изменении поведения данных.
Косвенное обращение - модели нельзя напрямую спроектировать и манипулировать ими в соответствии со спецификациями. Вместо этого мы настраиваем то, что влияет на модель, пока не получим примерно то, что хотели.
Может быть, Agile сможет работать с машинным обучением, несмотря на его особые потребности?
TL; DR - принципы гибкой разработки незыблемы; его методы не работают как есть для машинного обучения
Гибкие методологии принесли огромное облегчение командам разработчиков программного обеспечения, и в отрасли существует значительный объем знаний и понимания того, как их реализовать и настроить.
Неудивительно, что некоторые команды машинного обучения по умолчанию обращаются к гибкой разработке, особенно в компаниях, которые поставляют продукты, не относящиеся к машинному обучению, и имеют действующие методы проектирования и доставки продуктов.
Хорошее
Принципы Agile очень надежны и применимы к большинству проектов, включая ML.
Например, Agile является итеративным и принимает тот факт, что требования могут часто меняться, что, безусловно, полезно для проектов машинного обучения.
Кроме того, Agile признает, что «большие» требования трудно спланировать и выполнить с предсказуемостью, и что способ снизить риск - разбить работу на небольшие этапы, которые обеспечивают некоторую ценность для проекта.
Плохое
Гибкие методы (церемонии, планирование, измерения, отчетность) были тщательно адаптированы для инженерных проектов и плохо переносятся на ML из-за неопределенности и косвенных характеристик ML.
Например, логическое обоснование пользовательских историй и их планирования не подходит для машинного обучения:
Другими словами, Agile предполагает, что небольшие функциональные улучшения четко соответствуют достижимым целям с низким риском и высокой предсказуемостью.
В ML трудно реализовать даже «небольшие» функциональные улучшения - и, следовательно, методы Agile по планированию и измерению прогресса не могут работать из коробки в проектах ML.
Может ли методология научных исследований удовлетворить потребности машинного обучения?
TL; DR - полезные методы; не полное решение, поскольку оно не предназначалось для выпуска коммерческого программного обеспечения.
Хорошее
Научный метод был разработан, чтобы делать точные, воспроизводимые открытия перед лицом неизвестного.
Далее следует цикл вопросов - ›гипотеза -› эксперимент - ›результаты -› анализ - ›выводы. Это может быть полезно в проекте машинного обучения.
Кроме того, многие группы по анализу данных состоят из людей с учеными степенями, причем некоторые из них только что закончили университет. Эти члены команды, естественно, склонны рассматривать проект как задачу академического исследования.
Итак - методы исследования очень полезны в проектах машинного обучения, где изначально существует высокая неопределенность и где есть необходимость методически обнаруживать, как ведут себя данные и как реагирует модель, выдвигая гипотезы о том, почему и как подтолкнуть модель вправо. направление.
Плохое
Предлагая полезные методы работы с неопределенностью, Scientific Research не является полным решением для проектов машинного обучения, поскольку он не был разработан для поставки коммерческого программного обеспечения.
Более конкретно:
- Академические исследования в большинстве случаев являются индивидуальным видом спорта, который не способствует совместной работе.
- Цель исследования - открыть для себя новинку и написать статью. В то время как разработка коммерческого продукта связана с предоставлением пользователю ценности как можно раньше с минимальными рисками насколько возможно
- В академических исследованиях есть определенная свобода делать предположения и сужать рамки, чтобы обнаружить интересную новинку. В продукте мы ищем общие решения, которые могут анализировать реальные, беспорядочные данные.
- Наконец, подход к академическим исследованиям не затрагивает какие-либо аспекты поставки программного обеспечения.
Примечание: у некоторых крупных компаний есть чисто исследовательская функция, которая выполняется как академическая лаборатория профессора. Но их цель - бумаги, а не решения.
Возможно, мы сможем разработать ML поэтапно, связанными в конвейер?
Существует множество ресурсов, которые описывают действия, связанные с построением модели машинного обучения, и, в общем, они описывают следующую последовательность:
- Идея проекта, требования и ключевые показатели эффективности
- Прием данных, исследование, очистка, разработка функций
- Моделирование
- Оценка
- Подготовка кода вывода, тестирование, упаковка, развертывание
- Мониторинг, устранение неисправностей
- Измерения, анализ, доработки
- Повторить
На первый взгляд это выглядит как чистый упорядоченный процесс - когда одна фаза выполняется, а другая начинается, с четко определенными передачами. Это привлекательно, потому что это легко понять; также похоже, что это может позволить каждому владельцу фазы работать в соответствии со своими собственными стандартами, если передачи чистые.
Однако на самом деле разработка машинного обучения - это скорее противоположность чистой последовательности - это итеративный процесс с большим количеством возвратов и назад - от моделей к данным, от требований к метрикам. Причина в том, что команда пробует разные вещи и учится в процессе, и каждое обучение может привести к уточнению плана и продукта.
Ингредиенты для ML Dev. Методология (проект)
Итак, надеюсь, к настоящему времени мы понимаем особые требования машинного обучения, у нас есть некоторые идеи о том, что мы можем позаимствовать из других методологий, и мы готовы приступить к решению задачи определения разработчика. методология ML.
Что мы ожидаем от методологии? вот некоторые из ингредиентов:
- Обоснование и принципы - они необходимы для того, чтобы направлять команды в принятии решений и обеспечивать последовательность в методологии.
Для начала мы можем попробовать гибкое мышление ( и при необходимости настроить позже). - Схема преобразования требований в продукт - включая действия, точки принятия решений и переходы между действиями.
В нашем случае поток будет итеративным , поскольку машинное обучение является итеративным, и точки принятия решений должны обеспечивать высокую адаптируемость перед лицом нового обучения, поскольку команда «пробует материал» и «изучает» проблему - Опишите основные артефакты в проекте
Как входные артефакты (например, то, что мы определяем как часть планирования), так и выходные артефакты (которые могут быть оценены и приняты, означают прогресс и влияют на поток) .
Например - в Agile требования формализованы как «пользовательские истории» -
формат был тщательно выбран, чтобы соответствовать принципам метода Agile (пользователь в центре, рассказывая о том, что и почему, и оставляя как команде и т. д.).
В ML нам понадобится нечто подобное. - Мы можем использовать методы научных исследований - поскольку они формальны и доказали свою эффективность в борьбе с неопределенностью и обнаружении информации.
- Формализуйте, как результат «пробного эксперимента» вызывает множество решений, и, следовательно, он заслуживает статуса артефакта и может иметь ценность сам по себе.
- Предоставьте инструменты управления проектами, такие как церемонии, роли, показатели, способы настройки процесса, чтобы сделать метод конкретным.
Жизненный цикл разработки машинного обучения (черновик)
Быстрое прохождение
- Этот поток является итеративным по своей природе.
- Требования к продукту переводятся в Цели машинного обучения (обычно 1: n), которые точно сформулированы в области целей машинного обучения и данных.
Цели машинного обучения трудно оценить с точки зрения усилий, но мы должны стараться делать их небольшими (в том числе разбивать их на узнаем, если нужно). - Цели машинного обучения достигаются путем опробования различных направлений с помощью экспериментов
(снова 1: n) - Эксперименты - основная исполнительная единица. Они следуют научному методу и включают гипотезу, измерения, анализ и Обучение - и иногда улучшение функциональности модели .
- Обучение, полученное в результате экспериментов, влияет на выбор re.
следующий эксперимент, определение или приоритет целей машинного обучения, а также то, как мы определяем Требования.
Это означает, что в проектах машинного обучения обучение является очень важным показателем прогресса наряду с новыми функциями рабочей модели
- Этот процесс включает выпуск в производство, когда команда считает, что модель готова и что это будет полезно.
Некоторые из недостающих частей, чтобы сделать это предложение конкретным
- Формализация того, как должны выглядеть артефакты - как артефакты планирования, такие как Требования, цели машинного обучения, эксперименты, так и выходные артефакты (Обучение, Рабочее программное обеспечение и т. Д.)
- Рекомендации о том, как принимать правильные решения - например, как преобразовать требования в цели машинного обучения, как расставить приоритеты для экспериментов или как сделать выводы из обучения.
- Предложите несколько церемоний, ролей
- Методы расчета размеров и планирования
- Показатели прогресса
- Еще несколько…
Однако на этом я остановлюсь - поскольку этот пост достаточно длинный.
Заключение
Некоторые проекты машинного обучения сложны и полны неопределенности.
Команды машинного обучения должны использовать надежных разработчиков. методологии, которая поможет им справиться с неопределенностью и поможет им эффективно работать в разных дисциплинах.
Заимствуя принципы академических исследований и гибкой разработки, в этом посте делается попытка обрисовать процесс разработки машинного обучения, который, как мы надеемся, удовлетворяет уникальные потребности машинного обучения. Это все еще ранний черновик, но я надеюсь, что некоторые из вас сочтут это полезным в своих проектах.
Я с нетерпением жду возможности услышать, каким методологиям вы следуете в своих проектах машинного обучения, что сработало, а что нет, и что вы думаете о предложении выше ...
До скорого,
Ассаф