Comments 10
Это одна из самых вредных для прочтения статей по машинному обучению на хабре, и вот почему:
В общем, прежде, чем писать туториалы, следует самому разобраться в описываемом материале, как мне кажется.
- Автор использует ужасные велосипеды. Считать csv с помощью pandas сразу в DataFrame, структуру, специально предназначена для хранения датасетов? Использовать готовые метрики и математические функции из numpy и sklearn? Куда там, мы даже для one-hot encoding пишем свою кастомную реализацию.
Чем плох такой подход? Во-первых, автор рискует ошибиться при написании подобных алгоритмов, и если ошибка будет малозаметной, получить уменьшение скора (тогда как в том же sklearn алгоритмы реализованы пять лет назад и проверены не одним поколением куда более опытных разработчиков). Во-вторых, автор делает свои алгоритмы просто фантастически неэффективными (почему?). В-третьих, код получается огромным по размерам, делая ещё более громоздкой и так немаленькую статью (читаемость кода при этом снижается).
- Автор утверждает, что он придумал и реализовал «интерфейс модели, удобный для использования программистом». На деле же автор продублировал давно придуманный интерфейс scikit-learn, но заменил общеупотребляемое название метода predict на process, тем самым сбивая с толку других data scientist-ов, которые решат прочитать его код.
- Автор допускает ошибки и просто пропускает их, даже не разобравшись, в чём причина:
Пока трудно сказать, что за катастрофа происходит при превышении значения 168, по какой причине качество предсказания так резко и внезапно ухудшается. В остальном — мы не видим сколько-нибудь значительных изменений. Для очистки совести посмотрим, как будет изменяться качество предсказания при уменьшении варьируемого параметра.
Очень жаль, но, видимо, нейросети — модель полезная и хорошая, но не для нашей задачи. Впрочем, если кто-то умеет для нее получить хороший результат с помощью моделей нейросетевого типа, то жду ссылок на код в комментариях, а мы переключимся на более консервативные подходы.
Выложите полный код экспериментов на github, и будет вам ссылка на рабочую нейросеть.
- Рекомендации по настройке гиперпараметров даже не хочется разбирать по отдельности. Укажу только на пару основных ошибок:
- Автор просто перебирает все возможные значения параметра. Очевидно, что в реальной жизни так делать не получится (просто потому что тренировка модели может занимать минуты или даже часы). Не верю, что пишу это, но советую почитать хотя бы про Grid search и Random search.
- Все параметры тюнятся по отдельность, хотя очень часто выбирать значение можно только для комбинации параметров (например, learning rate и количество деревьев в бустинге).
- Для того, чтобы настраивать параметры, неплохо хотя бы для начала разобраться, что они значат (и как работает алгоритм в целом). Тогда автор не будет писать таких глупостей, как, например:
Значит очередная проба «для очистки совести» помогла, как ни удивительно видеть качество немонотонно зависящее от значения гиперпараметра.
В общем, прежде, чем писать туториалы, следует самому разобраться в описываемом материале, как мне кажется.
Вы слишком многого хотите от автора, который пишет:
В статье, насколько возможно, используется русскоязычная терминология, выбранная автором на основе буквальных переводов англоязычных терминов и устоявшегося в сообществе сленга.
но не знает таких терминов как "фича признак (feature)", "фичселект выбор признаков (feature selection)", "пример выборка (sample)" и т.д.
Да, действительно, «фичеселект» — это явный пример того, как не надо делать.
Но все же говорят «фичеселект» по факту. Но в «условно литературном» тексте, конечно, «выбор признаков» лучше.
Слово «sample» указывает на один массив чисел, описывающий объект, а «выборка» — на их совокупность. Так что в этой части согласиться не могу.
Слово «sample» указывает на один массив чисел, описывающий объект, а «выборка» — на их совокупность. Так что в этой части согласиться не могу.
Если загуглить «фичеселект», то можно найти две страницы. Обе с вашими статьями.
Ну, и на заборе тоже что-то написано. Это ведь не значит, что это верно? Чистота в языке свидетельствует о ясности мышления, и обратное тоже верно.
Ммм… eсть генеральная совокупность, есть её выборка, есть элементы этой выборки. В чём проблема?
Ох, ну давайте пытаться вести дискуссию с претензией на обоснованность.
1. Да, я сознательно по возможности использую самописные функции и метрики. Делаю это со следующими целями:
— Больший контроль разработчика над кодом. Очень обидно потратить существенное время на отладку для того, чтобы понять, что та или иная функция работает немного не так, как предполагалось.
— Большая гибкость. Намного проще модифицировать ту или иную процедуру в связи с изменяющимися целями.
— Лучше для чтения, в частности — для изучения. По крайней мере первый раз лучше прочитать реально исполняющийся код, чем строку и ее математическое описание.
Есть и минусы у такого подхода. В первую очередь — в самом деле низкая скорость обработки данных. Однако в рассматриваемой задаче объем данных не так уж велик, так что это не составляет проблемы. Второй минус — работа с менее стандартными случаями. Типичный пример — строковые значения полей в csv (включающие в себя запятые). В этих случаях, разумеется, приходится [для меня — скрипя сердце] переходить на стандартные сторонние решения.
2. Я бы хотел видеть ссылку на аналогичный интерфейс Scikit-Learn. Название функции predict заменено на process сознательно. Я использую имя функции process в тех случаях, когда предполагается возможность наличия скрытых внутренних состояний и функция может давать разные результаты в зависимости от этих состояний. Как правило я, разумеется, стараюсь следовать интерфейсам Scikit-Learn, ставшим де-факто стандартными.
3. Автор идет по пути наименьшего сопротивления, улучшая целевую метрику наиболее простыми способами. Разбор всех «странных эффектов» откладывается до момента, когда он будет действительно необходим. Код есть в спойлере выше. Я не сомневаюсь, что при определенных настройках нейросети она даст более или менее приемлемый результат, однако на обсуждаемых данных как правило модели основанные на комитетах решающих деревьев работают лучше.
4. По пунктам.
— Автор не просто перебирает все возможные значения параметра. А упомянутые grid/random search как раз занимают занимают значительно больше времени и являются прямым путем к переобучению.
— Я пока не видел ни одного случая, когда был необходим тюнинг двух параметров одновременно. «One change in a time is still our holy grail».
— Обычно ошибка зависит от величины численного параметра монотонно и ее немонотонность указывает на неадекватность валидационной процедуры.
Критерий качества в машинном обучении (по крайней мере, в узком смысле этого термина) — качество предсказания. А оно (пока?) растет. Не гарантирую итоговый уровень топ 10 kaggle (по крайней мере без прочтения готовых решений), но уж более чем приличное качество предсказания я выжать смогу.
1. Да, я сознательно по возможности использую самописные функции и метрики. Делаю это со следующими целями:
— Больший контроль разработчика над кодом. Очень обидно потратить существенное время на отладку для того, чтобы понять, что та или иная функция работает немного не так, как предполагалось.
— Большая гибкость. Намного проще модифицировать ту или иную процедуру в связи с изменяющимися целями.
— Лучше для чтения, в частности — для изучения. По крайней мере первый раз лучше прочитать реально исполняющийся код, чем строку и ее математическое описание.
Есть и минусы у такого подхода. В первую очередь — в самом деле низкая скорость обработки данных. Однако в рассматриваемой задаче объем данных не так уж велик, так что это не составляет проблемы. Второй минус — работа с менее стандартными случаями. Типичный пример — строковые значения полей в csv (включающие в себя запятые). В этих случаях, разумеется, приходится [для меня — скрипя сердце] переходить на стандартные сторонние решения.
2. Я бы хотел видеть ссылку на аналогичный интерфейс Scikit-Learn. Название функции predict заменено на process сознательно. Я использую имя функции process в тех случаях, когда предполагается возможность наличия скрытых внутренних состояний и функция может давать разные результаты в зависимости от этих состояний. Как правило я, разумеется, стараюсь следовать интерфейсам Scikit-Learn, ставшим де-факто стандартными.
3. Автор идет по пути наименьшего сопротивления, улучшая целевую метрику наиболее простыми способами. Разбор всех «странных эффектов» откладывается до момента, когда он будет действительно необходим. Код есть в спойлере выше. Я не сомневаюсь, что при определенных настройках нейросети она даст более или менее приемлемый результат, однако на обсуждаемых данных как правило модели основанные на комитетах решающих деревьев работают лучше.
4. По пунктам.
— Автор не просто перебирает все возможные значения параметра. А упомянутые grid/random search как раз занимают занимают значительно больше времени и являются прямым путем к переобучению.
— Я пока не видел ни одного случая, когда был необходим тюнинг двух параметров одновременно. «One change in a time is still our holy grail».
— Обычно ошибка зависит от величины численного параметра монотонно и ее немонотонность указывает на неадекватность валидационной процедуры.
Критерий качества в машинном обучении (по крайней мере, в узком смысле этого термина) — качество предсказания. А оно (пока?) растет. Не гарантирую итоговый уровень топ 10 kaggle (по крайней мере без прочтения готовых решений), но уж более чем приличное качество предсказания я выжать смогу.
Полностью согласен с Вами, по личному опыту, такое часто бывает, когда типичный программист воображает себя дата саентистом...)
Sign up to leave a comment.
Настройка модели машинного обучения: подбор признаков и оптимизация гиперпараметров