Уроки, извлеченные из клиентских проектов машинного обучения

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

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

Вот основные моменты, которые я хотел бы осветить:

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

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

Начнем с разговора о данных.

1. Знайте свои (настоящие) данные

Что касается данных, в основном есть две проблемы: размер и содержание.

Что касается размера, очевидно, что вы всегда будете начинать с просмотра части полной картины. Это имеет в основном два влияния:

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

Первая проблема на самом деле вполне реальна, скажем, ваша команда разработала решение, которое хорошо работает с экспортом базы данных в 10 тысяч строк. Позже вы обнаружите, что фактические данные, которые будут обрабатываться, состоят из 100 тысяч или 1 миллиона строк, или, что еще хуже, это будет потоковая система, обеспечивающая ответы почти в реальном времени.

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

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

Таким образом, первая ловушка, о которой следует помнить: Подходит ли мое решение к объему данных в реальной жизни?

Для контентной части, поскольку вы не видите полной картины данных, распределение данных в развертывании может быть другим. Действительно, вы будете смотреть на данные, которые вы никогда раньше не видели, и, таким образом, удивитесь, которые могут быть обработаны неправильно. Маленькие проблемы, которые вы упустили из виду, на самом деле могут быть серьезными. Например, если ваше машинное обучение работает над обнаружением мошенничества, в вашем обучающем наборе данных будет 1% мошенничества, но в реальной жизни будет только 0,01% мошенничества. Весьма вероятно, что ваше решение будет предсказывать гораздо больше мошенничества, чем должно.

Таким образом, вторая ловушка: Хорошо ли содержание моего набора данных обобщается на реальную жизнь?

Еще один момент, который касается содержания данных, — это качество данных. Ваш клиент может прийти к вам с набором данных из 100 тысяч строк, который уже помечен, и он хочет, чтобы вы разработали решение для классификации электронной почты. Классы данных очень очевидны, например, Забытый пароль, Запросы балансовых отчетов и т. д.

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

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

Еще один случай, на который вы хотите обратить внимание, — это данные, помеченные как «Другие». Люди могут помещать в эту категорию все, что видят, просто для того, чтобы не думать о категории и не выбирать подходящую метку в раскрывающемся меню. В результате вы можете иметь смесь всех других категорий в категории «Другие».

Таким образом, третья ловушка: Хорошее ли качество моих ярлыков?

Еще одна вещь, которую необходимо проверить до/во время проекта, это позволяет ли содержание данных хотя бы человеку выполнить задачу?

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

2. Знайте бизнес-сторону

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

Здесь нужно ответить на вопрос: Как будет использоваться решение?

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

Каким будет рабочий процесс, в котором будет использоваться решение?
Кто будет использовать решение и сколько пользователей?
Где и в какой среде будет использоваться решение?

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

Например, однажды клиент просит вас создать систему рекомендаций, предоставив вам набор данных истории покупок с сайта электронной коммерции. Что бы вы сделали?

Будете ли вы предсказывать товары в будущих корзинах покупателей? Будете ли вы отправлять электронные письма клиентам с предложениями продуктов? Будете ли вы предлагать сопутствующие товары таким клиентам, как Amazon.com?

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

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

3. Определите (реальные) субъективные показатели успеха

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

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

Иногда точности и отзыва недостаточно, и вам нужно настроить, чтобы отразить реальное воздействие. Иногда вам даже нужно определить correct самостоятельно.

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

С другой стороны, если действительно важно, чтобы 80 %, а не 30 % предложенных элементов были правильными, вы также захотите настроить свой KPI, чтобы отразить это изменение. В противном случае прогресс, достигнутый вашей командой, не будет правильно отражен/измерен.

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

4. Найдите время, чтобы автоматизировать вещи и разработать свои инструменты

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

Действительно, каждое изменение на одном шаге может вызвать следующий шаг. Кроме того, в каждом из шагов, скорее всего, есть подшаги, это будет становиться все сложнее и сложнее, если ваши специалисты по данным будут продолжать работать, как на этапе «Анализ», написав отдельный скрипт для каждого отдельного шага. В один момент у вашей команды будет 20, 30 и более скриптов, причем некоторые с разными версиями. Будет сложно отслеживать детали, и вы можете получить очень разные результаты, пытаясь выполнить одну и ту же задачу. Кроме того, это будет очень неэффективно.

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

В качестве примера, в одном проекте я написал скрипт, который загружает набор обучающих данных с AWS S3, проводит обучение на графическом процессоре, а затем, когда обучение завершено, он загружает обученную модель обратно в S3 и удаляет все локальные файлы. . Это избавило меня от множества ручных шагов по перемещению файлов, выполнению шагов, а также от необходимости устанавливать библиотеки, такие как CUDA и cudnn, что действительно сэкономило мне много времени на кофе. ;-)

5. Документируйте все!

Я оставил тему документации здесь, но это, без сомнения, один из самых важных аспектов управления проектом Data Science. (или, может быть, любой проект!) Под документацией я подразумеваю не только написание технической документации по параметрам скриптов, как использовать функции и т. д., но и документацию по темам, включая:

Ценность бизнеса и бизнес-процесс, заинтересованные стороны.
Методология решения, как предполагается решать проект.
Решение принято в проекте. (что делать, чего не делать и почему)
Важные даты. (предоставление результатов, планирование и т. д.)

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

6. Не зацикливайтесь на быстрых деньгах

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

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

Может быть, набор данных, над которым вы работаете, является лишь небольшим подмножеством реальных данных? Может быть, ваше решение не совсем адаптировано к тому, как люди будут его использовать в реальной жизни? Может быть, ваш Data Scientist уже работает над 30 разными скриптами, и проект совсем не организован? Как будет выглядеть архитектура конечного решения?

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

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

Работали ли вы с данными, подобными тем, на которые вы будете смотреть при развертывании решения? (по объему и содержанию)
Позволяют ли имеющиеся у меня данные выполнить задачу хотя бы человеку?
Как будет использоваться решение? (с точки зрения процесса и типа пользователя)
Являются ли мои KPI хорошим показателем качества работы моей команды?
Моя команда теряет эффективность/последовательность при повторяющихся задачах?
Может ли моя документация информировать нового столяра о том, что происходит?

Первоначально опубликовано на http://www.lewen.live 4 ноября 2018 г.