С помощью ML-моделей сегодня выдают кредиты, регулируют движение на дорогах, определяют цены на товары и многое другое. Однако, процесс их разработки и вывода в продуктивную среду сложен и полон подводных камней. Очень часто качество прогноза, основанного на реальных данных, не соответствует ожиданиям пользователей. Меня зовут Надежда Костякова, я руковожу управлением анализа данных и машинного обучения в Первой грузовой компании (ПГК). В статье расскажу о принципах, которым следует наша команда Data Science, чтобы гарантировать надежную работу алгоритмов машинного обучения в продуктивной среде.

Какие проблемы возникают при использовании ML-моделей?

В 2013 году на площадке Kaggle было запущено соревнование. Его участники должны были отличить звук, издаваемый китом, от остальных звуков. Запуск прошел нормально, и люди начали загружать свои результаты. Один из них поразил организаторов: он был сильно выше ожидаемого и достигал невероятного показателя 0,99 ROC AUC. Как выяснилось, результат этот был достигнут даже без чтения звуковых файлов. Что же произошло?

Оказалось, что файлы с записью китов отличались по продолжительности от остальных, имели другой формат даты и были сгруппированы по времени. Организаторы и участники столкнулись с проблемой Data Leakage – когда не основные данные, а метаинформация помогла достичь результата. Это огромная проблема при использовании модели в «проде»: в реальных условиях у модели не будет таких метаданных, и ее результат будет крайне низким. В бизнесе это может привести к значительному экономическому ущербу.

Довольно часто встречаются задачи по классификации с сильным дисбалансом групп. Например, нужно определить наличие опухоли мозга по снимкам МРТ. Так как эта разновидность болезни встречается довольно редко, выборка содержит большое количество снимков без нее. Что может пойти не так? При оценке качества моделей бинарной классификации часто используют простые и понятные заказчику метрики, например, Accuracy – отношение правильно спрогнозированных классов относительно всех наблюдений. Ее легко использовать для оценки моделей.

Accuracy=\frac{TP+TN}{TP+FP+TN+FN}

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

Теперь перейдем к недавнему примеру с Xsolla. В компании захотели выявить неэффективных сотрудников, и отдел, занимающийся анализом больших данных, подготовил отчет об использовании всеми сотрудниками корпоративных инструментов: таск-трекера, базы знаний, почты и т.д. Отчет получился комплексным, но решил ли он задачу? 

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

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

Принципы ResponsibleAI приходят на помощь

Развитие ИИ создает новые возможности для улучшения качества жизни людей во всем мире. При этом важно научиться строить справедливые, интерпретируемые и безопасные системы, которые позволят получить объективные данные, соответствующие реальности. Недавно Google представил набор принципов, следование которым поможет снять часть вопросов, связанных с разработкой моделей.

- Концентрация на пользователе при разработке моделей и систем

То, как люди используют вашу систему, критически важно при разработке моделей. Для правильной интерпретации результатов нужно корректно сформулировать решаемую задачу и понимать контекст использования модели.

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

- Использование нескольких метрик для оценки модели

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

- Понимание данных для построения модели – ключевой фактор

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

- Понимание и трансляция ограничений своего датасета и данных

Модели основываются только на тех паттернах, которые есть в данных. Важно понимать имеющиеся ограничения и, более того, рассказывать об этом пользователям и заказчикам.

Наглядным примером может стать разработанная специалистами Amazon модель, которая отдавала предпочтение мужской аудитории при найме на работу. Подготовленный датасет не был достаточно проанализирован, что привело к неправильной трактовке результатов модели.

- Тестируйте

Тестирование – это ключ к созданию устойчивой и надежной системы, оно тесно вплетено в процесс разработки. Не менее важно тестирование и при разработке моделей.

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

- Продолжайте мониторить работу вашей модели после запуска в промышленную эксплуатацию

Мир меняется, распределения в обучении отличаются от распределений в «проде», пользователи взаимодействуют с моделью. Поэтому работа специалистов не может закончиться на этапе разработки. Необходимо постоянно смотреть на меняющийся контекст, чтобы модель всегда служила поставленной цели.

Широкое распространение ML-технологий только начинается, и, очевидно, мы еще не зафиксировали все проблемы, которые могут возникнуть в этой сфере. Однако, часть из них  уже можно пытаться решать, придерживаясь принципов, описанных выше. Необходимо постоянно развиваться в этом направлении и говорить о появляющихся сложностях. Именно так мы все сможем прийти к Responsible AI.

Примеры я брала в этих статьях, можно почитать более подробно:

https://www.capitalone.com/tech/machine-learning/10-common-machine-learning-mistakes/

https://hyperight.com/deep-learning-and-healthcare-breaking-new-ground-with-brain-tumour-segmentation/

https://ai.google/responsibilities/responsible-ai-practices/

Комментарии (0)