Машинное обучение и анализ: метрики точности и производительности моделей
Одна и та же модель YOLO26 nano обрабатывает кадр размером 640 пикселей за 38,9 мс при запуске ONNX на процессоре и за 1,7 мс через TensorRT на GPU NVIDIA T4. Входные данные и задача не меняются, а время ответа отличается более чем в двадцать раз.
Поэтому работу модели в продакшене нельзя оценить только по точности предсказаний: важны также задержка, пропускная способность и потребление памяти.
У ML-системы есть как минимум два слоя оценки. Статистические метрики показывают, насколько хорошо модель классифицирует объекты или предсказывает числа. Инженерные описывают, способна ли система выдавать эти предсказания с нужной скоростью и под реальной нагрузкой. Машинное обучение и анализ данных в сервисе начинаются с выбора метрик, которые учитывают оба слоя.
Классификация: почему Accuracy обманывает на несбалансированных выборках
Accuracy, или доля правильных ответов, рассчитывается так:
Accuracy = (TP + TN) / (TP + TN + FP + FN)
Здесь TP — истинно положительные результаты, TN — истинно отрицательные, FP — ложноположительные, FN — ложноотрицательные. Метрика показывает долю правильных ответов среди всех предсказаний. На сбалансированных выборках её удобно использовать как общую оценку. При сильном перекосе между классами Accuracy может выглядеть убедительно, даже когда модель почти бесполезна.
Например, доля мошеннических транзакций может составлять лишь небольшую часть потока. Классификатор, который объявляет все операции нормальными, при доле легитимных транзакций в 99% получит Accuracy 99%, но не обнаружит ни одного случая мошенничества. Похожая ловушка встречается при поиске редких заболеваний, сортировке инцидентов и фильтрации спама. Если редкий класс важен, общей доли правильных ответов недостаточно.
Полезнее посмотреть на несколько метрик, каждая из которых описывает свой тип ошибок:
- Precision, точность среди положительных предсказаний, отвечает на вопрос, какая доля объектов, помеченных моделью как целевые, действительно относится к целевому классу.
- Recall, или полнота, показывает, какую долю всех реальных целевых объектов модель смогла найти.
- F1-score — гармоническое среднее Precision и Recall: F1 = 2 × Precision × Recall / (Precision + Recall). Метрика снижает итоговую оценку, если одна из двух величин заметно отстаёт от другой. Это один из способов одновременно учитывать пропуски и ложные срабатывания, но не единственный.
- Fβ-score меняет баланс между полнотой и точностью. При β > 1 больший вес получает Recall, при β < 1 — Precision. Если важнее находить как можно больше инцидентов, даже ценой дополнительных ложных тревог, можно использовать F2. Если ложное срабатывание особенно дорого, может подойти F0.5.
Выбор метрики зависит от последствий ошибок. В антифроде высокая полнота помогает не пропустить подозрительные операции, но слишком низкая точность приводит к задержкам легитимных транзакций и дополнительной нагрузке на поддержку. В медицинском сценарии пропуск и ложная тревога тоже имеют разную цену. Поэтому сначала нужно определить, какая ошибка опаснее, а потом выбирать способ оценки.
| Метрика | Что измеряет | Что стоит учитывать | Где может пригодиться |
|---|---|---|---|
| Accuracy | Долю правильных ответов среди всех | Может скрывать провал на редком классе | Сбалансированные классы, первичная оценка |
| Precision | Долю верных среди положительных предсказаний | Снижается при избытке ложных срабатываний | Сценарии, где важна релевантность сигнала |
| Recall | Долю найденных объектов целевого класса | Снижается при пропусках | Поиск фрода, инцидентов и других редких событий |
| F1-score | Гармонический баланс Precision и Recall | Не отражает явно заданную цену разных ошибок | Сравнение моделей при равном внимании к обеим метрикам |
| Fβ-score | Баланс с приоритетом Precision или Recall | Значение β нужно обосновать задачей | Сценарии с более дорогим одним типом ошибки |
На несбалансированной выборке высокая Accuracy может говорить прежде всего о том, насколько часто модель угадывает самый распространённый класс.
Регрессия: MAE, MSE и коэффициент детерминации
Регрессионная модель предсказывает непрерывную величину: цену, объём продаж, температуру или время доставки. Для неё используют метрики ошибки, которые по-разному реагируют на крупные промахи.
MAE (mean absolute error, средняя абсолютная ошибка) — среднее абсолютное расстояние между предсказанием и фактическим значением. MAE, равная 35, означает, что средняя абсолютная ошибка составляет 35 единиц в шкале задачи. Это понятная метрика: её можно интерпретировать без дополнительного преобразования. При этом крупная ошибка влияет на MAE линейно.
MSE (mean squared error, средняя квадратичная ошибка) сначала возводит каждую ошибку в квадрат, а затем усредняет их. Большой промах из-за этого сильнее влияет на результат, чем несколько небольших. Такая метрика уместна, если крупные отклонения должны получать повышенный штраф. Но сравнивать MSE напрямую с исходными значениями неудобно: единицы измерения тоже оказываются возведены в квадрат.
RMSE — квадратный корень из MSE. Он возвращает результат в исходную шкалу, сохраняя повышенную чувствительность к крупным ошибкам. Если RMSE составляет 3,2 тыс. рублей, показатель выражен в рублях, хотя его нельзя автоматически трактовать как ошибку каждого отдельного прогноза.
R², или коэффициент детерминации, сопоставляет качество модели с предсказанием средним значением целевой переменной. В стандартной интерпретации R² = 0,85 означает, что модель объясняет 85% вариации на оцениваемой выборке относительно такого базового предсказания. R² = 1 соответствует идеальному совпадению, R² = 0 означает результат на уровне базовой модели со средним. Значение ниже нуля возможно, если модель на проверочных данных предсказывает хуже этого базового варианта.
| Метрика | Как устроена | Реакция на выбросы | Когда полезна |
|---|---|---|---|
| MAE | Среднее абсолютных ошибок | Крупные ошибки влияют линейно | Когда нужна понятная ошибка в единицах задачи |
| MSE | Среднее квадратов ошибок | Крупные ошибки получают больший вес | Когда особенно важны большие отклонения |
| RMSE | Квадратный корень из MSE | Сохраняет чувствительность MSE | Когда нужен масштаб целевой переменной с усиленным штрафом |
| R² | Сравнение модели с базовым предсказанием средним | Может сильно меняться при изменении данных | Для оценки объяснённой вариации и сравнения с базовым уровнем |
| MAPE | Средняя относительная ошибка в процентах | Проблемна при нулевых или близких к нулю значениях | Когда процентная ошибка имеет смысл и знаменатель не близок к нулю |
Универсально лучшей метрики для регрессии нет. Если небольшие промахи приемлемы, но единичные крупные сбои дорого обходятся, имеет смысл смотреть на RMSE. Если требуется понятная средняя погрешность в единицах задачи, обычно легче интерпретировать MAE. А R² отвечает на другой вопрос: насколько модель лучше или хуже простого прогноза средним. Его не стоит читать как прямую меру точности каждого отдельного предсказания.
Инженерные метрики: задержка, перцентили, пропускная способность
Задержка инференса, или Inference Latency, — время от получения запроса до выдачи результата. В неё могут входить предобработка данных, прямой проход модели и постобработка. Для изображения это может быть изменение размера и нормализация, затем вычисления в слоях нейросети, а после — декодирование и фильтрация результатов. В некоторых системах подготовка входных данных занимает сопоставимое с инференсом время, поэтому измерять только прямой проход недостаточно.
Среднее время и p50 — разные показатели. p50 — это 50-й перцентиль, то есть медиана: половина запросов обработана не медленнее этого значения, а другая половина — не быстрее. Медиана описывает типичную задержку устойчивее, чем среднее, на которое могут сильно влиять редкие долгие запросы. Но она не показывает, насколько неприятным бывает медленный хвост распределения.
Поэтому для сервисов смотрят и на высокие перцентили, например p90 и p99. Если p50 равен 20 мс, а p99 — 400 мс, то около 1% запросов обрабатываются за 400 мс или дольше. При тысяче запросов это примерно десять запросов, а не один. Если такие задержки повторяются, пользователь может воспринимать сервис как нестабильный, даже когда медиана выглядит хорошей.
В потоковой обработке изображений задержка связана с частотой кадров. При цели в 30 кадров в секунду на один кадр приходится примерно 33,3 мс. Модель, которая на целевом процессоре стабильно требует 40 мс только на инференс, не укладывается в этот бюджет. При этом в реальном контуре остаются ещё предобработка, передача данных и постобработка. Высокая точность не компенсирует нарушение ограничения по времени, если система должна отвечать в заданном ритме.
Кроме задержки, в продакшене полезно следить за несколькими инженерными показателями:
- RPS (Requests Per Second) показывает число запросов, обработанных за секунду. Сам по себе этот показатель не объясняет задержку: при росте нагрузки запросы могут накапливаться в очереди, и время ответа увеличится.
- Throughput, или пропускная способность, описывает число операций инференса за единицу времени. Для пакетной обработки важен общий объём работы, тогда как интерактивному API обычно критична задержка отдельного запроса.
- Загрузка CPU и GPU помогает понять, насколько близко система подошла к пределу вычислительных ресурсов. Постоянная высокая загрузка оставляет меньше пространства для всплесков нагрузки, но сама по себе ещё не говорит, что сервис нарушает SLA.
- Потребление оперативной памяти и видеопамяти важно для устойчивости процесса. Нехватка памяти может закончиться не постепенным замедлением, а аварийным завершением процесса или отказом принимать новые запросы.
Эти метрики стоит рассматривать вместе. Высокий Throughput в пакетном режиме не гарантирует низкую задержку для одиночного запроса. Низкая медиана также не обещает, что p99 укладывается в SLA. Системы мониторинга, например Prometheus, помогают собирать перцентили, RPS и загрузку ресурсов рядом, чтобы видеть не отдельное число, а поведение сервиса под нагрузкой.
p50 показывает медиану задержки, а p99 помогает увидеть, сколько времени ждёт самый медленный хвост запросов.
Аппаратная оптимизация: ONNX и TensorRT
Разница между 38,9 мс на CPU при исполнении ONNX и 1,7 мс на GPU T4 через TensorRT показывает, насколько среда исполнения влияет на результат. Сравнение полезно как иллюстрация, но его нельзя переносить на любую модель и конфигурацию: фактическая скорость зависит от оборудования, настроек, точности вычислений, размера пакета и включённых этапов обработки.
ONNX (Open Neural Network Exchange) — формат представления моделей, который упрощает перенос между инструментами и средами исполнения. Например, модель можно обучить в PyTorch, экспортировать в ONNX и запускать через ONNX Runtime. Такой подход удобен для совместимости, однако сам формат не гарантирует максимальную скорость на конкретном процессоре или ускорителе. Для производительности важны выбранный runtime и его оптимизации.
TensorRT — среда оптимизации и инференса для GPU NVIDIA. Она может перестраивать граф вычислений под поддерживаемое оборудование, объединять операции и использовать подходящие режимы вычислений. Например, переход с FP32 на FP16 может сократить требования к памяти и ускорить вычисления, но влияние на точность нужно проверять на конкретной модели и данных. Квантизация и другие преобразования тоже требуют повторной оценки качества, а не только замера скорости.
| Параметр | ONNX Runtime на CPU | TensorRT на GPU NVIDIA |
|---|---|---|
| Основное применение | Запуск переносимых моделей на процессоре | Оптимизация инференса на поддерживаемых GPU |
| Сильная сторона | Совместимость и выбор подходящего оборудования | Аппаратно-ориентированная оптимизация |
| Пример из материала | YOLO26 nano: 38,9 мс на CPU при входе 640 пикселей | YOLO26 nano: 1,7 мс на NVIDIA T4 при входе 640 пикселей |
| Что ещё нужно учитывать | Модель процессора, runtime, потоки и нагрузку | GPU, точность вычислений, сборку движка и настройки |
| Ограничение | Не всякая конфигурация обеспечивает нужный темп инференса | Привязка к экосистеме NVIDIA и конкретной среде исполнения |
Переход на GPU имеет смысл, если измеренная задержка на CPU нарушает требования SLA, а сокращение времени ответа оправдывает стоимость оборудования и эксплуатации. Для видеопотока с ограничением по частоте кадров ускорение может быть необходимым. Если же процессор укладывается в заданный бюджет, дорогая инфраструктура способна не дать заметной пользы продукту.
Сравнивать варианты следует на целевом железе и с тем же конвейером, который будет работать в сервисе. В замер стоит включать загрузку модели, подготовку входных данных, инференс и постобработку. Иначе можно оптимизировать прямой проход, но не получить заметного ускорения для пользователя. После экспорта или смены режима вычислений нужно повторно оценить и задержку, и метрики качества: ускорение не должно незаметно изменить поведение модели.
Точность предсказаний и ограничения SLA
В продакшене статистические и инженерные метрики приходится рассматривать одновременно. Универсального значения Accuracy, F1 или RMSE, которое подходит всем продуктам, нет: приемлемая ошибка зависит от последствий ложного срабатывания и пропуска. Для антифрода это может быть задержанная транзакция, для медицинского помощника — необходимость дополнительной проверки, для рекламного фильтра — потерянное сообщение. Поэтому одинаковое значение F1 может быть приемлемым в одном сценарии и недостаточным в другом.
Рабочий порядок оценки удобно выстраивать от ограничений к сравнению моделей:
1. Определить SLA. Зафиксировать допустимую задержку и перцентили, а для потоковой обработки — необходимую частоту кадров. Если ограничения нет, её трудно проверять в тестировании.
2. Выбрать целевую среду. Модель нужно измерять на процессоре или GPU, где она будет работать, с теми же настройками инференса, что и в продакшене.
3. Оценить ошибки на данных, похожих на реальные. Для классификации важно учитывать дисбаланс классов и цену пропуска или ложной тревоги. Для регрессии нужно выбрать метрику, которая отражает стоимость отклонений.
4. Измерить p50, p90 и p99 под нагрузкой. В тесте должны участвовать не только вычисления модели, но и сериализация, очереди, логирование и обработка результата.
5. Повторять проверку после изменений. Обновление весов, экспорт в другой формат, смена аппаратного обеспечения или переход на новый режим точности могут повлиять как на скорость, так и на качество.
Если модель не укладывается в SLA, можно упростить архитектуру, выбрать более быструю среду исполнения, изменить режим вычислений или пересмотреть требования к задержке. Если не хватает качества, можно менять признаки, данные, архитектуру и функцию потерь, а также подбирать порог классификации. Эти направления не всегда независимы: ускорение за счёт снижения точности вычислений способно ухудшить прогнозы, а более крупная модель может повысить качество ценой задержки и памяти.
Разговор о моделях машинного обучения и точности прогнозов поэтому не заканчивается одной таблицей результатов. Для осмысленного выбора нужен набор показателей: качество на проверочных данных, поведение на редких случаях, задержка по перцентилям и пропускная способность в условиях предполагаемой нагрузки. При этом инструменты анализа больших данных и ИИ помогают собирать такую картину, но не заменяют постановку задачи: команда должна заранее решить, какие ошибки допустимы и какой срок ответа приемлем.
В итоге модель выбирают не по единственному числу, а по сочетанию качественных и инженерных ограничений. Accuracy может скрыть провал на редком классе, медиана — хвост долгих ответов, а высокая пропускная способность — задержки отдельных запросов. Эффективность нейросетей в аналитике определяется тем, насколько хорошо они работают в конкретном сервисе: дают полезные предсказания, укладываются в SLA и сохраняют это качество под нагрузкой.