Статья. Честно о машинном обучении. Самые распространённые ошибки в ML-проектах

Привет! Я Антон Кудинов, сооснователь компании Rubius. Эта статья — текстовая адаптация наших вебинаров и выступлений на конференциях, где мы рассказывали, что важно учитывать в работе с ML, как со стороны исполнителя, так и клиента. Надеюсь, что она поможет российским компаниям понять, как они могут решить свои бизнес-задачи при помощи данной технологии.

В статье я буду использовать Machine learning и Искусственный интеллект как синонимы. Это самое хайповое направление в разработке последних лет. По данным Gartner, в 2024 году отечественный рынок решений с применением ИИ и ML достигнет 160 млрд рублей. Да и мы в Rubius подтверждаем, что число запросов на такие проекты год от года кратно растёт.

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

Я убеждён, машинное обучение работает в полную силу лишь в тесном тандеме клиента и исполнителя, при условии вдумчивой аналитики, качественных полных данных и честных отношений. Что именно нужно делать, чтобы всё получилось — читайте ниже. По ходу статьи буду приводить много примеров из практики, но из-за NDA не буду называть конкретные компании.

Полегче с ожиданиями

Решения и разработки, которые вы встретите на рынке, можно условно разделить на несколько групп. Когда думаете о своём проекте — стоит определить, к какой из них он относится. От этого зависит, насколько непроторённым будет ваш путь.

• Типовые рабочие кейсы, которые на 99% подойдут вам с небольшой адаптацией — например, прогноз спроса и предиктивная аналитика.
• Новые, но решаемые задачи — например, качественная генерация мимики и жестов.
• Нерешаемые задачи, по крайней мере пока. Например, видеокамера не определит, чистый ли в магазине пол, если усреднённый серо-бежевый цвет плитки сливается с пылью.

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

Важно учитывать, что даже отработанные решения нужно будет адаптировать под специфику ваших процессов и технологической базы. От последней зависит вообще очень многое: важно, какие и в каком состоянии у вас датчики, камеры, ИС и АСУ ТП.

Пример: грязные бензовозы в темноте

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

Курс на аналитику

Предпроектная аналитика. Делать её нужно, даже если у вас есть ТЗ и опыт в ML-проектах. И делать её нужно вместе — разработчику с клиентом, в партнёрских отношениях: так вы сможете порядком сократить сроки проекта и затраты на него. Больше того, надо подключить к процессу и конечного пользователя — это позволит заранее избежать сопротивления. Стоит держать в голове и вот что:

• важно вместе и заранее хотя бы поверхностно продумать план внедрения системы на базе вашей инфраструктуры;
• коммерческая тайна — святое, но всё равно нужно делиться данными с разработчиком, чтобы тот помог определить, насколько процесс реально критичный и дорогой.

Сообща сторонам нужно найти идеальный для автоматизации процесс.

Но даже при совпадении трёх критериев результат может отклониться от задуманного, поэтому разумно работать сразу в нескольких направлениях.

Пример: параллельные пилоты

Крупный ретейл запустил в работу 3 одновременных задачи. Заказчик расценивал все проекты как равноценные, считал экономику полностью сам и поставлял данные для анализа неполными и с задержкой в несколько месяцев. Из-за таких дистантных отношений клиент не сразу понял, что одно из направлений не несёт нужной выгоды, да и сам процесс не такой дорогой и критичный. Зато другие 2 пилота в работу пошли, то есть благодаря одновременной проработке нескольких идей мы выявили наиболее эффективные «маршруты».

Проекты с ML — всегда последовательность прогнозов и экспериментов в тесном тандеме клиента и разработчика, поэтому движение малыми шагами здесь особенно пригодится. Не нужно сразу стремиться к конечному решению: в первую очередь — прототипы, MVP, PoC — Proof of concept. В реальности компании внедряют лишь треть инициатив с ML, а многие громкие заявления корпораций — именно о тестировании минимально жизнеспособных продуктов, а не полноценных проектах. 

Внимание: данные

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

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

Пример: потёмкинские курьеры

В сервисе доставки товаров для дома были уверены, что данных за 3 года хватит с избытком — и заказали алгоритм, который будет прогнозировать время выполнения услуги в зависимости от типа посылок. Мы проверили базу и увидели, что в основном курьеры меняют статусы перемещения в системе в одно и то же время дня. Стало ясно: лишь 5% сотрудников заполняли графы как надо, остальные — «протыкивали» на автомате, только создавая видимость. Заказчику пришлось перестраивать бизнес-процессы в компании, прежде чем запустить этот функционал.

Пример: коварная уборщица

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

Время метрик

