Версия сайта для слабовидящих
Мы уже писали про особенности тестирования систем машинного обучения. Чтобы не повторяться, сегодня рассмотрим фреймворки для реализации идей MLOps, а также рассмотрим, какие тесты должны быть пройдены для проверки работоспособности ML-продукта.
3 категории тестов для ML-систем
Согласно концепции MLOps, полный конвейер разработки включает в себя три основных компонента: конвейер данных, алгоритмы ML-моделей и код приложения. Поэтому можно выделить 3 области тестирования в системах Machine Learning: тесты фичей и данных, тесты разработки моделей и тесты ML-инфраструктуры.
Для проверки фичей и данных надо реализовать следующие тесты:
- автоматическая проверка схемы данных и фичей. Для этого надо рассчитать статистику на основе обучающих данных. Эту схему можно использовать в качестве определения ожиданийили семантической роли для входных данных на этапах обучения и обслуживания ML-модели.
- тест важности фичей позволяет понять, добавляют ли новые фичи пользу ML-модели. Для этого следует вычислить коэффициент корреляции между предикторами, а также сравнить результаты моделей, обученных с разным набором фичей. При этом также надо измерить зависимости данных, задержку вывода и использование оперативной памяти для каждой новой фичи. По результатам сравнения необходимо удалить неиспользуемые/устаревшие фичи из инфраструктуры и отразить это в документации.
- Проверка на соответствие политикам, например, GDPR;
- Модульное тестирование кода создания фичей, чтобы выявить устранить ошибки.
Для проверки надежности ML-модели проводятся следующие тесты:
- Тестирование обучения ML, включая процедуры, которые проверяют, что алгоритмы принимают решения, соответствующие бизнес-целям. Это означает, что показатели потерь алгоритма машинного обучения (среднеквадратическое отклонение и пр.) должны коррелировать с бизнес-метриками (доход, вовлечение пользователей, клиентский отток и пр.). Чтобы понять взаимосвязь показателей потерь и бизнес-метрик, можно провести небольшое A/B-тестирование с использованием намеренно ухудшенной модели.
- Тест на устаревание модели. Модель Machine Learning считается устаревшей, если она не включает актуальные данные и/или не удовлетворяет требованиям влияния на бизнес. Для этой проверки также необходим A/B-эксперимент со старыми моделями, с возможностью отслеживать возраст алгоритма и качество результатов, чтобы понять, как часто следует обучать ML-модель.
- Оценка стоимости сложных моделей машинного обучения: производительность сложной ML-модели следует сравнить с простой базовой моделью машинного обучения, например, нейросеть vs линейная регрессия, чтобы использовать более простое и не требовательное решение.
- Проверка работоспособности модели. Здесь рекомендуется разделить команды и процедуры, собирающие обучающие и тестовые данные, чтобы устранить зависимости и избежать распространения ложной методологии из обучающего набора в тестовый набор. Для этого следует использовать дополнительный набор тестов, который не связан с наборами для обучения и проверки.
- Тестирование предвзятости для оценки объективности модели машинного обучения. Необходимо собрать как можно больше данных, включающих редкие категории, чтобы проверить объективность результатов прогнозирования.
- Наконец, необходимо выполнить обычное модульное тестирование для проверки кода создания любой фичи и обучения ML-модели.
Наконец, для тестирования инфраструктуры машинного обучения необходимо провести следующие проверки:
- Воспроизводимость машинного обучения — ML-модели, обученные на одних и тех же данных, должны выдавать идентичные результаты. Дифференциальное тестирование моделей машинного обучения основано на детерминированном обучении, которого трудно достичь из-за невыпуклости алгоритмов машинного обучения, генерации случайных начальных чисел или распределенного обучения ML-модели. Поэтому следует определить недетерминированные части в базе кода обучения модели и попытаться сократить недетерминизм.
- Проверка ML API и нагрузочное тестирование. Модульные тесты для случайной генерации входных данных и обучения модели для одного шага оптимизации, например, градиентного спуска. А крэш-тесты позволяют проверить устойчивость модели, которая должна восстанавливаться с контрольной точки после сбоя в середине обучения.
- Проверка корректности алгоритмов. Следует провести модульное тестирование для определения и уменьшения потерь во время обучения. При этом рекомендуется избегать дифференциального тестирования с ранее созданными ML-моделями, поскольку такие тесты сложно поддерживать.
- Интеграционное тестирование всего ML-конвейера. Необходимо создать полностью автоматизированный тест, который регулярно запускает весь конвейер машинного обучения. Такой тест должен подтвердить, что данные и код успешно завершают каждый этап обучения, а полученная ML-модель работает должным образом. Все интеграционные тесты следует запускать до выпуска модели в производственную среду.
- Проверка модели ML перед ее обслуживанием. Необходимо установить пороговые значения и протестировать ухудшение модели при разных условиях, включая внезапные падения производительности.
- Проверка выпуска ML-модели, т.е. подтверждение того, что она успешно загружается в рабочую среду и прогноз на основе реальных данных генерируется должным образом.
- Наконец, надо проверить разницу производительности модели в промышленной среде по сравнению с тестовой, стараясь обеспечить аналогичные условия обучения и обслуживания. Существенная разница в результатах указывает на инженерную ошибку.
Разобравшись с тем, какие тесты нужны для всесторонней проверки ML-модели, далее рассмотрим, как их разработать и автоматизировать проверку согласно принципам MLOps.
Тестирование ML с точки зрения MLOps
Типовой шаблон написания функции модульного теста включает следующие шаги:
- определить входные данные;
- выполнить логику, которую надо протестировать, с входными данными, и получить результаты;
- определить ожидаемые результаты;
- сравнить фактические результаты с ожидаемыми.
Платформой модульного тестирования по умолчанию в Python является Unittest . Он поддерживает автоматизацию тестирования, совместное использование кода настройки и завершения тестов, объединение тестов в коллекции и независимость тестов от системы отчетности. Также в Unittest имеется модуль unittest.mock, который позволяет использовать фиктивные объекты для замены частей тестируемой системы ML и делать утверждения о том, как они использовались. Для этого он предоставляет Mock-класс, который призван заменить использование тестовых двойников во всем проекте. Моки отслеживают, как они используются, позволяя делать утверждения о том, как ведет себя код.
Еще одна библиотека, предназначенная для помощи в написании модульных тестов для приложений, — Pytest. Pytest построен на трех основных концепциях, которые включают в себя тестовые функции, утверждения и настройку теста. Он имеет соглашение об именах для написания тестов, которое позволяет автоматически запускать тесты.
Фреймворк pytest помогает писать небольшие тесты и масштабируется для поддержки сложного функционального тестирования Python-приложений и библиотек. Он также отлично подходит для тестирования ML-моделей. С помощью pytest можно проводить модульное тестирование ML-моделей, при котором надо имитировать загрузку модели и прогнозы аналогично имитации доступа к файлам.
Модульные тесты ML не предназначены для проверки точности или производительности модели. Они нужны для проверки качества кода, например, принимает ли модель правильные входные данные и выдает ли выходные данные правильной формы, обновляются ли веса модели при запуске метода fit()? Еще одной важной частью модульного тестирования является включение тестовых примеров для проверки данных. Например, данные не предоставляются или представлены не в том формате, содержат нулевые значения или выбросы: все это нарушает надежность ML-конвейера.
В заключение отметим необходимость связать тестирование с процессом разработки согласно следующим принципам:
- atomic – при создании функций и классов необходимо убедиться, что у каждого из них есть единая ответственность , чтобы их легко протестировать. Иначе придется разделить их на более детальные компоненты;
- compose – при создании новых компонентов надо сразу составлять тесты для проверки их функциональности, чтобы обеспечить надежность и выявить ошибки на раннем этапе;
- reuse – следует поддерживать центральные репозитории, где основные функции тестируются в исходном коде и повторно используются, чтобы сократить усилия по тестированию кода в новых проектах;
- regression – регрессионные тест позволяют учитывать ошибки в новых версиях ПО, сравнивая их с предыдущими выпусками;
- coverage – покрытие кодовой базы тестами, что предполагает не написание теста для каждой отдельной строки кода, а проверку каждой строки кода;
- automate – автоматический запуск тестов при внесении изменений в кодовую базу.
Узнайте больше про использование MLOps-инструментов в системах аналитики больших данных и машинного обучения на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
