Тестирование ML-моделей. От «пробирки» до мониторинга боевых данных
Представление нейросети о том, как выглядят «тесты моделей искусственного интеллекта» :) Мы бы поставили там еще котел и положили гримуар! Ведь так и работают датасайнтисты.
Из этой статьи вы узнаете, почему важно проводить «лабораторные испытания» ML-моделей, и зачем в тестировании наработок «ученых по данным» должны участвовать эксперты из предметной области, а также — как выглядят тесты после того, как модель покинула датасайнтистскую лабораторию (и это не только мониторинг качества данных).
На первый взгляд кажется, что тестирование ML-моделей должно проходить по классическим ИТ-сценариям. Моделируем процесс, присылаем сценарии тестерам, и начинается магия — невозможные значения входных данных, попытки сломать логику системы и т. д. В некотором смысле все работает именно так: процесс разработки ML-сервисов включает и этот этап. Но только в некотором смысле — ведь у науки о данных есть масса особенностей.
Если обобщить все многообразие вариантов тестирования ML-моделей, можно выделить три базовых сценария:
Лабораторные испытания
Тестирование на живых данных в опытном режиме
Мониторинговые исследования работающей модели
Существует специфика, когда через три базовых сценария проходит не новая модель, а уже работающее решение, которое нужно обновить. Здесь в приоритете сравнение эффективности старой и новой версий модели на одних и тех же данных. Конечно, мы в первую очередь ожидаем, что новая версия модели будет точнее или быстрее, или хотя бы допускать меньше ошибок в более критичных моментах по сравнению с предыдущей. Если при обновлении модели в результатах произошли серьезные сдвиги — это повод задуматься. Если на полноценное А/В-тестирование не хватает ресурсов, стоит запустить версии модели параллельно и проанализировать их поведение.
Лабораторное тестирование
Конечно, мы говорим не о настоящей лаборатории.
Мы проводим испытания в стерильной среде и проверяем эффективность модели в условной «пробирке». Что класть в эту пробирку и о каких ограничениях нужно помнить?
Прежде всего, тестовые данные не должны быть слишком уж стерильными. Во время обучения модели может возникнуть желание использовать только самую качественную и «красивую» информацию. Или, если у нас в распоряжении не так много данных, появляется соблазн взять лишь их малую часть. Ведь иначе у нас останется меньше информации для «боевого» моделирования.
В результате можно получить «переобученную» модель. Она хорошо запомнит правила в стерильных данных, но не сможет применить их в менее красивых кейсах. Как правило, в опытной эксплуатации эффективность подобных решений сильно падает, что вызывает недоумение разработчиков: «Странно, ведь предварительные результаты были так хороши!» Чтобы этого избежать, нужно тщательно формировать тестовый набор данных — учитывать и историческую информацию, и потенциальные изменения в бизнес-процессах.
Отметим, что тестовый набор не должен быть слишком простым для прогнозирования. Предположим, нам нужно сделать сервис, рекомендующий добавки к сплавам на сталелитейном производстве. 95% ассортимента являются более предсказуемыми по итоговой химии, оставшиеся 5% — более сложными, но и экономия за счет их оптимизации будет больше. При случайном разбиении данных на обучающий и тестовый наборы бóльшая часть тестовых случаев придется на простые кейсы с минимальной экономией. Следует ли специально отбирать в тестовую выборку более дорогие и сложные для прогноза марки? Или сохранить такую же пропорцию, что и на производстве, но отдельно рассматривать ошибки для более простых и сложных случаев? Или применить какое-то преобразование к данным в целом? В данном случае для принятия решения недостаточно вводных данных — в конечном счете оно будет зависеть и от доводов дата-сайнтистов, и от конкретных потребностей бизнеса. Может быть, мы выясним, что 95% продукции вообще не нуждаются в моделировании, и поставим на этот участок простой алгоритм, а сложные ML-модели будем использовать только при работе с редкими марками.
При этом тестовый набор не должен быть и слишком необычным — отражающим совсем нетипичные для моделируемой величины характеристики. Допустим, небольшому кафе нужно прогнозировать уровень спроса на салат оливье, чтобы понимать, сколько заготовок делать ежедневно. В течение года люди покупают блюдо с разной частотой, но к 31 декабря и в первые недели января спрос растет лавинообразно. При этом на него могут влиять корпоративы в соседних офисах, открытие новых близлежащих ЖК, настроение покупателей и еще масса факторов, которые мы не сможем учесть при обработке данных. Соответственно, период «новогоднего бума» лучше исключить из лабораторного тестирования. В противном случае мы покажем модели нетипичные периоды (и будем надеяться, что она найдет в них закономерности). А бизнесу интересен прогноз по заготовкам именно на обычный день. К праздничным форс-мажорам все уже привыкли, и оптимизировать эту часть производства не так выгодно.
Отметим, что способ, которым мы формируем тестовый набор данных, может оказать заметное влияние на дальнейшее тестирование решения. Один из самых распространенных подходов — перемешать всю имеющуюся историческую информацию и взять случайные наблюдения. Но всегда ли он эффективен?
Очевидно, этот подход плохо работает на меняющихся с течением времени процессах. При этом, даже если процесс на первый взгляд кажется стабильным, скорее всего, он все равно меняется, просто не самым очевидным образом. Например, вокруг продуктовых магазинов со временем появляются новые здания — жилые дома, офисные центры и т. д. На рынок выходят новые товары, которые могут повлиять на продажи старых и в принципе отсутствуют в исторических данных. Инновационное оборудование становится привычным, и специалисты начинают эффективнее его использовать. Идеально смоделировать ситуацию «пару лет назад» с точки зрения бизнеса может быть бессмысленно — многие подобные кейсы интересны только математикам.
Вариант «взять самые новые исторические данные и успокоиться» кажется логичным, но это тоже не панацея. Как минимум потому, что при выборе временного отрезка и соответствующих данных для тестирования нам нужно понимать, не произошло ли каких-то важных изменений в смежных периодах. Может быть, часть исторических данных теперь имеет действительно только историческую ценность?
Чтобы правильно определить подходящий временной период и сформировать качественный набор тестовых данных, необходимо:
Узнать у представителей бизнеса, какие факторы могли оказать заметное влияние на данные, с которыми будет работать модель.
Четко определить бизнес-задачи, для решения которых формируется тестовый набор (бизнесу не нужны метрики — важно повысить эффективность конкретных процессов).
Тщательно проанализировать исторические данные не только как единое целое, но и в разрезе «обучающий период vs тестовый». Возможно, во время анализа вы обнаружите что-то новое.
Дети, не играйте со спичками, не катите плохо протестированные модели в прод!
Тесты во время опытной эксплуатации
Все вышесказанное касается и выбора тестового периода для эксплуатации модели в реальных условиях. Кроме того, на этом этапе важную роль начинают играть «нетехнические» аспекты проекта. Так, снижение эффективности модели относительно лабораторного этапа вполне вероятно, и лучше заранее подготовить к этому представителей бизнеса. При этом важно понять, что вызывает эти отклонения: не было учтено что-то важное, банально не хватает данных или проблема в чем-то еще?
Также на этом этапе крайне важна кооперация со специалистами из предметной области. Возможно, они заметят что-то интересное: например, «шумовой» признак, оказавшийся в наборе из жадности до данных и очень опосредованно связанный с моделируемой переменной, как в известной байке о корреляции числа утонувших в бассейне с количеством фильмов с Николасом Кейджем.
Идеально, если специалисты из предметной области поучаствуют и в подготовке тестовых сценариев. С одной стороны, это даст вам свежий взгляд на процесс. С другой, предметники, как правило, больше всех заинтересованы в том, чтобы модель показала качественные результаты. Или же в том, чтобы продемонстрировать ее неэффективность, что с точки зрения тестирования тоже хорошо :)
Впрочем, не стоит слишком раззадоривать «злобных зрителей» из предметной области. Именно от них во многом зависит, будет ли в принципе проводиться тестирование в опытной эксплуатации (они могут запросто задавить бизнес отзывами о бесполезности решения). Обязательно вовлекайте в процесс специалистов на местах и объясняйте, как тестируемая модель улучшит их жизнь.
Рассмотрим две показательные истории. Все совпадения случайны, хотя эти проблемы действительно были с реальными ML-моделями, но немного в других условиях.
Кейс № 1. На производстве решили прогнозировать очень важное с коммерческой точки зрения свойство продукции. В конечном счете изделия принимают вид рулона, но много раз меняют форму во время производства (условно говоря, проходят путь от мотка шерсти до полотенца). Это важное свойство, разумеется, измеряется «лабораторно» и уже постфактум. Для этого дата-сайнтисты собрали внушительный набор данных, отражающий соответствие отдельных «ниток из мотка» конкретным частям финального «полотенца», рассчитали все физические преобразования и т. д.
Но настало время ставить опыты на новых данных. Результат — полный провал: свойства продукции совершенно не соответствуют прогнозам. Может быть, дело в неверной «склейке» разных этапов? Или не хватило обучающих данных? Перебирая разные варианты, дошли до рядовых сотрудников, ответственных за измерение того самого важного свойства. И выяснилось, что эти измерения просто нельзя считать надежными: если «полотенце» размотать и взять пробы из разных мест, разброс получится гораздо больше погрешности измерительного прибора. Зная об этом ограничении, специалисты на местах использовали меру «не выше определенного значения», а не точный показатель, на улучшение которого и рассчитывал бизнес.
Итог: по результатам тестирования модель уходит на доработку, на производстве обсуждается замена целевого показателя с непрерывных чисел на прогноз категориями.
Кейс № 2 — о противостоянии ML-модели и экспертов в предметной области.
Разрабатываемая модель решает задачу визуальной классификации изображений. Раньше этим занимались эксперты: грубо говоря, людям показывали картинки, а они присваивали им определенные метки (классы).
Наверняка все, кто имел дело с экспертной оценкой изображений, уже догадываются, что случилось во время тестирования. Модель показала очень низкую эффективность по сравнению с работой экспертов. К счастью, существует дорогой, но действенный метод решения этой проблемы — отдать картинки на перекрестную проверку другим специалистам. Если в значимом числе случаев метки не совпадают, возможно, для начала нужно формализовать саму методику классификации, а уже после этого передавать задачу ML-модели. Собственно, именно это и показала перекрестная проверка :)
Итог: бизнес пересмотрел метрики качества работы модели. Раз меткам экспертов тоже не всегда можно доверять, значит, и модель может чаще от них отклоняться. Кроме того, компания проработала план дальнейшего обучения модели, потому что осознала, что цифровой анализ эффективнее экспертного подхода.
Отдельно отметим вопрос тестирования моделей на устойчивость к атакам. Здесь нужны принципиальная возможность реализации атаки (скажем, датчики на производственной линии могут сломаться, но консистентность приходящих с них данных все равно будет проверяться мониторингом на производстве) и наличие очевидной выгоды для злоумышленника. Ведь далеко не каждую систему выгодно ломать.
Подобные тесты, скорее, входят в область задач ИБ-подразделений, но дата-сайнтистам тоже стоит проверять обученную модель на устойчивость к известным атакам.
Тестирование работающей модели
При обновлении уже работающей модели хорошо бы провести штатное тестирование. А что если решение глобально не обновляется и данные поступают строго в рамках пайплайна? В этом случае нужно проводить мониторинг качества данных. Это тоже своего рода тестирование (или аналитика — с какой стороны посмотреть).
Что проверять при мониторинге качества данных:
Наличие неожиданных входных данных. Источники информации, которую принимает модель, могут меняться. Некоторые изменения вполне очевидны, и алгоритмы могут их отследить, например, если новая модель датчика присылает измерения в других единицах. Другие изменения автоматически отследить невозможно: к примеру, если в компании вводится новая методология оценки рейтинга надежности клиентов. В зависимости от характера изменений могут потребоваться как минимальная коррекция кода, так и полное обновление модели.
Сдвиг данных со временем (Data Drift). Важно убедиться, что модель не устарела и показывает эффективные результаты даже на новых данных.
Сдвиг целевой переменной со временем. Нужно проверить, что имеющиеся распределения признаков все еще актуальны. Тогда будут актуальны и зависимости, обобщенные в ML-модели. Особенно если речь идет о признаках, которые генерятся поведением людей, например, покупки (а значит, и целевая переменная в данном случае зависит от перемен в поведении людей). Что будет в случае внезапного экономического кризиса? Или пандемии? Заранее на большинство подобных вопросов ответить нельзя, но это не значит, что не нужно проверять, как меняются отношения целевой переменной и признаков.
Вместо заключения
Нужно ли вам тестировать ML-решение? Обязательно! Если вы отвечаете за технический аспект разработки в дата-сайнс, еще раз подумайте, как объяснить бизнесу, что и почему вы планируете тестировать. Если же вы бизнес-заказчик, обязательно обсудите с ML-экспертами все нюансы процесса тестирования — от метрик и набора данных до критериев оценки эффективности решения.
Александра Царева,
дата-сайнтист центра машинного обучения «Инфосистемы Джет».
