Как оценить пользу от внедрения ML-технологий до того, как запустить проект

Машинное обучение помогает бизнесу получать краткосрочные и долгосрочные прогнозы: например, что через полгода будут заказывать покупатели, как изменятся цены на товары в отрасли, какие объёмы отгрузок будут оптимальны — и знать наперёд, как изменятся другие важные для стратегического планирования показатели.

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

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

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

Но перед тем как вы определите исполнителя, стоит учесть следующее:

Мы в NLABTEAM более 20 лет разрабатываем сложное программное обеспечение, создаём, обучаем и развиваем ML-модели. В этой статье рассказываем:

А ещё вас ждут примеры из реальных ML-проектов, которые у нас сейчас в работе. Ими иллюстрируем всё, о чём вы прочитаете.

Поехали!

Обобщённо, предварительные работы по ML-проекту можно разбить на 3 шага.

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

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

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

Участники: клиент и исполнитель.

Длительность этапа: до одной недели.

Целевой результат: клиент видит, состоятельна ли идея о внедрении ML в его бизнес.

Со сбора данных начинается любая задача по машинному обучению.

Как мы исследуем входные данные перед обучением прогнозной модели на их основе?

Существует три стадии обработки данных: Extract, Transform и Load.

1. Сначала мы извлекаем данные из любых доступных источников: фотокамер, датчиков, машинописных, рукописных документов, любых разрозненных баз данных, используемых клиентом.

2. Преобразуем данные, в том числе очищаем от дублей.

3. Загружаем в общее хранилище в структурированном виде.

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

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

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

Целевой результат: данные собраны в достаточном для обучения ML-модели количестве и провалидированы исполнителем.

Пример из практики. В одном из проектов нам нужно было помочь клиенту узнавать наперёд загрузку железнодорожных вагонов. Клиент выслал нам около 10 ГБ данных в Excel для предварительного исследования.

Проанализировав их, мы выяснили, что клиент пользуется двумя разрозненными источниками данных, которые плохо соответствуют друг другу.

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

Отметим, что, чтобы изучить и оценить данные о пробеге 86 тысяч вагонов за 5 лет, мы потратили 2 недели. Этот объём данных можно признать большим — их достаточно для построения прогнозной ML-модели в случае корректно выстроенного сбора и отсутствия ошибок (мы проверяем, так ли это, строго перед началом проекта).

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

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

Кто выполняет: разработчик и клиент.

Длительность этапа: зависит от масштаба проекта.

Целевой результат: сформировано техническое задание на разработку и внедрение предсказательной ML-модели — в нём прописаны сроки, результаты, а также параметры, по которым можно отследить окупаемость проекта.

Пример. Для проекта по разработке системы прогнозирования оттока клиентов SmartCubes мы ещё на берегу рассчитали, какую выгоду этот продукт может принести клиенту.

В результате помогли сократить отток клиентов на 5 % благодаря своевременному прогнозированию рисков. В банковской сфере такой процент экономии фактически выражается в сотнях миллионов рублей.

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

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

Например, спрос на канцелярские принадлежности предсказать несложно — в среднем ими пользуются одинаково. А вот спрос, скажем, на предметы искусства, сложнее прогнозировать: на первое место у покупателей выходят эмоции, тренды.

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

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

Пример. К нам обратились с задачей: построить модель, предсказывающую рост и падение спроса на отгрузку картофеля. Клиент передал данные для предпроектного исследования. Мы изучили эти данные и увидели, что они описывают только часть отгружаемого объёма картофеля.

Компания отгружала его 30 поставщикам, а нам дали информацию об отгрузках только по одному из 30. Этих данных недостаточно, чтобы точно предсказать, получится ли, например, в следующем феврале выдать 20 тонн всем заказчикам, будет ли спрос на картофель выше или ниже.

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

Важно, чтобы данные были репрезентативны — то есть можно было определить закономерность в их формировании и понять всю картину в целом.

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

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

Какие данные мы сочли бы нерепрезентативными в случае этого проекта?

Представим, что X % вагонов ездят по южной части России, а Y % — по северной. И по каждому из этих сценариев много дополнительных вводных, необходимых, чтобы предсказать загрузку каждого вагона.

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

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

Подытожив всё вышеописанное, раскроем несколько признаков, по котором вы легко сможете определить, добросовестен ли потенциальный исполнитель по вашему ML-проекту — и стоит ли с ним работать.

Это самый очевидный показатель адекватного подхода к задаче со стороны исполнителя.

Если же он обещает, что бизнес получит ощутимый эффект от внедрения ML, но озвучил такой вывод, не изучив данные, с которыми предстоит работать, — вас вводят в заблуждение.

Конечно, существуют типовые решения с заранее понятной эффективностью. Например, при внедрении технологии распознавания лиц точность будет в среднем 98–99 %. Об этом можно сказать на основе анализа множества уже реализованных решений.

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

Нужно изучить минимум 20–30 фотографий, чтобы оценить возможную точность распознавания в процентах, и что нужно сделать, чтобы её повысить.

Если в любой документации (плане проекта, ТЗ и др.), составленном для вас подрядчиком, встречаются непонятные вам вещи, хороший подрядчик сможет подробно изложить ответы на любые ваши вопросы. А ещё лучше — презентуя вам документ, ещё в момент передачи предложит в реальном времени пройтись по нему и обсудить все детали так, чтобы всем всё было понятно.

И обратно, если после получения документации и общения с подрядчиком о планах по проекту вы чувствуете, что ничего не понятно, зато звучит очень серьёзно, — это тревожный звонок. Возможно, исполнитель таким поведением просто пытается поскорее подписать с вами контракт и выстроить проект так, как выгодно ему (но не обязательно вам).

Например, разрабатывая INENEX, систему объективной оценки качества эндоскопических исследований, мы постоянно созванивались, общались и даже встречались с врачами больницы, которая стала инициатором запуска этого проекта. Нас выбрали как партнёра по технической части: так, менее чем за 6 месяцев мы обучили и протестировали ML-модель, которая помогает врачам обнаруживать новообразования при проведении колоноскопии и контролировать качество.

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

Врачи больницы дают положительный фидбек по нашей совместной работе и без сомнений решили продолжить его с нами.

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

Это значит, что он не просто разрабатывает модель, но помогает заказчику использовать еë в работе: взять максимум пользы от ML. И для этого объясняет, как нужно видоизменить и выстроить бизнес-процессы, чтобы эффективно внедрить модель и не столкнуться с отторжением со стороны линейных сотрудников.

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

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

Это будет сложно, ведь все привыкли к Игорю — к нему можно прийти когда угодно, заодно выпить кофе и обсудить последние новости компании. Линейные сотрудники меньше всего хотят привыкать к новому, особенно когда говорим о внедрении технологий.

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

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

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

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