Метрики классификации на несбалансированных данных: 7 альтернатив accuracy с примерами

Когда классы в данных распределены неравномерно, привычная accuracy часто создает опасную иллюзию качества. Модель может показывать 95% правильных ответов и при этом почти не находить редкий, но критически важный класс: мошенничество, дефекты, отток клиентов, просрочку, риск отказа оборудования. Именно поэтому метрики классификации нужно выбирать не по привычке, а по бизнес-смыслу ошибок.

Для аналитиков, руководителей направлений и IT-команд это не только вопрос качества модели, но и вопрос управляемости решений. Нужны не просто дашборды с итоговыми цифрами, а понятная среда, где можно быстро увидеть разницу между precision, recall, ROC-AUC и PR-AUC, объяснить ее бизнесу и регулярно отслеживать на доверенных данных.

С FineBI + Dora бизнес-пользователи и аналитики могут запрашивать разбор метрик в чате, получать chart-based answer или dashboard-style analysis view на основе доверенных BI-активов, а также получать scheduled summaries перед очередным обсуждением модели, риска или продукта.

Все дашборды в этой статье созданы с помощью FineBI

Почему accuracy вводит в заблуждение на несбалансированных данных

Что такое дисбаланс классов и почему высокая доля одного класса искажает восприятие качества модели

Дисбаланс классов возникает, когда один класс встречается намного чаще другого. Например:

• 99% транзакций нормальные, 1% мошеннические
• 97% клиентов не уходят, 3% уходят
• 95% изделий без дефекта, 5% с дефектом

В такой ситуации модель может просто предсказывать почти все объекты как большинство и все равно выглядеть “хорошо” по accuracy. Формально она будет права часто, но практически окажется бесполезной там, где важен поиск редких событий.

Accuracy считается так:

Accuracy = (TP + TN) / (TP + TN + FP + FN)

Где:

• TP — истинно положительные
• TN — истинно отрицательные
• FP — ложноположительные
• FN — ложноотрицательные

Проблема в том, что при сильном дисбалансе количество TN может доминировать в формуле. Из-за этого метрика растет даже тогда, когда модель плохо работает по важному положительному классу.

Пример, в котором модель показывает высокий accuracy, но пропускает почти все важные случаи

Представим задачу выявления мошенничества:

• всего 10 000 операций
• 100 мошеннических
• 9 900 нормальных

Модель предсказала все операции как нормальные. Тогда:

• TP = 0
• FN = 100
• TN = 9 900
• FP = 0

Accuracy будет равна:

(0 + 9900) / 10000 = 99%

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

Именно поэтому метрики классификации нельзя сводить к одной цифре.

Когда accuracy все же полезна и при каких условиях ей можно доверять

Accuracy не стоит полностью исключать. Она полезна, если одновременно выполняются несколько условий:

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

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

Метрики классификации, которые стоит смотреть вместо одной accuracy

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

Precision

Precision показывает, какая доля объектов, предсказанных как положительные, действительно является положительной.

Формула:
Precision = TP / (TP + FP)

Что показывает точность положительных предсказаний и где она критична

Если модель помечает клиента как “высокий риск”, precision отвечает на вопрос: как часто это правда.

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

• ручная проверка заявок
• дорогостоящая диагностика
• блокировка транзакций
• эскалация инцидентов
• приоритизация лидов отделом продаж

Если у модели низкий precision, команда будет тратить ресурсы на большое количество ложных тревог.

• Метрика: Precision
  Определение: Доля истинно положительных среди всех положительных предсказаний.
  Бизнес-ценность: Позволяет контролировать цену ложных тревог и не перегружать процессы обработки.
  AI use: Dora может по запросу извлекать precision из доверенных расчетов FineBI, сравнивать по сегментам и включать в периодические сводки.

Recall

Recall показывает, какую долю реальных положительных объектов модель смогла обнаружить.

Формула:
Recall = TP / (TP + FN)

Почему полнота важна, если цена пропуска положительного класса высока

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

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

Если recall низкий, модель пропускает слишком много значимых событий.

• Метрика: Recall
  Определение: Доля найденных положительных объектов среди всех реально положительных.
  Бизнес-ценность: Снижает риск пропуска критически важных случаев.
  AI use: Dora может отслеживать динамику recall по версиям модели, регионам или продуктовым сегментам и уведомлять о падении ниже контрольного уровня.

