Почему одной метрики почти никогда недостаточно

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

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

Выбор метрики зависит от задачи не как от моды, а как от контракта. В бинарной классификации контракт часто звучит «не пропустить опасный класс» или «не засыпать оператора ложными тревогами». В компьютерном зрении — «боксы достаточно точны при нужном IoU». В OCR — «строка или поле совпали целиком». В поиске — «нужный документ в топ-K». В LLM и RAG — «ответ верен, полон, обоснован контекстом и не выдуман». Это разные оракулы; смешать их в «качество 0.93» — получить число без объяснения отката.

Практический пример из антифрода. Модель A даёт Accuracy 99,2%, модель B — 97,5%. Если мошеннических операций 0,5%, модель A может быть константой «легитимно», а модель B — реальной системой с Recall 80% на редком классе. Без Precision/Recall и без стоимости FP/FN сравнение бессмысленно. Тот же сюжет в контроле дефектов на линии: «всё годное» почти всегда выглядит сильным на Accuracy и бесполезно для качества продукции.

Обучение, проверка, тест и что считается ошибкой

Зачем три выборки

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

Утечка данных разрушает метрики тише, чем явный переобучение. Один и тот же документ в train и test после разных аугментаций, кадры одного видео в разных split, строки одной таблицы после случайного перемешивания при временной задаче, признаки, вычисленные с участием целевой метки — всё это делает отчёт оптимистичным. Тестовую выборку формируют так, чтобы она имитировала будущий вход: по времени, по устройству, по источнику, по клиенту — а не только по случайному проценту строк.

Отдельный benchmark, который не трогают ради «поднять цифру», — обязательный артефакт. Как готовить и версионировать данные под обучение и оценку — смежная тема инженерии датасетов.

Что именно мы считаем ошибкой

До выбора формулы договоритесь о единице учёта. Объект распознан правильно — один тип успеха. Объект найден, но класс неверен — другая ошибка (часто FP для одного класса и FN для другого). Объект пропущен — FN. Лишний объект — FP. В OCR ошибка в одном символе может быть лёгкой по CER и полной катастрофой по Exact Match для поля «сумма» или «номер паспорта».

В детекции «совпадение» обычно определяется порогом IoU между предсказанным и эталонным боксом. В сегментации — перекрытием масок. В ранжировании — попаданием релевантного элемента в первые K позиций. В RAG — наличием нужного фрагмента в контексте и корректным использованием его в ответе. Пока определение ошибки плавает, метрики разных команд нельзя сравнивать.

Классификация: Accuracy, Precision, Recall, F1 и матрица ошибок

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

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

Accuracy

Если 99% транзакций легитимны, модель, которая на всё отвечает «легитимно», почти не ошибается в среднем. Мошенничество при этом проходит целиком, и отчёт остаётся зелёным.

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

Доля верных ответов удобна, когда классы относительно сбалансированы, цена ошибок симметрична, а вопрос именно «как часто модель права в среднем». На редком положительном классе Accuracy вводит в заблуждение: доминирующий класс маскирует провал. Если 99% транзакций легитимны, константа «легитимно» даёт Accuracy 99% и Recall 0% по мошенничеству.

По Accuracy решают, можно ли выпускать модель по одному среднему проценту: при редком опасном классе — нет, пропуски смотрят отдельно.

Precision

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

Precision = TP / (TP + FP)

Precision отвечает: среди всех срабатываний модели какая доля истинна. Высокая цена ложных тревог — типичный случай для Precision: блокировка честного клиента, остановка линии из‑за ложного брака, эскалация безопасного запроса. Низкий Precision убивает доверие операторов быстрее, чем средний Accuracy.

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

Recall

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

Recall = TP / (TP + FN)

Recall отвечает: какую долю реальных положительных случаев модель нашла. Там, где пропуск дороже ложной тревоги — онкология на снимке, утечка секрета, критический дефект, мошенничество — Recall часто важнее Accuracy. Поднять Recall обычно значит снизить порог и принять больше FP; это не «ухудшение модели», а сдвиг рабочей точки.

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

