Пропуски в данных

Очень часто задают вопрос, какие методы импутации я использую при работе с данными. В свое время написал статью http://issuu.com/gewissta/docs/____________________________________2610b514dbca97. На практике я почти ничего из описанного в статье сейчас не использую. Я перепробовал много методов импутации (с помощью регрессионного оценивания, максимизации ожидания и др.) и пришел к выводу, что сложность метода никак не влияет на его эффективность, только потеря времени, лишние манипуляции.

Я исхожу из того, что факт пропущенного значения может быть полезен сам по себе. И переменная даже с большим количеством пропущенных значений может быть полезной. Сначала я делаю missing_indicator для каждой переменной. Если значение исходной переменной не пропущено, missing_indicator для этой переменной равен 0, если пропущено, missing_indicator для этой переменной равен 1. Затем делаю примитивную импутацию, пропущенные значения количественных переменных заменяю медианой, для категориальных переменных пропущенное значение просто еще один вариант. Если missing_indicator значимый, то неважно, чем именно сделана импутация, а если незначимый, им можно пренебречь. Ниже рисунок, иллюстрирующий применение missing_indicator, нули соответствуют непропущенным значениям, единицы – пропущенным значениям (использована импутация медианой).

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

О Big data

На днях сотрудник подкинул ссылку на очередную статью, посвященную big data.

http://www.e-xecutive.ru/knowledge/announcement/1974193/?page=0

Неплохая статья. Но как и в большинстве статей, посвященных big data, немного смещены акценты (сознательно или нет, комментировать не буду).

Дело не в том, что данных раньше не было, а теперь их много, а в том, что сам подход к разработке алгоритмов экстенсивный. Например, я в школе математику изучаю. Первый класс — научился складывать однозначные числа, второй класс — научился складывать 2-значные, десятый класс — научился складывать 10-значные числа. Вот такой прогресс. Появление новых систем обнаружения, извлечения и хранения огромных данных (хотя вклад Teradata в этой области значителен) решает проблему big data лишь частично.

Чтоб реальный выхлоп от big data был и не искать «на всякий случай», надо менять способ разработки алгоритмов. Программы сегодня пишутся так же, как 20 лет назад. Те же модели, только больше данных. Единственное – стали в жесткие алгоритмы рандомизацию и усреднение внедрять (как пример random forest). Подгоняются вручную. О самообучении и речи нет. Накроется один транзистор в процессоре — процессору кирдык, а он даже не заметит — будет городить ерунду, интеллектом уровня Ex Machina даже не пахнет, вместо этого какие-то чатботы, которые по XML-файлу подходящий ответ находят.
Просто прежде чем делать big data, надо подумать, а нужны ли мне все эти миллиарды, нужны ли мне все те проблемы big data, которые описаны в статье, или можно случайную выборку сделать, ничего при этом не потеряв? А лучше даже не случайную, а стратифицированную. По крайней мере в финансах я ни одного примера big data не встречал. У меня коллеги в американском Citibank во фроде, application весь анализ вообще на своём десктопе делают. Все плохие, случайная выборка хороших. Большие данные – это немасштабируемые данные, twitter, google, вконтакте, вот там выборки делать нельзя без потери качества. Но и они на самом деле масштабируются. Google делает рандомизированные эксперименты, сложные выборки. Никто, имея квинтиллион наблюдений, не будет его использовать полностью. Почему? Об этом хорошо написано здесь http://habrahabr.ru/company/1cloud/blog/258219/. «Когда у вас есть огромное количество данных, то ваши аппетиты к выдвижению теорий также приобретают тенденцию расти. И если они растут быстрее, чем статистическая прочность данных, тем больше ваших выводов будут неверными. Вероятнее всего, они будут белым шумом»

Поэтому проектируешь выборку, выделяешь сегменты сильно различающихся между собой пользователей (в неструктурированных данных их может быть сколь угодно), строишь по каждому сегменту модель, а затем это множество подгоняешь, сравниваешь и, если нужно, агрегируешь. Решение SAS Factory Miner как раз про это. Удобно для скора соцсетей. Все прекрасно, но проблема, как я говорил выше, в том, что с т.з. алгоритмов делаем-то все как и 20 лет назад ручками, вручную подгоняем, потом смотрим выпуклым глазом, никакого самообучения.