Подписаться
Читать в телеграм
Какие проблемы могут возникнуть в случае некорректного тестирования ML-системы?
В чем специфика подходов к тестированию ML-моделей?
Почему классическое регрессионное тестирование не работает для ML?
Машинное обучение (Machine Learning, ML) находит все новые сферы применения: финансы, производство, медицина, логистика, ритейл и индустрия развлечений. Если раньше преимущества машинного обучения были доступны только крупным компаниям, то сегодня получить доступ к технологиям стало намного проще: достаточно запросить ML-экспертизу у интегратора. С ростом экспертизы обогащается и «копилка опыта» в сфере машинного обучения.
Специфика тестирования ML
При всей востребованности машинного обучения, из поля зрения заказчиков и исполнителей подобных проектов зачастую выпадает область тестирования в классическом ее понимании. Если тестированию уделяется недостаточно внимания, то это может привести к некорректной работе ML-систем и вызвать разочарование заказчика в технологии как таковой. Конечно, сами специалисты по работе с данными (Data Scientists) проверяют свои модели, используя специальные метрики, однако реальность такова, что сервис не всегда способен учитывать различные нюансы и узкие места производства. К сожалению, в ИТ-отрасли пока нет устоявшихся практик тестирования ML-сервисов, поэтому, подбирая тесты, мы опираемся на собственную экспертизу и опыт специалистов, знающих отраслевую специфику компании-заказчика.
На чем команда тестирования акцентирует внимание?
- На соблюдении критериев качества конечной рекомендации
В классическом тестировании мы всегда можем прогнозировать результат: как система отреагирует на те или иные входные данные. Если речь идет о применении ML в производственных средах, этим прогнозируемым результатом может стать соблюдение регламентирующих документов: ГОСТов, инструкций, постоянных и временных технологических карт, определяющих производственные процессы и качество конечного продукта. Тестирование позволяет убедиться в том, что прогнозы ML-системы не идут вразрез с регламентами, принятыми на предприятии.
- На умении сервиса работать с узкими местами на производстве
Лучше всего у ML-моделей получается рекомендовать то, что в исторических данных встречается чаще всего. И наоборот: модель становится бесполезной, как только сталкивается с чем-то непривычным для себя. Зачастую, чтобы оптимизировать сервис, приходится «вшивать» в него строгую логику, чтобы добиться адекватного поведения в той или иной ситуации. Но тут возникает вопрос: как предусмотреть все возможные случаи до того, как систему запустят в промышленную эксплуатацию?
На ранних этапах, чтобы определить уязвимые места модели, можно воспользоваться эмуляцией производственной среды. А после отладки сервиса — запустить его в фоновом режиме на производстве и начать Silence- тестирование. Этот процесс позволяет, не отвлекая оператора от работы, отслеживать все совершаемые им действия, чтобы в дальнейшем сопоставить их с теми, что рекомендовал сервис в аналогичный промежуток времени.
Кейс
Задача
Нам нужно было разработать сервис рекомендаций для управления производством материала N (информация о проекте пока не подлежит разглашению, поэтому далее по тексту используются условные наименования).
Решение
На первом этапе архитектор разработал интеграционный эмулятор, который генерировал данные, аналогичные продуктивным, и тем самым заполнял дата-фрейм, на основе которого оптимизационная модель выдавала рекомендации по обработке материала N.
Затем тестировщик разбирал эти рекомендации и выявлял наиболее подозрительные — те, которые выбивались из общей массы потока рекомендуемых параметров. Уже на этом этапе удалось выявить множество случаев, когда модель не могла адекватно обработать входящий поток данных. Мы стабилизировали состояние сервиса и перешли к следующей стадии ― Silence-тестированию. Сервис был введен в производственную среду в фоновом режиме. Он работал, не отвлекая оператора обработки материала N от управления станком, а мы, в свою очередь, собирали «операторские решения», сопоставляя их с теми, что рекомендовал сервис. Это помогло нам найти слепые зоны модели, которые не удалось отловить на предыдущем этапе.
- На регрессионном тестировании
Практика показала, что регрессионное тестирование, проверяющее работоспособность связанных компонентов при изменениях, для ML должно быть значительно обширнее, чем для другого ПО. В последнем случае есть возможность обратиться к системе контроля версий — посмотреть, в какие функции были внесены изменения и где эти функции использовались, чтобы разграничить зоны необходимых проверок. Для ML-моделей это не работает: в них все переплетено настолько сильно, что внесение даже небольших поправок в одной области способно спровоцировать возникновение ошибок в другой или даже привести к сбою всей системы. Поэтому мы вынуждены проверять работу наших сервисов целиком от релиза к релизу. В данном вопросе автоматизация тестирования может сильно облегчить решение задачи.
Если тестированию уделяется недостаточно внимания, это может привести к некорректной работе ml-систем и вызвать разочарование заказчика в технологии как таковой.
Инструменты тестирования ML
Несмотря на то что методология тестирования ML еще не устоялась, инструменты для его проведения можно использовать вполне традиционные:
- Jira для проектного управления. В ней мы планируем разработку, декомпозируем задачи и фиксируем дефекты ML-сервиса.
- Test Rail для управления качеством. Он позволяет удобно хранить тестовые сценарии для системы, управлять их прогонами и выгружать различную отчетность по части тестирования.
- GitLab в качестве системы контроля версий.
- Jenkins для CI/CD и запуска автотестов.
Сами автотесты мы реализуем в связке python + pytest либо java + testng/junit.
Построение практики ML-тестирования стало для нас вызовом, мы фактически «вырастили» ее с нуля. Несмотря на все трудности, тестирование необходимо: оно помогает уменьшить количество ошибок до выхода решения в опытную эксплуатацию и сократить срок внедрения.
Кейс
Задача
Перед нашей командой стояла задача оптимизировать производство материалов N (кейс пока не разглашаем, поэтому будем использовать анонимные названия) с помощью машинного обучения.
Решение
Мы классифицировали все марки смесей материалов N по уровню содержания в них химических элементов. Этот список мы планировали использовать для обеспечения достаточного тестового покрытия.
Убедившись в том, что выданные моделью рекомендации по всем этим смесям были безоговорочно приняты производственными технологами, мы зафиксировали результат в CSV-файле. Так мы получили рекомендации «золотого стандарта».
Далее мы написали скрипт, который от версии к версии прогонял список наших эталонных смесей через модель и сравнивал результат ее выдачи с теми, что хранились у нас в CSV «золотого стандарта».
Если никаких изменений в поведении модели не выявлялось, регрессионные тесты считались успешно пройденными. В противном случае проводился «разбор полетов».
Таким образом, мы решили вопрос регрессионного тестирования и убедились в том, что вносимые в модель изменения не затрагивают более ранних результатов нашей работы.