Потратьте минуты, чтобы сэкономить своей компании миллионы

Введение

Тысячи руководителей компаний влюбились в данные - отчасти потому, что их так много, отчасти из-за потенциала науки о данных и машинного обучения (ML), о которых пишут в деловой прессе, а отчасти потому, что они знают о ценности данных. но они не уверены, что со всем этим делать или как его извлечь, и он просто продолжает экспоненциально расти (Редман, Ваша компания знает, что делать со всеми своими данными ?, 2017). Тем не менее, согласно недавнему исследованию Gartner, 85% проектов в области науки о данных терпят неудачу. Почему? Более того, как ваша компания может попасть в число 15% (Walker, 2017)? Отраслевая литература изобилует некоторыми разумными причинами: неадекватные данные (Asay, 2017), технологии сами по себе, а не движущие силы прибыли и ключевых показателей эффективности (KPI) (Taylor, 2017), плохая коммуникация (Taylor, 2017) , недостаточная поддержка со стороны руководства (Taylor, 2017), чрезмерное усложнение (Veeramachaneni, 2016) и слишком узкий фокус проблемы (Veeramachaneni, 2016).

Однако, как специалист по анализу данных и руководитель организации, возникает вопрос, являются ли это просто симптомами, а не тем, что делает проекты в области науки о данных больными. Каковы их основные причины? Существуют ли мета-проблемы выше по течению от этих последующих последствий, например, если эти источники «болезней» будут выявлены и устранены, симптомы будут предотвращены, а проект по науке о данных / машинному обучению останется здоровым?

Основные причины успехов и неудач в области науки о данных

1. Разнообразие команд - кросс-функциональные команды - В середине 1990-х моя первая работа после университета была работа в первой в мире глобальной глобальной телекоммуникационной компании как раз тогда, когда Интернет - и, следовательно, трафик данных - был испытывает стремительный рост. Поскольку они подписали контракты на 700 миллионов долларов с 2000 клиентов в 40 странах на основе соглашений об уровне обслуживания (SLA) качества данных, было критически важно предсказать сбои качества данных, которые по контракту повлекут за собой финансовые штрафы, достаточно заблаговременно, чтобы сделать это. что-то, чтобы им помешать. Для этого им нужно было создать многомерные потоки данных качества передачи, сохранить их в хранилище данных, а затем разработать настраиваемые инструменты для автоматического анализа, прогнозирования и предупреждения, когда тип услуги и область будут соответствовать SLA с достаточным уведомлением, чтобы предотвратить это. , тем самым обеспечивая удовлетворение своих многонациональных клиентов и собственную прибыльность, избегая штрафных санкций.

Этот успешный многолетний проект почти взорвался на стартовой площадке по одной из тех же причин, по которым проекты в области науки о данных терпят неудачу - они ошибочно полагали, что программист, владеющий несколькими языками и инструментами, может: (а) делать все с помощью этих парных инструментов; и (b) выяснить все остальные элементы - успешное определение требований, технических стратегий, статистики, взаимодействия с пользователем, обеспечения качества, обучения и доставки.

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

Сформулированный таким образом ответ кажется очевидным: даже чрезвычайно талантливые программисты, работая в одиночку, скорее всего, не смогут реализовать крупную инициативу в области науки о данных, поскольку для этого требуется большее разнообразие межфункциональных навыков и талантов. Цитируя ведущую консалтинговую компанию по машинному обучению, «специалист по данным должен иметь представление о бизнесе, понимать математику, лежащую в основе данных, и работать в тандеме с опытным разработчиком» (Терещенко, 2017). Хотя теоретически возможно представить специалиста по данным, обладающего балансом знаний по многим функциям и инструментам, в реальной жизни они похожи на единорогов - их очень трудно найти. Итак, какова идеальная команда по науке о данных или машинному обучению? Что ж, это интересная и оживленная дискуссия в отрасли; однако, как идеальная команда разработчиков программного обеспечения кросс-функциональна, так и наука о данных и машинное обучение - это, по сути, особый случай для определенного типа команды разработчиков программного обеспечения. Хотя у каждого члена команды есть квазитрадиционные функции, гораздо важнее сосредоточиться на представлении функций, чем на названиях:

