что такое метрики качества

Метрики в задачах машинного обучения

В задачах машинного обучения для оценки качества моделей и сравнения различных алгоритмов используются метрики, а их выбор и анализ — непременная часть работы датасатаниста.

В этой статье мы рассмотрим некоторые критерии качества в задачах классификации, обсудим, что является важным при выборе метрики и что может пойти не так.

Метрики в задачах классификации

Для демонстрации полезных функций sklearn и наглядного представления метрик мы будем использовать датасет по оттоку клиентов телеком-оператора.

Accuracy, precision и recall

Перед переходом к самим метрикам необходимо ввести важную концепцию для описания этих метрик в терминах ошибок классификации — confusion matrix (матрица ошибок).
Допустим, что у нас есть два класса и алгоритм, предсказывающий принадлежность каждого объекта одному из классов, тогда матрица ошибок классификации будет выглядеть следующим образом:

	True Positive (TP)	False Positive (FP)
	False Negative (FN)	True Negative (TN)

Здесь — это ответ алгоритма на объекте, а — истинная метка класса на этом объекте.
Таким образом, ошибки классификации бывают двух видов: False Negative (FN) и False Positive (FP).

Accuracy

Интуитивно понятной, очевидной и почти неиспользуемой метрикой является accuracy — доля правильных ответов алгоритма:

Эта метрика бесполезна в задачах с неравными классами, и это легко показать на примере.

Допустим, мы хотим оценить работу спам-фильтра почты. У нас есть 100 не-спам писем, 90 из которых наш классификатор определил верно (True Negative = 90, False Positive = 10), и 10 спам-писем, 5 из которых классификатор также определил верно (True Positive = 5, False Negative = 5).
Тогда accuracy:

Однако если мы просто будем предсказывать все письма как не-спам, то получим более высокую accuracy:

При этом, наша модель совершенно не обладает никакой предсказательной силой, так как изначально мы хотели определять письма со спамом. Преодолеть это нам поможет переход с общей для всех классов метрики к отдельным показателям качества классов.

Precision, recall и F-мера

Для оценки качества работы алгоритма на каждом из классов по отдельности введем метрики precision (точность) и recall (полнота).

Precision можно интерпретировать как долю объектов, названных классификатором положительными и при этом действительно являющимися положительными, а recall показывает, какую долю объектов положительного класса из всех объектов положительного класса нашел алгоритм.

Именно введение precision не позволяет нам записывать все объекты в один класс, так как в этом случае мы получаем рост уровня False Positive. Recall демонстрирует способность алгоритма обнаруживать данный класс вообще, а precision — способность отличать этот класс от других классов.

Как мы отмечали ранее, ошибки классификации бывают двух видов: False Positive и False Negative. В статистике первый вид ошибок называют ошибкой I-го рода, а второй — ошибкой II-го рода. В нашей задаче по определению оттока абонентов, ошибкой первого рода будет принятие лояльного абонента за уходящего, так как наша нулевая гипотеза состоит в том, что никто из абонентов не уходит, а мы эту гипотезу отвергаем. Соответственно, ошибкой второго рода будет являться «пропуск» уходящего абонента и ошибочное принятие нулевой гипотезы.

Precision и recall не зависят, в отличие от accuracy, от соотношения классов и потому применимы в условиях несбалансированных выборок.
Часто в реальной практике стоит задача найти оптимальный (для заказчика) баланс между этими двумя метриками. Классическим примером является задача определения оттока клиентов.
Очевидно, что мы не можем находить всех уходящих в отток клиентов и только их. Но, определив стратегию и ресурс для удержания клиентов, мы можем подобрать нужные пороги по precision и recall. Например, можно сосредоточиться на удержании только высокодоходных клиентов или тех, кто уйдет с большей вероятностью, так как мы ограничены в ресурсах колл-центра.

Обычно при оптимизации гиперпараметров алгоритма (например, в случае перебора по сетке GridSearchCV ) используется одна метрика, улучшение которой мы и ожидаем увидеть на тестовой выборке.
Существует несколько различных способов объединить precision и recall в агрегированный критерий качества. F-мера (в общем случае ) — среднее гармоническое precision и recall :