F1-score

Одна модель почти не ошибается в тревогах и пропускает девять опасных случаев из десяти — тот самый перекос, где Precision близок к единице, а Recall около 0.1. Другая ловит почти всё и засыпает смену. Ни доля истинных тревог, ни доля найденных случаев по отдельности не скажут, какая ближе к рабочему компромиссу.

F1 = 2 × Precision × Recall / (Precision + Recall)

F1 — гармоническое среднее Precision и Recall. Оно штрафует сильный перекос: Precision 1.0 при Recall 0.1 даст низкий F1. Macro F1 усредняет F1 по классам поровну; Micro — через суммарные TP/FP/FN; Weighted — с учётом поддержки классов. Macro полезен, когда редкие классы важны сами по себе; Micro ближе к общей доле ошибок; Weighted может снова спрятать редкий класс.

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

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

Одна цифра F1 уже посчитана, а на платежах модель всё равно путает соседние классы решения. Без таблицы, кто с кем смешался, непонятно, копить ли примеры пары «одобрено / отклонено» или шум в других метках.

Confusion matrix показывает, какие классы путаются. Одна цифра F1 не скажет, что модель систематически меняет «3» на «8» или «одобрено» на «отклонено». Для мультикласса матрица и per-class Precision/Recall часто полезнее любого среднего: вы видите, куда вкладывать данные и аугментации.

По матрице ошибок решают, куда нести разметку: в пару классов, которую модель путает, а не в общее среднее.

Дисбаланс классов, ROC-AUC и PR-AUC

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

Дисбаланс классов — норма промышленных задач: брак, фрод, спам, редкий диагноз, редкий тип документа. Balanced Accuracy усредняет Recall по классам и не даёт доминирующему классу купить высокий балл. Macro F1 делает похожую услугу для F1. Но для ранжирующих вероятностных моделей дополнительно смотрят кривые.

ROC-кривая и ROC-AUC

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

ROC строится по TPR (тот же Recall) и FPR при изменении threshold. Площадь под кривой (ROC-AUC) оценивает способность модели ранжировать положительные примеры выше отрицательных в среднем по порогам. Это полезно для сравнения скореров. Слабое место: при очень редком положительном классе FPR может выглядеть маленьким даже при большом абсолютном числе ложных тревог, потому что отрицательных примеров огромное множество. ROC-AUC тогда «зелёный», а оператор тонет в FP.

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

Precision-Recall и PR-AUC

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

PR-кривая смотрит на Precision и Recall при разных порогах. PR-AUC чувствительнее к качеству на редком классе: каждый FP бьёт по Precision напрямую. Для фрода, дефектов и редких событий PR-AUC и рабочая точка на PR-кривой обычно информативнее ROC-AUC.

По PR-AUC и точке на кривой выбирают рабочий порог для редкого события, а не «зелёную» площадь, которая терпит толпу ложных тревог.

Почему AUC недостаточно для выпуска

Одинаковая AUC допускает разные пороги с разным Precision/Recall. Продукту нужна рабочая точка: выбранный threshold, ожидаемые FP/FN в сутки, очередь на разбор, SLA. Сравнивать модели только по AUC — сравнивать потенциал ранжирования, а не поведение системы после решения «сработал / не сработал».

Регрессия: MAE, MSE, RMSE, MAPE и R²

Отдел закупок спрашивает не «насколько модель умная», а насколько она промахивается по сроку и цене. Доля верных ответов здесь вообще не считается: цель — число, а не класс.

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

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

MAE = mean(|y - ŷ|) — средняя абсолютная ошибка, легко читается в исходных единицах и относительно устойчива к выбросам.

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

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

MSE = mean((y - ŷ)²) — сильнее штрафует крупные промахи; удобна математически, хуже интерпретируется напрямую.

