Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 21

Спасибо за статью!
Действительно проблемы сепуления встречаются сплошь и рядом.
Да и относятся не только к ML, а практически к любому проекту.
Всего голосов 1: ↑1 и ↓0+1
F1 score — это синтетический показатель объединяющий пользу от precisions и recall. Его самое хорошее значение вблизи 70%.

Почему 70 % лучше, чем, например, 95 %?

Всего голосов 1: ↑1 и ↓0+1
Здесь все дело в математике ) Хорошее значение precision — как можно ближе к 1 (это максимальное совпадение хороших выборов обучаемого и обучающего). Затем recall — хорошее значение 0.5 (это значит что обучаемый в равной степени хорошо проверен на способность различать хороший и плохой вариант). Теперь считаем: 2*1*0.5/(1+0.5) = 0.6(6). Округляем для красоты и получаем 0,7. Теперь если мы хотим получить значение 0.95, то мы должны загнать recall аж в значение 0.91, а это в свою очередь значит, что в контрольной выборке появится значительное превышение TP над FN (например 100 и 9 дадут нам нужное значение recall). Для нашего примера такое, явно недостаточное число порченных персиков в контрольной выборке, может породить сомнение, а так ли все хорошо с обучением? Или все дело в том, что просто мало порченных персиков.
Всего голосов 2: ↑1 и ↓10
Затем recall — хорошее значение 0.5

А, что? Хорошее значение recall — это единица, когда мы не даем false negative.


Для нашего примера такое, явно недостаточное число порченных персиков в контрольной выборке, может породить сомнение, а так ли все хорошо с обучением? Или все дело в том, что просто мало порченных персиков.

Извините, но порченные персики в контрольной выборке — это просто negative, не обязательно false negative.

Всего голосов 2: ↑2 и ↓0+2
сами испорченные персики — это и вправду negative, а вот то, что они были определены обучаемым, как испорченные — это false-negative
А теперь разберем 4 показателя эффективности ML, в которых бывает путаются. Это true-positive (TP), false-positive (FP), true-negative (TN) и false-negative(FN). Первая половина слова означает совпадение (true) или несовпадение (false) мнения вашей сестры с тайной наклейкой на персике. Вторая половина просто означает контейнер, в который ваша сестра бросила персик (X-хороший — positive, П-плохой — negative). А два слова вместе — это просто число персиков в такой категории.
Всего голосов 2: ↑1 и ↓10

Эм. Если у вас испорченные персики — это negative, то то, что они обучаемым определены, как испорченные (то, есть, определены правильно) — это заведомо true (потому что правильно) negative.

Всего голосов 1: ↑1 и ↓0+1
Вы абсолютно правы, я внес изменения в статью. Очень признателен вам за своевременно обнаруженную неточность, действительно ранее был описан совсем другой показатель вместо recall.
Всего голосов 2: ↑2 и ↓0+2
Затем recall — хорошее значение 0.5 (это значит что обучаемый в равной степени хорошо проверен на способность различать хороший и плохой вариант).

Это не так. У идеального классификатора значение recall = 1.


Если вы откроете хотя бы википедию, то увидите, что идеальное значение F1 также 1.

Всего голосов 1: ↑1 и ↓0+1
поправка: благодаря очень своевременному комментарию пользователя lair была устранена неточность в статье насчет recall (вместо него был описан другой показатель, который действительно используется для балансирования позитивных и негативных образцов). еще раз выражаю мои благодарности пользователю lair
Всего голосов 1: ↑1 и ↓0+1

Простите, а чем вот это всё, которое вы описали, отличается от совершенно не специфических для ML "приемочных критериев"?


Проект ML должен начаться с легитимации метрики валидизации.

Знаете, что занятно? Никогда, ни в какой литературе о ML-проектах я не видел этого термина. Можете дать ссылку на источник?


Важнейшим показателем текущего положения дел в проекте для менеджмента является accuracy.