(A) Лидерство проекта - это бывает двух форм: (i) менеджер проекта, который имеет опыт создания дорожных карт и знает потенциальные ошибки, управляет персоналом, бюджетами и результатами и обеспечивает высокое качество результатов, на -время и в рамках бюджета, превышающие ожидания; и (ii) технический руководитель, у которого обычно есть окончательная рекомендация, если не одобрение, по техническим элементам того, как лучше всего удовлетворять функциональные и бизнес-требования. Обе стороны часто играют роль в построении команды; однако они редко бывают одним и тем же человеком.

(B) Стратег. Вероятно, это человек, обладающий обширным опытом в области статистики, биостатистики, прогнозной аналитики, искусственного интеллекта и машинного обучения. Как правило, они имеют возможность преобразовывать бизнес-проблемы или исследовательские вопросы в наиболее подходящие модели науки о данных, интерпретировать результаты, сравнивать модели, знать, когда использовать какие статистические инструменты, контролируемое обучение и алгоритмы обучения без учителя, а также какие типы (например, случайные леса для пропорциональной причинно-следственной связи - особенно с большими данными, которые моделируют избыточно или недостаточно и как улучшить, повышение градиента для функций поисковых систем, когда и как использовать информационные панели, такие как Tableau, для демократизации данные в реальном времени для пользователей компании на передовой, в розничной торговле для использования K-средних или самоорганизующихся карт для сегментации клиентов или кластеризации, когда и как использовать коллективную предиктивную аналитику,« мудрость толпы » в электронной розничной торговле и т. д.), а также понимание на высоком уровне того, как использовать типы данных, очищать, обучать и т. д. Короче говоря, стратеги специализируются на том, что делать, когда они могут создавать новые инновационные подходы к решениям. от дифф в разных областях и на высоком уровне знают, как это сделать.

(C) Коммуникация / перевод. Лучшие специалисты по обработке данных выходят и разговаривают с людьми, - говорит Томас Редман в Harvard Business Review (Redman, 2017). Лучшие требования выявляются в ходе множества бесед с конечными пользователями, документируются, просматриваются, редактируются, а затем устанавливаются приоритеты. Эти сеансы вопросов и ответов требуют навыков судебно-медицинской экспертизы и легкого диалога со всеми, от квалифицированных рабочих до менеджеров и руководителей. В идеале они также должны обладать обширными бизнес-знаниями, чтобы понимать, как работают процессы, каковы ключевые проблемы, которые помогают бизнесу расти и быть прибыльным. И они должны быть опытными переводчиками, способными преодолеть пропасть между потребностью, функциональным решением и технологией, которая ее решает. Они частично аналитики, частично знакомые, частично писатели и почти всегда являются авторами подробных документов с функциональными и техническими требованиями, на которые полагаются разработчики и программисты. [1] Иногда эти аналитики-коммуникаторы-писатели также являются идеальным человеком для ведения документации и обучения - это то, что он делает, как это работает и почему - потому что они уже досконально знают бизнес-проблемы и решения и в полной мере способны сформулировать и объяснить их людям, с которыми они уже построили отношения.