По MSE решают, наказывать ли обучение за редкие большие промахи сильнее, чем за частые мелкие; в отчёт для бизнеса её одну не кладут.

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

RMSE = sqrt(MSE) — возвращает ошибку в исходную шкалу, сохраняя чувствительность к хвостам.

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

Процентная ошибка звучит для бизнеса привычно: «в среднем 8%». Она же разваливается, когда цена или срок близки к нулю, и по-разному штрафует завышение и занижение.

MAPE считает среднюю процентную ошибку. Она понятна бизнесу («в среднем 8%»), но ломается на значениях, близких к нулю, и асимметрична к завышению/занижению. Если целевая величина бывает нулевой или крошечной, MAPE — плохой единственный критерий.

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

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

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

По R² не принимают выпуск: высокая доля объяснённого разброса не заменяет допуск и поведение на дорогом крае шкалы.

Для регрессии в продукте часто важнее не средний RMSE, а квантили ошибки, доля предсказаний в допуске и поведение на стратах (регион, сегмент клиента, диапазон величины). Как и в классификации, среднее без структуры ошибок обманывает.

Компьютерное зрение: классификация, детекция и сегментация

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

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

Классификация изображений

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

Базовый слой тот же: Accuracy, Precision, Recall, F1, confusion matrix, per-class метрики. В крупных наборах с тысячами классов дополнительно используют Top-1 и Top-5 Accuracy: попал ли верный класс в первую или в пятёрку гипотез. Top-5 полезен для исследовательского сравнения и бесполезен, если продукту нужен один жёсткий ярлык без списка кандидатов.

Средняя метрика по классам легко скрывает провал на редком, но дорогом классе («огнеопасно», «персональные данные на снимке», «критический дефект»). Публикуйте per-class Recall/Precision вместе со средним — иначе оптимизация пойдёт в частые лёгкие классы.

Детекция объектов и IoU

Детектор отметил поле, но рамка захватила соседнюю колонку. Для человека «номер найден», для распознавания текста кроп уже чужой: в строку попадут лишние символы. Пока не измерено перекрытие рамки с разметкой, высокий процент найденных полей не говорит, годен ли документ.

IoU = Area(Intersection) / Area(Union)

IoU измеряет перекрытие предсказанного и эталонного бокса. Порог IoU (часто 0.5, иногда выше) решает, считать ли детект истинным совпадением. При низком пороге модель с «примерными» рамками выглядит сильной; при высоком — требуется точная геометрия, важная для кропа под OCR или для робототехники.

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

TP/FP/FN в детекции считаются по сопоставлению боксов, а не по пикселям картинки целиком. Один лишний бокс — FP; пропущенный объект — FN; бокс с верным классом, но слабым IoU — обычно FP плюс FN относительно эталона.

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

Average Precision (AP) интегрирует Precision-Recall для класса; mAP усредняет AP по классам. [email protected] считает совпадение при IoU ≥ 0.5. [email protected]:0.95 усредняет по нескольким порогам IoU и гораздо строже к качеству рамок. Модель может быть сильна по [email protected] и заметно слабее по [email protected]:0.95 — это сигнал «находит, но локализует грубо».

По паре [email protected] и [email protected]:0.95 решают, выпускать ли детектор в документный конвейер: сила только на мягком пороге значит, что рамки для кропа ещё грубые.

Сегментация

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

Pixel Accuracy снова опасна при маленьких объектах на большом фоне: «всё фон» даёт высокий процент пикселей. IoU / Jaccard и mean IoU (mIoU) смотрят на перекрытие масок по классам. Dice / F1 для масок:

Dice = 2|A ∩ B| / (|A| + |B|)

Dice связан с IoU монотонно, но иначе взвешивает пересечение; в медицине и малых структурах Dice часто привычнее как целевая метрика обучения и отчёта. Для тонких границ и мелких дефектов смотрите класс-wise Dice/IoU, а не только средний pixel score.

По Dice решают, годится ли маска для измерения мелкой структуры: на тонких дефектах её смотрят по классам, а не как средний процент пикселей.

