Проблемы промышленности и Kaggle. Собирать больше наблюдений и иметь доступ к большему количеству переменных важнее, чем модное моделирование?

Я надеюсь, что название говорит само за себя. В Kaggle большинство победителей используют стеки с иногда сотнями базовых моделей, чтобы выжать несколько лишних% MSE, точность ... В целом, по вашему опыту, насколько важно модное моделирование, такое как стекирование, а не просто сбор большего количества данных и больше функций для данных?

Для справки, я занимаюсь прогнозированием магазина $\times$ временных рядов SKU для розничных продаж уже 12 лет. Десятки тысяч временных рядов в сотнях или тысячах магазинов. Мне нравится говорить, что мы занимаемся большими данными еще до того, как термин стал популярным.

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

Когда вы понимаете свои данные, вам нужно работать, чтобы очистить данные. Я руководил целым рядом юниоров и стажеров, и единственное, чего они никогда не испытывали во всех своих уроках статистики и науки о данных, - это сколько всего дерьма может быть в ваших данных. Затем вам нужно либо вернуться к источнику и попытаться получить его, чтобы получить хорошие данные, либо попытаться очистить его, или даже просто выбросить некоторые вещи. Изменение работающей системы для получения лучших данных может быть на удивление трудным.

Как только вы поймете свои данные и получите действительно чистые данные, вы можете начать с ними возиться. К сожалению, к этому времени я часто оказывался вне времени и ресурсов.

Лично я большой поклонник сочетания моделей («стекирование»), по крайней мере, в абстрактном смысле , в меньшей степени - с фантазийным проектированием, которое часто пересекает черту на переоснащение территории - и даже если ваша более модельная модель работает в среднем немного лучше, часто можно обнаружить, что действительно плохие прогнозы ухудшаются с более сложной моделью. Это разбойник в моей сфере деятельности. Один действительно плохой прогноз может полностью разрушить доверие ко всей системе, поэтому надежность в моем списке приоритетов чрезвычайно высока. Ваш пробег может варьироваться.

По моему опыту, да, комбинация моделей может улучшить точность. Тем не менее, действительно большие выгоды достигаются с первых двух шагов: понимание ваших данных и их очистка (или получение чистых данных в первую очередь).

Я не могу говорить за всю отрасль, очевидно, но я работаю в отрасли и соревновался на Kaggle, поэтому я поделюсь своим POV.

Во-первых, вы правы, подозревая, что Kaggle не совсем соответствует тому, что люди делают в промышленности. Это игра, которая зависит от мастерства игры, с множеством безумных ограничений. Например, в текущем конкурсе Сантандер :

1. Названия объектов были искусственно хешированы, чтобы скрыть их значение.
2. «Тренировочный» набор был искусственно ограничен, чтобы иметь меньше строк, чем столбцов, так что выбор характеристик, устойчивость и методика регуляризации были бы необходимы для успеха.
3. Так называемый «тестовый» набор имеет заметно отличающееся распределение, чем обучающий набор, и эти два явно не являются случайными выборками из одной популяции.

Если бы кто-то дал мне такой набор данных на работе, я бы сразу предложил им поработать над созданием функций, чтобы мы могли получить более полезные функции. Я бы предложил использовать знания предметной области для определения вероятных условий взаимодействия, пороговых значений, стратегий категориального кодирования переменных и т. Д. Подход к решению проблемы таким образом был бы более продуктивным, чем попытка извлечь смысл из файла исчерпания, созданного инженером базы данных без обучение в ML.

Кроме того, если вы узнаете, скажем, что определенный числовой столбец вовсе не числовой, а скорее почтовый индекс, то вы можете пойти и получить данные из сторонних источников данных, таких как перепись США, для дополнения ваших данных. Или, если у вас есть дата, возможно, вы включите цену закрытия S & P 500 на этот день. Такие внешние стратегии дополнения требуют детального знания конкретного набора данных и значительного знания предметной области, но обычно имеют гораздо большие выгоды, чем чистые алгоритмические улучшения.

Итак, первое большое различие между промышленностью и Kaggle заключается в том, что в отрасли возможности (в смысле исходных данных) являются предметом переговоров.

Второй класс отличий - производительность. Часто модели будут развернуты в производство одним из двух способов: 1) прогнозы модели будут предварительно рассчитаны для каждой строки в таблице очень большой базы данных, или 2) приложение или веб-сайт передадут модели одну строку данных и нужен прогноз, возвращаемый в режиме реального времени. Оба варианта использования требуют хорошей производительности. По этим причинам вы не часто видите модели, которые могут быть медленными для предсказания или использования огромного объема памяти, такие как K-Nearest-Neighbours или Extra Random Forests. Логистическая регрессия или нейронная сеть, напротив, могут получить пакет записей с несколькими умножениями матриц, а умножение матриц может быть высоко оптимизировано с помощью подходящих библиотек.Даже если бы я мог получить, возможно, +0,001 AUC, если бы я использовал еще одну непараметрическую модель, я бы этого не сделал, потому что пропускная способность и задержка прогнозирования слишком сильно упадут.

