Вопросы о машинном обучении: вердикт по критериям пригодности моделей

Формально результат выглядит внушительно. Для бизнеса он бесполезен.

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

Шесть групп метрик промышленной валидации

Зрелая оценка ML-модели состоит из нескольких слоёв. Каждый отвечает на свой вопрос. Хороший результат в одном слое не компенсирует провал в другом.

1. Качество решения задачи. Для классификации используют precision, recall, F1, AUC-ROC и MCC; для регрессии подходят MAE, RMSE и R²; для ранжирования применяют NDCG и MAP. Выбор метрики зависит от цены ошибки. Предсказать отказ клиента от подписки и обнаружить патологию на снимке можно как задачи классификации, но последствия пропуска или ложной тревоги у них разные.

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

3. Калибровка и неопределённость. Если модель выдаёт вероятность 87%, такие предсказания должны оправдываться примерно в соответствующей доле случаев. Когда модель регулярно ошибается при высокой уверенности, её вероятностный выход плохо откалиброван. Это имеет значение там, где решение зависит от порога или требует участия человека. Для оценки применяют, например, Brier score, диаграммы надёжности и expected calibration error.

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

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

6. Эксплуатационные SLO. Задержка ответа, доля технических ошибок и стоимость обработки запроса определяют, сможет ли модель работать в продукте. Алгоритм может быть точным, но слишком медленным или дорогим для выбранного сценария.

Метрика отвечает только на тот вопрос, для которого её выбрали. Пригодность модели проверяется по всей системе: от качества предсказаний до поведения сервиса под нагрузкой.

Ловушки единственного показателя

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

В таких задачах полезно смотреть на матрицу ошибок и метрики, учитывающие разные типы промахов. MCC (коэффициент корреляции Мэтьюса) использует все четыре значения матрицы ошибок: истинно положительные и отрицательные предсказания, а также ложноположительные и ложноотрицательные. Его диапазон простирается от −1 до +1: ноль указывает на отсутствие связи между предсказаниями и истинными метками, а +1 соответствует идеальному разделению классов. Это не универсальная замена другим метрикам, но хороший способ увидеть, не скрывает ли высокий accuracy пустую работу модели.

AUC-ROC измеряет, насколько хорошо модель ранжирует положительные примеры выше отрицательных при разных порогах классификации. Значение около 0,5 соответствует ранжированию на уровне случайного; более высокое значение говорит о лучшем разделении классов в рамках этой оценки. Однако AUC не показывает, сколько ложных тревог возникнет при конкретном пороге. При редком положительном классе модель может иметь внушительный AUC-ROC, но выдавать слишком много ложных срабатываний для реального процесса.

Интерпретировать AUC нужно с учётом задачи, распределения классов, последствий ошибок и выбранного рабочего порога. Значение, приемлемое для инструмента, который помогает оператору сортировать заявки, может оказаться недостаточным для автоматического решения с серьёзными последствиями. Поэтому универсальная граница, после которой модель можно объявить полезной или бесполезной, вводила бы в заблуждение. Порог пригодности задают требования конкретного продукта и отрасли.

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

Precision и Recall: выбор под цену ошибки

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

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

F-метрики помогают свести precision и recall к одному числу, но это не отменяет выбора приоритетов. F₂ сильнее учитывает recall, F₀.₅ даёт больше веса precision. Когда команда задаёт этот параметр, она фактически закрепляет решение о том, какая ошибка считается более приемлемой. Это решение стоит обсуждать с владельцами процесса, а не прятать в настройках модели.

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

Изоляция данных и предотвращение утечек

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

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

1. Тестовая выборка влияет на подбор модели. Если команда многократно смотрит на тестовый результат и меняет гиперпараметры, признаки или архитектуру, тест перестаёт быть независимой проверкой. Для настройки используют обучающую и валидационную части, а тест откладывают до финальной оценки.

2. В признаки попадает информация из будущего. Например, агрегат активности клиента рассчитывается за период, который выходит за момент предсказания. В обучающих данных модель получает подсказку, которой не будет в работе. Это разновидность look-ahead bias.

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

4. Связанные примеры оказываются по обе стороны разбиения. Если записи одного пользователя, сделки или сессии случайно попали и в обучение, и в тест, модель может распознавать знакомые особенности этих объектов. Для серийных данных полезно группировать записи по сущности, чтобы одна группа целиком оставалась в одной части выборки.

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

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

SLO, задержка и стресс-тесты

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

P95 показывает задержку, быстрее которой завершается 95% запросов. P99 описывает более медленную часть распределения: задержку, в которую укладывается 99% запросов. Среднее время способно скрыть редкие, но заметные задержки, поэтому хвост распределения важен для сервисов с жёсткими требованиями ко времени ответа.

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

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

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

Перед полным запуском используют несколько способов проверить систему на реальном потоке:

• Теневой режим. Новая модель получает реальные запросы, но её ответы не влияют на пользователей. Команда сравнивает предсказания с текущей системой и анализирует задержки.
• Канареечный запуск. Новую версию подключают к ограниченной доле трафика и постепенно расширяют её присутствие, если наблюдаемые показатели остаются приемлемыми.
• A/B-эксперимент. Новую модель сравнивают с контрольной группой по показателям продукта, например конверсии или удержанию. При этом нужно учитывать, что бизнес-результат может зависеть не только от качества предсказаний.

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

Дрифт данных и мониторинг после запуска

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

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

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

Мониторинг обычно включает несколько видов наблюдения:

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

Для сравнения распределений используют, например, KS-тест, PSI и KL-дивергенцию. Эти методы показывают изменения в данных, но сами по себе не сообщают, насколько изменился бизнес-результат. Сигнал о дрифте должен запускать разбор причин, а не автоматическую замену модели без проверки.

Регуляторный контур: ГОСТ и отраслевые стандарты

В регулируемых и критически важных областях оценка включает не только метрики, но и документированные процедуры, ответственность и мониторинг. Для медицинских систем применимость конкретных требований зависит от вида решения и его назначения. В российском контексте к профильным документам относятся серия ГОСТ Р 59921, включая части 59921.1-2022, 59921.7-2022 и 59921.9-2022, а также ГОСТ Р 71673-2024.

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

Универсального числового порога для F1, AUC или задержки нет. Его задают цена ошибки, сценарий использования и требования отрасли.

Пригодность начинается с контекста

Accuracy может скрыть бесполезную работу на несбалансированных данных. AUC-ROC описывает способность ранжировать примеры, но не показывает, сколько ошибок возникнет при выбранном пороге. Высокий precision или recall тоже не говорит сам за себя, пока неизвестно, какая ошибка дороже для пользователей и владельца процесса.

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

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