Улучшите рабочие процессы и управление ожиданиями в ML с помощью технических чертежей

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

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

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

Почему технические чертежи?

Общение на словах затруднено и может привести к недопониманию, особенно когда люди говорят на немного разных языках (деловая сторона, с одной стороны, и технология, с другой). Кроме того, слова, описывающие сложные отношения, требуют большого количества текста или длительных встреч. Преимущество рисунков, однако, в том, что они просты для понимания и могут быть очень интуитивно понятными (конечно, только когда они сделаны хорошо). Иногда один рисунок (или картинка) может заменить 1000 слов.

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

Технические чертежи: от простого к сложному

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

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

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

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

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

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

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

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

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

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

  • Предварительная обработка. Чтобы хранилище объектов было в некоторой степени масштабируемым, любая обработка существующего объекта (например, создание версии с задержкой для авторегрессии) будет происходить на лету во время предварительной обработки с использованием функций представлений/указателей, а не добавляться в магазин как еще одна избыточная функция.
  • Разделение на 4 набора данных: обучение модели — это итеративный процесс. Однако, чтобы улучшить эти итерации, нам нужно получить представление о том, как улучшить модель, и при этом мы автоматически вводим смещение, которое может привести к переоснащению. Поэтому мы создаем один набор данных для обучения, один набор данных для проверки обучения, один набор данных, где мы можем отлаживать и получать информацию для итеративных улучшений, и один набор данных в самом конце в качестве финального теста проекта и если модель нуждается в успехе. критерии.
  • Уровни оценки: имея в виду 4 набора данных, мы также вводим 3 различных оценки, основанных на проверке, отладке или тестовом наборе. Прежде чем приступить к работе над внутренним циклом, важно выровнять и записать, что на самом деле означает «успех» для проекта с точки зрения этих оценок. Только когда оценка теста проходит в соответствии с планом, модель считается успешной и готовой к производству.

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

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

Используйте цвета или формы для планирования и установки сроков

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

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

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

Резюме

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

Все изображения, если не указано иное, принадлежат автору.