Выводы аэрокосмического инженера, ставшего специалистом по обработке данных
Это часть I из двух частей, посвященных продуктам машинного обучения (ML). В этой первой части я провожу параллели между производством физических продуктов и продуктов машинного обучения. В Части II я обсуждаю, почему эти сходства должны определять подход специалистов по данным к разработке продукта.
Как отрасль науки о данных появилась совсем недавно, и нормы, регулирующие эту область, все еще устанавливаются. Существует множество ресурсов, объясняющих математику, статистику и итеративную логику, задействованные в машинном обучении. Еще больше исследуется, как машинное обучение может быть использовано в качестве инструмента для принятия решений и решения бизнес-проблем, таких как A / B-тестирование и прогнозирование оттока клиентов, или как функцию для оптимизации взаимодействия с пользователем - подумайте о системах рекомендаций и персонализированном контролируемом контенте. Но поскольку это менее распространено в бизнесе, гораздо меньше обсуждений машинного обучения как продукта, где его основной целью является решение рыночной проблемы и непосредственное генерирование доход, например от беспилотных автомобилей, услуг чат-ботов службы поддержки клиентов, автоматизированных страховых услуг и т. д.
В этой серии статей я по-новому формулирую концепцию продукта машинного обучения, используя свой опыт в аэрокосмическом производстве, чтобы провести параллели, которые показывают, как специалисты по обработке данных и менеджеры по продуктам должны подходить к разработке и обслуживанию продуктов машинного обучения.
Заводская аналогия
Хотя это может показаться нелогичным, процесс разработки и сопровождения продукта машинного обучения имеет больше общего с созданием физического продукта, чем с разработкой программного приложения. Чего обычно не хватает в жизненном цикле разработки программного обеспечения, так это одного критического компонента: цепочки поставок данных. И это отсутствие упрощает разработку программного обеспечения в некоторых отношениях, потому что наличие данных, которые являются неотъемлемой частью продукта, означает необходимость учитывать их на протяжении всего его жизненного цикла.
Так что это значит? Давайте начнем с простой аналогии, которая, как я нахожу, помогает моим друзьям-нетехническим специалистам понять связь между продуктами машинного обучения и физическими продуктами.
Если вы хотите произвести физический продукт - давайте использовать авиационную радиостанцию, поскольку я работал в компании, которая ее производила - вам необходимо спроектировать и построить завод, обучить персонал сборке радиостанции, управлять поставкой деталей. которые необходимы для его создания, включения любых настроек клиента, сборки радио и доставки его вашим клиентам. Точно так же при создании продукта машинного обучения вам необходимо обучить модель (то есть спроектировать / построить фабрику и обучить рабочих), собрать входные данные клиентов (настройки) и обогатить эти входные данные (управлять поставкой деталей) для создания прогнозов ( то есть радио).
Поскольку существует так много взаимозависимых движущихся частей, отказ одной функции может привести к поломке других. У вас может быть современный завод с высококлассным оборудованием и высочайшей квалификацией рабочей силы, но ненадежная или неадекватная цепочка поставок (т. Е. Отсутствие данных или неправильные данные) в конечном итоге приведет к потере вашего продукта.
Для сравнения, процесс разработки программных продуктов намного более сдержанный. Это похоже на проектирование и создание опыта. Возьмем, к примеру, веб-сайт, продающий одежду. После постройки его необходимо поддерживать в рабочем состоянии. Вы можете периодически менять контент или добавлять новые функции, чтобы улучшить взаимодействие с пользователем, но обычно вы не зависите от потоковой передачи данных из внешних источников для работы веб-сайта. Хотя будет существовать цепочка поставок для инвентаризации, она отделена от работы веб-сайта; для самого веб-сайта просто нет необходимости в выделенной цепочке поставок. По этой причине аспект управления поставками не существует в структуре жизненного цикла разработки программного обеспечения. Как только информационные продукты полагаются на непрерывно поступающие данные, инфраструктура должна следовать практике управления поставками физических продуктов, иначе вы будете вынуждены перейти к реактивному управлению.
Взгляд глубже
Возвращаясь к аналогии с физическим продуктом, давайте рассмотрим пару реальных сценариев, которые иллюстрируют, почему сравнение с физическим продуктом так информативно, особенно в отношении управления цепочкой поставок.
Какое-то время я работал покупателем в той аэрокосмической компании, которая производила радиоприемники. Однажды мы обнаружили неисправную партию переключающих ИС (разновидность электронного чипа). Большая часть партии не прошла тестирование, и нам нужно было купить больше, чтобы построить одну из наших менее популярных радиостанций. Когда я связался с нашим поставщиком, я обнаружил, что они больше не продают этот чип. Хуже того, другие поставщики указали его как устаревший. Производитель прекратил их выпуск двумя годами ранее, и мы не знали об этом. Мы делали радио 12 лет. Нам нужен был новый чип как можно скорее!
Мы смогли немного изменить конструкцию узла, чтобы включить в него более новый чип меньшего размера. Это потребовало остановки производства до тех пор, пока не будет разработан новый дизайн, повторного тестирования продукта перед возобновлением производства и сверхурочной работы по заполнению заказов для выполнения обязательств клиентов. Для более консервативной отрасли, где одни и те же продукты продаются десятилетиями, такой сценарий не редкость.
Хотя это может быть не сразу очевидно, ситуация такого типа на самом деле невероятно похожа на то, с чем могут столкнуться специалисты по данным. Недавно я проверял обновления данных для прототипа модели. Я хотел убедиться, что все внешние контекстные данные, которые мы использовали, были свежими, чтобы прогнозы тестов были точными. Проверяя, я заметил, что один источник устарел, и, что еще хуже, у нас больше нет доступа к этому источнику. Нам нужен новый набор данных как можно скорее!
Хотя нам удалось найти новый источник сопоставимых данных, данные не были точными. Как и в предыдущем примере с авиационными радиостанциями, замена на замену потребовала переобучения и повторного тестирования новой модели машинного обучения и повторного запуска всех наших оценочных показателей для проверки воздействия. К счастью, это происходило не в живой среде; Я мог только представить себе кошмар, связанный с отключением производственной модели для исправления проблем с качеством или извлечением данных, подобных этой. Это было бы невероятно разрушительно. Существуют передовые методы и проверки, которые могут помочь предотвратить эти проблемы, но я оставлю это обсуждение на другой раз.
Из этих примеров должно быть очевидно несколько более глубоких сходств между физической разработкой продукта и разработкой продукта машинного обучения. Оба:
- Требовать постоянных поставок высококачественных материалов (или деталей) для стабильного производства / доставки;
- Подвержены милости цепочки поставок (особенно в тех случаях, когда продукт полагается на данные, которые не генерируются внутри компании);
- Требовать доработки дизайна с течением времени по мере необходимости для обеспечения устойчивости и / или производительности. В обоих случаях это часто сильно зависит от цепочки поставок.
Более того, эти примеры намекают на необходимость управления разработкой с учетом того, как цепочка поставок влияет на различные этапы жизненного цикла продукта. Так же, как и в производстве, информационные продукты, которые полагаются на поставку данных, должны управляться с самого начала с учетом этих данных. Это то, что я буду обсуждать в следующем посте этой серии из двух частей, где я исследую традиционные методы управления цепочкой поставок, используемые для минимизации риска, переведенные и перепрофилированные для продуктов для анализа данных.
Таким образом, природа машинного обучения и систем, основанных на данных, открывает перед вами уникальные риски, которые обычно не наблюдаются в других программных приложениях, но эти риски не являются уникальными для отрасли. Они существуют в аналогичной форме в производственном мире, и концепция стратегии цепочки поставок может быть напрямую применена к науке о данных. Правильное управление рисками, связанными с данными, - это гарантия непрерывного успеха вашего продукта машинного обучения. Именно здесь наличие или отсутствие стратегии предоставления данных может повлиять на ваш продукт.
Привет, я Кэти Лэзелл-Фэйрман. Я специалист по обработке данных в компании GeoPhy из Нью-Йорка. Есть вопросы по этому посту или вам интересна эта тема? Не стесняйтесь комментировать ниже или свяжитесь со мной!