(D) Разработка / программирование. В начале большинства технологических циклов все кодируется индивидуально, поскольку пакетов с графическим пользовательским интерфейсом еще не существует. Раньше это было верно для статистики; однако теперь MATLAB, Minitab, SAS и SPSS являются лидерами в графических пакетах, которые позволяют специалистам по обработке данных получать гораздо более быстрые и точные результаты с гораздо меньшими затратами драгоценного и дорогостоящего времени на программирование или отладку кода. На мой взгляд, те, кто использует графические инструменты для разработки программного обеспечения, являются разработчиками, а те, кто программирует на языках, - программистами. В науке о данных переход от пользовательского кода к графическому программному инструменту находится на полпути. Конечно, есть графические решения, в том числе упомянутые выше, которые быстро справляются со своей задачей и могут быть настроены с помощью кода, но часто в этом нет необходимости; однако для специализированных приложений все еще есть достаточно веские аргументы в пользу использования специального кода с программистами - обычно на Python или R, в зависимости от того, является ли это общим приложением, в котором необходимы другие функции, или чисто наукой о данных и статистикой, соответственно. Сегодня, вероятно, все еще необходимо иметь оба набора навыков в вашей команде. Даже если кто-то использует автоматизированные инструменты машинного обучения нового поколения, такие как Data Robot, который может параллельно сопоставить десятки популярных моделей и алгоритмов машинного обучения, экономя месяцы на догадках и трудоемком построении моделей - лучший алгоритм все равно должен быть построен в индивидуальном порядке. производственная среда. Разработчики и программисты - это люди, которым подробно рассказывают, как.

(E) Обработка данных - «Только 3% данных компаний соответствуют основным стандартам качества», - обнаружили три исследователя в 2017 году (Nagle, 2017). Эта проблема достоверности данных принимает разные формы - «грязные данные», которые могут быть неправильно классифицированы, неверно идентифицированы или просто неверны - отсутствующие данные или, возможно, наиболее тревожные - данные, которые кажутся правильными; однако определяется по-разному. Он создает входной канал для контроля качества, который требует обеспечения максимальной точности данных, прежде чем они будут использованы для анализа данных или инженерных процессов. Несмотря на то, что существуют стратегии работы с отсутствующими данными - удаление записей, вставка среднего или медианного значения для оставшихся данных, удаление выбросов, которые в 2,5 раза превышают среднее значение отсутствующих элементов данных, это наверняка требует времени - важно знать, как и когда использовать каждый. В идеале этот человек, вероятно, должен иметь большой опыт извлечения, преобразования и загрузки (ETL) данных в разных системах, а также должен хорошо понимать словарь данных и определения, которые использовались и используются в каждой среде. Эта проблема умножается, когда компании объединяют себя или системы, потому что у каждого объекта часто была своя собственная система данных и определения, и их согласование является предпосылкой для целостных и общекорпоративных проектов по науке о данных. Инженеры по обработке данных - неоценимые партнеры в детальном «как», на котором сосредоточены разработчики и программисты.

(F) Обеспечение качества / тестирование. Возможно, эта функция наиболее часто игнорируется в группе специалистов по анализу данных. однако это критично. В традиционном жизненном цикле разработки программного обеспечения тестировщики изучают функциональные требования и проверяют, выполняет ли решение то, для чего оно предназначено. Затем они пытаются сломать его, делая странные вещи, которые делают пользователи, или загружают слишком много данных для стресс-тестирования. В развитии науки о данных это приобретает дополнительное значение из-за статистики и математики, которые должны быть правильными, чтобы получать ценные ответы и прогнозы. В противном случае компания буквально вкладывает сотни тысяч или миллионы долларов в сверхэффективную машину, генерирующую неправильные ответы, которая больше дезинформирует и вводит в заблуждение, чем информирует и дает возможность. Сделайте это один раз, и недоверие, которое это вызывает, может быть не преодолено поколением корпоративных лидеров. С точки зрения тактического подхода к обеспечению качества они критически отвечают на такие вопросы, как: работают ли инструменты анализа данных на нескольких поколениях данных (часто не учитываемых при обучении), были ли корреляции или ассоциации неправильно объединены с причинно-следственной связью, использовался ли статистический инструмент, который предполагаемые нормализованные распределения данных для ненормализованных данных, являются ли данные несбалансированными, вызывая правые или левые наклонные распределения, являются ли типы данных неправильно смешанными в методах (например, непрерывный, по сравнению с категориальным и т. д.). Если команда сказала мне, что они потратили 33% времени проекта на анализ и дизайн, 33% на разработку и 33% на QA / тестирование, это показалось мне разумным и правильным распределением затраченного времени и ресурсов.

