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

Мокс, выдающийся специалист по данным. В основном тратит свое драгоценное время на основные задачи науки о данных, такие как предварительный анализ данных, создание набора функций, моделирование и передача окончательного решения другому ответственному лицу или может управлять им самостоятельно. Помимо работы над проектами, он очень много инвестирует в передовые технологии, новые типы моделей и новый набор концепций, таких как 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 матерями.)

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