Чому однієї метрики майже ніколи недостатньо

Якість нейромережі — не властивість ваг сама по собі, а властивість зв’язки задача → визначення помилки → вибірка → поріг рішення → середовище експлуатації. Одна метрика стискає цю зв’язку в скаляр і неминуче губить виміри, критичні для продукту.

На тестовій вибірці ви вимірюєте узагальнення за фіксованим розподілом і фіксованою розміткою. У продукті з’являються дрейф вхідних даних, інший баланс класів, ручні правки оператора, таймаути, деградація сканера і зміна політики. На окремих етапах 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 часто звичніший як цільова метрика навчання і звіту. Для тонких меж і дрібних дефектів дивіться class-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, обрізане поле, інший сканер чи інший тип тексту. Набір зі спотвореннями порівнюють із вихідним заміром: наскільки цифра просіла. Окремо дивляться приклади з того самого джерела, що й навчання, і приклади з іншої камери, іншого цеху чи іншого постачальника сканів. Випадковий поділ кадрів однієї камери часто малює оптимістичний звіт відносно нової камери.

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

Загальний 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?» — а це вже інженерія, а не оптимізм звіту.

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