2. Разнообразие и широта данных - с чего начать - Донская свадьба, один из моих блестящих профессоров прогнозной аналитики в Северо-Западном университете и бывший технический руководитель в Институте SAS, приводит аналогию, чтобы передать импортировать эффективность машинного обучения во многом в зависимости от отправной точки. Если вы спросите алгоритм машинного обучения, какова наивысшая точка на Земле, и начнете он методом грубой силы, проб и ошибок, начиная с Аляски, он может сказать, что это гора Мак-Кинли. Если он начинается в Азии, это может быть гора Эверест. Если он начинается в Долине Смерти, это может быть ободок норы местной прерийной собачки. Результаты были очень хорошими, идеальными и очень плохими соответственно (Wedding, 2017).

Аналогичная проблема возникает в приложениях науки о данных к геномике. Большинство используемых сегодня геномных баз данных или биобанков представляют собой образцы кавказцев западноевропейского происхождения. Точно так же, как обнаружение мошенничества в розничной торговле ищет отклоняющиеся поведенческие данные, в приложениях геномного машинного обучения варианты - это главное. Каков нормальный геномный след и когда, где и почему что-то отличается от этого нормального следа? Следовательно, если данные не относятся к разнородной популяции с выборкой, соответствующей популяции, когда алгоритм ML идентифицирует «отличие» варианта от нормы, чтобы указать на болезнь, устойчивость и т. Д., Вполне может быть, что вариант от недопредставленное меньшинство в наборе данных, что делает это предположение ошибочным. Все это означает, что широта и разнообразие данных в инженерной части проекта по науке о данных являются ключевыми, в противном случае технология просто дает вам вводящий в заблуждение ответ более эффективно и ложную уверенность.

3. Поймите основную контекстуальную проблему (ы). Дону Веддинг также приписывают концепцию «аналитического оборотня», то есть тех вещей, которые являются более глубокими проблемами, которые заставляют компании полагать, что они должны заниматься наукой о данных или машинным обучением, чтобы «Убей оборотня» (Свадьба, 2017). Профессор Веддинг, который также является ведущим специалистом по анализу данных в компании Fortune 500, на основании своего значительного опыта высказал мнение и учил, что: (а) интерес к машинному обучению часто может указывать на отсутствие аналитических или статистических данных. талант, ограниченные навыки работы с SAS или устаревшими инструментами, неадекватные вычислительные мощности или модели или проблемы с качеством данных; и, (b) клиенты часто используют науку о данных или инициативу машинного обучения в качестве «серебряной пули» для обеспечения привлечения профессиональных консультантов для устранения своих аналитических пробелов, увеличения инструментов и / или обучения, обновления программного обеспечения, увеличения вычислительной мощности (например, переход в облако или более мощные процессоры или больший объем памяти, переход к архитектуре распределенных вычислений, более высокая пропускная способность базы данных и т. д.), реорганизация архитектур баз данных или любая комбинация. Эти основные потребности, мотивы и решения вовсе не обязательно плохие; однако при формировании инициативы в области науки о данных или машинного обучения важно контекстуализировать круговую диаграмму мотивов и причин, по которым наука о данных рекомендуется или желательна. Вы не можете предложить эффективные решения, не зная о проблемах.