в данном случае определяет вес точности в метрике, и при это среднее гармоническое (с множителем 2, чтобы в случае precision = 1 и recall = 1 иметь )
F-мера достигает максимума при полноте и точности, равными единице, и близка к нулю, если один из аргументов близок к нулю.
В sklearn есть удобная функция _metrics.classificationreport, возвращающая recall, precision и F-меру для каждого из классов, а также количество экземпляров каждого класса.

Здесь необходимо отметить, что в случае задач с несбалансированными классами, которые превалируют в реальной практике, часто приходится прибегать к техникам искусственной модификации датасета для выравнивания соотношения классов. Их существует много, и мы не будем их касаться, здесь можно посмотреть некоторые методы и выбрать подходящий для вашей задачи.

AUC-ROC и AUC-PR

При конвертации вещественного ответа алгоритма (как правило, вероятности принадлежности к классу, отдельно см. SVM) в бинарную метку, мы должны выбрать какой-либо порог, при котором 0 становится 1. Естественным и близким кажется порог, равный 0.5, но он не всегда оказывается оптимальным, например, при вышеупомянутом отсутствии баланса классов.

Одним из способов оценить модель в целом, не привязываясь к конкретному порогу, является AUC-ROC (или ROC AUC) — площадь (Area Under Curve) под кривой ошибок (Receiver Operating Characteristic curve ). Данная кривая представляет из себя линию от (0,0) до (1,1) в координатах True Positive Rate (TPR) и False Positive Rate (FPR):

TPR нам уже известна, это полнота, а FPR показывает, какую долю из объектов negative класса алгоритм предсказал неверно. В идеальном случае, когда классификатор не делает ошибок (FPR = 0, TPR = 1) мы получим площадь под кривой, равную единице; в противном случае, когда классификатор случайно выдает вероятности классов, AUC-ROC будет стремиться к 0.5, так как классификатор будет выдавать одинаковое количество TP и FP.
Каждая точка на графике соответствует выбору некоторого порога. Площадь под кривой в данном случае показывает качество алгоритма (больше — лучше), кроме этого, важной является крутизна самой кривой — мы хотим максимизировать TPR, минимизируя FPR, а значит, наша кривая в идеале должна стремиться к точке (0,1).

Критерий AUC-ROC устойчив к несбалансированным классам (спойлер: увы, не всё так однозначно) и может быть интерпретирован как вероятность того, что случайно выбранный positive объект будет проранжирован классификатором выше (будет иметь более высокую вероятность быть positive), чем случайно выбранный negative объект.

Рассмотрим следующую задачу: нам необходимо выбрать 100 релевантных документов из 1 миллиона документов. Мы намашинлернили два алгоритма:

Скорее всего, мы бы выбрали первый алгоритм, который выдает очень мало False Positive на фоне своего конкурента. Но разница в False Positive Rate между этими двумя алгоритмами крайне мала — всего 0.0019. Это является следствием того, что AUC-ROC измеряет долю False Positive относительно True Negative и в задачах, где нам не так важен второй (больший) класс, может давать не совсем адекватную картину при сравнении алгоритмов.

Для того чтобы поправить положение, вернемся к полноте и точности :

Здесь уже заметна существенная разница между двумя алгоритмами — 0.855 в точности!

Precision и recall также используют для построения кривой и, аналогично AUC-ROC, находят площадь под ней.

Здесь можно отметить, что на маленьких датасетах площадь под PR-кривой может быть чересчур оптимистична, потому как вычисляется по методу трапеций, но обычно в таких задачах данных достаточно. За подробностями о взаимоотношениях AUC-ROC и AUC-PR можно обратиться сюда.

Logistic Loss

Особняком стоит логистическая функция потерь, определяемая как:

здесь — это ответ алгоритма на -ом объекте, — истинная метка класса на -ом объекте, а размер выборки.