OCR и распознавание документов

OCR — область, где наивная «точность символов» особенно часто врёт бизнесу. Практический разбор рукописных цифр и связки CNN/TrOCR — в заметке про OCR цифр.

Character accuracy и CER

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

Character accuracy — доля верно угаданных символов после выравнивания. Пример из отчёта: 158 / 223 = 70.9%. Это полезно для диагностики модели, но слабо как единственный KPI продукта.

CER = (S + D + I) / N, где S — замены, D — удаления, I — вставки, N — число символов в эталоне. CER учитывает редакторское расстояние и обычно информативнее «сырой» доли совпавших позиций без аккуратного выравнивания. Ниже CER — лучше; сравнивайте CER только на одном и том же определении нормализации (пробелы, регистр, юникод).

По CER решают, какая модель меньше правит эталон при одной и той же нормализации; по ней не решают, можно ли проводить поле в оплату без сверки.

WER и Exact Match

Для фразы в письме опечатка внутри слова часто ещё читается. Для номера счёта та же одна ошибка делает платёж чужим. «Ошибка на слово» и «строка совпала целиком» — разные приёмки, и для кодов вторая важнее.

WER = (S + D + I) / N на уровне слов. WER грубее к локальным опечаткам внутри слова и ближе к читаемости фразы. Для номеров, кодов и сумм WER менее естественен, чем CER и Exact Match.

По WER решают, читается ли фраза; для номера, кода и суммы выпуск принимают по полному совпадению строки, а не по ошибке на слово.

Exact Match Accuracy требует полного совпадения строки. Виньетка, которую стоит помнить каждому, кто внедряет OCR:

• эталон: 48291037;
• предсказание: 48291057 (ошибка в одном символе);
• character accuracy ≈ 87.5–90% в зависимости от длины и выравнивания;
• Exact Match = 0%.

Если поле — номер счёта, «почти правильно» равно «неправильно». Для форм с несколькими полями вводят field-level exact match и document-level exact match: доля документов, где все критичные поля верны одновременно.

Структурированный OCR и геометрия

В документном пайплайне ошибка бывает в тексте, в привязке к полю, в координатах бокса, в разборе таблицы, в постпроцессинге. Отдельно считают точность полей, качество детекции зон, устойчивость к пустым клеткам и повреждённым фрагментам. End-to-end accuracy документа — главный бизнес-оракул; CER по кропам — диагностический слой.

Пример отчёта для модели распознавания числовых значений на фиксированном benchmark:

Читается так: символы в среднем почти верны, но на длинных и сложных входах целые строки падают заметно чаще — именно это увидит бухгалтерия, а не CER.

NLP, LLM и RAG: что измерять отдельно

Ассистент отвечает гладко и не по договору: нужный абзац в поиске не всплыл, а модель дописала срок возврата из общих формулировок. Одна цифра «качество ответа» смешивает провал поиска и провал генерации, и чинить будут не ту ступень.

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

Классический NLP

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

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

Текстовая классификация использует тот же набор Accuracy/Precision/Recall/F1. Для sequence labeling (NER и подобные задачи) различают token-level F1 и entity-level F1: сущность «почти с тем же span» может быть верной по токенам и ошибочной как бизнес-объект. Entity-level обычно ближе к продукту.

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

В машинном переводе BLEU, chrF и COMET автоматические и масштабируемые, но ограничены: они не заменяют человеческую оценку на критичных доменах и плохо ловят смысловое отрицание. В генерации ROUGE/BLEU/BERTScore измеряют похожесть на эталон, а не истинность; perplexity — уверенность языковой модели в тексте, а не полезность ответа. LLM-as-a-Judge масштабирует разметку и требует калибровки. Подробная карта тестов — в проверке качества LLM; почему поверхностные метрики пропускают противоречие эталону — в разборе MATCHA.

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

Качество ответа LLM

