Инновации и инсайты в мире Java из первых уст. Новая конференция Java Fest — 21 марта >>
×Закрыть

8 правил для ML-проектов на каждый день: как найти и удержать нужный фокус

Меня зовут Игорь Кауфман, и последние 4 года я занимаюсь проектами, связанными с Machine Learning и Data Science, лидируя это направление в компании DataArt. Исследую проблемы в разных индустриях, нахожу параллели, вместе с командой предлагаю технические решения и контролирую их внедрение. До этого 7 лет занимался менеджментом инжиниринговых команд.

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

1. Не изобретайте колесо

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

Однако реалии рынка таковы, что провайдеры облачных решений стремительно осваивают сферу машинного обучения — так же, как раньше освоили Big Data. То же относится и к открытому ПО, и в 99% случаев с ML вам не нужно изобретать новую библиотеку. Скорее всего, вы найдете на рынке продукт или технологию, которые при наличии фантазии можно адаптировать под вашу задачу.

Покажу это на примере экстракции данных из PDF-документов — допустим, из purchase orders (когда одна компания заказывает товары у другой). Как правило, они имеют смешанную структуру и состоят из:

  • шапки со слабо структурированным текстом, содержащим информацию о заказчике и поставщике, номер заказа и прочие детали;
  • таблицы со списком товаров, часто с кучей деталей, которые мешают распознать структуру.
Можно разбивать такой документ на части, по отдельности проводить распознавание таблицы и полей NER (named entity recognition) из шапки. Альтернатива — Amazon Textract, который хорошо распознает номер заказа и дату, а также структуру таблиц. Детали можно распознавать с помощью regular expressions. Для старта необходима всего пара дней, и в результате людям, которые обрабатывают такие документы вручную, сразу станет легче, а компания сможет сэкономить. Дальше вы сможете спокойно решить, стоит дописывать правила или в долгосрочной перспективе оправдан другой подход. Это приводит нас к следующему пункту.

Not invented here syndrome. Image: DrinkBird

2. Оценивайте ROI (возврат инвестиций)

Business value first — принцип, особенно важный в R&D-проектах. На любом этапе работы вы должны быть готовы привести реальный пример юзкейса, которым занимаетесь. Если не можете оценить потенциальную пользу в числах, скорее всего, вы занимаетесь либо выдуманной проблемой, либо экстремальным случаем.

В случае с ML потребуется изменить методологию расчета ROI. Ведь машинное обучение, в отличие от классического программирования, никогда не дает 100%-ной точности. Поэтому всегда следует оценивать, окупится ли повышение точности на 2, 5, 10 или 20%.

Вернемся к примеру с purchase orders. Мы работаем с компанией, в которой больше тысячи человек заняты преимущественно извлечением данных из PDF. Улучшив точность результатов на 5–10%, можно каждый год экономить миллионы долларов. Но если необходимо вложить сотни тысяч долларов, чтобы увеличить точность всего на 1-2% — обычная ситуация для компьютерного зрения, — возможно, имеет смысл оставить на этом участке человека и потратить деньги на решение более срочных задач.

Image: Deloitte

3. Не начинайте работу, не сформулировав гипотезы

Иногда бизнес формулирует запрос так: «У нас есть куча данных. Как мы можем извлечь из них пользу?» Либо обратная ситуация со стороны инжиниринга: «У нас есть куча данных. Давайте попробуем на них алгоритмы x, y и z — и посмотрим, что получится».

От поиска иголки в стоге сена спасает формирование гипотезы. Попробуйте начать с вопросов:

  • Какую проблему я пытаюсь решить?
  • Какой результат я ожидаю получить?
Машинное обучение хорошо решает одну задачу: автоматизирует то, с чем вы не можете справиться вручную из-за недостатка времени или вычислительной мощности. Если не можете описать, что именно ищете и как бы вы делали это руками, вероятность успеха невысока.

Приведу пример. В одном из проектов мы ищем возможности роста для компаний на рынке среди текстовых данных: описаний стартапов, пресс-релизов, отчетов по индустриям и т. д. Например, райдшеринг Lyft стал партнером авиакомпании Delta и теперь имеет возможность возить людей из одного города в другой end-to-end. А его конкурент — Uber — возит пациентов на заранее назначенные приемы у докторов. При этом и тот и другой усиленно инвестируют в автопилоты. Идея, в общем-то, понятна человеку — аналитику конкретной индустрии. Но, пока вы не опишете, как решал бы такую задачу специалист (в каких источниках и какую информацию он ожидал бы найти, как определял бы искомые формулировки и каким образом агрегировал бы знания), построить масштабируемую систему практически невозможно. Такой этап планирования и формирования гипотезы — ручное моделирование — может сэкономить много времени и денег в будущем.

4. Думайте об интеграции заранее