А с чего бы вдруг? Люди копья ломают, подбирают метрику под конкретную бизнес-задачу — а вы так взяли, и легко выдали "важнейший показатель — accuracy".

Всего голосов 1: ↑1 и ↓0+1
я вроде так и написал:
Естественно, каждый проект ML в зависимости от своей предметной сферы будет иметь свою собственную метрику валидизации
Комментарий пока не оценивали0

Неа. Метрика валидизации — она до рассчета accuracy, потому что — ну, конечно, если вам верить — "валидизация" влияет на, собственно, обучающую и тестовую выборки, а accuracy считается по этим выборкам.


Ну либо вы так объяснили, что из вашего текста понятно совсем не то, что вы имели в виду.

Всего голосов 1: ↑1 и ↓0+1

Спасибо, я проходил курс МИФИ-Яндекса (в том числе и у Соколова), и то, что вы говорите, не совпадает с тем, что я там услышал. Как оно не совпадает и с тем, что говорит Эндрю Ын в "Structuring Machine Learning Projects".

Всего голосов 2: ↑2 и ↓0+2
Зачастую возникает вопрос: зачем менеджеру проекта ML так глубоко знать и понимать все эти показатели. Ответ: это важно для бизнеса. Как менеджеру молочной фермы нужно знать, что такое удои ...

Извините, нет. Современному менеджеру совершенно излишне знать смысл цифр, как они считаются и на что влияют, помимо его отчета. А если они не передаются «наверх» или клиенту, то и слышать об этих цифрах он не желает.

Если бы менеджер интересовался цифрами и формулами, то он не стал бы менеджером.

А за статью спасибо
Всего голосов 1: ↑1 и ↓0+1
Благодарю за чудесную формулировку проблемы, которую я, признаться, не решился вставить в тело статьи. Ведь вроде все правильно: современную цивилизацию сделало разделение труда и логично, когда программист пишет код, а менеджер организует рабочий процесс. На деле же уже давно прошли те благословенные времена, когда менеджер вмешивался в процесс разработки только, если проект выходил за рамки бюджета или срывал сроки. (народ: если есть еще те реликтовые места, где это так — я попрошусь к вам на работу:). Сейчас, даже делая внеплановую таску на 14 стори-поинтов, ее нужно обосновать менеджеру. А сделать это непросто и тимлиды бывает идут на хитрость: они делают в проекте эпик с эпичным названием «Онтология сепуления» на 120 стори-поинтов и все, что было не учтено сразу при планировании (а такое бывает часто) пишут на этот эпик, избегая тем самым непростых переговоров. Но у этого метода есть недостаток — нужно иметь дружную команду. Если туда затешется карьерист, он легко сдаст ТЛ и займет его место, и, кстати, сразу столкнется с той же проблемой, что и предшественник. Я же хочу предложить другой путь для ТЛ — фасилитацию, т.е. умение сложное объяснить простыми и ясными бытовыми примерами. И, если описанные в статье приемы пригодятся хоть одному человеку — напишите, я буду знать что это кому-то нужно, и продолжу серию.
Всего голосов 2: ↑1 и ↓10
В общем то не все менеджеры с двухбуквенным тайтлом одинаковы. ПМ и пм но есть одно но. Проджект менеджеру в общем случае этого не надо, это больше про софт скиллы, там у разумного ПМ девиз «найти толкового тимлида», а вот продукт менеджер просто обязан понимать влияние сепуления на продукт.
Комментарий пока не оценивали0
Позвольте с вами не согласиться — ПМ — это всего лишь жалкая копия Walther PP.\

— С уважением,
Генрих Мюллер, группенфюрер.
Комментарий пока не оценивали0
Это замечательная иллюстрация предмета статьи. В то время, как программер здесь видит совершенно очевидное и строгое определение, менеджер (см. пред комментарий) — кружочки в сомнительном цветовом сочетании.
Всего голосов 1: ↑0 и ↓1-1

Дадада, "очевидное и строгое определение".

Всего голосов 1: ↑1 и ↓0+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr