… Но командам машинного обучения необходимо преодолеть большой культурный разрыв.
За последние несколько лет многие компании-разработчики программного обеспечения начали разрабатывать продукты, использующие машинное обучение.
Как и любая новая технология, машинное обучение предполагает определенную кривую обучения, и управление этой кривой обучения имеет решающее значение для успешного внедрения машинного обучения.
Интересно, что многие организации так сильно сосредотачиваются на областях, которые им необходимо изучить, что упускают возможности использовать уже имеющиеся у них активы, которые имеют решающее значение для их успеха.
Прекрасным примером этого явления является миф о «Единороге в области науки о данных».
Миф о «единороге в области науки о данных»
Некоторые компании рассчитывают нанять одного специалиста по данным, который будет реализовывать их проект машинного обучения практически в одиночку.
Этот человек - «единорог Data Science» - мифическое существо, которое может волшебным образом выполнить проект Data Science самостоятельно.
Вкус того, что включает в себя нетривиальный проект в области науки о данных
Вот некоторые из задач, которые вам необходимо выполнить, чтобы реализовать успешный проект машинного обучения:
- Неоднократно обсуждайте с представителями бизнеса требования. Сообщайте ожидания, обсуждайте и переводите их потребности в цели машинного обучения.
- Получите данные, очистите их и систематизируйте
- Принимайте решения о том, какие ярлыки создавать и какие компромиссы
- При необходимости контролировать процесс маркировки
- Разработайте и протестируйте функции
- Настроить и организовать ее среду разработки
- Запускайте модельные эксперименты и отслеживайте их
- Проанализируйте ошибки модели и выясните, что с ними делать.
- Выполнять статистический анализ и составлять отчеты о производительности
- Вносите изменения в данные и требования несколько раз по мере того, как она узнает что-то о предметной области.
- Разберитесь с упаковкой модели для развертывания.
- Станьте владельцем модели, когда она запущена в производство
- Обновляйте и обновляйте его, когда поступают данные обратной связи
Действительно, хорошие специалисты по данным часто любят работать в одиночку, особенно тем, кто недавно получил ученую степень. Они также очень аналитичны и любят иметь дело с новыми проблемами и неизвестностями.
Однако очень мало людей, которые могут сделать все это самостоятельно, для чего-либо, кроме POC, просто потому, что у них нет навыков или контекста, а у большинства из них есть только две руки.
Что происходит, если вы верите в миф?
Если вы скажете специалисту по анализу данных, что ожидаете, что он выполнит проект самостоятельно,
доверие ему польстит, и он сделай все возможное, чтобы оправдать твои ожидания.
Однако через некоторое время вы начнете замечать следующие вещи:
- Специалист по анализу данных ошеломлен, нервничает и чувствует себя изолированным
- Она может не осознавать некоторые области, с которыми ей следует иметь дело, или тратить большую часть своего времени на области, которые интересуют больше, и пренебрегать другими.
- Никто не может реально контролировать работу или проверять предположения.
Трудно взвесить или помочь ей в принятии решений - поскольку никто другой не знает деталей в достаточной степени - Трудно добавить новых людей в проект на поздней стадии, поскольку он построен в очень уникальном и своеобразном стиле.
- Специалист по анализу данных становится единственной точкой отказа для проекта.
Если она решит уйти, вы вернетесь на круги своя. - Прогресс медленный и непредсказуемый
- Есть хороший шанс, что она на самом деле пытается решить не ту проблему.
- Все расстроены
Игнорирование основной правды о проектах машинного обучения
Миф о единороге - хороший пример того, как компании делают все возможное, чтобы избежать создания команд машинного обучения, несмотря на все необходимые задачи и навыки.
Даже когда многие из этих навыков остаются недосягаемыми, мягко говоря ...
Контакт с вашей программной (товарной) стороной
Вот несколько хороших новостей, которые вы, возможно, забыли: машинное обучение - это, в конце концов, вид разработки программного обеспечения.
Если вы раньше доводили до производства достаточно сложные программные проекты, вы, вероятно, уже на полпути к успеху (или даже больше, в некоторых случаях).
Многие из действий в проекте машинного обучения по-прежнему подчиняются основным принципам и передовым методам разработки программного обеспечения.
Предупреждение:
ML следует большинству принципов разработки программного обеспечения, но их реализация часто требует адаптации. Так что пока не пытайтесь переносить свои скрам-церемонии, сюжетные моменты и учет времени в новый проект машинного обучения…
Вам нужно убедить? Пойдем!
- Будут ли требования к вашему продукту машинного обучения?
В большинстве нетривиальных проектов так и должно быть!
Конечно, вам нужно будет определить их по-другому и ожидать, что вы доработаете их на ходу, но вам все равно нужно их написать - и принять результаты тоже. Это должен быть кто-то, кто представляет пользователя. У вас должен быть
владелец продукта - Вам нужно будет строить конвейеры данных и создавать на их основе функции?
Специалисты по обработке данных могут помочь в этом. - Будет ли ваша модель обслуживать решения в производственной среде?
Бэкэнд-инженеры хорошо умеют настраивать производительность, определять API и масштабировать сервисы. Позвоните им - Говоря о производстве - очевидно, что перед запуском в эксплуатацию вам необходимо провести достаточное тестирование - вам помогут инженеры по контролю качества и автоматизации, которые помогут вам проверить свою модель на соответствие требованиям.
- Как вы думаете, вы когда-нибудь захотите заново обучить свою модель с использованием новых данных?
Вы хотите иметь возможность быстро проверять идеи и воспроизводить?
Тогда вам нужно спроектировать свой конвейер обучения моделей, среда, система отслеживания экспериментов и множество других инструментов, которые помогают легко (или, что более вероятно, терпимо) отлаживать и исследовать модели.
Вам следует назначить инженера-исследователя для создания ваша инфра
Это логические роли, но в достаточно крупных проектах вам потребуется, чтобы многие из этих ролей выполнялись отдельными лицами - потому что вы
потребуются как высокий уровень знаний, так и достаточный потенциал.
Есть еще одно важное преимущество вовлечения ваших «программистов» на раннем этапе - они хорошо разбираются в предметной области, чего обычно не бывает у новичков в сфере машинного обучения.
Если эти идеи кажутся очевидными, это должно быть облегчением.
Но если это так очевидно, то почему так много компаний не внедряют эти практики и дисциплины в свои проекты машинного обучения, а в крайнем случае делают ставку на единорогов?
Я считаю, что это в основном культурный вопрос.
Понимание культурного разрыва в проектах машинного обучения
Специалисты по анализу данных происходят из совершенно другой культуры, которая, вероятно, является новой для вашей организации. С разными системами убеждений, взглядами на то, как выглядит профессиональный успех, и, конечно же, повседневными практиками.
Некоторые из них пришли из академических кругов, что радикально отличается во многих других, даже более фундаментальных аспектах.
В основе культурного столкновения лежат два разных образа мышления: исследовательское мышление и инженерное мышление. Успешные команды должны преодолеть это столкновение и создать гармонию между собой.
Вот несколько примеров того, как выглядит конфликт:
Чтобы сделать очень широкое и слегка преувеличенное обобщение:
Когда команды только формируются, инженеры часто смотрят на специалистов по анализу данных и думают, что они очень важны, что они слишком усложняют, не выполняют и не выполняют своих обязательств. Они также будут шокированы своими рабочими привычками, особенно в отношении кода.
Ученые, с другой стороны, могут изначально рассматривать инженеров как техников, которые не понимают данных или машинного обучения и, следовательно, на самом деле не «понимают» проект. Вместо этого они проводят все свое время, зацикливаясь на церемониях и практиках, которые кажутся далекими и не имеющими отношения к рассматриваемой проблеме. Неужели они действительно думают, что фиксация кода каждые пять минут - это то, что поможет решить эту проблему смещения модели?
Что делает этот культурный разрыв плохим?
Я не специалист по теории мультидисциплинарных команд, хотя я провел 15 лет своей карьеры в мультидисциплинарной среде.
Основываясь на своем опыте, я могу сказать, что культурный разрыв в сфере ML-программного обеспечения представляет собой особенно серьезную проблему по сравнению с другими межкультурными трениями, которые часто возникают в командах.
Например, разработка продукта - это значительный культурный разрыв, но все же большая часть команды нашла способ заставить его работать, верно?
Вот несколько причин, почему я так считаю:
Это новый опыт
Скорее всего, продукт и разработка работали вместе в предыдущих проектах или в других компаниях. Они вроде как знают, чего ожидать и что вместе они могут добиться успеха.
В проектах ML этого доверия еще нет.
Четких основных правил не существует
Обычно команды разработчиков работают с четко сформулированным разработчиком. методология - обычно привкус гибкой разработки. Методология точно определяет, каковы разные роли и обязанности разных дисциплин, и отводит каждой из них свое место, не создавая разрозненности или неуважения.
Однако в машинном обучении такого ремня безопасности пока нет, и командам нужно найти собственный способ заставить его работать. Это большой вызов для любой команды - даже без культурного разрыва.
Сходство вводит в заблуждение
Что касается людей, занимающихся разработкой продуктов, или любого нетехнического МСП (профильных экспертов), которые являются частью команды - ясно, что они имеют разное происхождение и там очень мало пересекающихся навыков. Обычно они не пытаются (и не могут) переступить границы и говорят инженерам, как выполнять свою работу, и наоборот.
В случае машинного обучения и инженеров это намного менее очевидно, поскольку на первый взгляд обе дисциплины пишут код и, во многих случаях, выполняют множество других аналогичных действий.
В результате разница во мнениях между машинным переводом и инженерами остается нераскрытой до поздней стадии, а когда она проявляется, она проявляется прямо посреди домашнего газона людей, что еще больше усугубляет ситуацию.
Тем не менее, если вы хотите создать успешный проект машинного обучения, необходимо преодолеть первоначальное культурное противоречие и найти способ задействовать ценность каждой из дисциплин проекта.
Заключение
Машинное обучение сильно отличается от разработки программного обеспечения, но также во многом пересекается.
Успешные проекты машинного обучения требуют сильного присутствия профессионалов в области разработки программного обеспечения, таких как менеджеры по продукции и инженеры.
Некоторые компании упускают этот факт из виду и пытаются создать «команды из одного человека», или нанять «единорогов в области науки о данных». Однако это не лучшая стратегия для чего-либо, кроме POC.
Одной из серьезных проблем при создании команды из нескольких дисциплин является культурное столкновение между культурами машинного обучения и разработки программного обеспечения. Зная об истоках и областях, в которых эти культуры сталкиваются,
вы, надеюсь, сможете приступить к решению этой проблемы.
Можно еще многое сказать о создании успешных команд машинного обучения, которые могут эффективно работать вместе. Я надеюсь рассказать об этом в будущих публикациях.
Ваше здоровье,
Ассаф