Новое ML-решение придется интегрировать с существующей системой. Технически в этом нет ничего страшного, но для бизнес-пользователей этот процесс может выглядеть пугающе. Если у компании есть прозрачная система принятия решений, основанная на правилах, то новое решение, базирующееся на ML-алгоритмах, может казаться абсолютным черным ящиком. Поэтому крайне важно иметь четкий план миграции, учитывающий человеческое восприятие и ручную обработку false positives / false negatives. Люди должны понимать, кто и на каком этапе будет это делать и какие риски существуют.

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

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

Более того, по крайней мере 10% билетов все равно придется покупать по старому алгоритму, основанному на правилах. Это позволит и дальше обновлять знания ML-системы и избежать ситуации переобучения (состояния, когда AI думает, что знает все на свете).

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

5. Версионирование экспериментов

Каждая новая версия вашей модели — эксперимент. Как и всякий эксперимент, он может оказаться неудачным. Поэтому важно всегда иметь рабочие CI/CD-пайплайны, позволяющие в любой момент откатиться до более старой версии.

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

Image: DVC

6. Помните о цели, но не забывайте о «низковисящих фруктах»

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

7. Будьте изобретательны

Всегда существует дорогой и «правильный» способ решения любой задачи. Но первый вопрос, который стоит себе задать: можно ли добиться 80%-ного результата, приложив 20% усилий?

В одном из проектов нам нужно было среди материалов, скопившихся за 20 лет, определить, какие из них актуальны. Это были десятки тысяч документов, содержащих логотипы Mastercard. В какой-то момент мы обнаружили, что последнее изменение логотипа Mastercard произошло в 2016 году. День на маркировку и обучение облачного сервиса распознавания изображений — и вуаля, мы отобрали только свежие документы.

Image: Design Chambers

При анализе данных постоянно приходится использовать фантазию и творческое мышление. К примеру, нам нужно было классифицировать процессы в большой химической компании. Используя общедоступные NLP-модели, мы преобразовали процессы, содержащие химические термины, в векторы и нашли наиболее близкие к ним названия отделов. Точно? Нет. Но это отличный старт, чтобы не делать всю работу вручную.

8. Управляйте ожиданиями

Machine Learning и Data Science — черный ящик для большинства людей, поэтому в случае с ними ценность управления ожиданиями выше, чем где-либо еще.

Не забывайте обучать людей, количественно оценивать результаты вашей работы (сколько времени/денег вы сэкономили, стало ли быстрее и лучше, и если стало, то насколько) и сравнивать ответы с изначальными целями. Заранее продумывайте процесс интеграции вашего сервиса в существующую систему как с технической, так и с человеческой точки зрения.

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

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

Надеюсь, мой опыт окажется кому-то полезен. Вероятно, вы сможете дополнить этот список собственными правилами (непосредственно связанными с ML или универсальными).

LinkedIn

29 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо за хорошую статью. Пример с логотипами мастеркард просто супер :)

Вы могли бы чуть больше рассказать про оценку roi? Часто изначально сложно предположить, насколько может улучшит систему применение ml (особенно если есть внедренные эвристики). Конечно, если у клиента реально тысячи человек разбирают полуструктурированные пдф-ки, то можно достаточно уверенно предполагать, что автоматизация тут поможет :) но в реальности часто есть какая-то работающая система, и сложно оценить, улучшит ли ситуацию ml

Я бы мог рассказать на AI Ukraine :) но не сложилось, к сожалению

Вот тут у нас есть некоторый неполный взгляд на эти вещи, если будет интересно:
www.altexsoft.com/...​nd-data-science-projects

Спасибо! А эту exploratory фазу клиент оплачивает? И часто ли бывает так, что клиент оказывается разочарован результатом первоначальной или даже финальной модели? Какие у вас аргументы в этом случае? Мне кажется, сейчас из-за хайпа на дата сайенс люди из бизнеса могут переоценивать бенефиты, которые им может принести дата сайенс :)

Извини за запоздавший ответ :) Да, клиент оплачивает. Объясняем, что будем делать feasibility study именно для того, чтобы потратить как можно меньше денег и выяснить, решаема ли задача на имеющихся данных с нужным уровнем точности или нет. Если по факту не получается получить нужный результат, но данные, например, можно дособирать или купить — делаем это. Как-то так :)

Спасибо! В дополнение к отличной статье от Саши, скажу, что действительно оценка ROI на начальном этапе часто является проблемой.
Мы обычно идем несколькими путями:
— если есть данные, делаем фазу feasibility study, обычно она занимает от 20 до 80 часов, часто за свой счет, это грубая прикидка самым простым способом. Например, если задача фрод детекшн, то кластеризовать данные, посмотреть на маленькие кластера вручную, вероятно в них есть фрод. Если задача по экстракции данных из документов — вручную разметить 100, 200, 300 документов, посмотреть как будет расти точность. Эта фаза позволяет нам понять какие данные доступны и их качество, а клиентам — посмотреть как выглядит процесс и лучше понять что они получат на выходе;
— если к данным доступа нет, но есть примерное понимание области, можем оперировать отраслевыми стандартами. К примеру, в computer vision мы знаем, что распознать меланому с Jaccard index выше 0.8 крайне сложно, а в фрод детекшне есть оптимальная точка баланса ручной валидации результатов и кол-ва false positives, на уровне 87.5% действительных случаев фрода из распознанных. От таких чисел можно отталкиваться для оценки абстрактных примеров;
— в конце концов, есть инвестиционный аспект: решение использовать ML — это всегда риск для компании, но если на него не идти, то конкуренты обгонят. У компаний часто есть бюджет на инновации и R&D, можно попробовать понять сколько компания готова потратить на эксперимент. Возможно, этого будет достаточно, чтобы оценить ROI в будущем и в целом перспективы использования ML.
Надеюсь, это поможет :)

