Собираем команду ML

Для проектов ML требуются команды, члены которых обладают различными навыками, опытом и обязанностями, связанными с машинным обучением. Вот наиболее распространенные роли в типичных командах ML:

Роль Знания и навыки Основной результат
Менеджер по продуктам ML Менеджеры по продуктам ML имеют глубокое понимание сильных и слабых сторон ML, а также процесса разработки ML. Они согласовывают бизнес-проблемы с решениями ML, работая совместно с командой ML, конечными пользователями и другими заинтересованными сторонами. Они создают видение продукта, определяют варианты использования и требования, а также планируют и расставляют приоритеты проектов. Документ о требованиях к продукции (PRD).
Пример PRD для обнаружения аномалий ML см. в разделе PRD для обнаружения аномалий .
Главный инженер Инженерные менеджеры достигают бизнес-целей, устанавливая, общаясь и достигая командных приоритетов. Подобно менеджерам по продуктам ML, они согласовывают решения ML с бизнес-проблемами. Они устанавливают четкие ожидания от членов команды, проводят оценку производительности и помогают в карьерном и профессиональном развитии. Проектная документация, планы проектов и оценки производительности.
Пример документации по проектированию машинного обучения см. в go/ml-design-doc-example .
Специалист по данным Ученые, работающие с данными, используют количественный и статистический анализ, чтобы извлечь из данных ценную информацию и ценность. Они помогают идентифицировать и тестировать функции, создавать прототипы моделей и помогают интерпретировать модели. Отчеты и визуализация данных, которые отвечают на бизнес-вопросы посредством статистического анализа.
инженер машинного обучения Инженеры ML проектируют, создают, производят модели ML и управляют ими. Это сильные инженеры-программисты с глубоким пониманием технологий и лучших практик машинного обучения. Развернутая модель с достаточным качеством прогнозирования для достижения бизнес-целей.
Дата-инженер Инженеры по обработке данных создают конвейеры данных для хранения, агрегирования и обработки больших объемов данных. Они разрабатывают инфраструктуру и системы для сбора и преобразования необработанных данных в полезные форматы для обучения и обслуживания моделей. Инженеры по обработке данных несут ответственность за данные на протяжении всего процесса разработки машинного обучения. Полностью автоматизированные конвейеры данных с необходимым мониторингом и оповещением.
Инженер по эксплуатации разработчиков (DevOps) Инженеры DevOps разрабатывают, развертывают, масштабируют и контролируют обслуживающую инфраструктуру для моделей машинного обучения. Автоматизированный процесс обслуживания, мониторинга, тестирования и оповещения о поведении модели.

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

Установите командные практики

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

Технологическая документация

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

  • Как генерируются данные для модели?
  • Как мы исследуем, проверяем и визуализируем данные?
  • Как изменить входной признак или метку в обучающих данных?
  • Как нам настроить конвейер генерации, обучения и оценки данных?
  • Как изменить архитектуру модели, чтобы учесть изменения во входных объектах или метках?
  • Как мы получаем примеры тестирования?
  • Какие показатели мы будем использовать для оценки качества модели?
  • Как мы запускаем наши модели в производство?
  • Как мы узнаем, что с нашей моделью что-то не так?
  • От каких вышестоящих систем зависят наши модели?
  • Как мне сделать мой SQL удобным для обслуживания и повторного использования?

Документ Google со списком этих вопросов доступен по адресу go/ml-list-of-questions .

Больше потенциальных вопросов

Модель
  • Могу ли я обучать модели на разных наборах данных в одном конвейере, например, для точной настройки?

  • Как добавить в конвейер новый набор тестовых данных?

Обучение
  • Как проверить предсказание модели на созданном вручную примере?

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

  • Как определить, какая функция наиболее ответственна за данный прогноз?

  • Как понять, какие функции оказывают наибольшее влияние на прогнозы в данной выборке?

  • Как вычислить или построить прогнозы модели для выбранного набора данных или выборки?

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

  • Как разрабатывать и рассчитывать пользовательские метрики?

  • Как мне сравнить мою модель с другими моделями в автономном режиме?

  • Могу ли я выполнить метаанализ для нескольких оценок модели в одной среде разработки?

  • Могу ли я сравнить текущую модель с той, что была 10 месяцев назад?

Производство, мониторинг и обслуживание
  • Думаю, я создал хорошую модель. Как запустить его в производство?

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

  • Могу ли я получить историю оценок модели с течением времени?

  • Как я узнаю, что с моделью что-то не так?

  • Мне назначили страницу/ошибку, в которой упоминается что-то о модели. Что я должен делать?

Трубопроводы
  • Как я могу настроить конвейер генерации/обучения/оценки данных?

  • Когда и как мне следует создать совершенно новый конвейер?

SQL
  • Мне нужен SQL для генерации некоторых данных. Куда мне его положить?

Инфраструктура
  • Как работает наша модель обслуживания? Есть ли схема?

  • От каких вышестоящих систем зависит моя модель и о которых мне следует знать?

Коммуникация
  • Я ничего не могу понять. К кому (и как) мне следует обратиться?

Иметь ввиду

То, что представляет собой «лучшая практика ML», может различаться в разных компаниях, командах и отдельных лицах. Например, некоторые члены команды могут рассматривать экспериментальные Colabs как основной результат, в то время как другие захотят работать в R. У некоторых может быть страсть к разработке программного обеспечения, кто-то считает, что мониторинг — это самое важное, а кто-то еще знает о хорошем. практику разработки функций, но хочет использовать Scala. Каждый «прав» со своей точки зрения, и при правильном управлении смесь станет мощной. Если нет, это может быть беспорядок.

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

Оценка производительности

Из-за двусмысленности и неопределенности, присущих МО, менеджерам по персоналу необходимо заранее сформулировать четкие ожидания и определить результаты.

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