ML-системы всегда что-то предсказывают: бракованный товар или нет, купят его или не купят, сломается или не сломается станок. Здесь не может быть 100% точности, измерять результат нужно как-то иначе. К тому же кроме истинно положительных и отрицательных ответов модель может давать ложноположительные и ложноотрицательные: система сказала, что товар купят, завод затарил склад, а спроса нет, или наоборот — не стали производить, а тут набежали клиенты. 

Для задач классификации, к примеру, обычно говорят о таких метриках:

• Accuracy — число истинных предсказанных ответов. Этот показатель часто бесполезен: если система оценит все единицы товара как бракованные, то она истинно детектирует весь брак, но ошибётся со всеми качественными экземплярами. То есть accuracy будет равен 100%, но не учтёт число ложных ответов;
• Precision — доля истинно положительных среди всех положительных ответов системы. Эта метрика тем важнее, чем больше мы теряем от ложноположительного прогноза: если мы рассчитали, что продадим 100 машин, а по факту — 50, то остальные останутся на складе;
• Recall — это наоборот: доля фактов, которые система опознала как положительные, среди всех реально положительных фактов. Показатель важен, когда проблемы возникают, если мы что-то не предсказали. Например, если мы детектируем аварийные остановы оборудования на исторических данных их была 1000, то recall 70% говорит о том, что наша модель видит 700 случаев из 1000. К оставшимся 300 остановам мы не были готовы – не были закуплены детали и не были подготовлены резервные мощности.

Для других задач — регресса или ранжирования — и показатели понадобятся другие.

Повышение точности предсказаний всегда удорожает проект, и команде нужно определить баланс, при котором дополнительные инвестиции будут иметь смысл. При прогнозировании спроса на массовый товар рост точности интересной бизнесу метрики на 5% в эффекте масштаба даёт ощутимую прибыль, в других ситуациях и 99% точности могут почти не увеличить результат. Математические метрики нужно переводить на бизнес-язык: выгодно ли нам увеличить число верных предсказаний, если поднимется и доля ложных? Может наоборот, сократить число ложных и предотвратить ненужные остановки производства?

В целом, по моему опыту, предприятия могут ориентироваться на изменение бизнес-показателей в 1-3%, если производство уже серьёзно цифровизовано, и 3-5%, если они лишь начали внедрять ML-решения — ведь здесь добавляется прирост от экономии на энергии, воде и сырье. Кроме того, стоит иметь в виду, что пятая часть проектов теряет в качестве просто при переходе из модели в боевой MVP из-за другого датасета, а 5-10% всех решений в итоге оказываются нежизнеспособными.

Пример: уточнение прогноза спроса

Компании из пищевой промышленности мы помогли повысить точность прогноза с 65 до 70%, и это уже дало заметный прирост. К тому же прогноз теперь работает с более широким ассортиментом. В пересчёте на обороты крупного ритейла — это миллионы рублей каждый месяц.

Лучшее время считать ROI — сейчас

Чем раньше вы оцените возврат на инвестиции от проекта, или ROI — Return on investment — тем яснее поймёте, стоит ли игра свеч. И эта задача — тоже групповая, партнёрская. Как только вы определили метрики проекта — собирайте всех, чтобы считать главную.

Допустим, мы видим, что точность прогноза спроса выросла на те же 5%. На что это влияет? Закупки, план производства, сокращение запасов. Тестируйте несколько таких связок, ищите корреляцию и максимальный эффект, чтобы затем рассчитать ROI. Это очень пригодится, чтобы скорректировать метрики проекта, задать их минимальные пороги, которых нужно достичь. Или вовсе от проекта отказаться.

Пример: дорогая технология

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

Всё бы хорошо, но при запоздалом расчёте ROI, лицензии западного статистического ПО оказались слишком дороги — заказчик изначально в смете их не учёл. В итоге нашу аналитику применили как аудит и пересобрали процессы.

В конце концов

Надеюсь, что сохранил нить повествования от и до. Давайте коротко подытожим:

• любой проект с ML — эксперимент: надо быть готовым к любому развитию событий;
• аналитика — обязательный этап поиска «идеальной задачи», и в нём нужны люди, которые понимают всю экономику, природу данных и процессы, а также конечные пользователи;
• партнёрские отношения: выделяйте грамотных экспертов с обеих сторон и в крепкой связке работайте с данными, метриками и расчётами эффективности.

И, конечно, добавлю, что несмотря на сложности, мы набираемся опыта, и с каждым годом внедряем всё больше реально успешных проектов. Если у вас есть идеи — готовы оценить, какие у них перспективы.

*Meta — организация, деятельность которой признана экстремистской и запрещена на территории РФ