Сайт находится в состоянии доработки. Извиняемся за неудобства.

x
© 1995-2019 Компания «Инфосистемы Джет» Разработано в Liqium
Машинное обучение Тестирование ML-систем: еще не очевидная, но необходимая практика
Автор
Сергей Агальцов тест-менеджер Центра программных решений компании «Инфосистемы Джет»
Статей: 1 Фото-факт: 26

248

0.

12

0

3

Машинное обучение (Machine Learning, ML) находит все новые сферы применения: финансы, производство, медицина, логистика, ритейл и индустрия развлечений. Если раньше преимущества машинного обучения были доступны только крупным компаниям, то сегодня получить доступ к технологиям стало намного проще: достаточно запросить ML-экспертизу у интегратора. С ростом экспертизы обогащается и «копилка опыта» в сфере машинного обучения.

Специфика тестирования ML

При всей востребованности машинного обучения, из поля зрения заказчиков и исполнителей подобных проектов зачастую выпадает область тестирования в классическом ее понимании. Если тестированию уделяется недостаточно внимания, то это может привести к некорректной работе ML-систем и вызвать разочарование заказчика в технологии как таковой. Конечно, сами специалисты по работе с данными (Data Scientists) проверяют свои модели, используя специальные метрики, однако реальность такова, что сервис не всегда способен учитывать различные нюансы и узкие места производства. К сожалению, в ИТ-отрасли пока нет устоявшихся практик тестирования ML-сервисов, поэтому, подбирая тесты, мы опираемся на собственную экспертизу и опыт специалистов, знающих отраслевую специфику компании-заказчика.

На чем команда тестирования акцентирует внимание?

 

  • На соблюдении критериев качества конечной рекомендации

В классическом тестировании мы всегда можем прогнозировать результат: как система отреагирует на те или иные входные данные. Если речь идет о применении ML в производственных средах, этим прогнозируемым результатом может стать соблюдение регламентирующих документов: ГОСТов, инструкций, постоянных и временных технологических карт, определяющих производственные процессы и качество конечного продукта. Тестирование позволяет убедиться в том, что прогнозы ML-системы не идут вразрез с регламентами, принятыми на предприятии.

Кейс

 

Задача
Перед нашей командой стояла задача оптимизировать производство материалов N (кейс пока не разглашаем, поэтому будем использовать анонимные названия) с помощью машинного обучения.

 

Решение
Мы классифицировали все марки смесей материалов N по уровню содержания в них химических элементов. Этот список мы планировали использовать для обеспечения достаточного тестового покрытия.

 

Убедившись в том, что выданные моделью рекомендации по всем этим смесям были безоговорочно приняты производственными технологами, мы зафиксировали результат в CSV-файле. Так мы получили рекомендации «золотого стандарта».

 

Далее мы написали скрипт, который от версии к версии прогонял список наших эталонных смесей через модель и сравнивал результат ее выдачи с теми, что хранились у нас в CSV «золотого стандарта».

 

Если никаких изменений в поведении модели не выявлялось, регрессионные тесты считались успешно пройденными. В противном случае проводился «разбор полетов».

 

Таким образом, мы решили вопрос регрессионного тестирования и убедились в том, что вносимые в модель изменения не затрагивают более ранних результатов нашей работы.

  • На умении сервиса работать с узкими местами на производстве

 

Лучше всего у ML-моделей получается рекомендовать то, что в исторических данных встречается чаще всего. И наоборот: модель становится бесполезной, как только сталкивается с чем-то непривычным для себя. Зачастую, чтобы оптимизировать сервис, приходится «вшивать» в него строгую логику, чтобы добиться адекватного поведения в той или иной ситуации. Но тут возникает вопрос: как предусмотреть все возможные случаи до того, как систему запустят в промышленную эксплуатацию?

 

На ранних этапах, чтобы определить уязвимые места модели, можно воспользоваться эмуляцией производственной среды. А после отладки сервиса — запустить его в фоновом режиме на производстве и начать Silence- тестирование. Этот процесс позволяет, не отвлекая оператора от работы, отслеживать все совершаемые им действия, чтобы в дальнейшем сопоставить их с теми, что рекомендовал сервис в аналогичный промежуток времени.

Кейс

 

Задача
Нам нужно было разработать сервис рекомендаций для управления производством материала N (информация о проекте пока не подлежит разглашению, поэтому далее по тексту используются условные наименования).

 

Решение
На первом этапе архитектор разработал интеграционный эмулятор, который генерировал данные, аналогичные продуктивным, и тем самым заполнял дата-фрейм, на основе которого оптимизационная модель выдавала рекомендации по обработке материала N.

 

Затем тестировщик разбирал эти рекомендации и выявлял наиболее подозрительные — те, которые выбивались из общей массы потока рекомендуемых параметров. Уже на этом этапе удалось выявить множество случаев, когда модель не могла адекватно обработать входящий поток данных. Мы стабилизировали состояние сервиса и перешли к следующей стадии ― Silence-тестированию. Сервис был введен в производственную среду в фоновом режиме. Он работал, не отвлекая оператора обработки материала N от управления станком, а мы, в свою очередь, собирали «операторские решения», сопоставляя их с теми, что рекомендовал сервис. Это помогло нам найти слепые зоны модели, которые не удалось отловить на предыдущем этапе.

  • На регрессионном тестировании

 

Практика показала, что регрессионное тестирование, проверяющее работоспособность связанных компонентов при изменениях, для ML должно быть значительно обширнее, чем для другого ПО. В последнем случае есть возможность обратиться к системе контроля версий — посмотреть, в какие функции были внесены изменения и где эти функции использовались, чтобы разграничить зоны необходимых проверок. Для ML-моделей это не работает: в них все переплетено настолько сильно, что внесение даже небольших поправок в одной области способно спровоцировать возникновение ошибок в другой или даже привести к сбою всей системы. Поэтому мы вынуждены проверять работу наших сервисов целиком от релиза к релизу. В данном вопросе автоматизация тестирования может сильно облегчить решение задачи.

Инструменты тестирования ML

Несмотря на то что методология тестирования ML еще не устоялась, инструменты для его проведения можно использовать вполне традиционные:

 

  • Jira для проектного управления. В ней мы планируем разработку, декомпозируем задачи и фиксируем дефекты ML-сервиса.
  • Test Rail для управления качеством. Он позволяет удобно хранить тестовые сценарии для системы, управлять их прогонами и выгружать различную отчетность по части тестирования.
  • GitLab в качестве системы контроля версий.
  • Jenkins для CI/CD и запуска автотестов.

 

Сами автотесты мы реализуем в связке python + pytest либо java + testng/junit.

 

Вывод

Построение практики ML-тестирования стало для нас вызовом, мы фактически «вырастили» ее с нуля. Несмотря на все трудности, тестирование необходимо: оно помогает уменьшить количество ошибок до выхода решения в опытную эксплуатацию и сократить срок внедрения

 

Следите за нашими обновлениями

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал
Спасибо!
Вы подписались на обновления наших статей
Подписаться
на рубрику
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Оформить
подписку на журнал
Спасибо!
Вы подписались на наши новости.
Оформить
подписку на Новости
Ваш комментарий отправлен.
После прохождения модерации комментарий будет опубликован на сайте.
Оставить
комментарий
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Задать вопрос
редактору

Оставить заявку

Мы всегда рады ответить на любые Ваши вопросы

* Обязательные поля для заполнения

Спасибо!

Благодарим за обращение. Ваша заявка принята

Наш специалист свяжется с Вами в течение рабочего дня