Для продуктового ассистента полезно раскладывать свойства: correctness (верность), relevance (по делу ли), completeness (полнота), faithfulness / groundedness (опора на источники, отсутствие выдумок). Одно среднее «качество ответа» снова смешивает разные отказы.

RAG: retrieval и generation

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

Типичный конвейер: Question → Retrieval → Context → LLM → Answer. Ошибки на этапах независимы. Плохой поиск при сильной модели даёт уверенный ответ не на тех фрагментах. Хороший поиск при слабой генерации — правильный контекст и искажённый вывод.

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

Когда индекс молчит, растёт доля вопросов, на которые в контексте нет нужного фрагмента. Когда абзац найден, а ответ переврал срок, падает опора на источники при живом поиске. Эти два отказа не видны одной сквозной оценкой.

Метрики retrieval: Context Precision, Context Recall, Retrieval Recall, Hit Rate, MRR. Метрики ответа: Answer Relevance, Faithfulness, groundedness, точное совпадение фактов/полей где возможно. Сквозной успех нужен, но без разложения вы будете менять LLM, когда виноват индекс, или наоборот. Сборка эталонов — в золотом наборе RAG, инженерия цепочки — в production RAG.

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

Виньетка. Запрос: «какой срок возврата по договору 14-А?» Retrieval не кладёт нужный абзац в топ контекста — Context Recall падает, генерация честно или нет отвечает «из общих знаний». Другой случай: нужный абзац в контексте есть, модель меняет «14 дней» на «30» — Faithfulness падает при живом retrieval. Лечить эти два провала одним fine-tuning «на ответы» — дорогая путаница причин.

Ранжирование: Precision@K, MRR и NDCG

Сотрудник ищет регламент и смотрит первые строки выдачи. Документ глубоко в списке для него не существует, даже если в архиве он есть и формально подходит под запрос. Обычная доля верных ответов по всему корпусу здесь не про задачу: неподходящих документов почти бесконечно много.

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

Precision@K — доля релевантных среди первых K. Recall@K — какая доля всех релевантных попала в топ-K. Hit Rate@K — был ли хотя бы один релевантный в топ-K. MRR (Mean Reciprocal Rank) смотрит на позицию первого релевантного: чем выше, тем лучше. MAP усредняет точность по релевантным находкам. NDCG учитывает и позицию, и градуированную полезность: документ «идеально релевантен» на первом месте ценнее, чем на десятом.

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

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

Калибровка, порог решения и устойчивость

Модель пишет «0.9» на заявке, и правило проводит её само. Если среди таких заявок успех бывает заметно реже, чем обещает цифра, автоматика врёт, хотя классы модель разделяет неплохо. Уверенность и решение — разные вещи, и средняя доля верных ответов их не различает.

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

Калибровка уверенности

Модель может хорошо разделять классы и плохо говорить вероятность. Calibration curve сравнивает предсказанную вероятность с наблюдаемой частотой. Brier Score и Expected Calibration Error (ECE) численно оценивают рассогласование. Высокая Accuracy при плохой калибровке опасна там, где по score решают «автоматически принять / отправить человеку / отказать»: «0.9» должно означать примерно 90% частоты успеха, иначе автоматика врёт.

Threshold — не «магические 0.5»

Decision threshold превращает score в действие. Сдвиг порога двигает Precision и Recall в противоположные стороны. Выбор делают под бизнес-ограничение: максимум Recall при Precision ≥ X, минимум FP при Recall ≥ Y, стоимость очереди разбора. Универсального 0.5 нет: он осмыслен лишь если score калиброван и классы/цены симметричны — редкий случай.

Устойчивость и OOD

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

Fairness по группам

Общий F1 может скрывать провал на подгруппе: язык, регион, тип сканера, демографическая страта, источник трафика. Считайте per-group Accuracy/F1/Recall и раздельно FPR/FNR. Отдельная валидация по источникам данных — минимальная гигиена, даже если формальный аудит справедливости не требуется регулятором.

Производственные метрики: задержка, ресурс и стоимость

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

