Меня зовут Павел Куницын, я работаю главным специалистом по анализу данных и машинному обучению в ПГК. На нашем примере расскажу, с какими трудностями мы сталкивались при внедрении ML-инициатив и как их преодолевали.
Решил написать серию статей. В первых статьях я подробно опишу проблемы, с которыми может встретиться DS-команда, чтобы помочь участникам проектов с машинным обучением проводить более грамотную предпроектную проработку. В дальнейшем поделюсь нашим опытом в решении некоторых из них.
В одном из своих выступлений Эндрю Ын (Andrew Ng), возможно, самый известный популяризатор deep learning, предложил концепцию Data-Centric AI (https://www.youtube.com/watch?v=06-AZXmwHjo). В отличие от ранее распространенного подхода (Model-Centric AI), согласно которому улучшение качества ML-решения достигается за счет совершенствования алгоритма, новая концепция ставит во главу угла постоянное совершенствование используемых данных.
Первая статья, которую вы сейчас читаете, — о препятствиях, которые могут возникнуть при работе с данными.
Процесс разработки моделей
Обычно последовательность операций, которые должны быть выполнены для создания алгоритма, выглядит так*:
*В этой схеме я намеренно оставляю только те этапы, которые традиционно входили в пул работ data scientist’а, и исключаю стадии проработки инициативы, формализации задачи, деплоя, тестирования, мониторинга и др. Они заслуживают отдельного внимания.
Как мы видим, загрузка и подготовка данных находятся в самом начале цепочки, следовательно, качество реализации этих стадий окажет прямое влияние на эффективность последующих. Ниже я раскрою основные проблемы первых двух этапов. Созданию признаков, обучению моделей и оценке качества будет посвящена отдельная статья.
Загрузка данных
Как известно, модели строят свои оценки на основании закономерностей в данных, выявленных в процессе обучения. Поэтому ML-конвейер всегда начинается с получения необходимого массива. К частым сложностям, с которыми может столкнуться data scientist на этой стадии, можно отнести:
1. Неожиданные изменения данных в источниках
Как показывает практика, данные — это очень подвижная субстанция. Много проблем в Data Science связано именно с изменениями данных: обновлением справочников и нормативов, изменением распределений или логики обработки, вводом новых категорий, ручной правкой и т.д. В большинстве случаев контроль версий этих данных отсутствует, и сами изменения происходят без уведомления пользователя. Учитывая, что стабильные и воспроизводимые конвейеры являются залогом высокого качества DS-решения, вопрос постоянства данных нужно всегда учитывать.
2. Отсутствие документации
Ситуация, когда у data scientist'а сразу есть информация о данных для анализа и обучения, возможна, наверное, только на хакатонах. На деле наименования столбцов в БД могут быть абсолютно нечитаемыми, а их описание — отсутствовать. В то же время зависимости в данных намного проще искать, понимая заранее, с чем вы имеете дело. К сожалению, эта проблема является повсеместной и отнимает очень много времени, поэтому, берясь за проект, обязательно имейте это в виду.
3. Большие объемы данных
Не всегда вычислительные ресурсы в распоряжении специалистов по машинному обучению соответствуют тем массивам, с которыми нужно будет работать. Можно также столкнуться с ограниченной пропускной способностью сети. Если вы отвечаете за проработку проекта, то обязательно обращайте внимание на то, с какими объемами данных вы будете иметь дело, чтобы адекватно оценивать ресурсы и определять подходящий целевой стэк.
4. Большое количество источников
Источники данных могут быть абсолютно разными: HDFS, S3, реляционная база данных или даже excel-файл на рабочем столе. Работа с одним таким источником через какой-нибудь API на Python сегодня уже не представляет сложности. Однако чаще информация распределена между различными хранилищами, и необходимо искать способы их агрегации. Другой классической проблемой, связанной с количеством источников, является расхождение данных по одним и тем же сущностям в разных системах.
Это доставляет огромное число неприятностей в машинном обучении, особенно, когда дело доходит до деплоя. Конечно, если в команде есть инженер данных, эти задачи перекладываются на него, но далеко не каждый проект укомплектован DE, и даже когда он есть, на выстраивание потоков данных обычно требуется время. Поэтому такие трудности регулярно становятся частью работы аналитиков.
5. Ошибки в ETL-процессах
Когда заходишь на проект, часть потоков данных, которые должны готовить датасеты для обучения, могут быть уже выстроены. При этом гарантии, что логика предварительной обработки соответствует задаче, никто не дает, и часто это вскрывается не на старте проекта, а когда он уже идет полным ходом. Опыт показал, что детальная проработка существующих потоков данных на первых порах может существенно снизить риски задержек проекта.
Подготовка данных
Сырые данные практически никогда не пригодны для моделирования, и именно эта стадия является самой трудоемкой. Здесь часто приходится тратить много сил на аналитику, процесс подготовки данных может отнять большую часть времени проекта. К основным преградам на пути к формированию чистых данных можно отнести следующие проблемы:
1. Низкое качество данных
В реальной жизни чистых данных не бывает. Даже если вам достался чистый, на первый взгляд, датасет, будьте уверены, что перед этим он мог пройти не одну итерацию обработки. К основным проблемам качества, на которые можно сразу проверить исходный массив, можно отнести:
Пропуски;
Дубликаты;
Аномально высокие или низкие значения;
Несоответствие типов данных;
Нарушение логики (например, отрицательное время или возраст).
Когда ошибка выявлена, нужно понять причину и устранить ее. К сожалению, этот процесс может растянуть срок реализации проекта на несколько недель.
2. Сложности в разметке данных
Большинство ML-алгоритмов обучаются на размеченных данных, т.е. используют исторические значения прогнозируемой величины (например, объем спроса или время в пути) в качестве ориентира при построении прогнозов. Здесь также кроются потенциальные сложности. Во-первых, разметки может просто не быть. Особенно часто это встречается в узкоспециализированных областях. Во-вторых, проведение разметки может требовать привлечения экспертов ввиду особенностей решаемой задачи. В-третьих, разметка может быть выполнена некорректно, что отразится на качестве модели в продуктивной среде. В результате эта задача может отнять очень много денег и времени.
3. Нехватка данных
Выше я писал, что большие массивы данных могут доставить неприятности. Возможна и обратная ситуация, когда данных слишком мало для выявления закономерностей и построения качественных моделей. Иногда не хватает только части данных, например, в случае дисбаланса классов в задачи классификации, когда прогнозируемое событие случается слишком редко. Как правило, чем больше исторических данных, тем более высокие результаты ожидаются. Но практика показывает, что не все ML-инициативы могут позволить себе такую роскошь, и часто приходится работать в ограниченных условиях.
4. Отсутствие бизнес-экспертизы
В каждой сфере бизнеса существуют устоявшиеся процессы, в том числе связанные со сбором, хранением и обработкой данных. Когда принимаешься за проект в новой для себя области, также сталкиваешься с незнакомыми профессиональными терминами и понятиями. Поэтому стоит быть готовым к тому, что в процессе подготовки датасетов у data scientist’ов будут регулярно возникать вопросы по предметной области.
Приведу пример из железнодорожной области. Одна из основных сущностей, с которой работают железнодорожники, — накладная. Это документ, который содержит сведения о грузе и особенностях перевозки, информацию по контрагентам, станциях отправления и назначения, дате прибытия вагона и т.д. В исторических данных можно встретить накладные, которые были закрыты не на станции назначения. В этом случае реальное время в пути может не совпадать с расчетным в накладной. Такие подводные камни нелегко интерпретировать, опираясь на классические способы анализа качества данных, и помочь может только знание отраслевых процессов.
Надеюсь, что учет трудностей, которые я перечислил, поможет вам избежать лишних проблем при подготовке данных для ваших алгоритмов и позволит сделать свои ML-решения качественнее и стабильнее. Если вы сталкивались с проблемами в загрузке и подготовке датасетов для анализа и моделирования, о которых я не упомянул, буду рад узнать о вашем опыте в комментариях.
Источник иллюстраций: Freepik.com
