Ключові висновки

Немає універсальної метрики якості нейромережі. 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

Дисбаланс класів — норма промислових задач: брак, фрод, спам, рідкісний діагноз, рідкісний тип документа. 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 за класами. [email protected] рахує збіг за IoU ≥ 0.5. [email protected]:0.95 усереднює за кількома порогами IoU і набагато суворіший до якості рамок. Модель може бути сильною за [email protected] і помітно слабшою за [email protected]:0.95 — це сигнал «знаходить, але локалізує грубо».

Сегментація

Pixel Accuracy знову небезпечна за маленьких об’єктів на великому тлі: «усе тло» дає високий відсоток пікселів. IoU / Jaccard і mean IoU (mIoU) дивляться на перекриття масок за класами. Dice / F1 для масок:

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

Dice пов’язаний з IoU монотонно, але інакше зважує перетин; у медицині та малих структурах Dice часто звичніший як цільова метрика навчання і звіту. Для тонких меж і дрібних дефектів дивіться class-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 на кадрах однієї камери часто оптимістичний відносно нової камери в цеху.

Справедливість за групами

Загальний 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.
• Результати відтворювані тим самим скриптом оцінки.

Часті питання

Яка метрика якості нейромережі найважливіша?

Та, що відповідає ціні помилки продукту. Універсальної немає: для фроду частіше Recall/PR-AUC і робочий поріг, для OCR полів — Exact Match, для пошуку — NDCG або MRR, для RAG — зв’язка retrieval і faithfulness плюс наскрізний успіх.

Чому Accuracy не можна використовувати завжди?

Бо за дисбалансу та асиметрії шкоди вона маскує провал на рідкісному чи дорогому класі. Accuracy лишається корисною як одна з метрик на збалансованих задачах із симетричною ціною помилок.

Що обрати: ROC-AUC чи PR-AUC?

Для рідкісного позитивного класу зазвичай PR-AUC і PR-крива ближчі до практики. ROC-AUC зручна для порівняння ранжування, але може оптимістично виглядати за маси негативних прикладів. Для випуску все одно потрібна робоча точка, а не лише площа.

Чим CER відрізняється від Exact Match в OCR?

CER вимірює частку символьних правок відносно еталона і добре діагностує модель. Exact Match вимагає повного збігу рядка або поля і ближчий до бізнес-приймання номерів, сум і кодів.

Чи потрібно оцінювати RAG однією наскрізною метрикою?

Наскрізна потрібна для релізу, але недостатньо однієї. Без окремої оцінки retrieval і generation ви лікуєте не ту стадію. Тримайте обидва шари і E2E.

Як часто оновлювати тестовий benchmark?

За розкладом і за інцидентами: нові джерела даних, нові типи помилок із продакшену, дрейф. Не оновлюйте тест заради покращення звіту поточної моделі; додавайте випадки як нову версію набору.

Чи достатньо mAP, щоб впроваджувати детекцію в документний конвеєр?

Ні як єдиного критерію. Потрібні поріг IoU, якість кропів під OCR і end-to-end точність документа. Високий mAP за грубих рамок може вбити Exact Match на полях.

Що робити після того, як метрики пораховано?

Запустити error analysis: FP/FN, confusion pairs, зрізи за складністю і джерелами, порівняння з baseline. Потім вирішити, лагодити дані, модель, поріг чи конвеєр — метрика сама цього не підкаже.

Як порівняти дві моделі з різницею в 1%?

На одному benchmark, з одним порогом і препроцесингом, з інтервалом невизначеності і з розрізом за стратами. Додайте latency і вартість. Іноді «гірше на 1% середньої метрики» виявляється кращим на критичному класі і дешевшим у проді.

Коли людська оцінка обов’язкова?

Коли автоматичний оракул слабкий: вільні відповіді LLM, спірна повнота, тон, нові класи шкоди, якість перекладу на критичному домені. Людей використовують точково для калібрування і прихованого контролю, а не замість усіх автоматичних метрик.

Далі за темою

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