4. Это работает? - Мы, специалисты по анализу данных, много фанатиков. Торговые журналы, не говоря уже об академических рецензируемых журналах, полны статей, основанных на загадочном жаргоне, касающемся настройки этого алгоритма процесса или этой формулы для более точного прогнозирования 0,01 или чрезмерных или недостаточных исправлений для достижения постепенно лучших результатов. Несомненно, эти чисто исследовательские статьи важны для развития этой области. Например, если кто-то работает в развивающейся области ИИ, применяемой в медицине, и, возможно, именно поэтому мы живем намного дольше, чем наши предки (или нет), постепенное повышение точности чтения изображений или прогнозирования заболеваний может увеличить продолжительность жизни. для тысяч людей; однако в бизнесе большая часть окупаемости инвестиций в науку о данных (ROI) проще. Если решение для науки о данных увеличивает прибыльность больше, чем его стоимость, упрощенная, это успех. В частности, если решение для науки о данных может повысить прибыльность, сегментацию, привлечение клиентов, прогнозирование поведения, удержание или предпочтение клиентов более чем на 10%, это, вероятно, большой успех. Если он сможет делать это более чем на 10% многократно в каждой области, это, вероятно, сделает вас лидером ваших конкурентных пространств.

5. Будут ли они использовать это? - Ответ на этот вопрос может во многом зависеть от его объяснимости широкой аудитории и уровня их доверия (Gray, 2017). В отношении AI-ML стороны науки о данных (в отличие от статистической) есть немного грязный секрет, о котором не раз писали в технической прессе (Knight, 2017). А именно, когда ML включает в себя обучение без учителя, может быть трудно установить, как модель получила свой ответ, и из-за этой необъяснимости общее руководство и непрофессиональные пользователи могут не доверять ей. Представьте, если бы алгоритм машинного обучения без учителя предсказал, что у вашего нового ребенка через 20 лет разовьется болезнь, которая может резко сократить его / ее продолжительность жизни. Следовательно, их гены должны быть немедленно отредактированы после рождения, чтобы попытаться предотвратить болезнь; тем не менее, такое редактирование генов может иметь непредвиденные последующие последствия, которые могут вызвать другие проблемы. Ты это сделаешь? Ответ, вероятно, во многом зависит от того, понимаете ли вы, почему алгоритм это предсказал. При отсутствии этого доверия к результату / прогнозу лица, принимающие решения, испытывают аллергию на то, чтобы действовать в соответствии с ним. Используя статистику и даже контролируемое обучение, стороны науки о данных, мы можем объяснить лицам, принимающим решения, почему машина сделала такой прогноз или открытие; с неконтролируемым машинным обучением, где оно обучается само по себе, при отсутствии цикла обратной связи, объясняющего, что он сделал с людьми, мы часто не знаем, как оно пришло к своему выводу. Верить или не верить.

Ансамбли - ключ к успеху

Наконец, будущее науки о данных и машинного обучения, возможно, заключается в объединении моделей и подходов в ансамбли, которые превосходят по производительности отдельные приложения. То же самое и с успешными проектами в области науки о данных. Самый успешный подход может не максимизировать ни одну из пяти вышеупомянутых основных причин или драйверов, но дать наивысшее среднее или среднее значение по всем пяти. Например, клиенты могут доверять - и поэтому использовать - многомерный куб оперативной аналитической обработки (OLAP), который сегментирует клиентов графически таким образом, чтобы они могли понять больше, чем k-средние или самоорганизующаяся карта, даже если последняя подходы более сложные, точные и автоматизированные. Точно так же лучший подход машинного обучения для определения причинных элементов и встраивания их в прогнозирующую модель может быть деревом решений, за которым следует автоматическое сравнение прогнозирующей модели с помощью Data Robot; однако, если у команды нет этих инструментов, а вместо этого есть эксперт по программированию Python в TensorFlow или экземпляр Minitab, который может производить логистическую регрессию (часто почти так же хорошо, как ML), это баланс, который вполне может выиграть день.

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

Стиву Джобсу приписывают то, что может быть окончательным ключом к успеху в применении этих междисциплинарных и специализированных областей, которые становятся повсеместными в 21 веке - возможно, по иронии судьбы, потому что у него было ограниченное формальное образование - в объяснении огромного долгосрочного инновационного двигателя Apple Computers: «Большинство компаний нанимают умных людей, а затем говорят им, что делать, мы нанимаем умных людей и позволяем им говорить нам, что делать».

