В прошлом году отрасль уделяла больше внимания переносу моделей машинного обучения (ML) из лабораторий в реальные развертывания. В своей любви к созданию более крутых и крутых моделей машинного обучения команды машинного обучения не уделили достаточного внимания некоторым важнейшим аспектам программной инженерии, которые мы усвоили на собственном горьком опыте за последние десятилетия. Модель машинного обучения, которую можно рассматривать как часть программного обеспечения для бизнеса, должна быть высококачественной (функционально), надежной, совместимой и объяснимой. Эта статья представляет собой краткий обзор этих аспектов, которые определяют качество в жизненном цикле науки о данных (DSLC).
На практике DSLC рассматривался как три мини-жизненных цикла - управление данными, построение модели и управление развертыванием. В этой статье я разбиваю этап управления развертыванием на две части - принятие в эксплуатацию (AIS) и обслуживание на рабочем месте (ILS). AIS включает необходимые функции независимой проверки и верификации, такие как интеграционное тестирование, приемочное тестирование и т. Д., Тогда как ILS - это скорее операционная функция, поддерживающая и отслеживающая модель машинного обучения в производственной системе.
В корпоративной среде обычно не бывает одноразовых ценных проектов. Поставляемое приложение должно быть обслуживаемым и непрерывно развиваться в течение длительного периода времени. Ни один компонент сам по себе не может принести пользу для бизнеса. DSLC должен быть разработан с хорошо продуманным планом управления конфигурацией для длительного срока хранения всех артефактов проекта. Несмотря на то, что мы не будем подробно обсуждать их, эти фундаментальные аспекты необходимо иметь в виду до конца этого обсуждения.
Следующие общие аспекты должны быть частью DSLC для реализации модели машинного обучения.
- Функциональная проверка - Обеспечьте функциональную производительность модели машинного обучения с помощью адекватного тестирования, включая модульное, интеграционное и бизнес-приемочное тестирование. Валидации на уровне кода также являются важной частью стратегии сквозной валидации.
- Справедливость машинного обучения: модель машинного обучения справедлива и не поддерживает или не поддерживает какую-либо отдельную группу или совокупность групп.
- Безопасный DSLC: жизненный цикл Data Science следует методам построения безопасных данных и моделей
Вышеупомянутые три требования в дополнение к конфиденциальности данных (которые мы не рассматриваем в этой статье) в основном формируют качественную основу модели машинного обучения. Давайте посмотрим на них по отдельности.
Функциональная проверка
Раннее выявление и устранение проблем необходимы для поддержания оптимального уровня затрат на качество. Взгляд инженера по обработке данных на качество будет вращаться вокруг стандартных показателей качества данных. Спросите любого инженера по модели машинного обучения о тестировании - ответ в основном будет касаться наборов данных тестирования и проверки. Но DSLC должен обеспечивать целостную гарантию качества поставляемой модели машинного обучения.
Фаза управления данными
В рамках деятельности по конвейеру данных инженеры по обработке данных включили необходимые проверки для обеспечения основных целей качества данных, таких как проверка дубликатов, отсутствующие значения и т. Д., Например, в Apache Nifi и Airflow есть механизмы валидатора. Требования к тестированию на этом этапе более зрелые по сравнению с другими этапами из-за текущих проектов BigData / BI / Analytics. В настоящее время основное внимание уделяется тому, чтобы отойти от мышления в пакетном режиме и максимально приблизить этап управления данными к требованиям CI / CD. За последние пару лет были созданы специализированные фреймворки, такие как Great Expectations и Tensorflow Data Validation (TFDV), с упором на раннее тестирование данных. Эти фреймворки построены со специализированными функциями тестирования, обеспечивая необходимое разделение требований валидации от «программной» части конвейера данных.
Фаза построения модели
Важным шагом, который уменьшит количество кошмарных диагностических запусков во время построения модели, будет проверка данных перед началом обучения модели машинного обучения. Хотя определенный уровень гарантии качества данных должен был быть обеспечен во время приема, данные должны были пройти через множество уровней преобразования в конвейере данных, чтобы добраться до этой точки. На этом этапе настоятельно рекомендуется защитное программирование с проверками, такими как проверка формы данных, проверка схемы, аномалии данных и т. Д. Этого можно достичь с помощью сочетания встроенного программирования с использованием кода Python и вызовов функций библиотеки данных - например. Функции TFDV, такие как display_anomolies / validate_statistics.
Проверка времени сборки с помощью тестового набора данных гарантирует, что модель машинного обучения работает в рамках ограничений исходного распределения данных. Готовность модели машинного обучения к продвижению от разработки к производству зависит не только от совокупных показателей производительности, таких как оценка F1, AUC, ROC и т. Д. Теоретически допустимый сценарий может быть чрезмерно представлен в сбоях даже в высокопроизводительной модели машинного обучения. . Только когда специалист по анализу данных изучит результат и связанные с ним тестовые данные (выборка за выборкой), он / она сможет обнаружить этот перекос. Этот очень важный аспект ручной проверки производительности модели машинного обучения чаще всего пропускается инженерами машинного обучения.
Управление развертыванием - этап AIS
Интеграционное тестирование: в проектах, где приложение на основе машинного обучения заменяет существующее приложение, не относящееся к машинному обучению, практический подход к интеграционному тестированию должен заключаться в том, что критерии успеха не должны изменяться из-за внедрения машинного обучения. Любое изменение на уровне тестового примера для внедрения ML должно быть тщательно проанализировано и подписано менеджером тестирования.
Приемочное тестирование: настоящая ценность приемочного тестирования возникает, когда конечный пользователь вырабатывает уровень доверия к приложению до его запуска. Доверие к приложению, основанному на модели машинного обучения, может оказаться более трудным. Из-за своей недетерминированной природы система, основанная на модели машинного обучения, может выглядеть слишком темпераментной по сравнению с традиционной программируемой. Наиболее предпочтительный подход - дать пользователю возможность поиграть с моделью машинного обучения с помощью простых в использовании интерфейсов, которые дают ему / ему интуитивное представление о поведении модели машинного обучения. Поведение можно сделать вывод, позволив пользователю изменять значения характеристик в пределах понятных границ (создавать контролируемые возмущения), чтобы увидеть влияние на прогнозы. Если пользователь создает возмущение, ожидая, что вывод изменится по сравнению с исходным прогнозом, поведение может стать причиной для беспокойства. Курсив преднамеренно означает, что неожиданное поведение модели машинного обучения не обязательно должно быть проблемой во всех случаях. Сочетание такого рода экспериментов с объяснимостью модели машинного обучения позволит пользователю глубже оценить работу модели машинного обучения и развить уверенность в новой системе. IBM AIX360 - фантастический фреймворк для этого. В дополнение к этому, настройка способа запуска контрфактов - еще один способ вглядываться в таинственную работу сложных моделей машинного обучения. Инструмент Google What-if и Cortex CertifAi - два инструмента, которые обеспечивают хорошую основу для достижения этой цели.
Управление развертыванием - этап ILS
Также необходимо постоянно оценивать ввод данных о времени вывода. Проверка на перекос в распределении данных при обучении - это то, что может помочь выявить проблему до того, как она затронет развернутую модель машинного обучения. Для проведения этой оценки нам необходимо постоянно сравнивать данные логического вывода с базовыми данными обучения, связанными с реальной моделью машинного обучения. Тренд на перекос может дать оценку дрейфа за период времени и помочь принять необходимые меры до того, как система упадет. TFDV предоставляет удобные функции generate_statistics / validate_statistics для создания базовой линии обучения и проверки данных вывода. Для неструктурированных данных в этой области начинают находить применение новые подходы с использованием базовых линий на основе гистограмм и центроидов.
Использование начального живого тестирования, такого как A / B, Multi-Arm Bandit, Canary testing и т. Д., До полноценного развертывания теперь становится все более распространенным и быстро набирает обороты. Поскольку реальная проверка производительности модели машинного обучения проводится с использованием оперативных данных, настоятельно рекомендуется по возможности проводить подобные живые рандомизированные контролируемые эксперименты. Успех этих тестов явно зависит от выбора ключевых показателей эффективности, отбора когорт и продолжительности тестирования. Поскольку данные доступны в реальном времени, может возникнуть соблазн быстро отреагировать на показатели. Но из-за статистических особенностей, которые являются основной причиной, по которой мы в первую очередь начинаем проводить эти типы тестирования, лучше позволить тестам идти своим чередом, изучать результаты и принимать меры.
Ключевые выводы
- Настоятельно рекомендуется использование специализированных платформ тестирования, таких как Great Expectations и TFDV, на этапе конвейера данных.
- Проверка времени сборки - это комбинация показателей производительности модели машинного обучения и ручных проверок сценариев режима отказа для обеспечения надлежащего поведения машинного обучения.
- На этапе приемки и тестирования бизнес-пользователям должны быть предоставлены правильные инструменты для игры и развития доверия с моделями машинного обучения.
- Правильная стратегия операций машинного обучения включает в себя мониторинг дрейфа данных с использованием базовых обучающих данных и данных логического вывода в реальном времени, чтобы предотвратить сбой реальной модели машинного обучения.
- Используйте рандомизированные контрольные эксперименты, чтобы убедиться, что модель машинного обучения работает хорошо в условиях реального трафика.
Мы будем освещать ML Fairness и Secure DSLC в частях 2 и 3. Благодарность и ссылка в конце части 3.
