Эээ, а зачем нам такой второй класс? Давайте говорить о нормальных примерах, где все классы имеют смысл.
К сожалению, не все классы всегда хорошо разделимы, и встречаются классы, которые больше и хуже разделимы. И добавление более плохого класса ухудшает качество описанным способом. Крайний пример с шумом был приведен, чтобы продемонстрировать мысль, но вы перед началом задачи не знаете какой класс шумный, а какой нет, и это еще надо выяснять, например, описанным способом.
Получили решающее дерево. И? Как это на метрики-то повлияло?
Это влияет на постановку задачи: что от чего различается и это, естественно, определяет метрики. Непонятно, какого влияния вы ожидаете.
Вот у нас есть мультиклассификатор, черный такой ящик. Мы не знаем, что в нем — то ли OVR, то ли OVO, то ли дерево решений, то ли сетка. На входе — данные, на выходе — классификация. Так как же его внутренность влияет на метрики? (ну кроме возможности-невозможности смотреть на вероятности и их кривые
Вопрос в том, что вы подаете на обучение. Пример: есть три класса 1, 2 и 3, при этом класс 2 — это белый шум, куда по ошибке входят элементы и из 1го и 3го класса. В этом случае, строя классификатор 1 vs 3 (обучая только на элементах 1го и 3его класса), вы получаете условно «хорошие» значения метрик, а добавляя элементы класс 2 в классификатор, ухудшаете все метрики и классификатор выглядит плохим.
Тогда ваша взвешенная сумма ошибок — это (FN/(TP+FN))+(FP/(FP+TN)),
Не совсем — я имел ввиду, что просто количество ошибок это:
(FN+FP)/(TP+FN+FP+TN),
а взвешенное (w1*FN+w2*FP)/(TP+FN+FP+TN)
(ну, кроме OVR/OVO, но про это мы уже говорили)?
Кроме OVR и OVO, мы, например, можем обобщить и рассматривать один подмножества классов против других подмножеств классов в структуре. Например, сначала определить 1+2 vs 3+4 и или 1 vs 3+4 и 2 vs 3+4, — тут вопрос, какие классификаторы будут иметь большую точность и какими имеет смысл пользоваться. Если рассматривать крайнюю дилемму, то OVO – мало шума, но и мало данных для обучения (не используются другие сэмплы), OVR – много данных, но и может быть много шума, поэтому имеет смысл часто поподбирать именно какие подмножества классов против каких хорошо различаются.
Простите, а почему у вас в одном ряду стоит методология решения (OVR) и метрика оценки (кстати, что вы складываете в «сумме ошибочных предсказаний»?)?
Методология решения определит и метрики, которые можно демонстрировать. Сумма ошибочных предсказаний – это сумма sampl'ов в которых была допущена ошибка. Не очень понятен вопрос.
И как это на метрики влияет?
Это сводит нашу задачу мультиклассификации к задаче бинарной классификации, и дальше метрики уже можно выбрать исходя их этой задачи.
Точность (Accuracy) определяется как отношение верных ответов модели к общему числу ответов модели.
Есть модель, которая просто для всех людей предсказывает, что они не обратятся за страховым случаем (константая модель). Эта модель для 100 человек предсказала, что они не обратятся. Она была верной в 93 случаях – 93 человека и правда не обратились, таким образом, точность составила 93/100 = 93%.
В примере с метеоритом в постановке задачи не раскрываете период, за который считается вероятность, поэтому непонятно, откуда появляется прямо сейчас.
Вопросы с мультиклассом — это отдельная интересная область. Ее можно решать и как One vs. All, и как взвешенную сумму ошибочных предсказаний, и как (если) эти классы можно упорядочить, и как регрессию и прочие подходы.
На практике наиболее интересным и жизнеспособным для бизнеса является выделение множеств классов, которые хорошо или плохо отличимы друг от друга. Например, если мы говорим о поведении пользователя на сайте, то можно отличать человека который больше никогда не придет на сайт, от человека который зайдет завтра, но вводя третий класс: люди которые зайдут через 3 дня, но не зайдут завтра, мы теряем точность, т.к. этот третий класс перемешивается с обоими по сходным признакам.
Действительно, когда руководство решает, что пора внедрять DevOps, то оно берет с рынка DevOps-инженера. Но в этом варианте руководство уже понимает необходимость и выходы от DevOps (кто-то ранее уже продал им это) и DevOps-инженеру доказывать руководству нужность DevOps уже не надо. Он просто садится и пилит автотесты с тестировщиками, развертывает стенды и тд. Но суть от этого не меняется. DevOps-инженеру надо идти и выстраивать взаимоотношения с разработчиками и тестировщиками, а также погружаться в бизнес-процессы (чтобы хоть как-то понимать, как система работает). А если он этого делать не будет, то на развертывании Kubernetes все и закончится. Да и это уже не DevOps-инженер, а обычный админ, который решил себя назвать по-модному.
Спасибо!
Для отслеживания мы используем систему GPS-мониторинг. Сложность обычно в том, что система мониторинга работает как GPS-связь и на момент отсутствия связи накапливает данные, а потом выпускает на портал.
Периодически всех людей отслеживаем и обзваниваем.
Проблема бывает еще в том, что вызвать подмогу — это тоже несколько сотен километров и несколько часов езды.
Но, конечно, каждый водитель фиксирует время выезда и прибытия.
То что было рассказано – это случаи, которые имели место быть не на регулярной основе. При всем этом, температура –30 — это вполне обычная температура на северах, и ребята совершают рейсы по 2-3 раза в неделю, вполне уверенно работая в таких условиях.
Так и есть. Например, какая-то компания выиграла тендер и зашла на объект с новой техникой, отработала ей условно 5-10 лет, заработала свою «кучу денег» и уходит. Техника им не нужна, потому что на рынке спустя 5-10 лет она становится неликвидна, а заниматься перепродажей невыгодно из-за удаленности объекта от цивилизации. Вот они ее и закапывают безжалостно.
К счастью, в нашей работе специфика такова, что техника не настолько изнашивается — перевозим ее с места на место. Плюс изначально покупаем ее с дальним прицелом — чтоб надолго хватило.
В данном абзаце шла речь не конкретно про Новый Уренгой, а про Тюменскую область, в которую входит и ЯНАО, и ХМАО. Необходимость была вызвана производственными причинами, а не желанием геройствовать.
Какая разница, большая она или нет? Для грубой оценки нам всё равно выгоднее взять более быстрый алгоритм (во всяком случае вы пока не назвали ни одного аргумента, почему это не так).
Не совсем. При грубой оценке хочется выбирать наиболее приближенный к лучшему значению, если это сравнимо по времени.
Если утрировать, то самым быстрым алгоритмом тогда можно взять линейную регрессию и просто решающее дерево, однако это не даст вменяемый потолок.
Вопрос в балансе скорости получения результата и адекватности полученного результата. За счет быстроты работы к Lightgbm, например, быстрее подобрать гиперпараметры, однако если просто попробовать, без задания грида и as is, то это может быть не лучшим, т.к. нет уверенности что это не плюс-минус километр (как, например, при применении необученного RandomForest из scikit-learn).
Это миграция библиотеки для MatLab Torch на язык питон с сохранением функционала, грубо говоря. В данном обзоре мы рассматривали именно Python с упором на функциональную разницу.
К сожалению, не все классы всегда хорошо разделимы, и встречаются классы, которые больше и хуже разделимы. И добавление более плохого класса ухудшает качество описанным способом. Крайний пример с шумом был приведен, чтобы продемонстрировать мысль, но вы перед началом задачи не знаете какой класс шумный, а какой нет, и это еще надо выяснять, например, описанным способом.
Это влияет на постановку задачи: что от чего различается и это, естественно, определяет метрики. Непонятно, какого влияния вы ожидаете.
Вопрос в том, что вы подаете на обучение. Пример: есть три класса 1, 2 и 3, при этом класс 2 — это белый шум, куда по ошибке входят элементы и из 1го и 3го класса. В этом случае, строя классификатор 1 vs 3 (обучая только на элементах 1го и 3его класса), вы получаете условно «хорошие» значения метрик, а добавляя элементы класс 2 в классификатор, ухудшаете все метрики и классификатор выглядит плохим.
Не совсем — я имел ввиду, что просто количество ошибок это:
(FN+FP)/(TP+FN+FP+TN),
а взвешенное (w1*FN+w2*FP)/(TP+FN+FP+TN)
Кроме OVR и OVO, мы, например, можем обобщить и рассматривать один подмножества классов против других подмножеств классов в структуре. Например, сначала определить 1+2 vs 3+4 и или 1 vs 3+4 и 2 vs 3+4, — тут вопрос, какие классификаторы будут иметь большую точность и какими имеет смысл пользоваться. Если рассматривать крайнюю дилемму, то OVO – мало шума, но и мало данных для обучения (не используются другие сэмплы), OVR – много данных, но и может быть много шума, поэтому имеет смысл часто поподбирать именно какие подмножества классов против каких хорошо различаются.
Методология решения определит и метрики, которые можно демонстрировать. Сумма ошибочных предсказаний – это сумма sampl'ов в которых была допущена ошибка. Не очень понятен вопрос.
Это сводит нашу задачу мультиклассификации к задаче бинарной классификации, и дальше метрики уже можно выбрать исходя их этой задачи.
Есть модель, которая просто для всех людей предсказывает, что они не обратятся за страховым случаем (константая модель). Эта модель для 100 человек предсказала, что они не обратятся. Она была верной в 93 случаях – 93 человека и правда не обратились, таким образом, точность составила 93/100 = 93%.
В примере с метеоритом в постановке задачи не раскрываете период, за который считается вероятность, поэтому непонятно, откуда появляется прямо сейчас.
На практике наиболее интересным и жизнеспособным для бизнеса является выделение множеств классов, которые хорошо или плохо отличимы друг от друга. Например, если мы говорим о поведении пользователя на сайте, то можно отличать человека который больше никогда не придет на сайт, от человека который зайдет завтра, но вводя третий класс: люди которые зайдут через 3 дня, но не зайдут завтра, мы теряем точность, т.к. этот третий класс перемешивается с обоими по сходным признакам.
Для отслеживания мы используем систему GPS-мониторинг. Сложность обычно в том, что система мониторинга работает как GPS-связь и на момент отсутствия связи накапливает данные, а потом выпускает на портал.
Периодически всех людей отслеживаем и обзваниваем.
Проблема бывает еще в том, что вызвать подмогу — это тоже несколько сотен километров и несколько часов езды.
Но, конечно, каждый водитель фиксирует время выезда и прибытия.
То что было рассказано – это случаи, которые имели место быть не на регулярной основе. При всем этом, температура –30 — это вполне обычная температура на северах, и ребята совершают рейсы по 2-3 раза в неделю, вполне уверенно работая в таких условиях.
К счастью, в нашей работе специфика такова, что техника не настолько изнашивается — перевозим ее с места на место. Плюс изначально покупаем ее с дальним прицелом — чтоб надолго хватило.
Не совсем. При грубой оценке хочется выбирать наиболее приближенный к лучшему значению, если это сравнимо по времени.
Если утрировать, то самым быстрым алгоритмом тогда можно взять линейную регрессию и просто решающее дерево, однако это не даст вменяемый потолок.
Вопрос в балансе скорости получения результата и адекватности полученного результата. За счет быстроты работы к Lightgbm, например, быстрее подобрать гиперпараметры, однако если просто попробовать, без задания грида и as is, то это может быть не лучшим, т.к. нет уверенности что это не плюс-минус километр (как, например, при применении необученного RandomForest из scikit-learn).
Графики AUC vs время обучения в сравнении catboost с другими алгоритмами можно найти в этой презентации от Яндекса assets.ctfassets.net/oxjq45e8ilak/1NtBCBQxXCaAOwy8kumUKu/edccea9c32bdf119e10417367cc85602/_________________________________________CatBoost___________________________________________________________________________.pdf