35 реальных рисков, убивающих data- и machine learning проекты

в 13:47, , рубрики: big data, data engineering, машинное обучение, провал проекта, риск, риск-менеджмент, риск-ориентированное мышление, риски, риски в проектах, риски иб, риски программных проектов, Управление продуктом, управление проектами

Всем привет! Эта статья - обобщение моего опыта 30+ проектов, связанных с обработкой данных и машинным обучением. Здесь не будет теории про управление рисками и общего перечня проектных рисков. Я перечислил только наиболее частые “грабли” именно из data-специфики, с которыми приходилось сталкиваться за последние 7 лет. Надеюсь, что эта статья поможет менеджеру проекта или менеджеру продукта сохранить свой цвет волос, ценное время команды и удовлетворенность заказчиков. Риски я разделил на три группы:

  • риски моделей машинного обучения,

  • риски источников данных,

  • риски пользовательских данных.

Риски моделирования

  • Нет гарантий, что удастся добиться удовлетворительного качества ML-моделей в отведенное время. Ни объективно - в сравнении с baseline, ни субъективно - по мнению заказчика. Это может быть серьезной угрозой для проекта. По возможности, всегда нужно проводить Discovery фазу или начинать с Proof of Concept, чтобы доказать реализуемость и найти baseline. Также важно ориентировать заказчика на долгосрочную стратегию постоянных улучшений. Большинство заказчиков по прежнему  ожидают попадания с первого выстрела.

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

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

  • Недостаточное качество данных может привести к недостаточному качеству ML-моделей. Перед началом разработки модели рекомендуется провести тщательное исследование данных и составить отчет для заказчика с обозначением всех находок и рекомендациями.

  • Регулярности в данных может и не быть. Регулярность в данных - главный фактор качества ML-моделей. Во-первых: регулярности в данных может не быть. Это сделает проект не выполнимым. Во-вторых: сильные внешние события могут кардинально поменять паттерны в данных и привести к падению качества моделей. 
    Например, локдаун принципиально изменил характер трафика. Настолько, что время “до” нельзя было даже использовать для обучения.   

  • Неверно выбранный baseline для сравнения с ML-моделью. Baseline нужен, чтобы можно было посчитать добавленную ценность от внедрения ML-модели. От сравнения результатов модели и baseline может зависеть решение об успешности всего проекта. На мой взгляд наиболее честно - выбрать в качестве baseline тот подход, который использовался “до” внедрения модели. Важно  Еще бывает необходимо оценить конкретную ML-модель, а не целиком внедренную систему. Тогда в качестве дополнительных baseline можно использовать, например,  random-модель, dummy-модель или rule-based подход. Важно не только правильно выбрать baseline, но и сформировать правильные ожидания у заказчика. Какой процент улучшения будет считаться хорошим?

    Пример из практики: Разрабатываемая платформа с системой продуктовых рекомендаций должна была заменить “ручные” рекомендации, сделанные экспертами. За бизнес-baseline выбрали текущий экспертный подход, за технический для оценки модели - случайные рекомендации. Оказалось, что случайные рекомендации работают лучше, чем экспертные 😱. Если бы бизнес-результат оценивали в сравнении с random, он выглядел бы меньше, чем в реальный эффект от внедрения.  

  • Некорректное разделение аудитории при AB-тестировании. При тестировании нескольких моделей и подходов важно правильно разделить аудитории. Сегменты должны быть сравнимого объема и равноценны по паттерну данных. Иногда это сделать сложно. Например, трафик на сайте делится на анонимных и авторизованных пользователей. Если модель работает только для авторизованных клиентов, то нельзя сравнивать ее работу с другим подходом на всей аудитории. Нужно разбивать на AB-сегменты только авторизованную аудиторию, а анонимную - рассматривать отдельно. Когда нужно протестировать 10 алгоритмов со своими особенностями могут начаться сложности разделения аудитории.

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

  • Ожидания заказчика насчет интерпретируемости ML-моделей Бывает, что для заказчика важнее интерпретируемость результатов, чем точность модели. Это частое явление, когда инновации внедряются в важные бизнес-процессы компании. Важно заранее выяснить, готов ли заказчик слепо доверять ML-модели или будет требовать обоснования принятых ею решений. Иначе можно создать совсем не ту модель, потерять время, демотивировать команду дата-саентистов, нарваться на отказ заказчика при переходе в продакшен.  

  • Требования к производительности ML-модели. Часто бывает, что более точные модели имеют сложную архитектуру и реализацию, поэтому требуют гораздо больше времени на обучение и инференс. А иногда и принципиально другого оборудования. Если не выяснить временные и технические ограничения вначале, можно разработать супер-красивую, сложную и точную модель, которая никогда не будет внедрена.   

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

  • Дата-саентист может сделать неверные предположения и неправильно интерпретировать данные. Если не убедиться, что дата-саентист на 100% понимает смысл каждого поля в данных, поставленную задачу и оптимизируемую величину, это с самого начала может увести проект в другую сторону.    

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

  • Ручное управление жизненным циклом модели Я часто встречался с экономией на автоматизации процесса управления жизненным циклом моделей. Эти затраты сложно обосновать “бизнесу”, так как они не влияют напрямую на результат. Отсутствие автоматизации управления, тестирования, валидации, тренировки, инференса, бэкфила приводят к регулярным монотонным ресурсоемким ручным операциям.  Это отнимает кучу времени, тормозит развитие продукта и демотивирует команду.

  • Отсутствие или искажения в цепочке обратной связи Для улучшения ML-моделей важен автоматизированный процесс объективной обратной связи. Когда мы узнаем, успешна модель в конкретном случае или нет. Отсутствие замкнутой цепочки backloop может привести к отказу при приемке проекта или невозможности развития решения. 

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

  • Готовность заказчика к запуску ML-модели. Бывает, что, несмотря на доказанную тестами эффективность модели, заказчик не готов согласовать внедрение в продакшен. Наиболее частая причина - отсутствие доверия и страх нарушить важные для бизнеса процессы. Идентифицировав этот риск на раннем этапе менеджер может предложить следующие варианты:

    • постепенный поэтапный вывод модели в продакшен

    • функционал “ручного” управления в критичной ситуации  

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

    Примеры:  

    • Модель выдает рекомендации только по 1% аудитории   

    • Модель определяет только 1% случаев фрода.   

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

  • Некоторые ML-модели могут потребовать применения специального оборудования. Например, серверы с GPU. Перед  стартом разработки таких моделей убедитесь, что у вас будет доступно необходимое оборудование.  

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

    Примерный список ролей:

    • Архитектор - отвечает за выбор технологий, проектирует систему, принимает технические решения

    • Дата-инженер - отвечает за интеграции и все дата-пайплайны

    • Девопс - отвечает за инфраструктуру, CI/CD, мониторинг

    • Дата-саентист - разрабатывает модель

    • ML-инженер - продуктивизирует модель

    • Эксперт в предметной области - принимает участие в разработке модели

    • Бизнес-аналитик / консультант - берет на себя формулирование требований, играет роль эксперта для инженерной команды 

    • Менеджер - отвечает за проект и команду

