Введение
Наука, связанная с обработкой данных, продолжает волновать людей, однако реальные результаты нередко вызывают разочарование у заинтересованных бизнесменов. Как мы можем снизить риски и обеспечить соответствие результатов ожиданиям? Работа в качестве технического специалиста на стыке НИОКР и коммерческих операций дала мне представление о проблемах, которые стоят на этом пути. Я представляю свою личную точку зрения на наиболее распространённые виды провалов и неудач проектов, связанных с информатикой.
Полная версия со слайдами и поясняющим текстом имеется здесь. Слайды есть также отдельно в ПДФ-файле.
Есть также некоторое обсуждение на Hacker News.
Сначала несколько слов обо мне:
Руководил группами специалистов по теории и методам анализа данных в двух стартапах в Лондоне.
Разработанные продукты используются компаниями Time Inc, Staples, John Lewis, Top Shop, Conde Nast, New York Times, Buzzfeed и т.д.
Настоящий пост базируется на обсуждениях, которые я вёл со многими ведущими специалистами по обработке данных в последние несколько лет. Многие компании, кажется, проходят через общую схему найма команды специалистов по обработке данных только для того, чтобы примерно через 12 месяцев спустя бросить дело или распустить всю эту команду. Почему же количество неудач так велико?
Давайте рассмотрим причины.
1. Ваши данные не готовы
Если данные находятся в базе данных, то их можно использовать, правильно?
Но можно предположить, что это просто мусор, если их не использовали ранее.
Проверяйте данные.
Весьма мудрый консультант по обработке данных сказал мне, что он всегда спрашивает, использовались ли данные ранее в каком-либо проекте. Если нет, то он добавляет 6-12 месяцев на работы по очистке данных.
Проверьте данные, прежде чем начать. Проконтролируйте данные на полноту и загрязнённость. Например, может обнаружиться, что база данных содержит разные операции, сохранённые в долларах и иенах без указания валюты. Подобное, действительно, случается.
2. Нередко слышно: «Обработка данных — это новая нефть»
Но это не так. Данные не являются товаром; они должны быть преобразованы в некоторый продукт, прежде чем приобретут какую-то ценность. Многие собеседники рассказывали мне о проектах, которые запускались без какого-либо представления, кто будет их пользователем или как использовать их «ценные данные». Ответ приходил, как правило, слишком поздно: «никто» и «никак».
3. Ваши специалисты по работе с данными подумывают об уходе
Могли бы вы прислать мне рабочее задание?
Что вы разрабатываете в настоящее время?
Вообще-то, я только что получил доступ к R и Python! Буквально 5 минут назад.
Не создавайте проблем вашим специалистам, не обеспечивая им доступа к данным и инструментам, требуемым для нормальной работы. Старшему научному сотруднику из переписки выше понадобилось шесть недель на получение разрешения установить Python и R. Он был счастлив!
Увы, счастье было недолгим:
Вы, должно быть, шутите…
Вот оно.
Эта программа заблокирована по требованиям групповой политики. За дополнительной информацией обращайтесь к вашему системному администратору.
Теперь позвольте представить этого парня:
Он был менеджером по продукту на сайте интернет-аукциона, о котором вы, возможно, слышали. Его рассказ был об A/B-тесте нового алгоритма прототипа для главной поисковой машины продуктов. Тест был успешным, и новый алгоритм пошёл в дело.
К сожалению, после того как прошло много времени и было потрачено много денег, выяснилось, что в коде A/B-теста имелась ошибка: прототип не был использован. Они случайно проверили старый алгоритм на собственных данных. Результаты оказались бессмысленными.
Это была проблема:
Вы не будете знать, что результаты представляют собой мусор.
Ошибка выборки, смещение измерения, парадокс Симпсона, статистическая значимость и т.д.
НИОКР — непростое дело
4. У вас нет специалиста-лидера по обработке данных
Вам нужны люди, которые живут и дышат ошибкой выборки, смещением измерения и подобными вещами — или вы никогда не узнаете, что ваши результаты не имеют смысла. Таких людей называют «учёными».
Да, кстати.
Этот человек не является ни «учёным», ни специалистом по обработке данных:
«Руководитель-аналитик, формирующий стратегию для управления информационными потоками, для средств бизнес-аналитики (BI) и для аналитических решений, направленных на организационное преобразование. Имеет опыт руководства командами при разработке решений корпоративного класса и максимизации стоимости бизнеса.»
А этого специалиста по обработке данных можно считать «учёным»:
«Специализация: вероятностное программирование, анализ данных, байесовское моделирование, скрытые Марковские модели, методы Монте-Карло с цепями Маркова (MCMC), рекуррентные нейронные сети (LSTM), многозадачное обучение, доменная адаптация.»
Также — противоположное утверждение очень часто является верным:
5. Вы не должны были нанимать учёных*
*См. пункт 3.
Для технологии ETL (извлечение, преобразование и загрузка данных) нанимайте специалистов по инженерии данных.
Для создания отчётов нанимайте специалистов по средствам бизнес-аналитики (BI).
Конец.
6. Ваш босс читает публикации в блоге по машинному обучению
Шумиха вокруг машинного обучения означает, что там есть много легкодоступного контента. Это может привести к явлению, которое можно было бы назвать «скороспелый эксперт»: теперь каждый имеет великие идеи по машинному обучению. Симптомом является использование таких словосочетаний как, например, «устранение расходимости» или «ансамблевый метод» в неподходящем контексте. Поверьте мне, подобное хорошо не кончается.
Ориентированный на экономию средств проект HealthCare использовал данные из больниц для обработки сведений о пациентах с симптомами пневмонии, поступавшими в приёмные отделения. Было желание создать систему, которая могла бы выявлять людей с достаточно низкой вероятностью летального исхода, благодаря чему их можно было бы просто отправлять назад домой, снабдив антибиотиками. Это позволило бы сосредоточить уход на наиболее серьёзных случаях, которые могли угрожать осложнениями.
Разработанная нейронная сеть имела очень высокую точность, но она, как ни странно, всегда отправляла астматиков домой. Это было необъяснимо, так как у астматиков на самом деле риск осложнений от пневмонии довольно высокий.
Оказалось, что астматиков, которые проявляли симптомы пневмонии, всегда направляют в отделение интенсивной терапии. Поэтому за интервал обучения нейронной сети не было ни одного случая смерти астматика. Модель в результате заключила, что у астматиков риск летального исхода чрезвычайно низкий, хотя в действительности ситуация обратная. Эта модель имела большую точность, но если бы её стали использовать, то это неизбежно привело бы к смерти людей.
7. Ваши модели слишком сложные
Используйте, прежде всего, поддающуюся объяснению модель.
Тестируйте, используя для сравнения некоторые базовые характеристики.
Мораль этой истории: используйте простую модель, которую вы можете понять. Только затем двигайтесь к чему-то более сложному и то, если в этом есть необходимость.
8. Ваши результаты не воспроизводятся
Git;
Анализ кода;
Автоматическое тестирование;
Обеспечение взаимодействия при конвейерной обработке данных.
Основой любой науки является воспроизводимость результатов. Делайте всё из указанного. И не говорите потом, что я не предупреждал вас.
9. Лаборатория, занимающаяся НИОКРом, чужда корпоративной культуре вашей компании.
Люди предпочитают интуицию.
НИОКР является областью деятельности с высоким риском.
Встречи в лаборатории, переговоры, публикации статей и т.д.
Лаборатория, занимающаяся прикладной наукой, накладывает серьёзные обязательства на компанию. Точные данные часто могут быть весьма опасными для людей, которые предпочитают доверять своей интуиции. НИОКР несёт в себе высокий риск неудачи и требует — как необходимое, но всё же недостаточное для успеха условие — необычно высокого уровня упорства. Спросите честно сам себя — ваша компания, действительно, принимает такую культуру?
10. Разработка информационных продуктов без опоры на реальные данные равносильна занятию таксидермией без наблюдения за живыми животными.
При подготовке какого-либо информационного продукта (даже некоторого макета) категорически не допускается разработка взаимодействия с пользователем и работа менеджеров по продуктам с использованием неподлинных данных. Как только на макете будут использованы реальные данные, может оказаться, что он является полной фантазией.
Реальные данные могут оказаться со странными выбросами или, наоборот, совершенно монотонными. Они могут проявиться как исключительно динамичные. Они могут быть полностью или трудно прогнозируемыми. Используйте реальные данные с самого начала, или ваш проект закончится в страданиях и ненависти к себе.
ссылка на оригинал статьи https://habrahabr.ru/post/317836/
Добавить комментарий