Как тестировать продукты с AI под капотом

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Меня зовут Артем Прищепов, я занимаюсь вопросами качества около 8 лет. Сейчас мой фокус находится в построении и оптимизации QA-процессов/подразделений. Сегодня я хочу поделиться опытом Solvd в тестировании продуктов, которые содержат в себе модули на основе машинного обучения. Когда мы столкнулись с этой предметной областью, у команды было много вопросов и неуверенности в том, как именно гарантировать заказчику предсказуемое качество конечного продукта.

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

Мы уже успели привыкнуть к тому, что модели машинного обучения используются в production-проектах повсеместно. К сожалению, не связанные с прикладной ML-разработкой или хотя бы в общих чертах знакомые с data science члены команды не всегда понимают, можно ли доверять качеству конечного продукта. Еще интереснее, когда заказчик как обычно просит гарантий работоспособности и наличия объективных критериев приемки модели кроме «подали на вход, смотрим на выход».

Вкупе с этим, методы машинного обучения сегодня используются в большом количестве доменов:

• Прогнозирование финансовых показателей;
• Кредитный скоринг;
• Обнаружение мошенничества;
• Предсказание ухода клиента;
• Медицинская диагностика;
• Промышленная диагностика;
• Компьютерное зрение (распознавание лиц, объектов на изображениях и видео, распознавание символов);
• Распознавание речи и тп.

Несмотря на то, что бизнес-домены разнятся между собой, вот наиболее часто задаваемые вопросы, которые мы получаем от наших заказчиков касательно процесса обеспечения качества в контексте AI-based продукта:

1. Я хочу провести приемку (UAT), можете ли вы мне рассказать как это сделать?
2. Окей, мы развернули модель в проде, как мне быть уверенным что ничего не сломается?
3. Как мне быть уверенным в том, что модель не врет?

Как правило, от QA ожидают простых и понятных ответов на эти вопросы. Как их предоставить? Стоит ли опасаться чего-то за рамками традиционных процедур QA?

Попробуем разобраться.

Краткое введение в машинное обучение для тестировщика

Чтобы разобраться в отличиях ML-тестирования от любого другого взглянем на то, как все работает. Есть ли разница между классическими алгоритмами / hardcoded логикой и функционалом, основанном на ML-моделях?

С точки зрения blackbox-подхода, это все тот же ящик с входами и выходами. Подай данные на вход, посмотри что с ними на выходе — красота ведь?

Тем не менее, внутри ящика, а именно в том, как система строится, все немного иначе. Основное отличие «на пальцах» вот в чем:

Вы пишете функцию на основе правил, которые задаете сами (традиционное программирование) или функция с ее коэффициентами подбирается путем работы алгоритма на основе тех данных, которые вы ему даете (машинное обучение).

Типичный процесс разработки состоит в следующем:

1. Формулирование задачи на основании бизнес-требований;
2. Сбор, очистка и подготовка данных (ибо garbage in — garbage out);
3. Выбор альтернатив алгоритмов обучения на основе типа задачи, доступности данных и их качества;
4. Параметризация алгоритма;
5. Разбиение датасета на обучающую и тестовую выборки;
6. Запуск процедуры обучения на подходящей инфраструктуре;
7. Итеративное обучение с требуемым количеством эпох, с регулярным тестированием на изолированных тестовых выборках данных;
8. Подготовка модели к продакшн использованию (часто подразумевает ре-имплементацию на другой технологии для оптимизации производительности).
9. Интеграция функционала, основанного на модели в продакшн-систему.

Методы машинного обучения могут решать следующие задачи:

1. классификации
2. ранжирования
3. регрессии / прогнозирования
4. кластеризации
5. поиска ассоциативных правил
6. поиска пропущенных значений и тп.

Они так или иначе соотносятся с решаемой бизнес-задачей и, как правило, на проекте используется ограниченное и малое число решаемых задач. Для каждой из них есть свои методы оценки качества модели (обычно оцениваются командой data science, но нам как QA полезно их понимать). Тут есть отличные факультативные материалы на эту тему.

В чем здесь роль QA

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

1. В ваших тест-кейсах есть разные тестовые датасеты. Помните: клиенту больнее всего в случае поломки системы при контакте с реальными данными, которые не всегда однотипны. Постарайтесь добыть несколько сетов данных в этих целях (пункт 7 может с этим помочь). При этом входные данные для выборки не эквивалентны по важности: функция распознавания речи голосового помощника должна хорошо отрабатывать на «позвони ребенку», «какая сейчас погода», и скорее всего менее требовательна к распознаванию сочетаний таких как «импенданс магнепланарных наушников». Соответственно, в целях оптимизации времени тестирования данные можно и нужно ранжировать.

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

