Нарываюсь на минуса, но все же.
Почему?
Я согласен, что код следует писать хорошо, и что часто академический код ужасен. Но делать код очень аккуратным в исследовательском проекте — пустая трата времени.
Почему магические константы (как в данном случае 64) — это плохо? Я согласен, что повторяющие захардкоженнные константы — это плохо. Потому, что поменяв ее в одном месте, можно забыть поменять в другом.
Конкретно тут она используется в одном месте. Лучше было ее сделать именованной константой и вынести в начало скрипта? Кажется, что нет.
А чем 'ksi' лучше/хуже имени 'loss'? Если человека реализовывает алгоритм по статье — лучше пусть он следует обозначениям статьи, нежели придумывает свои длинные длинные, но интерпретируемые названия. В оригинальных обозначениях можно хотя бы со статьей сверяться.
Из текста понятно, как это работает с датасетами.
А как с моделями?
Основная проблема таких подходов — они хорошо работают в накатанном сценарии использования. Шаг в сторону — и либо самому переписывать, либо обвешиваться callback'ами.
К слову, примерно так, как описано в тексте, работает класс Dataset в torch(torchnet)/pytorch.
Можно каждое значение хеша закодировать числом. Например, частотой встречаемости. Или сглаженной вероятностью целевой переменной (в случает бинарной классификации). И после кодировки — использовать любимый алгоритм.
А можно не кодировать, а оставить в виде one-hot и использовать линейную модель, для нее 8000 бинарных колонок — совсем не проблема.
Кроме того, можно применить разные матричные разложения к получившейся бинарной матрице — и их результаты использовать как признаки для ваше любимого алгоритма.
Уверены, что между категориальными переменными есть взаимодействие? Можно попробовать построить квадратичную линейную модель.
Пространство очень большое, а данных не хватает? Можно факторизовать матрицу квадратичных весов (как это сделано в факторизационных машинах)
Хочется взаимодействий более высоко порядка? Адаптивные полиномы или полные полиномы + хэширование.
Эти методы (кроме кодировки и описанного сценария использования матричных разложений) реализованы как минимум в vowpal wabbit.
Участникам выдаются 2 датасета: тренировочный (с ответам) и тестовый (без ответов). Требуется сгенерировать предсказание для тестового множества и послать его в систему. На стороне сервера предсказания разделяются фиксированным образом (но неизвестным участникам) на открытую (public) и закрытую (private) часть. Как правило, в пропорции 30 \ 70.
Участники могут отправлять свои решения — и будут видеть качество только на открытой части. Таблица участников ранжируется по этому результату. Однако финальный результат будет вычисляться по закрытой части датасета.
То есть можно сильно переобучиться на public часть — и быть высоко в таблице. Но это не имеет смысла, потому что по итогам private слетишь вниз. Такое бывает часто =)
Почему «конечно»?
Может мы расходимся в понимании слова «моделирование»? Я его сейчас использую как «написание решающего правила в символьном виде и его обоснование здравым смыслом \ экспертными знаниями».
Вы говорите про обогащение данных внешними источниками, а не про необходимость получения интрепретируемой модели.
Безусловно, хеширование затрудняет процесс построения решения, но не лишает задачу смысла.
Да, мы не знаем, что каждый признак означает — но все численные характеристики сохранились.
Достаточно ли этого, чтобы производить отбор и генерировать новые признаки на основании уже имеющихся? Мне кажется, да.
А нужно ли моделирование в данном случае?
Задача ведь ставится именно как аппроксимация y=f(x1, x1...xn), никто не требует интерпретируемости отображения f.
Т.е. народ обучает сначала традиционные алгоритмы типа RandomForest, SVM, adaBoost etc. получают на них результаты ~60-80% точности на тестовой выборке, а потом просто считают результат как голосование(иногда делают хитрее и строят по этим выходам регрессию) от всех таких «средних» моделей и получают результаты >90% с которыми и попадают в топ. Т.е. по сути оверфитятся на данные, при этом какой либо значимой практической пользы от таких моделей нет.
А что вы в данном случае называете оверфитом? В чем проблема, если народ получает те же >90% на тестовом множестве?
Собралось 100 человек, каждый участник подбрасывает монетку 100 раз, и считается рейтинг участника как процент выпадения орла. Что будет в результате? В топе будут игроки с результатами и 60 и 70 и 80%.
Но значит ли это, что они умеют управлять монеткой?
Именно потому в конкурсах всегда есть открытая часть (та, по которой отображается текущий топ) и закрытая (та, по которой считается финальный результат)
Если человек показывает 70% на одной части и столько же на другой — да, он вероятно умеет управлять монеткой.
Хеши несут информацию о том, что данный признак является категориальным, проверка категорий на равенство сохраняется.
Почему их нельзя считать нормальными данными?
Почему?
Я согласен, что код следует писать хорошо, и что часто академический код ужасен. Но делать код очень аккуратным в исследовательском проекте — пустая трата времени.
Почему магические константы (как в данном случае 64) — это плохо? Я согласен, что повторяющие захардкоженнные константы — это плохо. Потому, что поменяв ее в одном месте, можно забыть поменять в другом.
Конкретно тут она используется в одном месте. Лучше было ее сделать именованной константой и вынести в начало скрипта? Кажется, что нет.
А чем 'ksi' лучше/хуже имени 'loss'? Если человека реализовывает алгоритм по статье — лучше пусть он следует обозначениям статьи, нежели придумывает свои длинные длинные, но интерпретируемые названия. В оригинальных обозначениях можно хотя бы со статьей сверяться.
А как с моделями?
Основная проблема таких подходов — они хорошо работают в накатанном сценарии использования. Шаг в сторону — и либо самому переписывать, либо обвешиваться callback'ами.
К слову, примерно так, как описано в тексте, работает класс Dataset в torch(torchnet)/pytorch.
А можно не кодировать, а оставить в виде one-hot и использовать линейную модель, для нее 8000 бинарных колонок — совсем не проблема.
Кроме того, можно применить разные матричные разложения к получившейся бинарной матрице — и их результаты использовать как признаки для ваше любимого алгоритма.
Уверены, что между категориальными переменными есть взаимодействие? Можно попробовать построить квадратичную линейную модель.
Пространство очень большое, а данных не хватает? Можно факторизовать матрицу квадратичных весов (как это сделано в факторизационных машинах)
Хочется взаимодействий более высоко порядка? Адаптивные полиномы или полные полиномы + хэширование.
Эти методы (кроме кодировки и описанного сценария использования матричных разложений) реализованы как минимум в vowpal wabbit.
Участники могут отправлять свои решения — и будут видеть качество только на открытой части. Таблица участников ранжируется по этому результату. Однако финальный результат будет вычисляться по закрытой части датасета.
То есть можно сильно переобучиться на public часть — и быть высоко в таблице. Но это не имеет смысла, потому что по итогам private слетишь вниз. Такое бывает часто =)
Может мы расходимся в понимании слова «моделирование»? Я его сейчас использую как «написание решающего правила в символьном виде и его обоснование здравым смыслом \ экспертными знаниями».
Вы говорите про обогащение данных внешними источниками, а не про необходимость получения интрепретируемой модели.
Безусловно, хеширование затрудняет процесс построения решения, но не лишает задачу смысла.
Да, мы не знаем, что каждый признак означает — но все численные характеристики сохранились.
Достаточно ли этого, чтобы производить отбор и генерировать новые признаки на основании уже имеющихся? Мне кажется, да.
Задача ведь ставится именно как аппроксимация y=f(x1, x1...xn), никто не требует интерпретируемости отображения f.
Если это out-sample — то второй лучше.
А что вы в данном случае называете оверфитом? В чем проблема, если народ получает те же >90% на тестовом множестве?
Именно потому в конкурсах всегда есть открытая часть (та, по которой отображается текущий топ) и закрытая (та, по которой считается финальный результат)
Если человек показывает 70% на одной части и столько же на другой — да, он вероятно умеет управлять монеткой.
Почему их нельзя считать нормальными данными?