Для проектов ML требуются команды, члены которых обладают различными навыками, опытом и обязанностями, связанными с машинным обучением. Вот наиболее распространенные роли в типичных командах ML:
| Роль | Знания и навыки | Основной результат |
|---|---|---|
| Менеджер по продуктам ML | Менеджеры по продуктам ML имеют глубокое понимание сильных и слабых сторон ML, а также процесса разработки ML. Они согласовывают бизнес-проблемы с решениями ML, работая напрямую с командой ML, конечными пользователями и другими заинтересованными сторонами. Они создают видение продукта, определяют варианты использования и требования, а также планируют и расставляют приоритеты проектов. | Документ о требованиях к продукции (PRD). |
| Инженерный менеджер | Инженерные менеджеры достигают бизнес-целей, устанавливая, общаясь и достигая командных приоритетов. Подобно менеджерам по продуктам ML, они согласовывают решения ML с бизнес-проблемами. Они устанавливают четкие ожидания от членов команды, проводят оценку производительности и помогают в карьерном и профессиональном развитии. | Проектная документация, планы проектов и оценки производительности. |
| Специалист по данным | Ученые, работающие с данными, используют количественный и статистический анализ, чтобы извлечь из данных ценную информацию и ценность. Они помогают идентифицировать и тестировать функции, создавать прототипы моделей и помогают интерпретировать модели. | Отчеты и визуализация данных, которые отвечают на бизнес-вопросы посредством статистического анализа. |
| инженер машинного обучения | Инженеры ML проектируют, создают, производят модели ML и управляют ими. Это сильные инженеры-программисты с глубоким пониманием технологий и лучших практик машинного обучения. | Развернутая модель с достаточным качеством прогнозирования для достижения бизнес-целей. |
| Дата-инженер | Инженеры по обработке данных создают конвейеры данных для хранения, агрегирования и обработки больших объемов данных. Они разрабатывают инфраструктуру и системы для сбора и преобразования необработанных данных в полезные форматы для обучения и обслуживания моделей. Инженеры по обработке данных несут ответственность за данные на протяжении всего процесса разработки машинного обучения. | Полностью автоматизированные конвейеры данных с необходимым мониторингом и оповещением. |
| Инженер по эксплуатации разработчиков (DevOps) | Инженеры DevOps разрабатывают, развертывают, масштабируют и контролируют обслуживающую инфраструктуру для моделей машинного обучения. | Автоматизированный процесс обслуживания, мониторинга, тестирования и оповещения о поведении модели. |
В успешных проектах ML есть команды, в которых хорошо представлена каждая роль. В небольших командах отдельным сотрудникам придется выполнять несколько ролей.
Установите командные практики
Поскольку роли, инструменты и платформы в разработке машинного обучения сильно различаются, крайне важно установить общие практики с помощью качественной документации процессов. Например, один инженер может подумать, что просто получить нужные данные достаточно, чтобы начать обучение модели, в то время как более ответственный инженер проверит правильность анонимизации набора данных и задокументирует его метаданные и происхождение. Обеспечение того, чтобы инженеры разделяли общие определения процессов и шаблонов проектирования, уменьшает путаницу и увеличивает скорость работы команды.
Технологическая документация
Документы по процессам должны определять инструменты, инфраструктуру и процессы, которые команда будет использовать для разработки ML. Хорошая документация процессов помогает согласовывать действия новых и нынешних членов команды. Им следует ответить на следующие типы вопросов:
- Как генерируются данные для модели?
- Как мы исследуем, проверяем и визуализируем данные?
- Как изменить входной признак или метку в обучающих данных?
- Как нам настроить конвейер генерации, обучения и оценки данных?
- Как изменить архитектуру модели, чтобы учесть изменения во входных объектах или метках?
- Как мы получаем примеры тестирования?
- Какие показатели мы будем использовать для оценки качества модели?
- Как мы запускаем наши модели в производство?
- Как мы узнаем, что с нашей моделью что-то не так?
- От каких вышестоящих систем зависят наши модели?
- Как мне сделать мой SQL удобным для обслуживания и повторного использования?
Больше потенциальных вопросов
МодельМогу ли я обучать модели на разных наборах данных в одном конвейере, например, для точной настройки?
Как добавить в конвейер новый набор тестовых данных?
Как проверить предсказание модели на созданном вручную примере?
Как найти, изучить и визуализировать примеры, в которых модель допустила ошибки?
Как определить, какая функция наиболее ответственна за данный прогноз?
Как понять, какие функции оказывают наибольшее влияние на прогнозы в данной выборке?
Как вычислить или построить прогнозы модели для выбранного набора данных или выборки?
Как вычислить стандартные метрики для прогнозов моей модели для выбранного набора данных?
Как разрабатывать и рассчитывать пользовательские метрики?
Как мне сравнить мою модель с другими моделями в автономном режиме?
Могу ли я выполнить метаанализ для нескольких оценок модели в одной среде разработки?
Могу ли я сравнить текущую модель с той, что была 10 месяцев назад?
Думаю, я создал хорошую модель. Как запустить его в производство?
Как мне убедиться, что моя новая модель правильно работает в производстве?
Могу ли я получить историю оценок модели с течением времени?
Как я узнаю, что с моделью что-то не так?
Мне назначили страницу/ошибку, в которой упоминается что-то о модели. Что я должен делать?
Как я могу настроить конвейер генерации/обучения/оценки данных?
Когда и как мне следует создать совершенно новый конвейер?
Мне нужен SQL для генерации некоторых данных. Куда мне его положить?
Как работает наша модель обслуживания? Есть ли схема?
От каких вышестоящих систем зависит моя модель и о которых мне следует знать?
Я ничего не могу понять. К кому (и как) мне следует обратиться?
Иметь в виду
То, что представляет собой «лучшая практика ML», может различаться в разных компаниях, командах и отдельных лицах. Например, некоторые члены команды могут рассматривать экспериментальные Colabs как основной результат, в то время как другие захотят работать в R. У некоторых может быть страсть к разработке программного обеспечения, кто-то считает, что мониторинг — это самое важное, а кто-то еще знает о хорошем. практику разработки функций, но хочет использовать Scala. Каждый «прав» со своей точки зрения, и при правильном управлении смесь станет мощной. Если нет, это может быть беспорядок.
Создание инструментов, процессов и инфраструктуры, которые команда будет использовать до написания строки кода, может стать решающим фактором между провалом проекта через два года или успешным запуском на квартал раньше запланированного срока.
Оценка производительности
Из-за двусмысленности и неопределенности, присущих МО, менеджерам по персоналу необходимо заранее сформулировать четкие ожидания и определить результаты.
При определении ожиданий и результатов подумайте, как они будут оцениваться, если проект или подход не увенчаются успехом. Другими словами, важно, чтобы производительность члена команды не была напрямую связана с успехом проекта. Например, члены команды нередко тратят недели на поиск решений, которые в конечном итоге оказываются безуспешными. Даже в этих случаях их высококачественный код, тщательная документация и эффективное сотрудничество должны способствовать их оценке.