Риски источников данных

  • Отсутствие subject-matter expert (SME) по конкретному источнику данных. Если вы работаете с неизвестным ранее источником данных, наличие эксперта по этим данным крайне важно. Без него исследование источника данных может потребовать значительное время команды и даже привести к непоправимым ошибкам в будущем. Не стоит также полагаться на документацию. Как правило она содержит устаревшую информацию.

  • Предоставление доступа к источнику данных может сильно затянуться. В крупных компаниях предоставление доступов к источникам данных может представлять длительный и многоэтапный процесс с чередой согласований, препятствий, политикой и т.п. Получить доступ к данным - первая задача менеджера. После понимания ценности, целей и приоритетов, конечно. И это не должно сводиться просто к перекладыванию ответственности на заказчика. Лучше сделать все возможное для получения доступа к данным на начальной стадии проекта, чем потом спорить “кто виноват” при обсуждении сдвига сроков.
    Лайфхак: если чувствуете, что предоставление доступа к данным может затянуться, обязательно просите разовые выгрузки, чтобы команда могла начать работать. Однажды мы получили доступ к источнику данных, когда 3/4 проекта уже прошло.  

  • Данные на TEST и PROD окружениях источников могут отличаться. Иногда команде предоставляется доступ только на тестовое окружение источников данных. Нужно очень внимательно изучить, как происходит копирование данных с PROD на TEST. Какие преобразования производятся при этом? Выводы, сделанные после исследования данных на TEST-окружении, могут быть неверными для PROD-данных. Особенно это относится к исследованию данных с целью построения data-quality или ML-моделей.
    На одном из проектов данные TEST-окружения были уменьшены без соблюдения случайности, баланс классов для обучения модели был нарушен. В результате на PROD-данных на этапе стабилизации мы в авральном режиме переобучали деградировавшую модель и почти удвоили количество data quality проверок. 

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

  • “Неожиданные” планы по развитию источника данных. Вывод из эксплуатации, миграции, обновления, рефакторинг, резкое увеличение объемов данных, изменения в политике хаускипинга и глубины данных. Если не обсудить планы развития источника хотя бы на полгода - год, можно ждать сюрпризов. 
    Примеры из практики: 1. Через три месяца после вывода в PROD интеграции с источником данных, объем поступающих в него данных вырос в 20 раз. Пришлось очень оперативно дорабатывать ingestion, рефакторить хранилище, добавлять хаускипинг. 2. Через полгода успешной эксплуатации ML-модели в один день вдруг резко упало качество. Паттерны в данных за последние периоды не поменялись сильно. Мы не могли понять, в чем причина. Потом обнаружили, что в одном из ключевых источников просто удалили прошлые несколько лет данных. Эти данные использовались у нас для обучения модели. Оказалось, что это регламентная операция, которая происходит раз в год :( 

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

    Скрытые технические ограничения, которые мы встречали на проекте:

    1. Нельзя было считывать данные из БД более чем в 10 потоков. Все дополнительные потоки отрубались.

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

    3. Источник за один запрос возвращает максимум 300 точек из time series датасета. Если за указанный период в датасете окажется больше точек, то они будут семплированы.

  • Глубина обновления данных в источнике. Хорошо, если у источника есть ключи, по которым явно можно определить факт обновления данных и организовать инкрементальный обмен. В другом случае нужно обязательно обращать внимание, за какое время “назад” могут обновляться данные в источнике. Причем эта характеристика может варьироваться. Например,  ежедневно за 3-4 дня “назад” и каждое последнее число месяца - за 10 дней “назад”. Ошибки при интеграции приводят к рассинхрону в данных и ошибкам в последующих вычислениях. 
    Пример из практики: Статистика в Google Adwords обновлялась в реальном времени, но при этом могла уточняться в течение нескольких дней. Экспериментально мы установили максимальную глубину обновления - 20 дней. Т.е. каждый день нужно было подтягивать данные за последние 20 дней.  

  • Источник данных может обновить данные “целиком”. Это может быть свойственно различным датасетам в корпоративном DWH, MDM-системам и т.п. Готовы ли ваши инкрементальные ETL/ELT инструменты однажды полностью перезалить данные из источника, не свалившись и не нарушив SLA? Возможно, имеет смысл встроить проверку на количество обновленных записей для загрузки или выстроить организационный процесс, когда дата-оунеры  будут уведомлять вашу команду о таких случаях. 

  • Качество данных обязательно будет хуже любых ожиданий. Этот риск срабатывал в 90% всех дата-проектов. Необходимо уделять время на исследование данных, разрабатывать компоненты по обработке данных с учетом data-quality проверок и логирования ошибок. Чистота данных - залог правильно работающей ML-модели. Качество ML-модели очень часто определяет бизнес-ценность разрабатываемого решения.

    Вот наиболее частые ошибки в данных:

    1. Непечатные символы в строковых полях
    2. Несоответствие типа данных ожидаемому
    3. Отсутствие данных в обязательном поле
    4. Отсутствие ожидаемого столбца
    5. Несоответствие данных ожидаемому диапазону значений
    6. Запятая в строковом поле в CSV-файле
    🤦‍♂️
    7. Пропуски/нули в time-series данных
    8. Резкие спайки в time-series данных (например, когда мониторинг агент долго не считывал данные метрики и не обнулял ее счетчик, а потом считал)

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

    Примеры изменения паттерна в данных:  

    • приемка проекта с ML-моделями совпала с сезонным всплеском пользовательской активности (Рождество, Новый год).  

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

    • неожиданно и необъяснимо активность Google bot на сайте резко возросла. В результате трафик на сайте и все метрики выросли в несколько раз, исчезли ранее найденные закономерности.

    • компания выпускает новую версию веб-сайта или мобильного приложения. Это привело к изменению паттерна поведения пользователей.

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

    Примеры из практики:  

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

    • Команда веб-сайта не поддерживала встроенный JS-код для трекинга. Как результат - постоянные сбои в потоке пользовательского трафика с сайта из-за изменения верстки веб-страниц. 

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

    Примеры из практики:  

    • Дискретность метрики “5 минут” не позволяет определить пиковую нагрузку на сервис “в моменте” 

    • Агрегация пользовательского трафика не позволяет анализировать цепочку событий каждого пользователя.  

Риски пользовательских данных

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

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

    • ПД должны быть в отдельном хранилище/сервисе, который должен находиться в защищенной зоне 

    • ПД должны быть хэшированы/зашифрованы специфичным алгоритмом 

    • Все запросы к ПД должны логироваться  

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

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

    Грабли, на которые наступали:  

    • Изменения  “золотой записи” (объединение, разделение) приводили к аномалиям в исторических данных

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

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

  • Задача идентификации клиента и его сопоставления с принятым понятием “профиль” может быть не тривиальна. Что считать профилем: домохозяйство, человека, браузер, устройство, все вместе?

    Примеры из практики:

    • С одного девайса люди авторизуются в вашем сервисе с разными логинами. Можно ли использовать cookie для идентификации клиента? Считать ли разные логины одним клиентом (например, семью)?

    • Китайские телефоны имеют динамические MAC-адреса. Можно ли использовать MAC для идентификации? 

И последний риск на сегодня:

  • Недостаточное понимание заказчиком сложности и особенностей дата-проекта. Как правило система, которая появляется в результате, почти не имеет интерфейса. Поэтому с точки зрения заказчика и пользователя почти невозможно “пощупать” и визуально оценить проделанную работу. Дата-проекты похожи на айсберги, у которых 90% работы скрыто от глаз. Это может быть причиной организационных проблем в проекте. Заказчик может нервничать, перестать доверять команде и т.п. Поэтому менеджеру рекомендуется визуализировать все, что можно. Показывайте презентации о прогрессе, скетчи архитектуры, компонентную архитектуру, потоки данных, визуализируйте use-кейсы, проводите демо панелей управления, мониторинга, отчетов, датасетов и т.п. 

Я искренне желаю удачи всем менеджерам проектов и продуктов. Всегда стремитесь к большему, берегите команду, уважайте заказчика. 

Автор: Александр Большаков

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js