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

Всем привет! Эта статья - обобщение моего опыта 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-кейсы, проводите демо панелей управления, мониторинга, отчетов, датасетов и т.п. 

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