F1-score

F1-score — это гармоническое среднее precision и recall.

Формула:
F1 = 2 × Precision × Recall / (Precision + Recall)

Как F1-score балансирует precision и recall и когда ее удобно использовать

F1-score удобна, когда:

• важны и precision, и recall
• нельзя оптимизировать только одну сторону
• нужен компактный показатель для сравнения моделей

Гармоническое среднее наказывает модель, если одна из двух метрик сильно проседает. Поэтому F1-score полезнее простой средней.

Но важно помнить: F1-score не учитывает TN, а значит не всегда отражает поведение модели по отрицательному классу.

• Метрика: F1-score
  Определение: Сбалансированная сводная метрика между precision и recall.
  Бизнес-ценность: Удобна для выбора модели, когда и ложные тревоги, и пропуски одинаково важны.
  AI use: Dora может автоматически формировать сравнение моделей по F1-score и пояснять, за счет чего метрика выросла или упала.

Specificity

Specificity показывает, насколько хорошо модель распознает отрицательный класс.

Формула:
Specificity = TN / (TN + FP)

Зачем отдельно оценивать качество распознавания отрицательного класса

Эта метрика особенно полезна, когда важно не создавать лишние тревоги. Если recall смотрит на положительный класс, то specificity — на отрицательный.

Например:

• в медицинском скрининге specificity показывает, насколько редко здоровые пациенты ошибочно отправляются на дополнительное обследование

• в антифроде — насколько редко нормальные транзакции блокируются ошибочно

• в производстве — сколько качественных изделий не попадает в отбраковку

• Метрика: Specificity
  Определение: Доля правильно распознанных отрицательных объектов среди всех реальных отрицательных.
  Бизнес-ценность: Помогает контролировать ложноположительные срабатывания на уровне процесса.
  AI use: Dora может выводить specificity рядом с recall, чтобы бизнес видел обе стороны компромисса.

Метрики качества моделей бинарной классификации с порогами и без

Часть метрик зависит от выбранного порога классификации, а часть помогает оценивать качество ранжирования модели без фиксации одного порога. Это особенно важно, когда модель выдает вероятности, а не только 0 и 1.

ROC-AUC

ROC-AUC — это площадь под ROC-кривой, где по оси Y откладывается TPR (recall), а по оси X — FPR.

Что измеряет ROC-AUC и почему она полезна для сравнения моделей при разных порогах

ROC-AUC отвечает на вопрос: насколько хорошо модель в целом отделяет положительный класс от отрицательного по всем возможным порогам.

Преимущества ROC-AUC:

• позволяет сравнивать модели без жесткой фиксации одного порога
• полезна на этапе отбора алгоритма
• отражает качество ранжирования, а не только итоговой бинаризации

Но на сильно несбалансированных данных ROC-AUC иногда выглядит слишком оптимистично, потому что FPR может быть маленьким просто за счет очень большого числа отрицательных объектов.

• Метрика: ROC-AUC
  Определение: Площадь под ROC-кривой по всем порогам классификации.
  Бизнес-ценность: Подходит для первичного сравнения моделей по способности разделять классы.
  AI use: Dora может по запросу показать ROC-AUC для нескольких версий модели и дать краткое резюме, где модель устойчивее по порогам.

PR-AUC

PR-AUC — это площадь под кривой precision-recall.

Почему PR-AUC часто информативнее ROC-AUC на сильно несбалансированных выборках

Когда положительный класс редок, бизнесу обычно важнее понимать, как меняются precision и recall, а не FPR на фоне огромного числа отрицательных объектов.

Поэтому PR-AUC часто полезнее, если:

• редкий класс и есть главная цель модели
• важно качество top-кандидатов
• стоимость ложных тревог и пропусков требует тонкого баланса

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

• Метрика: PR-AUC
  Определение: Площадь под кривой precision-recall по всем порогам.
  Бизнес-ценность: Лучше показывает полезность модели на редком положительном классе.
  AI use: Dora может автоматически включать PR-AUC в обзор моделей для задач риска, антифрода, оттока и контроля качества.

Balanced Accuracy

