Комментарии 36
archive.ics.uci.edu/ml/datasets/Wine
Хорошая попытка, но нет. Это работает все немного не совсем так. И математика тут как раз самое важное, а не эксперимент.
Да, качество предугадать невозможно, но есть некоторые соображения, исходя из природы данных и алгоритма, что могло бы повысить качество.
- Подходящий препроцессинг, и разные алгоритмы различным образом реагируют (или даже нет).
- Отбор признаков, не все алгоритмы умеют в него сами хотя бы на начальном уровне.
- Снижение размерности, да и вообще размерность датасета.
Серебряной пули пока не нашли, даже сетки, которые сами могут в feature engineering, имеют ряд заморочек, когда они не работают.
Если совсем абстрактно, алгоритмы из scikit-learn работают хорошо, когда пространство признаков с более-менее хорошими свойствами, а вот сделать его таким — ну если не искусство, то каждый раз серьезная задача.
«Исследователи данных тратят практически всё время на очистку и подготовку данных, добрых 90% этой работы представляет собой некую разновидность проектирования данных. При выборе между решением конкретных задач и поиском в данных полезной информации исследователи данных выбирают первое. Немного подробнее: начинайте с решения задачи и убедитесь в том, что вам есть что оптимизировать».
И опять немного не так. Процесс циклический, называется crisp-dm. Но я даже не о нем. Не в чистке дело, а в отображениях. Какое-нибудь банальное преобразование вроде перехода в полярные координаты или логарифмирования таргета, может докинуть качества в два раза — причем сразу для всех перечисленных алгоритмов.
И это часто видно глазами по pairplot, distplot и т.д.
то по вашему отверждению получается, что можно «докинуть качества в 2 раза» и достичь тем самым 1.7? Это как?)
Во-первых, очевидно, что «в два раза» — это была фигура речи. Во-вторых, если что, на таких значениях метрики под улучшением порой подразумевают снижение error rate. То есть, 90% accuracy -> 95% accuracy зачастую могут позиционировать таким образом.
Я в целом соглашусь с оратором выше.
Ни подход «забросить пачку датасетов в свой алгоритм», ни подход «забросить в пачку алгоритмов свой датасет» не демонстрируют реальных результатов.
Каждая модель требует своего варианта подачи данных, и хороший ресерчер априорно знает, что, грубо говоря, сетки хорошо работают с неструктурированными данными, бустинг умеет сам хэндлить пропуски и категориальные переменные (их не надо энкодить или эмбедить вручную), а логрег пригодится, если надо моделировать не очень сложные данные и нужна интерпретируемость (но на вход логрегу фичи придется скейлить, а категории кодировать, чего опять таки не нужно деревянным ансамблям), и так далее.
Каждая модель требует своего варианта подачи данных, и хороший ресерчер априорно знает, что, грубо говоря, сетки хорошо работают с неструктурированными данными, бустинг умеет сам хэндлить пропуски и категориальные переменные (их не надо энкодить или эмбедить вручную), а логрег пригодится, если надо моделировать не очень сложные данные и нужна интерпретируемость (но на вход логрегу фичи придется скейлить, а категории кодировать, чего опять таки не нужно деревянным ансамблям), и так далее.
Разве не об этом говорится в статье? Я не утверждаю обратного: действительно, каждая модель требует своего набора данных и вариант в целом. Никто с этим не спорит. Это и так ясно, причём без всяких «фигур речи». Но есть ситуации, причём очень частые, когда нужно провести быструю проверку алгоритмов на том или ином наборе данных. И предложенный метод блиц-проверки спасает или, по меньшей мере, облегчает усилия «ресерчера».
Конструктив нужен, камрады. А не глубокомысленная «мысля», что, мол, каждая ситуация уникальна.
Это конструктив — мы привели вам пачку примеров того, на что можно и нужно смотреть в реальности.
И, да, есть ситуации, где надо быстро понять примерно, какой алгоритм использовать для набора данных. Но никто в этой ситуации не делает "from sklearn import *". Вместо этого перебирают две-три модели, согласно опыту и здравому смыслу подходящие под данные, а их уже тюнят (в смысле — подбирают гиперпараметры и так далее).
А? Что? А я? А как мне? В sklearn нет моего датасета!!! Что делать?! Как превратить вон ту CSVшку в нужный формат? А какой формат вообще нужный? Ааааапаникааа!!!111одинодин
Например, самый простой вариант — TPOT: github.com/EpistasisLab/tpot
P.S. Шучу, вообще подход «давайте попробуем всякое руками и посмотрим, что получится» — он очень правильный. Пока ты не знаешь наизусть какой алгоритм хорош в какой ситуации, как-то так и надо делать для получения опыта. :)
Каждая модель требует своего варианта подачи данных, и хороший ресерчер априорно знает, что, грубо говоря, сетки хорошо работают с неструктурированными данными, бустинг умеет сам хэндлить пропуски и категориальные переменные (их не надо энкодить или эмбедить вручную), а логрег пригодится, если надо моделировать не очень сложные данные и нужна интерпретируемость (но на вход логрегу фичи придется скейлить, а категории кодировать, чего опять таки не нужно деревянным ансамблям), и так далее.
____________________________________
Спасибо за ссылку! Думаю, многие читающие тоже поблагодарят. Соглашусь,:) именно так и нужно набивать руку и только потом спокойно, обстоятельно, переваривать накопленный опыт.! Спасибо за конструктив!)
Ну и в целом полезно знать, что нынче полно есть инструментов разной степени сложности и полезности для, так называемого, AutoML. :) Глядишь, через какое-то время весь Data Science будет делаться через очень продвинувшийся к тому времени автоматический алгоритм.
Наверняка с появлением этого алгоритма отпадёт необходимость в исследователях данных, и будет как с человеком-радаром… Может, не надо его, «автоемелю»?)
«Главенствующий», разруливающий документ с терминологией ML мне не попадался. Так о каком AutoML может идти речь, если даже такого документа нет?
Статистика не может в полной мере объяснить те термины, которые вовсю используются в ML. К примеру, регрессия. В классическом понимании, Регрессия – односторонняя статистическая зависимость [Основы статистики с элементами теории вероятностей для экономистов: Руководство для решения задач. – Ростов н/Д: Феникс, 1999. – стр.263].
Статистический словарь не так лаконичен: Регрессионный анализ (регрессия множественная) – зависимость среднего значения какой-либо случайной величины (результативного показателя) от нескольких величин (регрессоров, независимых переменных, аргументов) [Статистический словарь / Гл. ред. М.А. Королёв. – 2-е изд., перераб. и доп. – М.: Финансы и статистика. – 1989].
А это из словаря Microsoft --> Machine learning tasks in ML.NET:
A supervised machine learning task that is used to predict the value of the label from a set of related features. The label can be of any real value and is not from a finite set of values as in classification tasks. Regression algorithms model the dependency of the label on its related features to determine how the label will change as the values of the features are varied. The input of a regression algorithm is a set of examples with labels of known values. The output of a regression algorithm is a function, which you can use to predict the label value for any new set of input features. Examples of regression scenarios include:
Predicting house prices based on house attributes such as number of bedrooms, location, or size.
Predicting future stock prices based on historical data and current market trends.
Predicting sales of a product based on advertising budgets.
Заметьте, вроде бы неплохо, но о методе регрессионного анализа forecast даже не упоминается.
Другой пример (из источника):
Regression — Predicting a continuous output (e.g. price, sales).
И таких примеров на 10 вкладок. :)
Известно, чтобы выявить закономерности, нужно провести регрессионный анализ, который применяется для «анализа нескольких переменных, когда основное внимание уделяется взаимосвязи между зависимой переменной и одной или несколькими независимыми» [ссылка].
То есть этот термин более верен в рамках ML, чем «регрессия». Однако о различающихся между собой методах predictive modeling и forecasting, о которых я написал в статье, мало где употребляется даже на англ.источниках, не говоря уже у нас…
Повторюсь, о различиях толково написано тут: ссылка.
Поэтому оперировать статистическими терминами в «машинлёрнинге» не всегда корректно. Поэтому и хотел предложить сообществу взяться за – давайте не будем бояться громогласности и ответственности – регламентирующий документ с терминами ML. Наверняка на хабре найдутся смельчаки), а площадка GitHub – идеальная среда для этого.
Единственный, кто тут не совсем прав — это Microsoft. «Predicting future stock prices based on historical data and current market trends.» — это всё-таки уже то, что вы называете forecasting, а в ML это чаще всё же называют time series analysis/modeling/predicting.
Это довольно разные задачи и они, совершенно определённо, различаются теми, кто занимается ML.
Кстати, что касается не-ML-специфичных терминов (таких как стэкинг, бустинг, кросс-валидация и т.д., которые относятся именно к ML), обычно вполне можно полагаться на термины, принятые в статистике. Та же регрессия наверняка в статистике описана довольно чётким и однозначным образом. Я бы полагался на хорошо устоявшийся статистический базис в таких вопросах.
Авторы прямо указывают, что термин регрессия в статистике не совсем корректно применяется. Более верный термин – регрессионный анализ.
Распространён такой подход в ML, как попробовать все алгоритмы из sklearn, и либо задача решится сама ("и так сойдёт"), либо надо будет думать. Эта статья очень полезна, потому что сводит к минимуму первую стадию. И если дойдёт до второй, предстоит нелёгкий выбор:
- переставать решать такую задачу;
- погружаться в предметную область, в программирование, а то и в математику;
- подбирать контанты через gridsearch, докидывать слои в нейронки, пока не будет нужный уровень accuracy и всё такое, но только не вдаваться в подробности, не тратить на это время.
Последний способ мне кажется современной алхимией, потому что его последователи произносят заклинания типа "AdaBoost!", "RandomForest!", не разбираясь в том, что при этом происходит. Плохого в этом ничего нет: специалист останется ценен, а неспециалист не побежит получать инженерное образование, чтобы вернуться через 10 лет и начать решать задачи, зато сможет быстрее начать пробовать и тренироваться. Но всё же от такой алхимии до содержательных решений далеко.
Я согласен, что бояться библиотечных алгоритмов не стоит, но всё-таки изучать предметную область, природу данных и логику алгоритмов хотя бы на базовом уровне надо, чтобы не начинать загонять в XGBoost, случайные леса и свёрточные нейронки то, что прекрасно решается линейной регрессией (вдруг можно при помощи сложных методов выразить линейную функцию более качественно; я слышал о тех, кто реально так делает). С блиц-проверкой можно начать делать именно это. Но для первого знакомства с ML почему бы и нет)))
в бизнесе по большей части нужы не инкрементальные доли процента, а совершенно другой подход — causal analysis, с проведением randomized controlled trial когда датасатанисты ставят эксперименты и находят первопричину наблюдаемых эффектов и численную величину эффекта. Это значит уходить от любимых фреймворков в «поле» — ближе к клиенту и бизнес процессам с ручкой и бумагой
Блиц-проверка алгоритмов машинного обучения: скорми свой набор данных библиотеке scikit-learn