Пока в сравнение не входят время, очередь и цена одного документа, вы сравниваете стенды, а не сервис.

В сравнение входят не только доли верных ответов. Задержку смотрят как среднее и как хвосты: медиана (P50), уровень, который переживают 95% запросов (P95), и редкий хвост (P99). Именно P99 ломает ощущение «ответ мгновенный». Пропускная способность — сколько запросов, кадров или документов система успевает за секунду или за час — решает, успеет ли ночная партия. Загрузка процессора, видеокарты, памяти и диска ограничивает, сколько копий модели можно поставить рядом. Цена одного вывода, одного документа или тысячи предсказаний решает, выдерживает ли «лучшая» модель экономику.

Модель с +1% полного совпадения поля при троекратной цене и удвоении P95 может быть шагом назад для продукта. Сравнивать кандидатов без времени и цены — сравнивать стенды, а не сервис.

Сквозное качество против компонентных метрик

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

Пока нет цифры «документ целиком годен», команда чинит ступень с худшим отчётом и может промахнуться мимо поля, на котором бизнес теряет деньги.

Документный конвейер типичен:

Image → Detection → Crop → OCR → Postprocessing → Structured JSON

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

Допустим, detection mAP = 95%, OCR character accuracy = 97%, постпроцессинг «почти всегда» чинит пробелы. Документ целиком корректен лишь в 82% случаев: ошибки на этапах коррелируют слабо и множатся на критичных полях. Компонентные метрики нужны, чтобы знать, куда чинить. End-to-end метрика нужна, чтобы знать, можно ли выпускать.

Тот же принцип в RAG и агентах: hit rate поиска, верный tool call и корректный финальный ответ — разные слои. Управленческая рамка сквозной оценки — в evaluating enterprise AI; автоматизация барьеров — в ai-eval-harness.

Конвейер оценки и разбор ошибок

Цифра в отчёте уже посчитана, а через неделю прогон не повторить: тестовый набор подправили, ответы модели не сохранили, порог в ноутбуке другой. Без зафиксированного набора и сохранённых ответов «стало лучше» не отличить от другой выборки.

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

Рабочий конвейер оценки выглядит так:

Dataset → Validation split / fixed benchmark → Model inference → Predictions → Metrics → Error analysis → Report → Regression tests

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

Автоматизация — это скрипт оценки, сохранённые предсказания и метрики, сравнение прогонов и журнал экспериментов (MLflow, Weights & Biases или свой контур). Контрольный набор версионируют и не правят ради красивого отчёта. Ответы модели хранят: без них не разобрать, где система врёт, когда цифра уже посчитана.

Метрика показывает, сколько ошибок. Дальше их сортируют по уверенности, разбирают ложные тревоги и пропуски, частые пары путаницы, срезы по классам, источникам и сложности. Для распознавания текста отдельно смотрят рукописные цифры, пары 1/7, 3/8, 5/6, шум, наклон, пустые клетки, повреждённые поля. Для ответа по документам — запросы, где нужный фрагмент не попал в контекст, попал частично, спорит с другим фрагментом или требует отказа.

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

Как выбирать метрики и сравнивать модели

Две команды приносят «плюс один процент» и спорят, кто лучше. Пока не сказано, процент чего — доли верных ответов, пропуска брака или целиком верного поля — спор пустой. Сначала контракт задачи, потом строка таблицы, потом сравнение на одном и том же наборе.

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

Матрица задача → метрики

Почему 97% может быть хуже 90%

Сценарии из практики. Если мошенничества почти нет, 97% верных ответов у модели, которая всегда говорит «норма», хуже 90% у модели, которая реально ловит брак. Модель со средним похуже, но вдвое меньшим числом дорогих пропусков, для линии лучше. 97% угаданных символов хуже 90% полей, совпавших целиком, если бизнес считает номера и суммы, а не буквы. Общий F1 может вырасти, пока полнота по классу «опасный» падает. Лабораторный тест чище боя. Высокая средняя точность при врющей уверенности ломает автопорог. Модель «лучше по цифре» может не уложиться в срок ответа.