Balanced Accuracy — это среднее между recall положительного и отрицательного классов.

Формула:
Balanced Accuracy = (Recall + Specificity) / 2

Как balanced accuracy учитывает оба класса и чем отличается от обычной accuracy

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

Если модель отлично распознает только отрицательный класс, но плохо — положительный, balanced accuracy это покажет сразу.

• Метрика: Balanced Accuracy
  Определение: Среднее качество распознавания положительного и отрицательного классов.
  Бизнес-ценность: Полезна как более честная замена accuracy на несбалансированных данных.
  AI use: Dora может использовать balanced accuracy как одну из базовых метрик в дашбордах мониторинга моделей.

Как выбирать метрику под бизнес-задачу

Выбор метрики — это не математическая формальность. Это перевод бизнес-риска в критерий качества модели.

Как стоимость ложноположительных и ложноотрицательных ошибок влияет на выбор метрики

Начинать нужно не с формулы, а с вопроса: какая ошибка дороже?

Если дороже ложноположительные ошибки, приоритет обычно у:

• precision
• specificity
• PR-анализу в области высоких precision

Если дороже ложноотрицательные ошибки, приоритет обычно у:

• recall
• sensitivity
• метрикам и порогам, уменьшающим FN

Если обе ошибки важны, смотрят на:

• F1-score
• balanced accuracy
• PR-AUC
• ROC-AUC для сравнения ранжирования

Примеры:

• Медицина: важнее recall, если опасен пропуск заболевания
• Антифрод: нужен баланс recall и precision, чтобы не пропускать мошенничество и не блокировать слишком много нормальных операций
• Скоринг заявок: важны recall по риску и specificity по хорошим клиентам
• Маркетинг: если коммуникация дорогая, может быть критичнее precision

Какие основные метрики задач классификации стоит сочетать, а не использовать по отдельности

Практически никогда не стоит смотреть только на одну метрику. Более надежный набор для бинарной задачи включает:

• Precision + Recall — чтобы видеть обе стороны ошибок
• F1-score — как краткий баланс
• Specificity — чтобы не игнорировать отрицательный класс
• PR-AUC — для редкого положительного класса
• ROC-AUC — для сравнения ранжирования модели
• Balanced Accuracy — как честную обзорную метрику

Для управленческой отчетности это можно свести к двум слоям:

1. Сводный слой: balanced accuracy, F1-score, ROC-AUC, PR-AUC
2. Операционный слой: precision, recall, specificity, порог, объем FP и FN

Именно здесь полезна BI-основа: метрики должны быть посчитаны одинаково для аналитиков, бизнеса и руководства.

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

Модель не существует сама по себе. Она встроена в процесс:

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

Поэтому метрики классификации должны быть связаны с:

• целями продукта
• стоимостью риска
• SLA процесса
• мощностью команд обработки
• допустимым числом ложных тревог
• последствиями пропуска

Для руководителей это значит одно: хорошая модель — не та, у которой “красивый accuracy”, а та, чьи метрики согласованы с реальной логикой принятия решений.

How an AI Data Agent Handles This Scenario

В enterprise-среде проблема обычно не в том, чтобы один раз посчитать precision или recall. Проблема в том, чтобы сделать эту аналитику повторяемой, объяснимой и доступной не только дата-сайентистам.

Здесь Dora выступает не как общий чат-инструмент, а как enterprise Data Agent поверх доверенной BI-основы. Для сценария оценки качества модели наиболее уместен цифровой сотрудник Data Analyst digital employee, а для регулярной отчетности — Report Researcher или Daily Briefing Secretary.

Сценарий типичен для аналитиков, IT-менеджеров, product owners и руководителей риска: нужно быстро понять, почему одна модель “лучше” другой, какую метрику брать в прод, и что изменится при смене порога.

Пример запроса в чате

“Покажи метрики классификации для модели антифрода за последний месяц: accuracy, precision, recall, F1-score, specificity, ROC-AUC, PR-AUC и balanced accuracy. Сравни с прошлой версией модели и выдели риски по порогу.”

Как Dora обрабатывает такой сценарий

1. Извлекает доверенные данные из FineBI
   Dora получает доступ к подготовленным в FineBI дашбордам, витринам, метрикам и semantic assets, связанным с моделью, выборкой, периодом и версией.

