Честно о Machine Learning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для вашего удобства мы с коллегами собрали схему реализации ML-проектов, которой пользуемся в Rubius. Пользуйтесь.

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