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

0
543
views

На сайте DOU.UA вышел интересный материал о проектах машинного обучения. Представляем его вашему вниманию.

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 — система контроля версий для машинного обучения. Несмотря на ряд недочетов, мы все же используем ее, кроме версионирования, в небольших проектах, например, для ускорения построения дата-пайплайнов.

DVC — система контроля версий для машинного обучения
Image: DVC

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

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

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

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

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

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

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

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

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

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

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

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

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here