Ключевые выводы

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

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

Дисбаланс классов ломает наивные проценты. Модель, которая всегда говорит «норма», легко набирает 99% Accuracy и одновременно пропускает почти все опасные случаи. Там, где положительный класс редок, смотрят Precision, Recall, F1, PR-AUC и матрицу ошибок, а не одно среднее.

Компонентные метрики не складываются в сквозной успех. Detection mAP 95% и OCR character accuracy 97% могут дать лишь 82% полностью корректных документов. Для документов, RAG и мультиэтапных конвейеров обязательны и разложение по этапам, и end-to-end метрика.

Порог, калибровка и стоимость — часть модели. Одна и та же ROC-AUC допускает разные рабочие точки. Без выбранного threshold, без проверки уверенности и без учёта задержки и цены вывода вы сравниваете не продукты, а лабораторные графики.

Разбор ошибок важнее красивого среднего. Метрика говорит сколько, error analysis отвечает где и почему: путаница классов, рукописные «1/7», пустой retrieval, необоснованная генерация. Без этого вы оптимизируете число, а не систему.

Набор оценки — такой же артефакт, как веса модели. Версионирование, запрет подгонки теста, воспроизводимый скрипт и отчёт с ограничениями превращают «кажется, стало лучше» в управляемый выпуск. Близкая рамка для LLM — в проверке качества языковых моделей, для контура CI — в harness оценки ИИ.

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

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

На тестовой выборке вы измеряете обобщение при фиксированном распределении и фиксированной разметке. В продукте появляются дрейф входных данных, другой баланс классов, ручные правки оператора, таймауты, деградация сканера и смена политики. На отдельных этапах 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, validation, test и что считается ошибкой

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

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

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

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

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

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

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

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

Accuracy

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

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

Precision

Precision = TP / (TP + FP)

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

Recall

Recall = TP / (TP + FN)

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

F1-score

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

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

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

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

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

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

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

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

Precision-Recall и PR-AUC

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

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

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

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

Когда цель — число (цена, срок, температура, вероятность как регрессия), набор метрик другой.

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

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

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

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

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 или для робототехники.

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

Average Precision (AP) интегрирует Precision-Recall для класса; mAP усредняет AP по классам. mAP@0.5 считает совпадение при IoU ≥ 0.5. mAP@0.5:0.95 усредняет по нескольким порогам IoU и гораздо строже к качеству рамок. Модель может быть сильна по mAP@0.5 и заметно слабее по mAP@0.5: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.

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 только на одном и том же определении нормализации (пробелы, регистр, юникод).

WER и Exact Match

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

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 на случайной подвыборке пар — частая методологическая ошибка.

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

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

Модель может хорошо разделять классы и плохо говорить вероятность. 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, обрезанном поле, другом устройстве съёмки или другом домене текста. Stress-наборы сравнивают деградацию относительно baseline. In-distribution test, out-of-distribution test, cross-domain / cross-device / cross-source evaluation показывают, не купили ли вы метрику случайным split внутри одного источника. Случайный train/test на кадрах одной камеры часто оптимистичен относительно новой камеры в цехе.

Fairness по группам

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

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

Качество модели в проде — не только ML-цифры. Latency: среднее, P50, P95, P99. Хвост P99 часто важнее среднего: именно он ломает UX и укладывается ли ответ в интерактивный сценарий. Throughput — requests/sec, images/sec, documents/hour — определяет, масштабируется ли партия ночной обработки. Утилизация CPU/GPU/RAM/VRAM и хранилища ограничивает плотность деплоя. Стоимость — cost per inference, per document, per 1000 predictions — решает, переживает ли «лучшая» модель экономику продукта.

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

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

Документный пайплайн типичен:

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.

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

Рабочий evaluation pipeline выглядит так:

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

Автоматизация включает скрипт оценки, сохранение предсказаний и метрик, сравнение прогонов, трекинг экспериментов (MLflow, Weights & Biases или свой контур). Evaluation dataset версионируют, фиксируют и не правят ради улучшения отчёта. Предсказания хранят: без них нельзя сделать error analysis после того, как цифра уже посчитана.

Метрика показывает сколько ошибок. Дальше сортируют ошибки по confidence, разбирают FP и FN, частые confusion pairs, срезы по классам, источникам и сложности. Для OCR отдельно смотрят рукописные цифры, пары 1/7, 3/8, 5/6, шум, наклон, пустые клетки, повреждённые поля. Для RAG — запросы с пустым retrieval, с частичным контекстом, с конфликтующими фрагментами, с требованием отказа.

После метрик полезна model card: датасет и его версия, версия модели и preprocessing, основные метрики и порог, ограничения, known failure cases, latency, железо, версия evaluation pipeline, дата прогона. Это делает результат воспроизводимым через месяц, а не «у кого-то в ноутбуке».

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

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

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

Сценарии из практики. Дисбаланс: 97% Accuracy константы хуже 90% Accuracy модели с высоким Recall по браку. Цена FP/FN: модель с меньшим средним, но вдвое меньшим числом дорогих пропусков — лучше. Exact Match: 97% character accuracy хуже 90% Exact Match, если бизнес считает целые поля. Критический класс: общий F1 выше, а Recall по классу «опасный» ниже. Production distribution: тест из лаборатории чище боя. Плохая калибровка: высокий Accuracy, но автопороги врут. Высокая latency: «лучшая» модель не укладывается в SLA.

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

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

Не ограничивайтесь Model A = 95% против Model B = 96%. Проверьте одинаковый test set, одинаковый preprocessing, одинаковый threshold, одинаковые метрики, сопоставимые доверительные интервалы, latency, память, стоимость, robustness и качество по классам/стратам. Bootstrap и confidence intervals напоминают: на маленьком тесте разница в один пункт часто лежит внутри шума. Повторная оценка и размер выборки — часть честности, не бюрократия.

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

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

1. Оценка на train dataset.
2. Data leakage между split.
3. Слишком маленький test set.
4. Изменение test set после каждого эксперимента.
5. Использование только Accuracy.
6. Игнорирование class imbalance.
7. Игнорирование threshold.
8. Оценка только средней метрики без per-class / per-slice.
9. Отсутствие error analysis.
10. Игнорирование production latency.
11. Игнорирование стоимости inference.
12. Сравнение моделей на разных данных.
13. Отсутствие фиксированного benchmark.

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

• Train/validation/test разделены корректно.
• Нет data leakage.
• Test set / benchmark зафиксирован и версионирован.
• Выбраны task-specific metrics под цену ошибки.
• Есть baseline metrics.
• Есть per-class / per-slice metrics.
• Учтён class imbalance (если он есть).
• Проведён error analysis.
• Проверена robustness / OOD на реалистичных искажениях.
• Проверена calibration, выбран threshold.
• Измерена latency (в т.ч. хвосты).
• Измерено потребление ресурсов.
• Оценена стоимость inference.
• Результаты воспроизводимы тем же скриптом оценки.

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

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

• Проверка качества языковых моделей — какие тесты 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?» — а это уже инженерия, а не оптимизм отчёта.