Рис. 9.1. Выброс меняет поведение
деревьев решений, нужно смотреть документацию конкретного метода в каком виде представить категориальные переменные. Когда идет работа с категориальной переменной, у которой три и более значений, в большинстве случаев требуется ее разбить на несколько бинарных. Например, если есть переменная c тремя значениями: Да/Нет/Не знаю, то ее нужно разбить на три переменные (по числу значений). Можно назвать эти переменные по названию значений: Да, Нет, Не знаю. Каждая переменная будет принимать значение 0 или 1. Например, если у исходной переменной было значение «Да», то эти переменные примут следующие значения: Да = 1, Нет = 0, Не знаю = 0. Эта операция кодирования называется one-hot encoding. Выполнять ее необходимо потому что, в отличие от непрерывных числовых переменных, взаимоотношения между значениями переменных (больше или меньше) не определены, а значит, операция сравнения значений невозможна. Некоторые методы поддерживают категориальные переменные со множеством значений, например, catBoost от Яндекса. Есть еще один вариант кодирования динамичных категориальных значений, например слов текста, метод называется hashing trick. Он нужен, чтобы не заводить огромное количество переменных, когда число значений очень велико.
В работе с данными часто встречается ситуация, когда значения некоторых переменных пустые (missing data). В самих данных в зависимости от системы можно увидеть либо пустоту, либо одно из значений: None или Null. Для категориальных переменных эта проблема решается легко достаточно просто завести новое значение и назвать его «unknown». Для непрерывных числовых переменных это сделать сложнее нужно понимать, не кроется ли за пустыми значениями какая-то закономерность. Если выяснится, что закономерности нет, можно или удалить данные, или заменить их на среднее значение. Подробно про работу с потерянными данными можно прочитать в книге Эндрю Гельмана [66].
В задачах классификации, когда мы обучаем модель различать два класса, часто возникает проблема несбалансированности этих классов. Это бывает в медицине при тестировании населения и диагностике редких болезней если в датасете есть данные десяти тысяч людей и из них только десять заболевших, то алгоритму очень сложно обучиться. Другой пример датасет показа рекламных баннеров в интернете: показов много, а кликов мало. Проблема в том, что модели проще не замечать данные малого класса, а просто предсказывать больший класс, ошибка точности при этом будет приближаться к 100 процентам. Что с этим делать? В курсе по машинному обучению от Google [67] советуют с помощью сэмплирования (downsampling) уменьшить самый большой класс, но назначить этим строкам пропорциональный вес. Это даст быструю сходимость, так как малый класс будет больше влиять на обучение, а веса дадут возможность сразу использовать вероятность, которую мы получим на выходе, для классификации.
Точность и стоимость ML-решения
Чем точнее изготовление какой-либо детали на производстве, тем оно дороже. То же самое можно сказать и про машинное обучение. Когда создается первая версия решения, получаем одну степень точности (рис. 9.2). Потом тратится очень много усилий и времени на улучшение этого результата к сожалению, рост результата не пропорционален усилиям, которые были на него затрачены (правило Парето никто не отменял!). Мой опыт создания рекомендательной системы говорит, что затраты на каждый процент улучшения растут по экспоненциальному закону. То же самое можно увидеть и в соревнованиях Kaggle.
Рис. 9.2. Зависимость стоимости решения от его точности
Это можно учитывать, когда создается первая версия продукта. Не нужно гнаться сразу за сверхточностью, лучше выбрать приемлемую точность. Второй способ сделать, что получится, довести решение до рабочей системы, а уже затем решать, нужно бизнесу улучшать метрики или нет. Возможно, стоит потратить усилия на другой продукт, вместо того чтобы бесконечно полировать один а клиенты этого не заметят и не оценят по достоинству.
Простота решения
Уильям Оккам сформулировал принцип: «Что может быть сделано на основе меньшего числа [предположений], не следует делать, исходя из большего». Этот принцип экономности под названием «бритва Оккама» позволяет, например, выстроить цепь гипотез в порядке возрастания сложности, и именно этот порядок в большинстве случаев окажется удачным. Его также можно использовать при выборе ML-модели. Всегда лучше идти от простого к сложному, от линейных моделей к нелинейным, таким, как, например, нейронные сети.
Простота решения
Уильям Оккам сформулировал принцип: «Что может быть сделано на основе меньшего числа [предположений], не следует делать, исходя из большего». Этот принцип экономности под названием «бритва Оккама» позволяет, например, выстроить цепь гипотез в порядке возрастания сложности, и именно этот порядок в большинстве случаев окажется удачным. Его также можно использовать при выборе ML-модели. Всегда лучше идти от простого к сложному, от линейных моделей к нелинейным, таким, как, например, нейронные сети.
Почему чем проще, тем лучше? Кроме точности любой ML-модели, есть стоимость ее содержания. Она складывается из вычислительных ресурсов сложные модели требуют их больше. Специалисты для обслуживания сложных моделей требуются сильные, и у них выше заработная плата. И главное внесение изменений в сложную систему будет сложным, а это приводит к потере времени и денег. Мы в Retail Rocket при проверке гипотезы всегда следовали простому правилу: если есть две модели, которые по эффективности почти равнозначны, то выбираем всегда модель проще.
В некоторых алгоритмах ML есть опция получения значимости фич (features importances). Этот принцип можно использовать и при отсечении фич. Я уже писал про трактовку коэффициентов линейных моделей если они стандартизованы, то модуль (игнорируем знак) коэффициента говорит о силе вклада переменной в модель. Для нелинейной оценки можно воспользоваться алгоритмом Random Forests, чтобы получить значимость фич. Эти данные тоже можно использовать для отсечения фич. Чем меньше фич будет использовано в модели, тем проще ее будет поддерживать. От большего их числа модель становится только сложнее. И если отсечь наименее значимые фичи, не сильно потеряв при этом в точности, то выводить в рабочую систему такую модель будет проще. Дело в том, что каждая фича требует внимания, отдельных строк кода. За этим нужно следить, и если получится прийти от 20 к 10 фичам, то поддержка будет дешевле, а источников ошибок будет меньше.
Простота системы и отличает рабочие варианты ML-моделей от конкурсов Kaggle. При этом, чтобы добиться простоты, возможно, понадобится приложить больше усилий, чем при разработке очень сложной модели на Kaggle. Стремление к сложности я часто наблюдаю у новичков, они пытаются строить космический корабль там, где можно обойтись самокатом.
Трудоемкость проверки результата
В восьмом уроке от рекомендательной системы Quora [68] говорится о том, как важно уметь отвечать на вопрос, почему рекомендательная система дала ту или иную рекомендацию. В Retail Rocket мы также сталкиваемся с такими вопросами. Однажды в качестве альтернативного товара к туалетной бумаге выступила наждачная. Кстати, алгоритм предложил ее из-за реального поведения клиентов но, конечно, рекомендация выглядела как пранк, и нам было не смешно, ведь с каждым таким случаем приходится разбираться в ручном режиме. В какой-то момент мы написали скрипты и инструкции нашей технической поддержке, чтобы подобные казусы можно было оперативно решать или просто объяснять клиенту без привлечения аналитиков.
Почему так происходит? Когда продукт, в основе которого лежат данные, работает на внешний мир, могут возникать ситуации, неожиданные для пользователей. И если система проста и в ней заложены средства поиска и отладки неисправностей, разрулить их можно быстро.
Mechanical Turk / Yandex Toloka
Даже в проектах с использованием ML-моделей все средства хороши. Совсем недавно писали про компанию ScaleFactor, которая, как утверждалось, использовала искусственный интеллект, чтобы оказывать бухгалтерские услуги [69]. В компанию было вложено порядка 100 миллионов долларов. На деле оказалось, что всю работу делали традиционным способом обычные бухгалтеры.
Впервые о ручном труде в ML я услышал на видео с конференции STRATA, когда сотрудники LinkedIn рассказывали о проекте Skills. Для создания датасета они с помощью сервиса Amazon Mechanical Turk использовали труд тысяч людей, чтобы разметить данные для проекта. Сама модель у них была простая логистическая регрессия, но датасет для нее нужен был качественный. Конечно, можно было использовать метод анализа текстов, но дешевле и с гарантированным качеством можно получить результат через такие сервисы.
Я уже писал, что одно из преимуществ ML огромная скорость по сравнению с людьми. Так вот, сервисы, подобные Amazon Mechanical Turk, позволяют использовать труд тысячи людей для решения задачи. Это может быть разметка обучающих примеров, как сделал LinkedIn, или проверка миллионов рекомендаций магазина, как делали мы, кстати, наши задания по рекомендациям исполнители любили, они были им интересны. Поисковые системы используют такие ресурсы для проверки своей поисковой выдачи. Яндекс вывел в свет свой сервис под названием «Толока» и сделал его общедоступным.