В этом есть и аспект надежности: использование четырех различных современных сторонних библиотек, скажем, LightGBM , xgboost , catboost и Tensorflow ( конечно же, на графических процессорах ), может дать вам снижение на 0,01 в MSE, которое выигрывает соревнования Kaggle, но это четыре разные библиотеки для установки, развертывания и отладки, если что-то пойдет не так. Здорово, если вы сможете заставить все это работать на своем ноутбуке, но запустить его в контейнере Docker, работающем на AWS, - это совсем другая история. Большинство компаний не хотят возглавлять небольшую команду разработчиков, чтобы заниматься такими вопросами развертывания.

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

По моему опыту, больше данных и больше функций важнее самой причудливой, наиболее сложенной, наиболее настроенной модели, которую можно придумать.

Посмотрите на конкурсы онлайн рекламы, которые состоялись. Модели-победители были настолько сложными, что на обучение у них ушла целая неделя (в очень небольшом наборе данных по сравнению с отраслевым стандартом). Кроме того, прогноз в модели с накоплением длиннее, чем в простой линейной модели. По той же теме, помните, что Netflix никогда не использовал свой алгоритм 1M $ из-за затрат на разработку .

Я бы сказал, что онлайновые конкурсы по науке о данных - это хороший способ для компании узнать, «какой максимальной точности (или любой метрики производительности) можно достичь», используя данные, которые они собирают (в определенный момент времени). Обратите внимание, что это на самом деле сложная проблема, которая решается! Но в отрасли полевые знания, аппаратные и бизнес-ограничения обычно препятствуют использованию «модного моделирования».

Укладка значительно увеличивает сложность и снижает интерпретируемость. Прибыли обычно относительно невелики, чтобы оправдать это. Таким образом, хотя ансамбль, вероятно, широко используется (например, XGBoost), я думаю, что в промышленности стекирование встречается относительно редко.

По моему опыту, сбор хороших данных и функций гораздо важнее.

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

Идет много экспериментов, и нам нужны модели, которые:

1. Быстро тренироваться
2. Быстрый прогноз (также часто является бизнес-требованием)
3. Легко интерпретировать

Пункт 3) особенно важен, потому что модели, которые легко интерпретировать, легче передать клиенту, и их легче поймать, если мы сделали что-то не так.

Вот кое-что, что не особенно подходит для Kaggle:

• больше переменных у вас есть в вашей модели, и
• чем сложнее отношения между этими переменными и выходом,

тем больше риск вы столкнетесь в течение всей жизни этой модели. В соревнованиях Kaggle время обычно либо замораживается, либо существует короткое временное окно, в которое вступают значения тестовых наборов. В промышленности эта модель может работать годами. И все, что может потребоваться, - это чтобы одна переменная пошла наперекосяк, и вся ваша модель пошла в ад, даже если она была построена безупречно. Я понимаю, никто не хочет смотреть соревнования, где конкуренты тщательно балансируют сложность модели с риском, но на работе ваш бизнес и качество жизни пострадают, если что-то пойдет не так с моделью, за которую вы отвечаете. Даже очень умные люди не застрахованы. Возьмем, к примеру, ошибку прогноза Google Flu Trends . Мир изменился, и они не ожидали его наступления.

На вопрос OP: « В целом, по вашему опыту, насколько важно модное моделирование, такое как стекирование, а не просто сбор большего количества данных и дополнительных функций для данных? » Ну, я официально стар, но мой ответ таков, если у вас нет действительно надежная инфраструктура моделирования, лучше иметь простые модели с минимальным набором переменных, где отношение ввода-вывода является относительно простым. Если переменная едва улучшает вашу метрику потерь, не указывайте ее. Помните, что это работа. Получайте свои удары вне работы на соревнованиях Kaggle, где есть стимул «иди или иди домой».

Единственным исключением может быть, если бизнес-ситуация требует определенного уровня производительности модели, например, если вашей компании необходимо соответствовать или опережать показатели конкурента, чтобы получить какое-то преимущество (возможно, в маркетинге). Но когда существует линейная зависимость между производительностью модели и выгодой для бизнеса, увеличение сложности, как правило, не оправдывает финансовую выгоду (см. « Netflix никогда не использовал свой алгоритм стоимостью 1 миллион долларов США из-за затрат на проектирование ») - извиняюсь перед @ RUser4512 за цитирование статья). Однако в соревновании Kaggle этот дополнительный выигрыш может сдвинуть вас на сотню рангов при прохождении соседних решений.

Короткий ответ - цитата из книги Гари Каспарова «Глубокое мышление».

Умный процесс побеждает превосходные знания и передовые технологии

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

Весь этот процесс больше, чем сумма его частей. Я стремлюсь получить «приемлемую» производительность обобщения с помощью линейной / логистической регрессии и бесед с экспертами в предметной области для создания функций, что позволяет сократить время, затрачиваемое на адаптацию моей модели к имеющимся у меня данным.