Подробно про математическую интерпретацию логистической функции потерь уже написано в рамках поста про линейные модели.
Данная метрика нечасто выступает в бизнес-требованиях, но часто — в задачах на kaggle.
Интуитивно можно представить минимизацию logloss как задачу максимизации accuracy путем штрафа за неверные предсказания. Однако необходимо отметить, что logloss крайне сильно штрафует за уверенность классификатора в неверном ответе.

Отметим, как драматически выросла logloss при неверном ответе и уверенной классификации!
Следовательно, ошибка на одном объекте может дать существенное ухудшение общей ошибки на выборке. Такие объекты часто бывают выбросами, которые нужно не забывать фильтровать или рассматривать отдельно.
Всё становится на свои места, если нарисовать график logloss:

Видно, что чем ближе к нулю ответ алгоритма при ground truth = 1, тем выше значение ошибки и круче растёт кривая.

Подытожим:

Полезные ссылки

Благодарности

Спасибо mephistopheies и madrugado за помощь в подготовке статьи.

Источник

Наука о данных. Модуль 6

Как проверить качество модели с помощью метрик

В предыдущих модулях мы прошли все основные шаги от постановки цели до создания обучающей выборки и тренировки алгоритмов.

В этом модуле вы узнаете:

• как с помощью метрик понять, насколько хорошо работает модель;
• какие метрики подходят для задач регрессии и классификации и в чем основные плюсы и минусы каждой;
• как выбрать метрику для проекта.

Оглавление

Модуль 6. Как проверить качество модели с помощью метрик

Почему мы выбираем метрику на самом старте проекта

Ваше сотрудничество с дата-сайентистом — это вариант отношений «заказчик — подрядчик», а о ключевых вещах и показателях в этом случае принято договариваться «на берегу». Метрика — один из таких ключевых показателей: с ее помощью вы будете оценивать результат работы алгоритма. Поэтому в процессе первоначального обсуждения проекта вопрос о метрике всплывет обязательно.

Давайте вспомним общую схему, по которой можно вести диалог и формулировать запрос к специалисту, и уточним ее, добавив в конец еще один шаг — выбор метрики. Чтобы вам было проще, разберем все на примере:

1. Определите бизнес-задачу

Вы: Компании нужно поднять выручку на 5% до конца года и…

2. Расскажите о конкретных шагах по ее достижению

Вы: … и для достижения этой цели мы хотим допродавать существующим клиентам цифровые продукты, которые будут удачно сочетаться с теми, что они уже у нас покупают. Но чтобы вероятность дополнительной покупки была высокой, рекомендации продуктов должны быть по-настоящему релевантными и качественными (по прикидкам отдела маркетинга, чтобы достичь показателей, мы должны убедить каждого десятого клиента).

3. Определите, можно ли решить задачу с помощью машинного обучения

Дата-сайентист: Можно проанализировать текущую базу клиентов, выявить их поведенческие паттерны и объединить клиентов со схожими паттернами в отдельные сегменты. Затем для каждого сегмента подобрать наиболее релевантные услуги или товары.

4. Определите, что у вас с данными, целевой переменной, объектами и прочим

Вы: У нас есть CRM (англ. Customer Relationship Management, система управления взаимоотношений с клиентами) и другие источники данных о клиентах — мы знаем, что и с какой частотой они покупали ранее, откуда они, какими еще услугами и продуктами компании пользовались или пользуются в их домохозяйстве.

Дата-сайентист: По идее, мы можем набрать достаточно признаков, а модель сама определит их веса и сгруппирует клиентов. Здесь угадывается задача кластеризации.

5. Определите метрику качества

Дата-сайентист: Итак, решено: мы строим рекомендательную систему. Остается понять, как мы определим, что алгоритм подсказывает именно то, что нужно людям? По какой метрике будем оценивать качество?

Чтобы вы могли ответить на этот вопрос, в модуле мы изучим основные метрики машинного обучения.

Метрики для задач регрессии: какие бывают, плюсы и минусы

Любой прогноз может быть не на 100% точен, а вот какое отклонение допустимо, решаете вы, исходя из задач и целей бизнеса. В этом видео Элен расскажет о пяти популярных метриках для работы с числовыми прогнозами и о том, как они помогают выявлять расхождения между оценкой модели и реальностью и «штрафовать» алгоритм за слишком неточные предсказания. Как всегда — с примерами.