2. Понимает KPI-логики и бизнес-термины
   Dora учитывает, как в компании определены precision, recall, positive class, рабочий порог, сегменты, каналы, регионы и правила доступа.

3. Строит chart-based answer или dashboard-style analysis view
   По запросу Dora возвращает не просто текст, а структурированный ответ: таблицу метрик, сравнение версий модели, график по порогам, краткое резюме отличий.

4. Выявляет аномалии и отклонения
   Если recall резко упал, а precision вырос, Dora может отметить, что модель стала консервативнее и начала пропускать больше положительных случаев.

5. Делает push и alert ответственным пользователям
   При заданных правилах Dora отправляет scheduled summary продуктовой команде, аналитикам или руководителю риска, если метрика ушла ниже допустимого уровня.

6. Формирует follow-up для обсуждения
   Dora может подготовить краткую записку к встрече: какая модель лучше при текущем пороге, где выросли FN, какие сегменты требуют ручной проверки.

Какую роль здесь играет FineBI

FineBI — это основа доверия и управления:

• единые определения метрик
• подготовленные дашборды и витрины
• семантический слой
• права доступа
• повторяемые расчеты KPI
• визуальное исследование результатов

Без такой BI-основы AI-слой часто начинает отвечать нестабильно или на разных определениях одной и той же метрики. FineBI решает именно эту задачу: создает governed foundation, на которой Dora может работать как управляемый AI assistant.

Почему Dora дает практическую ценность в этом сценарии

Dora улучшает не только доступ к аналитике, но и исполнение:

• дает natural-language data query по доверенным BI-активам
• извлекает уже существующие дашборды и метрики из FineBI
• формирует chart-based answers вместо сухого текста
• рассылает scheduled summaries
• отслеживает anomaly alerts
• поддерживает follow-up после встреч и отклонений
• использует Skills-based execution для более контролируемого и аудируемого workflow

Для IT-команд это означает смену роли: меньше ручной сборки одноразовых отчетов, больше работы над подключениями, семантикой, качеством данных, правами и переиспользуемыми Skills. Для бизнеса — меньше трения при получении нужных метрик и меньше зависимости от очереди к аналитикам.

Практический разбор: сравнение метрик на одном примере

Ниже — простой пример, который показывает, почему выводы меняются в зависимости от выбранной метрики.

Предположим, у нас есть модель для поиска дефектных изделий.

• Всего объектов: 1000
• Положительный класс: дефект
• Реально дефектных: 50
• Реально нормальных: 950

Модель дала следующие результаты:

• TP = 30
• FN = 20
• FP = 40
• TN = 910

Матрица ошибок

Матрица ошибок:

Теперь считаем базовые метрики:

• Accuracy = (30 + 910) / 1000 = 0,94
• Precision = 30 / (30 + 40) = 0,43
• Recall = 30 / (30 + 20) = 0,60
• F1-score ≈ 0,50
• Specificity = 910 / (910 + 40) ≈ 0,96
• Balanced Accuracy = (0,60 + 0,96) / 2 = 0,78

Как по confusion matrix быстро получить базовые показатели качества

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

• сколько положительных случаев модель реально нашла
• сколько важных событий она пропустила
• сколько ложных тревог создала
• за счет чего получилась высокая accuracy

В нашем примере accuracy = 94%, но precision = 43%. Это значит, что больше половины объектов, отмеченных как дефект, на самом деле нормальные.

Сценарии интерпретации

Что изменится в выводах, если оптимизировать модель по recall, precision или F1-score

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

Если оптимизировать по precision
Список подозрительных объектов станет “чище”, но модель начнет чаще пропускать реальные дефекты. Это подходит, если ручная инспекция очень дорогая.

Если оптимизировать по F1-score
Получаем компромиссный режим, удобный, когда нужно одновременно ограничивать ложные тревоги и не терять слишком много положительных случаев.

Именно поэтому нельзя обсуждать модель вне контекста порога и стоимости ошибок.

Частые ошибки

Почему нельзя сравнивать модели только по одной цифре и игнорировать порог классификации

Самые распространенные ошибки при анализе качества модели:

1. Смотреть только на accuracy
   На несбалансированных данных это часто вводит в заблуждение.