Главная идея: хорошая метрика — не обязательно высокая цифра. Хорошая метрика измеряет то, что важно системе.

Корректное сравнение двух моделей

Не ограничивайтесь Model A = 95% против Model B = 96%. Проверьте, что набор, подготовка входа, порог и сами метрики одни и те же, что интервал неопределённости сопоставим, и что рядом лежат задержка, память, цена и качество по классам. На маленьком тесте разница в один пункт часто лежит внутри шума. Повторная оценка и размер выборки — часть честности, не бюрократия.

Типичные ошибки и чек-лист

Модель «вдруг» стала лучше после того, как тестовые документы попали в обучение, или после того, как неудобные примеры вынули из теста. Отчёт зелёный, на бою — нет. Большая часть таких историй — про то, как посчитана цифра, а не только про архитектуру.

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

Типичные ошибки оценки нейросетей:

1. Считают качество только на обучающей выборке.
2. Одни и те же примеры попадают и в обучение, и в тест.
3. Тестовый набор слишком маленький.
4. Тестовый набор меняют после каждого эксперимента.
5. Смотрят только Accuracy.
6. Игнорируют перекос классов.
7. Не выбирают порог решения.
8. Смотрят только среднее, без разреза по классам и по источникам.
9. Не разбирают, какие ошибки повторяются.
10. Не меряют задержку в работе.
11. Не считают стоимость одного вывода.
12. Сравнивают модели на разных данных.
13. Нет зафиксированного контрольного набора.

Универсальный чек-лист перед публикацией модели

• Обучение, проверка и финальный тест разделены без утечки.
• Одни и те же примеры не сидят в двух частях.
• Контрольный набор зафиксирован и имеет версию.
• Метрики выбраны под цену ошибки, а не «как у всех».
• Есть исходный замер, с которым сравнивают.
• Есть разрез по классам и по источникам.
• Перекос классов учтён, если он есть.
• Ошибки разобраны, а не только усреднены.
• Проверены шум, другой сканер и чужой источник.
• Уверенность сверена с частотой, порог выбран.
• Задержка измерена, включая хвост.
• Измерено потребление ресурсов.
• Оценена стоимость одного вывода.
• Тот же скрипт оценки повторяет цифры.

Частые вопросы

Дальше по теме

• Проверка качества языковых моделей — какие тесты LLM существуют и что они реально измеряют.
• Контур оценки ИИ — как превратить метрики в CI, регрессию и критерии релиза.
• Золотой набор для оценки RAG — эталоны retrieval и ответа, а не экзамен «голой» модели.
• Промышленная инженерия RAG — где в цепочке рождается ошибка, которую метрика генерации не видит.
• Рукописные цифры: CNN и TrOCR — практический контур OCR и почему Exact Match строже символьной точности.
• Как оценивать корпоративный ИИ — связь качества, процесса и риска на уровне предприятия.
• Инженерия датасетов для ML — как данные и разметка определяют потолок любых метрик.

Заключение

Понять, что нейросеть «действительно работает», нельзя по одной красивой цифре из валидации. Нужен контракт ошибки, честный split, метрики под задачу, рабочий порог, разбор структуры провалов, проверка устойчивости и производственные ограничения. Accuracy, F1, ROC-AUC, IoU, mAP, CER, WER, NDCG, Faithfulness — это приборы; смысл появляется только когда ясно, какое утверждение о системе они подтверждают.

Для сложных пайплайнов держите два слоя правды: компонентный, чтобы чинить, и сквозной, чтобы выпускать. Evaluation dataset и скрипт оценки сделайте артефактами первого класса — наравне с весами. Тогда вопрос «насколько хороша модель?» дополняется вопросами «где она ошибается?», «почему?» и «можно ли доверять результату в production?» — а это уже инженерия, а не оптимизм отчёта.

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