Источник

А не фигню ли я опять делаю? Как и зачем внедрять метрики качества

Привет, Хабр! Когда-то мы использовали метрику «Вроде бы стало лучше» для оценки качества наших релизов. Но потом мы решили довериться чему-то более надёжному. В этой статье я расскажу о том, как искал гайд по метрикам, не нашёл и создал свой.

Бывает ли у вас такое, что вы делаете вроде бы полезную работу для проекта, но не понимаете, приносит ли это пользу? Вот и мы когда-то писали автотесты, но не могли объективно сказать, стали ли лучше релизы монолита и других сервисов, в которых ведётся активная разработка.

В поисках метрик

Я посмотрел в интернете и почему-то не нашёл статей или готовых гайдов о том, как выбирать правильные метрики, как их собирать и что с ними дальше делать. Но пока искал информацию, нашёл полезные видео и статьи, которые помогли мне справиться с этой непростой задачей. Ссылки на них будут появляться в статье.

Надеюсь, что эта статья будет полезной для тех, кто задумался об измерении чего угодно на своем проекте, но не знает, с чего начать. В статье содержится личный опыт, информация из статей, видео и платных курсов.

До того, как мы решили создать систему метрик качества, мы уже на постоянной основе измеряли:

Внедряем систему измерения качества за 11 шагов

Перед вами чек-лист из 11 шагов, который поможет внедрить всё и не упустить ничего.

Шаг 1. Определите цель своих измерений

Поймите, для чего вы хотите начать измерять что-либо. Измерять просто так, ради измерений, не имеет смысла.

Мы, например, хотели знать, как движемся к целям по качеству, которые поставили себе ранее. Ещё мы хотели видеть динамику показателей после приложенных усилий. Сами по себе цифры текущего состояния ничего не значат. Это просто цифры. Но, наблюдая цифры в динамике, мы можем видеть влияние наших действий.

Шаг 2. Определите целевые показатели

Вам нужно понять, к чему вы стремитесь. Сократить время тестирования? Сократить количество критичных багов в проде? Повысить тестовое покрытие?

В моём случае с определением целевых показателей проблем не возникло, так как в нашей компании есть цели по качеству. Эти цели и стали основой будущих метрик. Наши цели:

Шаг 3. Определитесь с метриками

Подумайте, как вы поймёте, что движетесь к целевым показателям.
На этом этапе работы мне помогла статья «Самые важные метрики QA».

Это время мы разбили на 4 этапа: подготовка стенда, озеленение стейдж пайплайна, ручное регрессионное тестирование, деплой на прод.

Мы разбили это время на этапы, чтобы детально видеть последствия наших действий и иметь возможность точно определить бутылочное горлышко в нашем процессе.

Важно! Не берите сразу много метрик. Три-четыре для начала достаточно. Когда процесс наладится, сможете добавить ещё, если это потребуется.

Много метрик сложно менеджерить. Растёт вероятность, что система не взлетит. А если процесс не взлетит с первого раза, то в следующий раз начинать будет сложнее, так как у вас и сотрудников за плечами будет негативный опыт.

Шаг 4. Определитесь с единицами измерения

Разные показатели можно считать в разных единицах измерения. Сразу нужно выбрать, чтобы у всех метрик была одна единица измерения, иначе можно столкнуться с непониманием и неправильным толкованием.

С этим пунктом у нас возникли проблемы. Время релиза мы считали в часах, включая ночные часы, но за исключением выходных дней. При этом целевое значение было – релиз за 4 часа. Довольно часто случались ситуации, когда мы создавали ветку release-xxx в 16:00 сегодняшнего дня, а заканчивали в 10:00 следующего дня. В нашей метрике считалось 18 часов, но по факту, активные действия проводились всего 3 часа, если не меньше.

Если бы мы продолжали считать таким образом, то никогда не достигли бы показателя «4 часа» по нашей метрике. Встав перед выбором, увеличить цель до 12 часов или брать в учёт только рабочие часы, мы выбрали второе.