Спасибо! Это полезные ориентиры. Хочу ещё вам адресовать вопрос, который выше задавала Саше:

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

Что касается удовлетворенности клиента — бывает по-разному, поэтому я писал про важность управления ожиданиями. Если задача решается без ML — мы первыми это говорим и рекомендуем на цепляться за хайп :)
Когда не уверены в результате, пытаемся адресовать возможные риски с помощью максимально итеративного процесса, часто показываем результаты, описываем перспективы. В принципе, максимум того, что мы можем сделать — вовремя предупредить, что-то порекомендовать, объяснить, что результат вероятностный, что зависит от качества и количества данных. Главное сделать это вовремя.

Спасибо! Было бы интересно почитать про опыт работы с клиентами по DS задачам. Особенно с крупными (бюрократическими) компаниями. Я сталкивалась с тем, что компания, например, не хочет давать данные ни в каком виде на предварительном этапе. Особенно если это не компания выходит на вас, а вы продаёте свои услуги (думаю, так тоже бывает :)
Может, вам будет интересно написать, а ДОУ опубликовать :)

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

Спасибо за хорошую статью.

Хочу добавить 2 цитаты как подтверждение приведенных правил

1. «All models are wrong, but some are useful» (управление ожиданиями)
2. «The details are not the details. These make the design» (будьте изобретательны)

Ссылки
[1] en.wikipedia.org/...​wiki/All_models_are_wrong
[2] en.wikiquote.org/wiki/Charles_Eames

Андрей, спасибо! Цитата про детали — прямо беру себе, очень полезная!

Взаимно. В работе с данными обычно «детали делают» дизайн и определяют качество приложения.

Ладно. Взъелся я за то, что в статейке как бы о обо всем и с большего правильно и ни о чем.
Получилось сразу как бы для детей и для не детей.

Но, это только мое мнение, напоминаю.

3. Не начинайте работу, не сформулировав гипотезы

Ось це.

Гипотез набредить можно бесконечно много.

Для початку необхідна принаймні одна.

А на вторую и денег уже не дадут. И причем тут гипотезы и их проверка?

А причем тут «набредить бесконечно много»? Вы только крайности рассматриваете? Либо с первого раза попали в рынок или в правильное решение, либо проект закрыт? Как-то противоречит в принципе исследовательскому подходу.

Набредить, конечно можно и наверно нужно (в качестве бреинсторма). Отметая именно **бредовые** гипотезы будет набираться список «рабочих» гипотез, подчеркиваю именно рабочих. Потом к рабочему списку применить прицип Бритвы Оккама и начать наботу с топ-1 или топ-3. Что не так с гипотезами?:) Черная дыра до сих пор всего лишь гипотеза и скорее всего ею и останется на всегда, так что теперь их не принимать во внимание?)

Балшит с BigData вышел из моды, теперь толпа кинулась загаживать ML. Скоро и machine learning станет стыдно упоминать в кругу приличных людей, особенно после подобных статеек.

Нормальна стаття. Альтернатива — зробити якусь модель на якихось даних, що влізуть у кеш процесора, та перекинути результат через паркан.

Твоя альтернативная о того, что он написал ничем не отличается.
А всё по тому, что он менеджер и нихрена не смыслит в ML и вообще научных подходах.

Науковий підхід в університеті. Тут прикладні результати.

Да ну. Навуковый и тут. А то что ТС предлагает — это подход мартышек.
Если отказаться от навукового, то разумнее становиться интеграторами и юзать то, что умные дяди и тети из-за океана придумали.

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

Уели, в частностях всё правильно.
В частностях и ТДД и аджайлы всегда правильны.
В частностях всё, что юзается в программинге и исследованиях правильно.

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

Хуже. Инет забит кривыми пересказами мануалов от разрабов.
Можно стать ML разрабом нихрена не зная в ML, только юзая, не думая, примеры на питоне из мануалов. Вот это загаживание возникло из новой моды-хайпа.

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

Опасность только хайпа в том, что он дохнет, потому как фантастики не получится. Такое уже было в 80-90-х с ML в речи. Фантастики не вышло и бизнес забил на ML на 15-20 лет. Тоже повториться снова через лет 5-10.

Подписаться на комментарии