Когда меньше значит больше: краткий рассказ о разработке функций с помощью XGBoost

Я сыграл второстепенную роль в запуске RAPIDS на Google Dataproc, усовершенствовав модель, которая прогнозирует стоимость проезда в такси в Нью-Йорке. Географическое расположение мест посадки и высадки пассажиров было в столбцах данных. Они записываются как измерения долготы и широты с точностью до многих десятичных знаков. Первое, что я сделал для улучшения характеристик модели, - округлил значения долготы и широты, чтобы сделать их менее точными. Что тут происходит? Разве больше информации не должно сделать модель лучше? Чтобы понять, что происходит, нам нужно немного подумать о том, что представляют собой данные геолокации, и понять, как XGBoost решает разделить данные, когда делает прогнозы.

Грубое поведение

Я недавно видел твит, в котором комментировалось, как данные геолокации часто хранятся на слишком точном уровне для многих целей. Возможно, из-за эффекта Баадера-Майнхоф меня сразу же заинтересовали геолокационные данные в этой задаче.

Я узнал, что один градус широты составляет 67 миль или 353 760 футов. Цифры в данных сообщаются с точностью до пятого десятичного знака, например -73,99477. Это означает, что последняя цифра выражается в 3,5 футах. Это настоящее чудо науки, что мы можем с такой точностью измерять количество подбираемых такси из космоса; длина в половину вагона - это столько, сколько я когда-либо хотел бы дойти на такси. Однако похоже, что мы слишком внимательно присматриваемся, чтобы увидеть какие-либо полезные закономерности.

Судя по нескольким визитам, которые я совершил в Нью-Йорк, кажется, что трафик может варьироваться от блока к блоку. Этот блог предполагает, что блок с севера на юг в Манхэттене составляет примерно 264 фута, а блок с востока на запад - примерно в 750 футов.

Если мы округлим наши географические данные до трех десятичных знаков, это означает, что наша самая маленькая единица будет 353 фута; немного длиннее короткого блока и чуть меньше половины длинного блока. Похоже, что разделение блока бесполезно, поэтому мы отступим еще немного. Основываясь на характеристиках модели, я округил числа долготы и широты до двух десятичных знаков, что составляет нашу наименьшую единицу мили. Вы также можете представить это как сетку 100 на 100 над Нью-Йорком.

Одно только это небольшое изменение снизило RMSE на 4,6%.

Что действительно важно?

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

Использование значений по умолчанию означает разделение Нью-Йорка на сетку размером 3,5 на 3,5 фута. В этом разрешении мы добавили шум в эту переменную относительно нашей проблемы. XGBoost будет принимать решения о разделении листьев на отрезках с этим допуском 3,5 фута, если данные не изменяются. Ни один разумный человек не поверит, что пара длинных шагов в любом заданном направлении вообще изменит ваш опыт такси. Здесь мы спрашиваем алгоритм: «Каково влияние отъезда с определенной площади города в ½ мили и прибытия в другой?» По умолчанию количество бинов, которые XGBoost создает для дискретизации непрерывных переменных, равно 256. Благодаря округлению мы существенно уменьшили количество бинов до 100.

Используйте свои знания

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

RAPIDS позволяет быстро перебирать и опробовать новые идеи. Поиск оптимального разрешения географических данных занял всего пару часов.

Надеюсь, вам понравился мой рассказ о разработке функций, и я надеюсь, что вы прочитали наш недавний блог на тему Начало работы с Google Dataproc. В каких случаях вы видели большие выгоды от, казалось бы, простой разработки функций? Дайте мне знать в комментариях ниже или найдите меня в твиттере @realpaulmahler.

  1. Мне не удалось найти этот твит, но я думаю, что увидел его, потому что подписался на Джона Марри (@murraydata).
  2. Неразумные люди, такие как я, могут представить себе ситуации Чарльза Аддамса / Эдварда Гори, где пара шагов, скажем, от центра дороги может помочь, но я предполагаю, что это редкие случаи.