Шаг 5. Анализ выбранных метрик на пригодность

В видео «Простые метрики тестирования на практике» спикер предложил крутой способ анализа метрик на пригодность. Нужно ответить на 9 вопросов по каждой метрике и принять решение.

После такого нехитрого анализа сразу становится ясно, нужна ли вам эта метрика или нет. Появляется более глубокое понимание самой метрики и её ценности для компании и вас.

Шаг 6. Согласуйте метрики с заинтересованными лицами

Покажите выбранные метрики тем, кого они будут затрагивать. Обсудите ограничения, которые вы выяснили на этапе анализа, а также способы их устранения или хотя бы снижения. Особенно важно получить согласие и одобрение тех, кто эти метрики будет собирать и заполнять.

Свои метрики я обсуждал в 3 этапа: с тестировщиками, разработчиками и продакт оунерами. Только после того, как все дали явное согласие, что эти метрики показывают качество системы, я смог перейти к следующему шагу.

Шаг 7. Визаулизируйте результаты

Люди не будут вчитываться в таблицы и смотреть динамику самостоятельно. Поэтому вам нужно позаботиться о наглядности.

Я сделал таблицу в Google Sheets, написал формулы и довольный хотел презентовать таблицу коллегам. Наш CTO предложил визуализировать эти метрики. Точнее сделать так, чтобы за 15 секунд было понятно текущее состояние системы: стало ли лучше по сравнению с прошлым спринтом или качество снизилось.

Совместными усилиями мы визуализировали показатели. Потом я попросил людей рассказать, что они увидели на этом графике. Судя по ответам, цели мы добились.

Вот как выглядит визуализация метрики «Качество релизов». Всё наглядно, сразу видно, как сейчас и как было, превышает ли количество проблем количество релизов, стало лучше или хуже по сравнению с предыдущими релизами. В идеальном графике, синяя линия должна стремиться к бесконечности, а красная должна стремиться к 0.

Визуализация отношения «проблемных релизов» к общему количеству релизов

Шаг 8. Соблюдайте периодичность сбора метрик

Важно наладить процесс сбора метрик, поработать над периодичностью. Если процесса не будет, то ваш дашборд потеряет актуальность и умрёт. Важно, чтобы были заинтересованные лица, которые будут этим заниматься. Но если вы озаботились этим, значит заинтересованное лицо уже есть.

Шаг 9. Снова и снова информируйте людей о полученных результатах

Какой бы ни был красивый ваш дашборд, люди не будут туда ходить и смотреть на метрики. Один раз все посмотрят, так как это что-то новенькое, но не на постоянной основе.

Шаг 10. Анализируйте и принимайте решения

Нужно смотреть на метрики, на их основании принимать решения. Можно использовать метрики, как дополнительный аргумент в пользу написания дополнительных тестов или фокусировке на техническом долге, а не на бизнес фичах и т.д.

Шаг 11. Автоматизируйте

Максимально автоматизируйте сбор метрик. Если вы используете популярные TaskMS и TestMS системы контроля версий, системы CI/CD, скорее всего, у них у всех есть открытое API, с помощью которого можно легко вытаскивать эту информацию. Если не умеете сами, просите помочь разработчиков. Возможно, для этого придется изменить некоторые процессы. Это нормально. И это малая цена за те преимущества, которое вы получите, начав собирать метрики.

Например, у нас есть бот, которой помогает релизменам катить релиз и сокращает их рутинные действия.

Итоги и выводы

Принимать решения, которые повлияют на качество продукта, основываясь на ваших внутренних чувствах – плохая затея. Чувства могут обмануть и подтолкнуть вас к неправильному решению. Поэтому просто заведите метрики и систему оценки качества.

Но помните, что заведение метрик – как заведение питомца. Кроме профита от общения с новым другом, вы получаете определённую ответственность и обязательства перед ним. Поэтому заводите метрики осознанно, с пониманием их необходимости и готовностью к преодолению сложностей, ожидающих вас на пути.

Источник