Помимо того, чтобы быть специалистом по данным в бизнесе: разработчик продукта для науки о данных
Мокс, выдающийся специалист по данным. В основном тратит свое драгоценное время на основные задачи науки о данных, такие как предварительный анализ данных, создание набора функций, моделирование и передача окончательного решения другому ответственному лицу или может управлять им самостоятельно. Помимо работы над проектами, он очень много инвестирует в передовые технологии, новые типы моделей и новый набор концепций, таких как Graph NN, The Latest Transformers, Kubeflow и т. д.
Если вы являетесь специалистом по внутренним данным для бизнес-отдела и имеете следующий профиль; мое мнение, что вы, вероятно, упускаете из виду некоторые общие факты. Этот профиль удивителен при работе в исследовательской лаборатории. Почему, я так думаю? — Именно об этом я сегодня и расскажу вкратце.
Бизнес-отделы (продажи, закупки, p2p, оплата, маркетинг и т. д.) в значительной степени ориентированы на продукт. Они не очень заинтересованы в том, чтобы увидеть, как вы представляете блокнот Jupiter, ppt или IDE с кучей изображений, которые вы объясняете им на встрече. На самом деле они с нетерпением ждут минимально жизнеспособного продукта (MVP), который они уже могут быстро опробовать и дать вам обратную связь. В то время как в предварительных исследованиях достаточно показать свои последние исследования и результаты в виде презентации. Таким образом, между исследователем данных и специалистом по данным в бизнесе есть существенные различия. Но проблема в том, что с моим более чем 6-летним опытом работы в текущей отрасли, я заметил, что у специалиста по данным в бизнесе такой же склад ума, как у исследователя данных. Меньше интересуются продуктовыми технологиями и больше интересуются моделированием ML/AI. Поэтому я надеюсь, что появится новая должность, которая поможет решить постоянную дилемму, кто-тосо знаниями в области науки о данных и разработки продуктов.
Но какую роль в области науки о данных должен играть разработчик продукта? Короче говоря, оберните текущую POC в продукт и запустите его как можно раньше. Кроме того, когда проект переходит к производству, необходимо учитывать множество критериев, таких как:
- Выберите Шаблон проектирования, который упростит: сбор данных, обучение, тестирование.
- Контроль версий, данные и модель для переключения между моделями в случае обнаружения каких-либо дрейфов
- Чтобы иметь возможность предоставить интерфейс API для предоставления совокупного результата и предсказания модели.
- Защитите интерфейс API с помощью стандартной аутентификации.
- Создайте интерфейс на стороне клиента, чтобы бизнес-пользователь мог использовать интерфейс модели.
- Ограничьте доступ на стороне клиента в соответствии с общекорпоративной системой единого входа или аутентификацией на основе SAM или Oauth2.
- Прикрепите промежуточное ПО ко всему процессу для мониторинга и регистрации для отслеживания предпочтений пользователя.
Теперь давайте взглянем на пример проекта и проведем криминалистический анализ.
Вы собираетесь создать службу перевода, в которой бизнес-пользователи будут загружать текстовый документ и ждать некоторое время, чтобы получить обратно переведенный документ. Звучит просто, верно? Но есть длинный список требований:
- Документы должны быть представлены в рамках проекта
- Проект необходимо отслеживать, когда кто-то: добавляет документ, обновляет документ или инициирует задание на перевод.
- Владелец проекта Необходимо отследить того, кто создал проект
- Необходимо обновить дополнительные метаданные о проекте.
- Каждое задание на перевод, запущенное пользователем, должно быть зарегистрировано с различным статусом, и позже пользователь сможет просмотреть историю.
- Приложение должно быть доступно авторизованным людям
- ….
Теперь, что вы думаете? Это должно быть полноценное веб-приложение, а ML/AI — лишь малая его часть. Теперь вопрос в том, может ли Data Scientist сделать это?
Давайте посмотрим на модель ежемесячного ценообразования, если кто-то из команды по науке о данных не может этого сделать (это просто относительный пример):
Первый подход:
- PM (наука о данных): 5 000
- специалист по данным (2x): 10 000 - Команда поддержки API (2x): 8K
- Команда внешнего интерфейса (2x): 7K
- PM проекта: 5K
- CloudOps и архитектор решений: 5K
Я упростил это: в крупных организациях люди более сумасшедшие, чтобы влезать в проекты, а не просто получать кусок из бюджета. Таким образом, вашему деловому партнеру придется платить всего 40k в месяц.
Что, если в команде Data Science есть кто-то, кто имеет опыт разработки продукта и может предложить следующую архитектуру, которая не требует команды Frontend и Backend.
Позвольте мне объяснить архитектуру. Документ можно отправить через Dash/Streamlit или любой интерфейсный фреймворк, встроенный в науку о данных. Отправка документа обрабатывается AWS ApiGateway и лямбда и, наконец, попадает в корзину s3. API защищен аутентификацией на основе jwt, предоставляемой AWS Cognito (которая будет настроена devops). Метаданные о документе и действиях пользователя сохраняются в DynamoDB. Когда пользователь запускает обработку файла, запускается StepFunction (например, пакетное задание), которая загружает документ из s3, предварительно обрабатывает его и запускает перевод на основе выбранной модели (скажем, модель pytorch) с использованием контейнера SageMaker Processing Job. Затем он сохранил новый переведенный документ обратно в s3 и сохранил метаданные в DynamoDB.
Давайте распределим работу между нашими коллегами, один специалист по данным может начать работу над частью перевода с самого начала. Облачные операции должны будут настроить роли и политики, чтобы различные службы могли взаимодействовать друг с другом. Разработчик продукта начнет написание лямбда-функций и смоделирует конечные точки API с помощью DynamoDb. Когда макет API будет готов, разработчик может начать работу на стороне клиента с помощью dash/streamlit. К тому времени, когда модель будет хорошо протестирована и готова к интеграции, у вас уже будет фиктивный бэкенд, которым вы сможете заменить. Также вы проводите регулярные встречи с деловыми партнерами, которые имеют доступ к текущему состоянию клиентской части для проверки взаимодействия с пользователем.
Теперь Сколько человек будет задействовано в проекте? Учитывая, что человек будет работать над вышеуказанной архитектурой, он является частью команды Data Science.
Второй подход:
- PM (наука о данных): 5 000
- специалист по данным (2x): 10 000 (разработчик продукта и DS) - PM проекта: 5K
- DevOps и архитектор решений: 5K
Теперь общая стоимость составляет 25 тысяч, почти половина, верно? Кроме того, эти облачные фреймворки проще в освоении, поэтому специалист по обработке и анализу данных с меньшим опытом также может быстро приступить к работе с соответствующими инструкциями, когда они закончат с частью моделирования. Есть и дополнительные преимущества:
- Меньше накладных расходов на синхронизацию между несколькими командами
- Упрощенная передача проекта в случае необходимости
- Полный жизненный цикл продукта известен как минимум 3 людям
Каковы дополнительные преимущества, если у вас будет команда с полным стеком (первый подход)?
- UX и UI могли бы быть более элегантными с отдельной командой фронтенда
- Команда Data Science будет нести ответственность только за жизненный цикл модели ML (скажем, модели-трансформера), и ей не нужно заботиться о других вещах.
- Проект может занять меньше времени, но это не гарантируется, так как зависимость и синхронизация могут занять много времени (Есть поговорка, вы не можете родить ребенка за 6 месяцев с 3 матерями.)
Вывод. В следующий раз, когда вы будете брать интервью у внутреннего специалиста по обработке и анализу данных вашего бизнес-подразделения, не только сосредотачивайтесь на том, какую последнюю статью он читает или насколько актуален последний фреймворк. Также попытайтесь понять, есть ли у них представление о продукте полного стека и его компонентах. Если у вас есть разработчик продукта в команде для проекта, вы можете выполнить ту же задачу с меньшими ресурсами в умеренные сроки.