2. Сравнивать модели без фиксации порога
   Одна и та же модель может давать очень разный precision и recall при разных threshold.

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

4. Не связывать метрики с процессом
   Хороший recall бессмысленен, если команда не способна обработать поток FP.

5. Считать метрики по-разному в разных отчетах
   Если определения классов, периода или сегмента отличаются, сравнение моделей становится ненадежным.

Actionable Best Practices

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

1. Стандартизируйте определения метрик и положительного класса

Одна из самых частых проблем — разные команды по-разному трактуют:

• что считать положительным классом
• какой порог принят рабочим
• как агрегировать метрики по сегментам
• какую выборку брать для сравнения

Это нужно фиксировать в BI-слое, а не в устных договоренностях.

2. Стройте семантический слой внутри BI-процесса

Если метрики классификации живут только в ноутбуках аналитиков, бизнес не получает устойчивого доступа к ним. FineBI позволяет перенести KPI, определения, срезы и dashboard logic в доверенную среду, где они переиспользуются без ручной интерпретации.

3. Начинайте с повторяемых AI-сценариев, а не с полной автоматизации

Не стоит пытаться сразу автоматизировать все вопросы вокруг моделей. Гораздо полезнее начать с сценариев с понятной ценностью:

• еженедельная сводка по quality metrics
• сравнение версии модели до и после релиза
• уведомление о просадке recall или PR-AUC
• подготовка краткой записки перед review-встречей

Это дает лучшую landing capability, чем абстрактное сравнение “AI-функций”.

4. Настройте alert thresholds, ответственность и follow-up

AI/Data Agent особенно полезен там, где нужен не только ответ по запросу, но и действие по регламенту:

• какое падение recall считается критичным
• кто получает уведомление
• кто подтверждает изменение порога
• кто отвечает за проверку сегментов
• как выглядит escalation path

Так Dora превращается в практический governed AI workflow, а не в эпизодическую подсказку.

5. Сохраняйте permission governance и human review

Даже хорошие AI-ответы не должны обходить правила доступа и контроля. В enterprise-среде важно, чтобы:

• Dora соблюдала границы доступа FineBI
• чувствительные данные не раскрывались лишним ролям
• AI-generated summaries проходили human review на первых этапах
• Skills расширялись постепенно, по мере стабилизации сценария

FineBI + Dora: как превратить анализ метрик классификации в рабочий enterprise-сценарий

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

Здесь связка работает так:

Building this manually is complex. FineBI helps teams build trusted dashboards, metrics, and semantic assets. Dora turns those assets into an AI assistant that can answer questions in chat, generate dashboard-style analysis views, push scheduled summaries, monitor anomalies, and follow up with responsible owners.

Для аналитиков это означает более быстрый доступ к разбору качества модели. Для IT — переход от ручной сборки каждого отчета к управлению подключениями, качеством данных, semantic layer и reusable Skills. Для руководителей — понятную картину риска и ROI по сценариям, где модели реально влияют на решения.

Важно и позиционирование AI-слоя:

FineBI + Dora is not only a BI upgrade; it is a practical fourth-generation Agentic BI path. FineBI provides governed metrics and visual analysis. Dora provides the AI assistant layer for scenario execution, with more controlled Skills, lower token waste, faster execution paths, and more stable workflows than prompt-only agents.

Иными словами:

• FineBI создает доверенную основу: дашборды, KPI, семантику, визуальный анализ
• Dora превращает эту основу в scenario-specific AI assistant или AI digital employee
• вместе они переводят работу из режима “люди сами ищут показатели в отчетах” в режим “AI помогает спросить, проанализировать, получить summary, alert и follow-up”

Получите готовые шаблоны дашбордов в Fine Gallery.

Сильнейшая подача Dora строится не вокруг абстрактного AI, а вокруг связки сценарий + продукт + сервис: FineBI дает доверенную BI-основу, Dora дает AI digital employee, а внедрение соединяет данные, governance, semantic setup, Skills и rollout.

Если вашей команде нужно не просто считать accuracy, а управляемо анализировать precision, recall, F1-score, ROC-AUC, PR-AUC и balanced accuracy на реальных бизнес-сценариях, связка FineBI + Dora дает для этого более практичный путь.