Не стоит полагаться на искусственный интеллект,
если у вас нет глубокого понимания процесса.
Рэй Далио
В компании «Инфосистемы Джет» мы внедряем машинное обучение в самых разных отраслях, и на основе нашего опыта выделяем необходимые составляющие успешного внедрения:
На практике все эти элементы вместе встречаются крайне редко, по статистике, только около 7% проектов с ML считаются успешными. Проекты, имеющие все перечисленные составляющие, можно смело относить к прорывным! Для иллюстрации, мы сформулировали несколько тезисов, которые можно назвать вредными советами про внедрение машинного обучения в бизнес.
Часто заказчик формулирует задачу, как «просто внедрить машинное обучение для некой оптимизации», без какой-либо связи с бизнес-метриками и приоритезацией задач бизнеса.
В таком случае мы можем увидеть несколько негативных сценариев. Например, таргеты будут меняться по ходу работы, но это значит, что весь препроцессинг и выбор методов оптимизации будет меняться, потому что они напрямую связаны со смыслом таргета. Либо data scientist выберет какую-то метрику из машинного обучения, например, auc, и будет ее совершенствовать, привносить все хайповые фрэймворки и библиотеки, исходя из своего чувства прекрасного – совершенствовать «пятый знак после запятой» в выбранной метрике. В тоже время для бизнеса эта работа может быть совершенно неважной и не приводить к успешному внедрению. Либо начнет решаться какая-то минорная для бизнеса задача, когда на самом деле рядом есть гораздо больший потенциал для внедрения машинного обучения.
В результате можно столкнуться с негативными последствиями:
Бытует мнение, что можно взять любого data scientist-а с рынка, посадить его изолированно с эксельками и он магическим образом сам разберется, что же нужно оптимизировать. На наш взгляд, крайне важна ментальность data scientist-ов, которые занимаются оптимизацией производства. Это значит, что они должны быть готовы глубоко погружаться в технологические процессы (например, электролиз алюминия, кислородно-щелочная обработка целлюлозы, доменное производство и т.д.). Так же важна готовность data scientist-ов ездить в далекие командировки с целью лично говорить с технологами и операторами на производстве, чтобы понимать, как в реальности все работает. Без этого, скорее всего, они будут обречены на большое количество бездумных итераций перебора моделей и до полезного внедрения можно так и не дойти.
Регулярно встречается идеология как можно более фрагментарной организации работы с максимальным разделением труда для минимизации затрат. Например, есть аналитик, который занимается пониманием технологического процесса, коммуникацией с заказчиками и технологами. Есть дата инженер – он процессит данные, генерирует фичи. И, наконец, есть data scientist – он делает просто import sklearn и fit/predict. Таким образом, работа data scientist-а происходит в отрыве от реалий жизни, крайне лабораторно, и есть высокий риск совершения большого количества ошибок и упущения важных аспектов исходной задачи.
Не всегда очевидно, что data scientist-ы должны понимать, как и откуда собираются данные. Бывают даже случаи, когда контракты на внедрение ML подписываются без предварительного ознакомления с данными, и в таких условиях есть риск никогда не достигнуть целевых значений метрик, описанных в контракте. При таком подходе неизбежно возникают проблемы как с оценкой качества моделей, так и с возможностью их реального применения.
Многие свойства данных влияют на выбор методов: усреднения данных и погрешности измерений, неравномерное семплирование примеров, временной лаг в измерениях. Важно грамотно очищать данные от шума в факторах и таргетах, причины шума могут быть разными: ошибки оцифровки, outlier-ы, дублирование переменных, погрешности приборов и т.д.
Компания должна быть заинтересована, чтобы data scientist-ы досконально понимали природу данных, иначе обработка данных будет долгой и не приведет к успешному моделированию. Без глубокого понимания специфики процесса сбора и сохранения данных можно столкнуться со следующими проблемами:
Часто параллельно с разработкой и внедрением модели происходят изменения технологических процессов, которые влияют на сбор данных. Представьте, что необходимо оптимизировать технологический процесс, и после внедрения модели некоторые агрегаты перенастраиваются и это влияет на сбор данных: фичи «поплывут», распределения изменятся, обучающая выборка перестанет быть репрезентативной. Никто заранее об этом конечно не знает. В итоге: модель перестанет работать и все надо переделывать. Например, в случаях с деревьями может возникнуть проблема out of domain.
Важно заранее согласовывать с data scientist-ами все изменения технологических процессов, чтобы они могли оперативно адаптировать модели под новые условия.
Некоторые виды усреднений приводят к проблемам, например:
В подобных случаях задача может не получить адекватного решения до появления соответствующих сырых данных.
Можно выделить несколько сценариев, когда data scientist-ы просят о дополнительных данных:
Data scientist-ы просят о дополнительных данных, когда у них есть опыт решения схожих задач, в которых использование этих данных приносило положительный результат, иначе можно получить качество моделей гораздо хуже потенциально достижимого.
Пусть требуется прогнозировать качество продукции на основе ручной разметки, т.е. операторы на производстве вручную записывают значения таргета. Если при этом операторы получают премии за хорошие результаты и наказание за плохие, то:
Схожие проблемы могут возникнуть с использованием краудсорсинговых решений (например, Яндекс.Толока), где эксперты получают вознаграждение за разметку данных. В таком случае нужно аккуратно валидировать полученную разметку. Для этого есть ряд подходов:
Вывод: если есть ручная разметка данных – нужно ее проверять, иначе могут возникнуть систематические ошибки.
Почитайте популярные статьи и потребуйте, чтобы решение задачи было основано на модном методе.
Сегодня data science – это область моды, публикуется очень много статей, почти каждый день проходят конференции, создается все большее число методов. Однако это не означает, что произвольно взятый популярный метод является оптимальным в задачах промышленности. Обычно не нужно использовать LSTM в задаче оптимизации производства чугуна, также не требуется использовать RL на небольших data set-ах маркетинга или добычи полезных ископаемых. В таких задачах разумно начинать с традиционных методов (например, градиентного бустинга), в чем убедить заказчиков бывает довольно непросто. Модные ML методы не всегда подходят для задач промышленности и часто оказываются дорогостоящими в реализации.
Приведенный набор советов не является исчерпывающим, но все они регулярно встречаются на практике. При таком подходе велика вероятность убедиться, что ML в индустрии не работает и является просто тратой денег.
Резюмируя, можно констатировать, что по-настоящему прорывными кейсами являются ML-проекты, внедренные в срок и стабильно приносящие измеримый профит бизнесу. Чтобы этого добиваться, важны компетенции анализа данных и машинного обучения, и условия, когда data scientist-ы хорошо понимают всю картину бизнес задачи.
Автор: Ирина Пименова, начальник отдела интеллектуального анализа «Инфосистемы Джет»
если у вас нет глубокого понимания процесса.
Рэй Далио
В компании «Инфосистемы Джет» мы внедряем машинное обучение в самых разных отраслях, и на основе нашего опыта выделяем необходимые составляющие успешного внедрения:
- постановка задачи, нацеленная на оптимизацию приоритетной для бизнеса метрики;
- команда data scientist-ов, которые обладают компетенциями и готовы глубоко погружаться в технологический процесс;
- данные, которые соответствуют бизнес-задаче;
- адекватный выбор метода.
На практике все эти элементы вместе встречаются крайне редко, по статистике, только около 7% проектов с ML считаются успешными. Проекты, имеющие все перечисленные составляющие, можно смело относить к прорывным! Для иллюстрации, мы сформулировали несколько тезисов, которые можно назвать вредными советами про внедрение машинного обучения в бизнес.
Вредный совет №1: «Задача – просто внедрить ML»
Часто заказчик формулирует задачу, как «просто внедрить машинное обучение для некой оптимизации», без какой-либо связи с бизнес-метриками и приоритезацией задач бизнеса.
В таком случае мы можем увидеть несколько негативных сценариев. Например, таргеты будут меняться по ходу работы, но это значит, что весь препроцессинг и выбор методов оптимизации будет меняться, потому что они напрямую связаны со смыслом таргета. Либо data scientist выберет какую-то метрику из машинного обучения, например, auc, и будет ее совершенствовать, привносить все хайповые фрэймворки и библиотеки, исходя из своего чувства прекрасного – совершенствовать «пятый знак после запятой» в выбранной метрике. В тоже время для бизнеса эта работа может быть совершенно неважной и не приводить к успешному внедрению. Либо начнет решаться какая-то минорная для бизнеса задача, когда на самом деле рядом есть гораздо больший потенциал для внедрения машинного обучения.
В результате можно столкнуться с негативными последствиями:
- невозможно предсказать сроки и трудозатраты;
- совершенствование моделей происходит в отрыве от бизнес-метрик;
- сделана инвестиция в минорную задачу.
Вредный совет №2: «Подойдет любой data scientist»
Бытует мнение, что можно взять любого data scientist-а с рынка, посадить его изолированно с эксельками и он магическим образом сам разберется, что же нужно оптимизировать. На наш взгляд, крайне важна ментальность data scientist-ов, которые занимаются оптимизацией производства. Это значит, что они должны быть готовы глубоко погружаться в технологические процессы (например, электролиз алюминия, кислородно-щелочная обработка целлюлозы, доменное производство и т.д.). Так же важна готовность data scientist-ов ездить в далекие командировки с целью лично говорить с технологами и операторами на производстве, чтобы понимать, как в реальности все работает. Без этого, скорее всего, они будут обречены на большое количество бездумных итераций перебора моделей и до полезного внедрения можно так и не дойти.
Вредный совет №3: «Работа должна быть лоскутной»
Регулярно встречается идеология как можно более фрагментарной организации работы с максимальным разделением труда для минимизации затрат. Например, есть аналитик, который занимается пониманием технологического процесса, коммуникацией с заказчиками и технологами. Есть дата инженер – он процессит данные, генерирует фичи. И, наконец, есть data scientist – он делает просто import sklearn и fit/predict. Таким образом, работа data scientist-а происходит в отрыве от реалий жизни, крайне лабораторно, и есть высокий риск совершения большого количества ошибок и упущения важных аспектов исходной задачи.
Вредный совет №4: «Не объясняйте data scientist-ам, как собираются данные»
Не всегда очевидно, что data scientist-ы должны понимать, как и откуда собираются данные. Бывают даже случаи, когда контракты на внедрение ML подписываются без предварительного ознакомления с данными, и в таких условиях есть риск никогда не достигнуть целевых значений метрик, описанных в контракте. При таком подходе неизбежно возникают проблемы как с оценкой качества моделей, так и с возможностью их реального применения.
Многие свойства данных влияют на выбор методов: усреднения данных и погрешности измерений, неравномерное семплирование примеров, временной лаг в измерениях. Важно грамотно очищать данные от шума в факторах и таргетах, причины шума могут быть разными: ошибки оцифровки, outlier-ы, дублирование переменных, погрешности приборов и т.д.
Компания должна быть заинтересована, чтобы data scientist-ы досконально понимали природу данных, иначе обработка данных будет долгой и не приведет к успешному моделированию. Без глубокого понимания специфики процесса сбора и сохранения данных можно столкнуться со следующими проблемами:
- предварительная обработка данных будет занимать много времени;
- модель может оказаться неприменимой в реальных условиях;
- условия контракта могут оказаться недостижимыми.
Вредный совет №5: «Сделайте сбор данных сложным и непонятным процессом, чтобы никто не знал, как он работает. После внедрения моделей обязательно внесите изменения в технологический процесс»
Часто параллельно с разработкой и внедрением модели происходят изменения технологических процессов, которые влияют на сбор данных. Представьте, что необходимо оптимизировать технологический процесс, и после внедрения модели некоторые агрегаты перенастраиваются и это влияет на сбор данных: фичи «поплывут», распределения изменятся, обучающая выборка перестанет быть репрезентативной. Никто заранее об этом конечно не знает. В итоге: модель перестанет работать и все надо переделывать. Например, в случаях с деревьями может возникнуть проблема out of domain.
Важно заранее согласовывать с data scientist-ами все изменения технологических процессов, чтобы они могли оперативно адаптировать модели под новые условия.
Вредный совет №6: «Усредняйте признаки»
Некоторые виды усреднений приводят к проблемам, например:
- ставится задача прогнозировать часовое энергопотребление, но при этом данные об энергопотреблении сохраняются только по месяцам, – в такой ситуации ничего нельзя сделать до накопления сырых данных;
- происходит усреднение по характеристикам, которые измеряются в существенно разные моменты времени;
- используются скользящие средние, захватывающие период предсказания (что приводит к проблеме data leak и искажению модели);
- хуже всего, когда данные каким-то образом усреднены и этот факт остается неизвестным.
В подобных случаях задача может не получить адекватного решения до появления соответствующих сырых данных.
Вредный совет №7: «Не выдавайте дополнительные данные»
Можно выделить несколько сценариев, когда data scientist-ы просят о дополнительных данных:
- необходимы дополнительные сырые данные;
- необходимо добавление новых признаков в data set. Например, в задачах банковского сектора и товарных рекомендаций полезно использовать как можно больше социально-демографических признаков;
- увеличение размера data set-а
- объем данных ограничен, но может быть расширен за счет исторических данных, либо возможно создать дополнительные данные, как например в задачах обработки изображений и видео.
Data scientist-ы просят о дополнительных данных, когда у них есть опыт решения схожих задач, в которых использование этих данных приносило положительный результат, иначе можно получить качество моделей гораздо хуже потенциально достижимого.
Вредный совет №8: «Точность ручной разметки не важна»
Пусть требуется прогнозировать качество продукции на основе ручной разметки, т.е. операторы на производстве вручную записывают значения таргета. Если при этом операторы получают премии за хорошие результаты и наказание за плохие, то:
- таргет с высокой вероятностью будет содержать смещение;
- в результате обучения этот bias перейдет в модель;
- модель не будет предсказывать реальное распределение целевой переменной.
Схожие проблемы могут возникнуть с использованием краудсорсинговых решений (например, Яндекс.Толока), где эксперты получают вознаграждение за разметку данных. В таком случае нужно аккуратно валидировать полученную разметку. Для этого есть ряд подходов:
- Перекрытие: несколько независимых экспертов производят разметку;
- Golden Set: в данные добавляются примеры с заранее известными результатами для оценки точности операторов и их отбора;
- Majority voting: алгоритмы выбора вердикта на основе разметки в перекрытии.
Вывод: если есть ручная разметка данных – нужно ее проверять, иначе могут возникнуть систематические ошибки.
Вредный совет №9: «Используйте самое модное»
Почитайте популярные статьи и потребуйте, чтобы решение задачи было основано на модном методе.
Сегодня data science – это область моды, публикуется очень много статей, почти каждый день проходят конференции, создается все большее число методов. Однако это не означает, что произвольно взятый популярный метод является оптимальным в задачах промышленности. Обычно не нужно использовать LSTM в задаче оптимизации производства чугуна, также не требуется использовать RL на небольших data set-ах маркетинга или добычи полезных ископаемых. В таких задачах разумно начинать с традиционных методов (например, градиентного бустинга), в чем убедить заказчиков бывает довольно непросто. Модные ML методы не всегда подходят для задач промышленности и часто оказываются дорогостоящими в реализации.
Мораль
Приведенный набор советов не является исчерпывающим, но все они регулярно встречаются на практике. При таком подходе велика вероятность убедиться, что ML в индустрии не работает и является просто тратой денег.
Резюмируя, можно констатировать, что по-настоящему прорывными кейсами являются ML-проекты, внедренные в срок и стабильно приносящие измеримый профит бизнесу. Чтобы этого добиваться, важны компетенции анализа данных и машинного обучения, и условия, когда data scientist-ы хорошо понимают всю картину бизнес задачи.
Автор: Ирина Пименова, начальник отдела интеллектуального анализа «Инфосистемы Джет»