Эрик Луеллен руководит проектами разработки программного обеспечения в области прогнозной аналитики во всем мире с 1997 года, имеет степень магистра информатики Северо-Западного университета, где в его диссертации были разработаны новые подходы к ансамблевому машинному обучению для прогнозирования на основе изображений высокой размерности. глобальный финалист премии Stanford MedX C3 2016 и World Technology Award в 2017 г.

Процитированные работы

Асаи, М. (12 июля 2017 г.). 3 способа массового провала машинного обучения (и один ключ к успеху). Tech Republic, стр. https://www.techrepublic.com/article/3-ways-to-massively-fail-with-machine-learning-and-one-key-to-success /.

Грей, К. (20 июля 2017 г.). AI может быть неприятным товарищем по команде. Harvard Business Review, стр. https://hbr.org/2017/07/ai-can-be-a-troublesome-teammate.

Найт, W. (2017, 11 апреля). Темный секрет в основе искусственного интеллекта. MIT Technology Review, стр. https://www.technologyreview.com/s/604087/the-dark-secret-at-the-heart-of-ai/.

Нэгл, Т., Редман, Т., Сэммон, Д. (11 сентября 2017 г.). Только 3% данных компаний соответствуют основным стандартам качества. Harvard Business Review, стр. https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards.

Редман, Т. (15 июня 2017 г.). Ваша компания знает, что делать со всеми своими данными? Harvard Business Review, стр. https://hbr.org/2017/06/does-your-company-know-what-to-do-with-all-its-data.

Редман, Т. (26 января 2017 г.). Лучшие специалисты по обработке данных выходят и разговаривают с людьми. Harvard Business Review, стр. https://hbr.org/2017/01/the-best-data-scientists-get-out-and-talk-to-people.

Редман, Т. (25 января 2018 г.). Вы настраиваете своих специалистов по данным на провал? Harvard Business Review, стр. https://hbr.org/2018/01/are-you-setting-your-data-scientists-up-to-fail.

Тейлор, Б. (2017, 16 октября). Почему большинство проектов ИИ терпят неудачу. Блог Data Robot, стр. https://blog.datarobot.com/why-most-ai-projects-fail.

Терещенко, М. (9 декабря 2017 г.). Создание кросс-функциональной команды, когда ML-as-a-Service не работает. Получено из DZone: https://dzone.com/articles/building-a-cross-functional-team -когда-мл-как-серв

Веерамачанени, К. (7 декабря 2016 г.). Почему вы не получаете пользы от своей науки о данных. Harvard Business Review, стр. https://hbr.org/2016/12/why-youre-not-getting-value-from-your-data-science.

Уокер, Дж. (23 ноября 2017 г.). Стратегии больших данных разочаровывают тем, что процент отказов составляет 85 процентов. Получено из цифрового журнала: http://www.digitaljournal.com/tech-and-science/technology/big-data-strategies-disappoint-with-85-percent-failure-rate/article/508325#ixzz5JvGk3AV0

Свадьба, Д. (2017). Прогностическое моделирование. (Д. Веддинг, исполнитель) Северо-Западный университет, Эванстон, Иллинойс, США.

[1] Хотя это обычная идея, пропускать эти трудоемкие шаги, команды делают это на свой страх и риск, потому что они закладывают основу ожиданий, функций и цели проекта. В идеале, по мнению автора, они должны быть полностью завершены, после чего начинается процесс быстрой разработки приложений (RAD), когда команда уходит, возвращается через 30 дней и спрашивает: Вы это имели в виду? и проект решения редактируется для следующего 30-дневного цикла проверки. Продукт за 2–3 коротких цикла часто экспоненциально лучше, чем один длинный цикл разработки.