Comments 36
Шикарно и спасибо! Пишите ещё!
Спасибо! Как только посетит вдохновение, так сразу. :) Скорее всего это будет сообщение про метрики оценки качества алгоритма. А точнее — взгляд на них с другого угла.
У вас есть методология оценки качества алгоритма если сам алгоритм недоступен? Только результаты его работы. Скорость там, время ответа, точность предсказания что там еще есть обучающая способность, способность обобщения. Я создаю алгоритм и возникла необходимость в оценке качества его работы, но как это сделать пока непонятно. Исходным кодом поделиться не могу, а вот возможность загружать датасеты есть и параметры обучения все собираются. Есть апи доступа к проверке входящих данных. Никаких специальных параметров для настройки нет. Все работает из коробки. Буду признателен если подскажите как это можно было бы сделать.
Я так понимаю, у вас так называемая scratch-built model, без использования «упрощающих» библиотек. Использование функции потерь будет верным шагом: ссылка.
Попробовал расчитать данные на своем алгоритме. Он расщелкал задачу за 454 секунды и 31 эпоху биморф.рф/bmf/wine со 100% результатом хотя написнао, что только один алгоритм дал 100% результат с парнями просто пытались как то измерить вновь написанный алгоритм habr.com/ru/post/474954 ваш тест подошел хорошо под такой алгоритм проверки.
archive.ics.uci.edu/ml/datasets/Wine
archive.ics.uci.edu/ml/datasets/Wine
В данной статье вышеобозначенные проблемы решаются силами библиотеки scikit-learn. Напомню, все алгоритмы, запряжённые блиц-проверкой, имеют настройки по умолчанию, за исключением некоторых моментов. Поэтому дальнейший шаг — оптимизация параметров у «отборных» алгоритмов. Например, в случае с классификацией у алгоритма 'KNN' можно попытаться подобрать оптимальный параметр n_neighbors (по умолчанию n_neighbors=5). Оптимизация этого c помощью подхода GridSearchCV или RandomizedSearchCV (Tuning the hyper-parameters of an estimator) будет хорошим началом.
автору большой респект за статью
Хорошая попытка, но нет. Это работает все немного не совсем так. И математика тут как раз самое важное, а не эксперимент.
Да, качество предугадать невозможно, но есть некоторые соображения, исходя из природы данных и алгоритма, что могло бы повысить качество.
- Подходящий препроцессинг, и разные алгоритмы различным образом реагируют (или даже нет).
- Отбор признаков, не все алгоритмы умеют в него сами хотя бы на начальном уровне.
- Снижение размерности, да и вообще размерность датасета.
Серебряной пули пока не нашли, даже сетки, которые сами могут в feature engineering, имеют ряд заморочек, когда они не работают.
Если совсем абстрактно, алгоритмы из scikit-learn работают хорошо, когда пространство признаков с более-менее хорошими свойствами, а вот сделать его таким — ну если не искусство, то каждый раз серьезная задача.
«Главная ценность метода, о котором речь впереди, в том, что его результаты позволят ответить на вопрос, чего стоит ваш набор данных…». Рассмотренные примеры с очень хорошими результатами — это своего рода «эталон», с которым можно и нужно сравнивать результаты выполнения алгоритмов на ваших данных. Теперь понятно?
«Исследователи данных тратят практически всё время на очистку и подготовку данных, добрых 90% этой работы представляет собой некую разновидность проектирования данных. При выборе между решением конкретных задач и поиском в данных полезной информации исследователи данных выбирают первое. Немного подробнее: начинайте с решения задачи и убедитесь в том, что вам есть что оптимизировать».
«Исследователи данных тратят практически всё время на очистку и подготовку данных, добрых 90% этой работы представляет собой некую разновидность проектирования данных. При выборе между решением конкретных задач и поиском в данных полезной информации исследователи данных выбирают первое. Немного подробнее: начинайте с решения задачи и убедитесь в том, что вам есть что оптимизировать».
И опять немного не так. Процесс циклический, называется crisp-dm. Но я даже не о нем. Не в чистке дело, а в отображениях. Какое-нибудь банальное преобразование вроде перехода в полярные координаты или логарифмирования таргета, может докинуть качества в два раза — причем сразу для всех перечисленных алгоритмов.
И это часто видно глазами по pairplot, distplot и т.д.
Спокойствие, мой френд, спокойствие!) Если эффективность ансамблевого метода 0.85 (85%), то по вашему отверждению получается, что можно «докинуть качества в 2 раза» и достичь тем самым 1.7? Это как?) Идеальный результат — это единица (метрика 'accuracy'). Может, вы чем-то порочным занимаетесь с данными?)
то по вашему отверждению получается, что можно «докинуть качества в 2 раза» и достичь тем самым 1.7? Это как?)
Во-первых, очевидно, что «в два раза» — это была фигура речи. Во-вторых, если что, на таких значениях метрики под улучшением порой подразумевают снижение error rate. То есть, 90% accuracy -> 95% accuracy зачастую могут позиционировать таким образом.
Я в целом соглашусь с оратором выше.
Ни подход «забросить пачку датасетов в свой алгоритм», ни подход «забросить в пачку алгоритмов свой датасет» не демонстрируют реальных результатов.
Каждая модель требует своего варианта подачи данных, и хороший ресерчер априорно знает, что, грубо говоря, сетки хорошо работают с неструктурированными данными, бустинг умеет сам хэндлить пропуски и категориальные переменные (их не надо энкодить или эмбедить вручную), а логрег пригодится, если надо моделировать не очень сложные данные и нужна интерпретируемость (но на вход логрегу фичи придется скейлить, а категории кодировать, чего опять таки не нужно деревянным ансамблям), и так далее.
Каждая модель требует своего варианта подачи данных, и хороший ресерчер априорно знает, что, грубо говоря, сетки хорошо работают с неструктурированными данными, бустинг умеет сам хэндлить пропуски и категориальные переменные (их не надо энкодить или эмбедить вручную), а логрег пригодится, если надо моделировать не очень сложные данные и нужна интерпретируемость (но на вход логрегу фичи придется скейлить, а категории кодировать, чего опять таки не нужно деревянным ансамблям), и так далее.
Разве не об этом говорится в статье? Я не утверждаю обратного: действительно, каждая модель требует своего набора данных и вариант в целом. Никто с этим не спорит. Это и так ясно, причём без всяких «фигур речи». Но есть ситуации, причём очень частые, когда нужно провести быструю проверку алгоритмов на том или ином наборе данных. И предложенный метод блиц-проверки спасает или, по меньшей мере, облегчает усилия «ресерчера».
Конструктив нужен, камрады. А не глубокомысленная «мысля», что, мол, каждая ситуация уникальна.
Это конструктив — мы привели вам пачку примеров того, на что можно и нужно смотреть в реальности.
И, да, есть ситуации, где надо быстро понять примерно, какой алгоритм использовать для набора данных. Но никто в этой ситуации не делает "from sklearn import *". Вместо этого перебирают две-три модели, согласно опыту и здравому смыслу подходящие под данные, а их уже тюнят (в смысле — подбирают гиперпараметры и так далее).
Почти у всех руководств «для новичков» есть одна и та же болезнь: «давайте возьмём данные! dataset = load_load_digits()»
А? Что? А я? А как мне? В sklearn нет моего датасета!!! Что делать?! Как превратить вон ту CSVшку в нужный формат? А какой формат вообще нужный? Ааааапаникааа!!!111одинодин
А? Что? А я? А как мне? В sklearn нет моего датасета!!! Что делать?! Как превратить вон ту CSVшку в нужный формат? А какой формат вообще нужный? Ааааапаникааа!!!111одинодин
Обучно у тех, кто занимается обучением оделей на постоянной основе есть инструменты перевода форматов друг в друга. У меня такой почти с самого начала работы есть. Строк на двести. За одно проверяет пустые данные и сигнализирует и запятые чтобы стояли вместо точек конвертирует. Буквально пару дней назад столкнулся что в csv могут использоваться числа без нуля алгоритм делал на нем ошибку и пришлось числа также конвертировать в удобочитаемый вид. Все это просто добавляется в скрипт готовый в любой момент сконвертировать данные.
Хорошо, если данные приходят в одном формате и из одного источника. Практика показывает, что зоопарк со временем растёт и данные приходится собирать в самом разном виде из самых разных источников. И везде их надо по-своему как-то обрабатывать, универсальные методы далеко не всегда помогают.
И что, много полезного Вы для нашли в этой статье? Кто является её целевой аудиторией?
Вах-вах-вах, сколько кода. Зачем кормить алгоритмы вручную, когда уже давно есть библиотеки, которые сами всё делают и выдают готовую цепочку трансформеров и алгоритмов для получения оптимальной метрики? ;)
Например, самый простой вариант — TPOT: github.com/EpistasisLab/tpot
P.S. Шучу, вообще подход «давайте попробуем всякое руками и посмотрим, что получится» — он очень правильный. Пока ты не знаешь наизусть какой алгоритм хорош в какой ситуации, как-то так и надо делать для получения опыта. :)
Например, самый простой вариант — TPOT: github.com/EpistasisLab/tpot
P.S. Шучу, вообще подход «давайте попробуем всякое руками и посмотрим, что получится» — он очень правильный. Пока ты не знаешь наизусть какой алгоритм хорош в какой ситуации, как-то так и надо делать для получения опыта. :)
:)
____________________________________
Спасибо за ссылку! Думаю, многие читающие тоже поблагодарят. Соглашусь,:) именно так и нужно набивать руку и только потом спокойно, обстоятельно, переваривать накопленный опыт.! Спасибо за конструктив!)
Каждая модель требует своего варианта подачи данных, и хороший ресерчер априорно знает, что, грубо говоря, сетки хорошо работают с неструктурированными данными, бустинг умеет сам хэндлить пропуски и категориальные переменные (их не надо энкодить или эмбедить вручную), а логрег пригодится, если надо моделировать не очень сложные данные и нужна интерпретируемость (но на вход логрегу фичи придется скейлить, а категории кодировать, чего опять таки не нужно деревянным ансамблям), и так далее.
____________________________________
Спасибо за ссылку! Думаю, многие читающие тоже поблагодарят. Соглашусь,:) именно так и нужно набивать руку и только потом спокойно, обстоятельно, переваривать накопленный опыт.! Спасибо за конструктив!)
В реальной жизни, да и на тех же соревнованиях по Data Science TPOT, к сожалению, не сильно помогает — там всё обычно упирается в какую-то супер-фичу, которую можно придумать только исследуя данные руками. Но каких-то идей, что можно ещё попробовать сделать с данными, TPOT может подкинуть. Ну и в целом полезно знать, что нынче полно есть инструментов разной степени сложности и полезности для, так называемого, AutoML. :) Глядишь, через какое-то время весь Data Science будет делаться через очень продвинувшийся к тому времени автоматический алгоритм.
Ну и в целом полезно знать, что нынче полно есть инструментов разной степени сложности и полезности для, так называемого, AutoML. :) Глядишь, через какое-то время весь Data Science будет делаться через очень продвинувшийся к тому времени автоматический алгоритм.
Наверняка с появлением этого алгоритма отпадёт необходимость в исследователях данных, и будет как с человеком-радаром… Может, не надо его, «автоемелю»?)
Камрады, хотел спросить. Есть желающие собраться и написать словарь терминов по тематике машинного обучения? Во многих постах путаница с терминами. Возможно, кто-нибудь уже начинал это дело, я бы с удовольствием присоединился.
Приведите примеры что ли для начала. И, кроме того, основным источником знаний в этой области до сих пор являются статьи на английском, там путаницы обычно меньше.
В том-то и дело, что приходится смотреть значение терминов «машинлёрнинга» на англоязычных сайтах: при подготовке данной статьи моя коллекция закладок пополнилась добрым десятком словарей на тематику ML и Data science. Например, словарь scikit-learn: Glossary of Common Terms and API Elements.
«Главенствующий», разруливающий документ с терминологией 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 – идеальная среда для этого.
«Главенствующий», разруливающий документ с терминологией 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 – идеальная среда для этого.
Ну вообще-то примерно все определения, которые вы привели, описывают вполне одно и то же, просто с разной степенью развёрнутости. Под регрессией в ML обычно понимается предсказание значения непрерывной переменной в зависимости от значений других переменных (не обязательно, кстати, непрерывных, в отличие от целевой переменной).
Единственный, кто тут не совсем прав — это Microsoft. «Predicting future stock prices based on historical data and current market trends.» — это всё-таки уже то, что вы называете forecasting, а в ML это чаще всё же называют time series analysis/modeling/predicting.
Это довольно разные задачи и они, совершенно определённо, различаются теми, кто занимается ML.
Кстати, что касается не-ML-специфичных терминов (таких как стэкинг, бустинг, кросс-валидация и т.д., которые относятся именно к ML), обычно вполне можно полагаться на термины, принятые в статистике. Та же регрессия наверняка в статистике описана довольно чётким и однозначным образом. Я бы полагался на хорошо устоявшийся статистический базис в таких вопросах.
Единственный, кто тут не совсем прав — это Microsoft. «Predicting future stock prices based on historical data and current market trends.» — это всё-таки уже то, что вы называете forecasting, а в ML это чаще всё же называют time series analysis/modeling/predicting.
Это довольно разные задачи и они, совершенно определённо, различаются теми, кто занимается ML.
Кстати, что касается не-ML-специфичных терминов (таких как стэкинг, бустинг, кросс-валидация и т.д., которые относятся именно к ML), обычно вполне можно полагаться на термины, принятые в статистике. Та же регрессия наверняка в статистике описана довольно чётким и однозначным образом. Я бы полагался на хорошо устоявшийся статистический базис в таких вопросах.
По мне, так наличие словаря в формате wiki (на русском/английском языке), было бы весовым ответом на вынужденные «учительские потуги», тем более, что отвечая на наиболее каверзные вопросы, сам иногда теряешься в двух соснах… Спасибо за развёрнутый комментарий!
Добавлю ко вчерашнему обсуждению. Вот что написано в книге «Теория вероятностей и прикладная статистика. Т. 1. / Прикладная статистика. Основы эконометрики: Учебник для вузов: В 2 т. 2-е изд., испр., авторы Айвазян С.А., Мхитарян В.С.»:
Авторы прямо указывают, что термин регрессия в статистике не совсем корректно применяется. Более верный термин – регрессионный анализ.
Страницы книги
Авторы прямо указывают, что термин регрессия в статистике не совсем корректно применяется. Более верный термин – регрессионный анализ.
Распространён такой подход в ML, как попробовать все алгоритмы из sklearn, и либо задача решится сама ("и так сойдёт"), либо надо будет думать. Эта статья очень полезна, потому что сводит к минимуму первую стадию. И если дойдёт до второй, предстоит нелёгкий выбор:
- переставать решать такую задачу;
- погружаться в предметную область, в программирование, а то и в математику;
- подбирать контанты через gridsearch, докидывать слои в нейронки, пока не будет нужный уровень accuracy и всё такое, но только не вдаваться в подробности, не тратить на это время.
Последний способ мне кажется современной алхимией, потому что его последователи произносят заклинания типа "AdaBoost!", "RandomForest!", не разбираясь в том, что при этом происходит. Плохого в этом ничего нет: специалист останется ценен, а неспециалист не побежит получать инженерное образование, чтобы вернуться через 10 лет и начать решать задачи, зато сможет быстрее начать пробовать и тренироваться. Но всё же от такой алхимии до содержательных решений далеко.
Я согласен, что бояться библиотечных алгоритмов не стоит, но всё-таки изучать предметную область, природу данных и логику алгоритмов хотя бы на базовом уровне надо, чтобы не начинать загонять в XGBoost, случайные леса и свёрточные нейронки то, что прекрасно решается линейной регрессией (вдруг можно при помощи сложных методов выразить линейную функцию более качественно; я слышал о тех, кто реально так делает). С блиц-проверкой можно начать делать именно это. Но для первого знакомства с ML почему бы и нет)))
это применительно к соревновательному DS, когда нужно выжать дополнительные десятые доли процента в целевой метрике, потому и городят большие вещи, чтобы предугадать какая будет температура на земле в 2020 г:
в бизнесе по большей части нужы не инкрементальные доли процента, а совершенно другой подход — causal analysis, с проведением randomized controlled trial когда датасатанисты ставят эксперименты и находят первопричину наблюдаемых эффектов и численную величину эффекта. Это значит уходить от любимых фреймворков в «поле» — ближе к клиенту и бизнес процессам с ручкой и бумагой
в бизнесе по большей части нужы не инкрементальные доли процента, а совершенно другой подход — causal analysis, с проведением randomized controlled trial когда датасатанисты ставят эксперименты и находят первопричину наблюдаемых эффектов и численную величину эффекта. Это значит уходить от любимых фреймворков в «поле» — ближе к клиенту и бизнес процессам с ручкой и бумагой
Вылажил свой саморасширяющийся алгоритм машинного обучения «биморф» приглашают всех поучаствовать в тесте биморф.рф Алгоритм самостоятельно создает всю необходимую структуру по мере роста сети.
Sign up to leave a comment.
Блиц-проверка алгоритмов машинного обучения: скорми свой набор данных библиотеке scikit-learn