№ 2 в серии «Развитие науки о данных»

Работая над данными, они преследуют две основные цели:

  1. Решить бизнес-проблему с учетом рекомендаций и ограничений, предоставленных бизнесом
  2. Передайте решение тем, кто будет им управлять

Этот подход имеет ряд существенных недостатков, а именно:

  • Специалисты по данным не поддерживают решение — у них нет шкуры на кону
  • Процесс индустриализации идет медленно и может привести к моделям, которые больше не актуальны и, возможно, совершенно неверны.
  • Нет гарантии, что недавно развернутая модель лучше или обеспечивает какую-либо ценность для бизнеса.

Необходимость «оставаться на связи»

Когда специалисты по данным не могут поддерживать связь со своим продуктом/решением, оно теряет доверие, жизнеспособность, ремонтопригодность и возможность развития. Итак, как это происходит? Я обсужу это, а потом расскажу, как с этим бороться.

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

Запуск модели в производство

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

Изготовление модели — это сложно

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

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

В то же время это приводит к некоторым проблемам решения:

  • Потеря контекста, который может быть неявным в коде
  • Предоставление результатов, которые больше не действительны
  • Становится трудно обновлять, когда решение расходится (становится недействительным, когда оно когда-то было)
  • Нелегко понять специалистам по данным
  • Доставляется после того, как его полезность прошла

Точно так же, когда ученый данных пытается предоставить решение без партнерства с инженером данных, некоторые аспекты могут быть «отброшены»:

  • Специалисты по обработке и анализу данных не являются инженерами данных, поэтому решения могут быть еще не готовы — подумайте о буханке хлеба, которая испечена и выглядит великолепно снаружи, но остается сырой и рыхлой внутри.
  • Соблюдение SLA и более тонкое взаимодействие с системой
  • Безопасность, связанная с решением
  • Архитектурные качества (надежность, доступность и т. д.), которые нельзя наблюдать или учитывать
  • Корректность (качество, вероятность ошибок и т. д.) кода может быть низкой.

Устранение пробелов

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

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

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

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

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

Это часть серии Развитие науки о данных.

Не стесняйтесь делиться на других каналах и будьте уверены и следите за всем новым контентом от Hashmap здесь. Чтобы послушать непринужденную беседу обо всем, что связано с обработкой данных и облачными технологиями, посмотрите подкаст Hashmap Hashmap on Tap, а также в Spotify, Apple, Google и других популярных потоковых приложениях.

Если вам понравилось это читать, некоторые из других недавних историй Джона приведены ниже:









Джон Авен, доктор философии, является техническим директором компании Hashmap, предоставляющей решения для данных, облачных вычислений, Интернета вещей и AI/ML, а также предоставляющей консультационные услуги по всему миру. промышленности с группой инновационных технологов и экспертов в данной области, которые ускоряют получение ценных бизнес-результатов для наших клиентов. Будьте уверены и свяжитесь с Джоном на LinkedIn, чтобы узнать больше о перспективах и идеях для ускорения ваших бизнес-результатов, основанных на данных.