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

Организационные вопросы:

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

Расширение прав и возможностей

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

Некоторые организации накладывают определенные ограничения на запуск кода в производство. Требование контракта на поддержку, уважение к конкретным S.L.A. и, конечно, на кого-то виноватого, чтобы не брать на себя полную ответственность, если что-то пойдет не так.

Эта ситуация может привести к тому, что специалисты по обработке данных не смогут запустить код в производство. Например, контракты на обслуживание могут охватывать только определенные языки программирования, например C #, а не язык программирования, обычно используемый для науки о данных, такой как Python или Scala. Некоторые организации могут попросить перестроить колесо, чтобы эффективно использовать модели.

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

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

Организационная разобщенность и офисная политика

М.Л. и А.И. проекты, как правило, охватывают несколько отделов и могут столкнуться с довольно высокой степенью разделения и политики, даже в большей степени, чем I.T. проекты.

Крупные предприятия обычно имеют дело с архитектурой предприятия и полагаются на процесс утверждения перед установкой приложений в производство. Функция E.A, возможно, не была особенно подвержена науке о данных в прошлом и может не рекомендовать наиболее прагматичный путь вперед.

У заинтересованных сторон также могут возникнуть проблемы с переводом моделей в производство. Это разные причины, по которым заинтересованное лицо теряет аппетит. Часто проекты Data Science вытесняются сверху, и заинтересованные стороны могут опасаться последствий их реализации.

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

Еще одна причина, по которой заинтересованные стороны могут потерять аппетит, заключается в том, что фактор успеха от P.O.C. может включать метрики «сэкономленное время». Заинтересованные стороны могут не захотеть придерживаться показателя, который можно было бы перевести в сокращение FTE.

Команда / Организация

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

Третьи стороны

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

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

Координация. Координация с несколькими третьими сторонами может стать проблематичной, особенно когда люди не работают над проектом полный рабочий день или когда задействованы несколько уровней менеджеров проекта.

Оформление документов. Привлечение третьих лиц может замедлить процесс запуска моделей в производство из-за административных процедур. Может потребоваться запрос дополнительного бюджета, определение конкретных технических заданий, подписание контрактов и т. Д.

Вспомогательные функции

Другие функции, помимо науки о данных, играют большую роль в возможности создания моделей. Усилия по производству могут потребовать ввода от управления продуктом / проектом, инженерии данных, разработки программного обеспечения, DevOps, Q.A.,…

Часто при построении доказательства концепции эти функции либо не присутствуют в проекте, либо, если они присутствуют, они обычно не включаются в обсуждение на ранних этапах. Это отсутствие участия может особенно затруднить преобразование P.O.C. в готовое к производству приложение. Включение этих функций может быть ключом к обеспечению успеха P.O.C.

Склад ума

Менталитет организации имеет важное значение для достижения успеха в области науки о данных. Положительный вклад вносят два основных фактора: ловкость и желание экспериментировать.

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

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

Организационные знания

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

Проблемы с данными:

Существуют различные проблемы, связанные с данными, которые могут возникнуть при разработке приложения или его интеграции в производственные системы. Общее качество данных может оказаться неподходящим. Может быть недостаточно данных или могут быть различия в базовых данных между тем, когда P.O.C. фаза произошла и когда она интегрируется в праодукцию.

Качество данных

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

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

Объем данных

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

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

Данные изменились

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

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

Проблемы проекта

На уровне проекта могут возникнуть множественные проблемы, из-за которых может быть маловероятным, что P.O.C. будет подтолкнуть к производству. Основополагающие факторы, объем, проблемы интеграции, неверные предположения об увеличении данных или использование ручных процессов - все это факторы, которые влияют на вероятность того, что P.O.C. будет производиться.

Основные проблемы

Часто возникают проблемы, если начинать проект не с правильного фундамента. Часто проекты Data Science продвигаются сверху вниз, и это не оставляет возможности правильно структурировать и гарантировать, что проект будет основан на правильной основе.

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

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

Проблемы с объемом

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

Одна из проблем объема, которая может возникнуть, заключается в том, что на этапе подтверждения концепции не решается достаточно большой объем. Тем, кто смотрел сериал «Силиконовая долина», стоит подумать о приложении «Хот-дог / Не хот-дог» от Jian-Yang. Приложение хорошо демонстрирует концепцию того, как оно может идентифицировать определенные типы продуктов питания, но не только для определения разнообразия продуктов питания. Для многих компаний этап проверки концепции является ограниченным по срокам мероприятием. Возможно, в отведенные сроки не удастся заняться достаточно большим объемом для проблемы, чтобы мы смогли протолкнуть P.O.C. к производству без значительных рисков.

Ручной процесс

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

Увеличение объема данных

Иногда P.O.C. не приносит ожидаемого улучшения и не оправдывает запуск приложения в рабочую среду. Завершение с более низкими, чем ожидалось, результатами может возникнуть по нескольким причинам. Метод, использованный для получения оценки, сам по себе может быть ошибочным, или может потребоваться нечто большее, чем просто более точный ввод данных для получения ожидаемого повышения.

Если полагаться на отраслевые эталоны или показатели роста, предоставленные консультантами, без учета всего вашего бизнес-контекста, это может привести к существенным различиям между ожидаемым увеличением и результатами, полученными во время запроса на закупку. . Например, персонализированная рекомендация продукта на среднем веб-сайте электронной коммерции сообщает о значительном увеличении доходов за счет персонализации. Но если на вашем веб-сайте нет проблемы с обнаружением и всего 10–20 элементов, маловероятно, что персонализированные рекомендации по продукту могут значительно увеличить доходы.

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

Проблемы интеграции

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

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

При запуске моделей в производство могут возникнуть и другие препятствия. Интеграция может оказаться неосуществимой либо из-за ограничений в текущих системах, либо из-за отсутствия специализированных ресурсов, необходимых для интеграции (например, третьих сторон).

Проблемы с инфраструктурой

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

Инфраструктура обработки данных

Чтобы легко производить и извлекать ценность из данных, необходима инфраструктура, позволяющая обрабатывать данные.

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

Помимо необработанных вычислительных мощностей, инфраструктуры с точки зрения хранения и передачи данных, а также инфраструктуры обработки (например, Spark) и структуры для обучающих моделей (например, Микеланджело Uber), помогают снизить затраты на производство доказательств науки о данных. концепции.

Инфраструктура обслуживания данных

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

Функции должны быть доступны в производственной среде и должны соответствовать тем, которые доступны во время обучения. Существуют разные подходы, позволяющие сделать эти данные доступными в экосистеме приложений, от использования подходов, подходящих для конкретных целей или использования микросервисов (например, Amazon), или использования унифицированной модели доступа к данным (например, Facebook). Наличие данных, легко доступных в производстве для целей моделирования, позволяет значительно снизить стоимость и сложность интеграции модели в производство.

Операции с данными / ML

Существуют также операционные аспекты запуска моделей в продукте, от возможности отслеживать и оценивать производительность моделей до развертывания моделей, управления версиями и экспериментов.

Резюме

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

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

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

Постепенно настраивайте инфраструктуру вместе с разработкой сценариев использования. С помощью инфраструктуры, помогающей снизить стоимость и сложность разработки будущих инициатив в области данных.

Еще от меня о Хакерской аналитике: