Комментарии 17
как раз делаю последние дни тоже самое (я про титаник на кэггле), но с использованием глубоких сетей и машин Больцмана -)
так какое место на момент публикации а вас там?
так какое место на момент публикации а вас там?
У меня места пока там нет — я тоже пытаюсь делать глубокими сетями и RBM, вдохновленный курсом НН на курсере www.coursera.org/course/neuralnets.
Тоже собираюсь заняться этой задачей, но пока засел на распознавании цифр.
Распознавание цифр — на хабре была статья про конволюционные сети, которые показывают хороший результат для этой задачи. Кстати, там же где взята база, на сайте Лекуна есть обзор методов для решения этой задачи. Про конволюционные сети(кстати, предложены Yann Lecun) habrahabr.ru/post/74326
кстати на счет кодирования перечислений, в МЛ удобно использовать так называемый dummy coding
допустим переменная принимает значение из множества из n элементов, допустим k-ую категорию, то переменная заменяется набором 00..010..00 из n нулей, а на k-ом месте 1
в табличном представлении, одна колонка заменится на n колонок
допустим переменная принимает значение из множества из n элементов, допустим k-ую категорию, то переменная заменяется набором 00..010..00 из n нулей, а на k-ом месте 1
в табличном представлении, одна колонка заменится на n колонок
Очень интересно. Надеюсь, что цикл не будет заброшен.
отличное начинание, будет интересно увидеть продолжение :)
имхо, можно уделить еще внимание следующим вопросам:
а) распространенным форматам входных данных (т.е. в каком вообще виде данные могут быть изначально);
б) валидации данных (по крайней мере продолжить вашу базовую идею по типам данных и соответствующим способам их кодирования);
в) работе с наборами данных с пропусками;
г) предварительной консолидации/перегруппировке данных
имхо, можно уделить еще внимание следующим вопросам:
а) распространенным форматам входных данных (т.е. в каком вообще виде данные могут быть изначально);
б) валидации данных (по крайней мере продолжить вашу базовую идею по типам данных и соответствующим способам их кодирования);
в) работе с наборами данных с пропусками;
г) предварительной консолидации/перегруппировке данных
Огромное спасибо, как раз то, что недавно искал! Прослушал лекции на Coursera «Computing for Data Analysing» и тут такой вот от вас подарок! Желаю довести цикл статей до какого то логического завершения а не забрасывать на первой же статье как часто делают, к сожалению…
Итак, вот логическое завершение цикла Data Mining: Первичная обработка данных при помощи СУБД Часть3. Дальше планирую описывать применение методов и их результативность.
Смущают следующие моменты:
1. «Вроде бы и можем мы так кодировать, но получается, что мы добавляем к данным составляющую, которой нет — сравнение имен(числа: больше-меньше) по неизвестному признаку.»
Это сравнение умозрительно. Можно формально сравнить имена по принципу «больше-меньше». Или, например, у вас имена будут: «1», «2», «3» — получается, что какое-то сравнение по неизвестному признаку уже есть? Так зачем плодить огромное количество лишних полей и потом заниматься сжатием данных?
Вот если имён у человека могло бы быть несколько, то да. Или, например, если речь идёт о перенесённых заболеваниях. Тогда такой вариант не только помогает плоской укладке отношения один ко многим, но и улучшает качество кластерного анализа.
2. «Самый простой вариант — опечатка. Лишняя точка, запятая, пробел или тире.
Наличие таких данных уже влечет искажения, и модель кторая построена на «испорченных» сведениях не покажет хорошего результата»
На то он и статистический анализ, чтобы не зависеть существенно от ошибок. Опечатки могут и в буквах и при этом существенные. Да и просто набор данных может содержать очевидных аутлайеров. Это известная палка о двух концах: точность-устойчивость. Чем выше точность, тем ниже устойчивость как раз из-за наличия таких ошибок. Конечно, по возможности такие искажения стоит убирать, однако, делать это огульно опасно.
3. «Довольно много совпадений. Если вникнуть в задачу глубже и узнать по какому принципу маркировались билеты — можно еще сократить количество наименований. Но, одним из условий задачи было не использовать дополнительных сведений по этой широкоизвестной трагедии. Потому остановимся только на этом.»
Получается, что вы предположили, что в билетах были опечатки, но исправили их «как бог на душу положит», а значит намеренно внесли в данные искажения. Иногда приходится прибегать и к таким методам, но при этом хорошо бы оставить и исходный вариант и уже по итогам анализа данных решить, годятся ли ваши предположения.
1. «Вроде бы и можем мы так кодировать, но получается, что мы добавляем к данным составляющую, которой нет — сравнение имен(числа: больше-меньше) по неизвестному признаку.»
Это сравнение умозрительно. Можно формально сравнить имена по принципу «больше-меньше». Или, например, у вас имена будут: «1», «2», «3» — получается, что какое-то сравнение по неизвестному признаку уже есть? Так зачем плодить огромное количество лишних полей и потом заниматься сжатием данных?
Вот если имён у человека могло бы быть несколько, то да. Или, например, если речь идёт о перенесённых заболеваниях. Тогда такой вариант не только помогает плоской укладке отношения один ко многим, но и улучшает качество кластерного анализа.
2. «Самый простой вариант — опечатка. Лишняя точка, запятая, пробел или тире.
Наличие таких данных уже влечет искажения, и модель кторая построена на «испорченных» сведениях не покажет хорошего результата»
На то он и статистический анализ, чтобы не зависеть существенно от ошибок. Опечатки могут и в буквах и при этом существенные. Да и просто набор данных может содержать очевидных аутлайеров. Это известная палка о двух концах: точность-устойчивость. Чем выше точность, тем ниже устойчивость как раз из-за наличия таких ошибок. Конечно, по возможности такие искажения стоит убирать, однако, делать это огульно опасно.
3. «Довольно много совпадений. Если вникнуть в задачу глубже и узнать по какому принципу маркировались билеты — можно еще сократить количество наименований. Но, одним из условий задачи было не использовать дополнительных сведений по этой широкоизвестной трагедии. Потому остановимся только на этом.»
Получается, что вы предположили, что в билетах были опечатки, но исправили их «как бог на душу положит», а значит намеренно внесли в данные искажения. Иногда приходится прибегать и к таким методам, но при этом хорошо бы оставить и исходный вариант и уже по итогам анализа данных решить, годятся ли ваши предположения.
Спасибо за комментарий!
В целом — со всем согласен. По сути, все вращается вокруг «существенно» и «несущественно» и точность-устойчивость. Но с другой стороны — любой хрестоматийный подход говорит — постарайтесь собрать исходные данные как можно боле аккуратно. Или сделай это несколько раз.
Огульное изменение — да, можно так сказать. Обоснованное только лишь гипотезой о том, что одно и тоже названо «немного» разными именами. И что такое «немного»? Но с другой стороны — это вариант который можно проверить. И зайти в тупик. Или наоборот.
Исходный вариант — конечно остался, и в этом особеная прелесть хранения таблиц в базе данных. Закомментировал обновления — получил уже исходный вариант данных без правок. Либо убрал часть и т.д.
Откуда растут ноги у первого пункта:
1. «Вроде бы и можем мы так кодировать, но получается, что мы добавляем к данным составляющую, которой нет — сравнение имен(числа: больше-меньше) по неизвестному признаку.»
Когда мы кодируем — мы так или иначе ранжируем. Если потом мы пытаемся строить модели — не важно регрессионные или нейросетевые или еще какие-либо, это ранжирование, и даже его крутизна и равномерность будет влиять на модель.Например, метод попарных сравнений Саати позволяет проранжировать, то, о чем можно спросить эксперта. А если спросить или проранжировать нельзя, тогда лучше, на мой взгляд, добавить лишнее поле. Хотя — согласен, момент спорный и нуждается в проверке.
Проверю оба варианта уже в 3-4 части опуса.
В целом — со всем согласен. По сути, все вращается вокруг «существенно» и «несущественно» и точность-устойчивость. Но с другой стороны — любой хрестоматийный подход говорит — постарайтесь собрать исходные данные как можно боле аккуратно. Или сделай это несколько раз.
Огульное изменение — да, можно так сказать. Обоснованное только лишь гипотезой о том, что одно и тоже названо «немного» разными именами. И что такое «немного»? Но с другой стороны — это вариант который можно проверить. И зайти в тупик. Или наоборот.
Исходный вариант — конечно остался, и в этом особеная прелесть хранения таблиц в базе данных. Закомментировал обновления — получил уже исходный вариант данных без правок. Либо убрал часть и т.д.
Откуда растут ноги у первого пункта:
1. «Вроде бы и можем мы так кодировать, но получается, что мы добавляем к данным составляющую, которой нет — сравнение имен(числа: больше-меньше) по неизвестному признаку.»
Когда мы кодируем — мы так или иначе ранжируем. Если потом мы пытаемся строить модели — не важно регрессионные или нейросетевые или еще какие-либо, это ранжирование, и даже его крутизна и равномерность будет влиять на модель.Например, метод попарных сравнений Саати позволяет проранжировать, то, о чем можно спросить эксперта. А если спросить или проранжировать нельзя, тогда лучше, на мой взгляд, добавить лишнее поле. Хотя — согласен, момент спорный и нуждается в проверке.
Проверю оба варианта уже в 3-4 части опуса.
Вы правы, а я поторопился с выводами. Даже простая регрессионная модель будет точнее с отдельными полями, если значений в перечислении больше двух. А если строить её правильно, то нужно добавлять измерения. Правда при большом количестве вариантов (как в случае с именами), если этот параметр значим, то скорее всего это следствие какого-то более простого правила.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Data Mining: Первичная обработка данных при помощи СУБД. Часть 1