3. Регрессия: у вас есть сервис, основанный на ML-функционале и развернутый в продакшн-окружении, который постоянно обновляется по мере прохождения новых эпох обучения. Он запущен, и вы хотите быть уверены, что результативность системы не ломается автоматическим развертыванием новых версий модели. Для этого случая используйте классический сценарий черного ящика: загрузите тестовый датасет и проверьте, что выходные данные лежат в допустимой области (например, сопоставляя с данными выходов модели на pre-deployment стадии). Принимайте во внимание: этот процесс не про полное соответствие actual и expected result, а про то, насколько actual result близок к expected. Часто бывает, что ошибка модели не будет являться багом в привычном нам понимании. Нас в первую очередь интересует систематика проблемы.

4. Если вы используете средства автоматизации для осуществления регрессионного контроля, будьте уверены в том, что задан необходимый уровень допустимого отклонения результата, а также допустимый уровень выбросов. В противном случае ваши тесты будут регулярно падать. Используйте метрики, соответствующие типу задачи, и проведите обязательный data scientist review для ваших тестовых сценариев.

5. Обязательно проверяйте, процессит ли развернутая ML-функция данные корректно (часто встречается инверсия +/-). Тут хорошо работает white-box подход: используйте тесты для проверки корректности загрузки входных данных, проверки feature outputs. Чем сложнее процесс подготовки данных и чем более он автоматизирован, тем тщательнее вам необходимо это отслеживать.

6. Данные в вашем продакшене могут мутировать. Это означает, что при тех же входных данных теперь ожидается другой выход — например, поведение пользователей изменилось. Технически ваша классно протестированная модель не станет дряхлой со временем, но она запросто станет непригодной. Это, к слову, один из важных моментов, который стоит обсудить с вашим клиентом: майнтенанс. Как правило, вы перестанете обучать модель лишь тогда, когда система перестает работать в продакшене. Объясняя это клиенту вы будете реже попадать в ситуацию, где в меняющемся рынке виноват QA. Не говоря о ситуации с динамически меняющимися данными. Если этот риск высок, распространены 2 подхода:

• Простой, но дорогой: переобучать часто, на свежих датасетах, и так же часто деплоить. Тут следует помнить о правильном балансе, так как переобучение требует инфраструктурных затрат.
• Сложный, но более дешевый и зависящий от способа сбора обратной связи. Если вы решаете задачу бинарной классификации (например, мошенник/не мошенник), вы можете делать регулярный расчет precision/recall/f1 и написать сервис, который будет регулярно скорить вашу модель с новыми данными. Если f1 падает ниже допустимого вашей задачей уровня, вы получите алерты, тогда пора работать над качеством модели.

7. Публичный бета тест — это просто мастхэв для ml-based систем. Чем больше хороших данных использовано как в обучении, так и в тестировании, тем лучше получится ваша модель. Одна из целей вашего проекта заключается в том, чтобы иметь хороший датасет, поэтому используйте для этого любую возможность. Важно: данные не должны быть экстраполированы — толку не будет. А вот если вы запустите 300 пользователей из закрытой бета-группы, которые нагенерят вам тестовых данных как реальные пользователи, такая штука будет бесценной. Оригинальный датасет — это хорошо, но большее количество качественных данных как правило лучше.

8. Уделяйте вниманию тестированию интеграции — они ломаются не менее часто, чем основанные на ML модули.

9. Подключите автоматический сервис мониторинга вашего продукта в стиле pingdom (общая мера для любых сервисов, не только AI). Такие штуки спасали наше лицо перед заказчиком множество раз. Существуют гораздо более продвинутые devops-решения для этого, но мы начинали именно с такой простой системы.

Отвечая на исходные вопросы

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

1. Я хочу провести приемку (UAT), можете ли вы мне рассказать как это сделать?

• Опишите черный ящик заказчику и предоставьте ему сеты тестовых данных, использованных в ваших тест-кейсах. Объяснив зачем нужен каждый из сетов, вы поможете ему не запутаться в процессе приемки;
• Опишите ему все слои, на которых производится тестирование (начиная от валидации данных и самой модели в процессе обучения, заканчивая интеграционными слоями);
• Предоставьте отчет о качестве модели от команды data science, где будут отражены текущие метрики модели в сравнении с базисными значениями.

2. Окей, мы развернули модель в проде. Как мне быть уверенным, что ничего не сломается?

• Вам необходимо проводить интеграционный QA sign off каждого пуша в прод, как и в случае с любым другим программным продуктом;
• Staged rollout всегда лучше, чем его отсутствие. Выводите новую модель к реальным пользователям постепенно, итеративно добавляя все больше пользователей (и тестовых данных как следствие);
• Ваши white-box тесты должны быть зелеными;
• Скорьте модель почаще для отлова глобальных изменений во внешних данных.

3. Как мне быть уверенным в том, что модель не врет?

• Необходимо иметь договоренность о допустимом % отклонений, и степени этих отклонений;
• Необходимо проводить регулярный мониторинг отклонений на данных прода.

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