Настройтесь на успех и избегайте катастрофы
Много пишут об алгоритмах и новых решениях, но недостаточно говорят о том, как осуществить разработку проекта машинного обучения, который повысит ценность вашей организации/компании. Чаще всего проект терпит неудачу не из-за реализации «неправильного» алгоритма, а из-за отсутствия организационной поддержки, четкой дорожной карты и методологии работы, которая одновременно проста и прозрачна. Несмотря на то, что это становится гораздо более важным для стартапов с ограниченным бюджетом, сложность проблемы возрастает в более крупных организациях, где необходимо связать больше участников.
В этом смысле, создаете ли вы компанию с нуля с продуктом/услугой, основанной на машинном обучении, или работаете в стартапе или в крупной компании, практически не имея опыта в подобных проектах, цель этой статьи ( разделить на две части), чтобы дать вам четкое представление о том, как с ними следует обращаться, чтобы не тратить ресурсы впустую, что, в свою очередь, также поможет вам выявить плохо организованные команды и низкокачественных внешних поставщиков услуг машинного обучения, которые обречены на провал ваших проектов.
Тогда каков рекомендуемый подход к машинному обучению? По какой-то причине нам нравятся списки из 10 основных шагов/правил, но в этом случае вам придется довольствоваться 14. Следующий список составлен на основе моего личного опыта работы в качестве специалиста по данным и стратегического консультанта, а также ценных материалов, которые я учился у действительно проницательных лидеров. Вы можете рассматривать его как список требований, если они не будут выполнены, рано или поздно ваш проект может потерпеть неудачу. Для простоты список разделен на 2 набора требований, связанных с управленческими решениями, и тех, которые связаны с техническими причинами, тесно связанными с процессом разработки:
Требования к управлению
- Определите проблему, ресурсы, необходимые для ее решения, и возможные ограничения
- Найдите ключевых действующих лиц, обладающих полевыми знаниями по рассматриваемой проблеме.
- Определить объем проекта
- Определить показатели успеха (как технические, так и бизнес-ориентированные)
- Установите мягкие/гибкие сроки
- Дайте общее представление о том, как будет осуществляться разработка (общий пример, который подходит для большинства случаев, приведен далее).
- Найдите внутренних чемпионов, которые будут продвигать ваш проект
Требования к разработке
- Понимать данные, их источники и процесс генерации
- Смиритесь и исследуйте новые решения/алгоритмы
- Не внедряйте модели, которые вы не в состоянии объяснить
- Создавайте эталонные модели, терпите неудачи быстро и как можно чаще
- Обсуждайте свои решения со всей командой как можно чаще, обращая внимание на свою аудиторию и отдавая приоритет прозрачности.
- Пройти этапы разработки, тестирования и производства
- Документируйте весь процесс (а не только код)
В первой части мы рассмотрим требования к управлению.
Подробные требования к управлению
Неважно, если ваша роль не связана с управлением, для успеха проекта каждый должен внести свой вклад в его порядок, даже когда от вас этого не ждут. В частности, это становится гораздо более важным при работе над техническими разработками, предполагающими множество сложных задач, которые не могут быть мастерски выполнены одним человеком за разумное время. В связи с этим последний сценарий, в котором вы хотите оказаться, — это тот, в котором кто-то без особых технических знаний дает обещания, которые предполагают выполнение невозможного или, что еще хуже, достижение конца проекта и осознание того, что вы совершили довольно серьезные ошибки, которые сводят на нет всю разработку. . Имея это в виду, давайте рассмотрим некоторые из наиболее важных требований, которым вы должны постараться соответствовать, работая над разработкой, включающей машинное обучение.
1. Определите проблему, ресурсы, необходимые для ее решения, и возможные ограничения
Хотите верьте, хотите нет, но многие проекты начинаются благодаря тому, что кто-то говорит: Давайте займемся машинным обучением, это звучит круто и поможет нам на пути цифровой трансформации. Некоторые могут пойти еще дальше и сказать: Мне все равно, чем мы занимаемся, но нам нужно внедрять инновации, искусственный интеллект сделает нас непохожими на конкурентов. Помимо этих вымышленных примеров, смысл здесь в том, что машинное обучение никогда не должно внедряться только для того, чтобы сказать, что вы его используете, или потому, что оно кажется инновационным. Звучит справедливо, верно?
В любом случае первым шагом всегда должно быть определение проблемы, которую вы пытаетесь решить, ресурсов, необходимых для ее решения, и возможных ограничений (осмелюсь сказать, что вам может даже не понадобиться использовать машинное обучение). Вот некоторые вопросы, на которые необходимо ответить перед началом:
- Что мы пытаемся решить? Актуально ли это? Чем это нам поможет?
- Решалась ли эта проблема ранее в других компаниях/отраслях?
- Сколько времени может занять потенциальное развитие?
- Достаточно ли у нас данных для этого? Как мы его извлекаем?
- Есть ли у нас инфраструктура, необходимая для начала разработки?
- Есть ли у нас команда, необходимая для реализации этого проекта? Если нет, то как мы его создадим?
- Какова наша цель/задача?
- Какие переменные можно использовать?
- Существуют ли какие-либо юридические ограничения (например, GDPR или CCPA)? Как это изменит наши ответы на предыдущие вопросы?
Важно отметить, что это требование должно выполняться параллельно с требованием № 2, поскольку для ответа на большинство предыдущих вопросов необходимы ключевые действующие лица как с несколькими точками зрения, так и с соответствующим голосом в организации.
2. Найдите ключевых участников, которые хорошо разбираются в проблеме на местах
Даже если вы являетесь экспертом в конкретной области, в которой вы работаете, вы всегда должны пытаться определить и привлечь группу профессионалов, которые помогут вам понять проблему в целом, ее сложности и важные детали с разных точек зрения. Никто не знает проблему/бизнес лучше, чем люди, которые с этим живут. Помня об этом, вы избежите использования заведомо неверных подходов, опираясь при этом на консенсус.
Кроме того, помните, что даже если вы уже решали проблему раньше или нашли решение, разработанное третьей стороной, это может быть не та же самая проблема, если вы примете во внимание семантику переменных, принадлежащих каждой компании/организации. /база данных. В этом смысле две компании могут иметь одну и ту же базу данных из-за того, что они используют одну и ту же финансовую/HR-платформу, но значение и релевантность каждой переменной могут быть совершенно разными в зависимости от того, как используются эти платформы.
3. Определить объем проекта
Проекты машинного обучения могут занять столько времени, сколько длится ваше творчество. Например, если вы когда-либо работали в процессе ETL, вы должны знать, что можете потратить целую вечность, пробуя новые методы вменения для отсутствующих значений (если применимо), работая над обнаружением выбросов/несоответствий, тестируя новые функции/переменные и даже глядя для новых данных/внешних источников.
Вопрос в том, где вы остановитесь? Конечно, вы не можете продолжать работать вечно, поскольку ожидается, что вы покажете результаты в какой-то момент времени… и чем дольше вы берете, тем дольше вам придется ждать, чтобы увидеть отдачу от ваших инвестиций. Ответ заключается в том, чтобы определить объем проекта, направленный на создание минимально жизнеспособного продукта (MVP) за короткий промежуток времени, а затем на его основе в будущих итерациях проекта. Примечание: вы должны четко и кратко указать, что входит в этот MVP, чтобы к концу проекта не возникло никаких сомнений.
Но что такое приемлемый результат и сколько времени вы должны потратить на его достижение? Чтобы ответить на это, у нас есть требования 4 и 5 (возможно, самые сложные).
4. Определите показатели эффективности (как технические, так и бизнес-ориентированные)
Давайте рассмотрим два наиболее важных аспекта показателей производительности: значение и допустимые значения.
Значение: если ваши наиболее важные внутренние заинтересованные стороны не могут объяснить простыми словами, как вы измеряете эффективность своей модели, значит, вы делаете что-то неправильно, так как это свидетельствует о полном отсутствии охвата, прозрачности и внимания к бизнесу. потребности. В этом смысле вам следует уделить время обсуждению и объяснению того, как вы собираетесь измерять производительность. Например, мы знаем, что для задач классификации точность может быть плохой метрикой или даже вводить в заблуждение, когда классы сильно несбалансированы. В этом примере точность, полнота или оценка f1 могут быть одними из лучших альтернатив, которые можно выбрать в зависимости от бизнес-цели. Другим примером может служить прогнозирование спроса на продукты во временных рядах для управления запасами, где плохо определенные модели нацелены на минимизацию функций потерь единичного значения (RMSE, MAE, MAPE, SMAPE и т. д.) вместо использования функции квантилей потерь, которая могла бы обеспечить бизнес. с изменяющейся во времени политикой уровня запасов. При необходимости не бойтесь создавать собственные функции потерь.
Приемлемые значения: у вас может возникнуть соблазн предложить приемлемые значения на основе вашего прошлого опыта, но, как мы знаем, это неразумное решение, поскольку качество (согласованность и изменчивость) и объем доступных данных будут скажите, что разумно/достижимо. Не будь этим человеком. Сначала попробуйте простую версию модели, которую вы собираетесь использовать, и проверьте результаты. Этого должно быть достаточно, чтобы предложить приемлемое значение.
5. Установите мягкие/гибкие сроки
Ответить, сколько времени потребуется, чтобы закончить проект, никогда не будет легко (если только проект не будет действительно простым). Опять же, даже если вы решили проблему раньше, вы можете столкнуться с несколькими распространенными проблемами, такими как:
- данные плохого качества
- отсутствие модели данных (или наличие испорченной)
- плохая документация по переменным и процессам
- медленные ИТ-отделы, которым требуется много времени, чтобы предоставить вам доступ к ресурсам, необходимым для работы (например, к облачным сервисам)
- практически отсутствует поддержка со стороны ключевых действующих лиц, которых вы определили, и т. д.
Чтобы справиться с первыми тремя, лучшее, что вы можете сделать, это попросить пару дней (менее недели), чтобы быстро разобраться с проблемами, связанными с данными. После того, как вам удалось получить представление о текущем состоянии данных, вы можете предложить несколько мягких/гибких сроков, которые не должны отличаться более чем на 2 недели на этапе MVP. Если вы не можете провести первую оценку, потому что являетесь внешним консультантом/поставщиком услуг, то вы все равно можете дать ответ… Давайте будем честными, если у вас есть способная команда из 2/3 специалистов по данным для решения наиболее распространенных задач моделирования. никакая разработка MVP не должна занимать более 3 месяцев (при условии, что задачи инженерии данных не нужны и от вас не ожидается создание платформы). Вам может быть интересно, а что является общей проблемой моделирования? Вот несколько примеров, ориентированных на бизнес:
- Прогнозирование временных рядов спроса
- Сегментация клиентов/конкурентов
- Системы рекомендаций
- Классификация текстов
- Анализ тональности и темы (самый простой и быстрый в реализации)
- Модели анализа выживания (отток клиентов/сотрудников/увольнение)
- Ценовая эластичность спроса (сделано правильно, а не с помощью простой регрессии и теоретических распределений)
- Оптимизация цепочки поставок (возможно, единственная, на решение которой может уйти больше времени, но только если вы работаете над ней впервые)
Что касается проблем, подобных последним двум, т. е. задержек, связанных с проактивностью других, четко определите ожидаемое время отклика и то, как его несоблюдение повлияет на время разработки.
6. Дайте общую картину того, как будет осуществляться разработка
В большинстве случаев ваши проекты должны следовать той же глобальной структуре, которая описана на следующих рисунках:
Вы всегда должны стремиться сначала создать прототип, выполнив несколько стандартных шагов, которые должны поддерживаться выполнением предыдущих требований:
- Определение проблемы и масштаба
- Идентификация и извлечение соответствующих данных
- Внедрение фильтров (если применимо), анализ отсутствующих данных и выбросов
- Работа над процессом разработки функций
- Определение подхода к моделированию, т. е. в рамках какой теоретической основы мы собираемся работать.
- Создайте эталонную модель и улучшите ее
- Проверить работоспособность модели
- Повторяйте весь процесс до тех пор, пока прототип не будет достаточно хорош в соответствии с требованием 4.
Показывая этот рабочий процесс, вы повышаете прозрачность своей работы и намекаете на сложность проблемы специалистам, не связанным с данными, участвующим в этом процессе. Это, в свою очередь, поможет вам более четко объяснить возможные задержки, которые могут возникнуть (особенно на этапах обработки данных).
После того, как этап прототипирования пройден, следует заняться часто игнорируемым этапом, который включает в себя перенос окончательной модели в производство. Краткое описание этого процесса показано на следующем рисунке.
Короче говоря, вам нужно определить архитектуру решения (в настоящее время это в основном облачные компоненты), организовать свой код в исполняемые сценарии, которые запускаются в выделенных средах, построить конвейер и организовать его выполнение, создать процесс мониторинга для отслеживания изменений в производительность модели (остерегайтесь дрейфа данных), формализуйте документацию и, если возможно, изучите новые расширения и определите возможности для улучшения.
7. Найдите внутренних чемпионов, которые будут продвигать ваш проект
Это последнее требование применяется только в крупных организациях. Вы быстро поймете, почему.
Второй худшей моделью является та, которая не используется. Возможно, вы проделали потрясающую работу, разрабатывая на основе консенсуса и используя новейшие современные алгоритмы, но, если пользователи не видят ценности вашей работы, у вас все еще есть последняя задача — заставить их использовать ее охотно. Вот где вступают в игру стратегии управления изменениями, поскольку в большинстве случаев использование новых инструментов требует некоторой культурной адаптации внутри организации (чем больше, тем хуже). Хорошей новостью является то, что если вы выполнили первые два требования, т. е. определение проблемы было обсуждено и поддержано ключевыми участниками, половина работы выполнена, так как высший менеджмент будет требовать дополнительных мер. В любом случае всегда полезно найти внутренних чемпионов, которые будут продвигать ваши проекты и обеспечивать их использование в своих командах, других командах или даже областях организации (возможно, вы разработали решение, которое предназначалось для использования только в определенной области). но с некоторыми небольшими изменениями это может помочь другим).
Заключительные замечания
В общем, мы рассмотрели некоторые из наиболее важных требований, которые вы должны учитывать при подходе к новому проекту машинного обучения. Многие из них могут показаться очевидными для некоторых, но, как мы знаем, все, что связано с менеджментом, кажется очевидным после прочтения. Как минимум, эта статья должна работать как: а) краткое напоминание об ошибках, которых следует избегать коллегам-профессионалам; b) стандарт для внешних/внутренних групп обработки данных.
И последний совет: всегда стремитесь/требуйте прозрачности, консенсуса и качества (по возможности не торопите события). Я надеюсь, что вы найдете что-то полезное в этом коротком чтении и не откажетесь от Части II.
Не забудьте поставить лайк и подписаться, чтобы получать больше контента, связанного с решением реальных бизнес-задач 🙂.
