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