Обеспечьте решение скрытых проблем с упреждающим организационным планированием
Вы собрали и подготовили свои данные, разработали отличные функции, обучили, оценили и развернули свою модель. Вы и ваша организация довольны: он показывает отличные результаты на практике и успешно продвигает бизнес-цели вашей организации. Вы наконец закончили!
Ну… не совсем так.
Что может пойти не так?
Все хорошо в течение пары недель, может быть, месяцев, но в конце концов кто-то понимает, что ваша модель работает не так хорошо, как вы думали. Это явление называется дрейфом модели. Дрейф модели в значительной степени вызван дрейфом данных и дрейфом концепции.
- Дрейф данных — это изменение предикторов модели (независимых переменных). Например, в модели прогнозирования спама в электронной почте предположим, что мы используем скорость исходящих электронных писем в качестве функции. Если после того, как мы обучим нашу модель, служба электронной почты теперь реализует ограничение скорости исходящих писем, распределение этой независимой переменной коренным образом изменилось.
- Дрейф концепции — это изменение прогнозируемой цели модели (зависимой переменной). Используя предыдущий пример, это может быть вызвано изменением концепции того, как пользователи интерпретируют «спам». Малоизвестная публикация со временем может стать более популярной и надежной, поэтому классифицировать электронные письма с этого домена как спам, которым они могли быть раньше, было бы неуместно.
Оба типа дрейфа со временем приводят к ухудшению характеристик модели. Если не отслеживать и не исправлять развернутые модели, они быстро становятся неточными и ненадежными.
Типичное решение
Это хорошая информация, которую нужно знать, но это решаемая проблема. Это легко исправить, наши инструменты мониторинга обнаружат дрейф модели, а затем мы просто соберем больше данных, переобучим и повторно развернем… правильно?
Проблемы
При тех же условиях, что и на начальном этапе разработки, это допустимое предположение. Но со временем, особенно несколько месяцев, могут возникнуть следующие вопросы:
- Кто работал над сбором данных, проектированием функций, созданием, оценкой и развертыванием модели? Они вообще больше в организации?
- Где живут данные? Как узнать, на какой версии данных обучалась модель?
- Где живут модели? Является ли "model_1_best_weights" или "updated_model_1_v2" моделью, развернутой в рабочей среде?
- Где код для обработки данных и разработки моделей? Код вообще существует? Почему чтение кода вызывает у меня желание плакать?
Эти вопросы могут показаться резкими. На самом деле, они действительно должны быть. Но вдохновением для этой статьи послужили ответы: они ушли несколько месяцев назад, данные потеряны, модель исчезла, а код не читается. Удачи представить это вашему клиенту.
Почему возникают эти проблемы?
Мне посчастливилось работать во многих организациях и видеть разные этапы процесса разработки машинного обучения. Я видел несколько очень проблемных ситуаций и несколько приличных ситуаций, но никогда не видел, чтобы этот процесс выполнялся очень хорошо. Почему это?
Было бы легко обвинить инженеров, специалистов по данным и команду разработчиков. Но на самом деле в большинстве ситуаций эти проблемы гораздо глубже укоренились в организации и культуре.
Проблема ухудшения модели, которую трудно исправить, возникает из-за организационной недальновидности. Фундаментальные долгосрочные проблемы множатся в недальновидных организациях.
Каковы аргументы против активных действий?
Я заметил следующие аргументы в пользу методов разработки, которые обычно создают эти проблемы, особенно распространенные в небольших, новых стартапах.
Эта проблема не является проблемой. Процесс разработки функциональной развертываемой модели гораздо менее важен, чем сама модель.
Что касается одноразовых систем или анализа, я бы согласился с этим. Специальные системы не обязательно должны быть идеальными, им просто нужно работать временно, чтобы прийти к выводу. Однако многие ошибочно рассматривают процесс разработки машинного обучения как специальный, что приводит к этой точке зрения. Наоборот, этот процесс должен быть вполне сравним с фундаментальными практиками традиционной разработки программного обеспечения.
Нам нужно быстро выполнить итерацию, чтобы вытолкнуть продукт за дверь.
Хотя это может быть правдой, несовершенные методы разработки на самом деле могут увеличить время выпуска. «При плохом качестве кода ошибки и сомнительные пограничные случаи легко остаются незамеченными. Позже это приводит к трудоемким исправлениям ошибок и, в худшем случае, к производственным сбоям. Качественный код позволяет выходить из строя рано и быстро». [1] Как ни странно, замедление процесса позволит организации ускорить получение результатов.
Это просто проверка концепции, нет необходимости рассматривать ремонтопригодность.
Подход многих «быстро развивающихся» организаций заключается в том, чтобы начать с сосредоточения внимания на высокоскоростном, низкокачественном испытании концепции. Это дает быстрые, но недальновидные результаты, которые плохо переносятся на MVP (минимально жизнеспособный продукт). Хотя этот процесс может быть весьма эффективным в организациях, которые не уверены в своих потребностях в данных, для организаций, которые стремятся управлять данными, мы уже понимаем, что эти проекты являются необходимым аспектом основного бизнеса.
Сочетание этих аргументов часто приводит к описанной нами проблеме.
Что мы можем с этим поделать?
Надеюсь, к этому моменту вы понимаете, что это серьезная проблема, которая может незаметно возникать в организациях. Я предложу набор рекомендаций по превентивным действиям, которые организация может предпринять, чтобы предотвратить эту проблему еще до того, как она возникнет.
1. Мониторинг
Самый минимальный шаг — просто отслеживать производительность моделей. Хотя это не позволяет нам исправить проблему, но позволяет обнаружить ее на начальном этапе. Если мы не знаем, что проблема существует, как мы узнаем, как ее исправить?
Цель мониторинга – «убедиться, что модель генерирует разумные показатели производительности при применении к набору доверительных тестов». [2]Кроме того, доверительный набор следует регулярно обновлять, чтобы учитывать сдвиги в распределении, описанные выше.
2. Важность итеративного процесса
Организация должна подчеркивать важность итеративного характера процесса разработки ML, давая командам достаточно времени для учета этого. Цикл технического обслуживания не следует недооценивать.
«Большинство серийных моделей необходимо регулярно обновлять. Ставка зависит от нескольких факторов:
• как часто он допускает ошибки и насколько они критичны,
• насколько «свежей» должна быть модель, чтобы быть полезной,
• как быстро становятся доступными новые обучающие данные,
• сколько времени требуется для переобучения модели,
• насколько дорого обходится развертывание модели и
• насколько обновление модели способствует продукту и достижению целей пользователя». [2]
3. Управление версиями данных
Многие инструменты управления версиями данных позиционируют себя как git for data. Основная цель любого инструмента управления версиями данных — синхронизировать разные версии кода и данных (данные для обучения, данные для тестирования, модели и т. д.). Когда модель нуждается в обновлении, мы можем получить точную копию состояния разработки при последнем обновлении. После обновления модели, если наш инструмент мониторинга указывает на снижение производительности, мы можем быстро и легко вернуться к предыдущему развертыванию. Я сторонник DVC, но существует множество альтернативных решений.
4. Отслеживание экспериментов
Инструменты отслеживания экспериментов позволяют отслеживать и визуализировать все данные, связанные с экспериментом (гиперпараметры, конфигурации модели, результаты и т. д.) при нескольких запусках. Такие инструменты, как Weights & Biases, MLflow и Neptune, среди многих других, — отличные варианты. Это позволит разделить разные версии моделей.
5. Документация
Нелюбимое занятие разработчика. Это хорошо видно в запутанной мешанине спорадических комментариев в Jupyter Notebooks и незавершенных README во многих проектах. К сожалению, для здравомыслия будущих инженеров выбор архитектуры модели, этапы репликации, выводы и вся другая соответствующая информация, не включенная в предыдущие разделы, должна быть хорошо задокументирована.
Заключение
Мы видели, как неправильный процесс разработки может привести к ухудшению модели, которую трудно исправить. Причиной этой проблемы является не отсутствие инструментов мониторинга, а скорее недальновидное поведение организаций, которое способствует возникновению этих долгосрочных проблем. Я предложил набор организационных руководящих принципов для решения всего комплекса вопросов, описанных выше.
Я надеюсь, что теперь вы сможете избежать той боли, которая заставила меня написать эту статью.
Это только начало! Если вам понравилась статья, подписывайтесь на меня, чтобы получать уведомления о следующих! Я ценю поддержку ❤️
Источники
[1] Э. Берге, Как написать высококачественный Python в качестве специалиста по данным (2022), На пути к науке о данных
[2] А. Бурков, Инженерия машинного обучения (2020), Квебек, Канада: True Positive Inc.
