Оцінювання AI

Шістнадцять речей для оцінювання — найдешевший оцінювач, що вирішує кожну, і що його обманює

На сторінку про оцінювання AI приходять із конкретним питанням: як мені це оцінити? Відповідь майже ніколи не «спитати іншу модель». Нижче — шістнадцять речей, які команда оцінює на асистенті замовлень зі сторінки «Тестування LLM-продуктів»: чаті магазину, що відповідає на «де моє замовлення», пояснює правила повернення й розпочинає повернення. Для кожної — найдешевший оцінювач, що її вирішує, і те, що цього оцінювача обманює. Префікс називає щабель на драбині нижче. Наступні розділи посилаються на рядки за номерами.

Спершу прочитайте, потім міряйте: аналіз помилок

Звичний перший крок — обрати метрики (корисність, вірність джерелам, бал галюцинацій) і вивести їх на дашборд. Так зʼявляються числа про проблеми, яких ніхто не бачив. Гамел Гусейн і Шрея Шанкар, які навчили оцінювання тисячі інженерів, кажуть прямо: загальні метрики в більшості AI-застосунків марні. Почніть натомість із читання того, що система насправді зробила.

Метод походить із якісних досліджень і має три кроки. Прочитайте щонайменше сотню справжніх розмов і для кожної, що пішла не так, запишіть коротку нотатку своїми словами — це відкрите кодування. Потім згрупуйте нотатки в категорії збоїв і порахуйте їх — це осьове кодування. Зупиніться, коли нові розмови перестануть давати нові види збоїв, — дослідники називають це насиченням. Лише тоді вирішуйте, як оцінювати кожну категорію.

Дві речі в цій таблиці типові. Найбільша група — не та, яку хтось вгадав би до читання, і більшість груп, щойно хтось придивився, виявилися перевірюваними кодом. Команда, що почала б із балу «корисності», не виміряла б ні не того замовлення, ні відповіді не тією мовою.

Що входить у набір і яким великим він має бути

Інстинкт підказує будувати на покриття: кейс на фічу, рівномірно. Виходить набір, що з першого дня дає девʼяносто з чимось відсотків і більше не рухається, — тобто вже нічого вам не каже. Набір виправдовує себе тим, що згущений там, де система слабка, тож його склад має бути навмисно незбалансованим. Ось склад набору асистента замовлень.

Тридцять–пʼятдесят справжніх збоїв — повноцінна стартова точка; сто пʼятдесят — зрілий набір для однієї фічі. Відкладена частина важить більше, ніж підказує її розмір. Без неї ви зрештою підганяєте промпт під набір, а не під клієнтів, і ніщо в числах не скаже, що це сталося. І кожен кейс потребує мітки від людини, що знає предметну область: для асистента замовлень — від власника правил повернення, а не від інженера, що писав промпт.

Драбина оцінювачів

Те, як судять відповідь, важить більше, ніж скільки відповідей ви судите. Пробувати оцінювачів варто в чіткому порядку, і дисципліна полягає в тому, щоб підійматися, лише коли щабель нижче справді не може вирішити питання.

Другий щабель покриває значно більшу частину справжнього набору, ніж очікують команди. Якщо відповідь наводить число — перерахуйте його (рядок 3). Якщо цитує фрагмент — знайдіть його (рядок 4). Якщо викликає інструмент — перевірте аргументи (рядок 5). Кожне з цього — детермінований код, що виконується за мілісекунди, нічого не коштує й дає результат, з яким ніхто не посперечається, — а це річ іншого роду, ніж оцінка.

Середньому щаблю варто не довіряти. Метрики перекриття слів на кшталт BLEU і ROUGE порівнюють відповідь зі схваленою, що пасує машинному перекладу сталих речень і майже нічому іншому. 2016 року Чіа-Вей Лю й колеги виявили, що на відповідях у діалозі вони збігаються з людською оцінкою слабко або ніяк (рядок 12). А запуск коду проти тестів (рядок 13) добрий рівно настільки, наскільки добрі тести: у лютому 2026 року OpenAI виявила, що в більшості складних задач поширеного бенчмарка з програмування тести відкидають правильні рішення, — це четвертий випадок наприкінці сторінки.

Модель як суддя — і як їй довіряти

Модель може оцінювати вивід іншої моделі, і для питань про зміст це справді корисно в масштабі, недосяжному людям. 2023 року Ляньмінь Чжен і колеги виявили, що сильні судді збігалися з людськими вподобаннями понад 80% випадків — приблизно так само часто, як люди збігаються між собою. Та сама стаття назвала упередження суддів, а пізніші роботи додали нові. Суддя — це вимірювальний прилад із відомими вадами, і на кожну ваду є відома протидія.

Далі калібруйте — і так, як тестували б будь-який класифікатор. Нехай предметний експерт розмітить кейси як «пройшло» чи «ні» з поясненням в один рядок. Гусейн радить близько сотні розмічених прикладів на кожен вид збою й попереджає, що за менш ніж шістдесяти невизначеність надто велика для висновків. Розділіть їх: кілька йдуть у промпт судді як приклади, приблизно половина — набір розробки, на якому покращують промпт, а решта — тестовий набір, на який дивляться один раз, наприкінці.

На тестовому наборі звітуйте два числа, а не одне. Частка істинно позитивних (TPRTPRtrue positive rate — частка спійманих справжніх збоївЧастка справжніх позитивних випадків, яку тест, класифікатор чи суддя-модель справді ловить, — та сама величина, що й повнота (recall). TPR 80% означає, що кожен пʼятий справжній збій проходить; читайте її поруч із TNR, бо суддя, що нічого не позначає, має ідеальну TNR і нульову TPR.Усі терміни) — це частка справжніх збоїв, які суддя ловить; частка істинно негативних (TNRTNRtrue negative rate — частка пропущених добрих випадківЧастка справжніх негативних випадків — добрих відповідей, здорових кейсів, — яку тест, класифікатор чи суддя-модель правильно пропускає. TNR 91% означає, що приблизно кожен одинадцятий добрий випадок позначено помилково; висока TNR сама по собі нічого не каже, бо «пропускати все» дає 100%.Усі терміни) — частка добрих відповідей, які він пропускає. Сама лише згода ховає той збій, що має значення, бо більшість відповідей добрі: суддя, що пропускає все, збігається з експертом так само часто, як трапляються добрі відповіді.

Каппа Коена, статистика 1960 року, каже те саме одним числом: згода, очищена від того, що дав би випадок. У судді A каппа дорівнює 0, у судді B — 0,62. А коли TPR і TNR відомі, сирий відсоток «пройшло» від судді можна виправити. Суддя B пропускає 80% відповідей; знаючи, що він відхиляє 9% добрих і пропускає 20% поганих, справжній відсоток добрих виходить 85%.

Суддя — ще й залежність із версією та ціною. Закріпіть його модель, інакше оновлення провайдера тихо перемасштабує всі історичні числа. Тримайте його промпт у системі контролю версій поруч із кодом: змінити лінійку так само значуще, як змінити те, що нею міряють, і значно легше зробити це випадково. Перевіряйте TPR і TNR щоразу, коли суттєво змінюється суддя або система, яку він оцінює.

Як читати числа, не обманюючи себе

Результат оцінювання — це вимірювання на вибірці, а вимірювання без невизначеності — пів факту. 2024 року Еван Міллер виклав, як звітувати результати оцінювання так, як інші науки звітують експерименти: стандартна похибка поруч із кожним балом, кластерні похибки, коли кейси йдуть повʼязаними групами, повторні вибірки, щоб зменшити шум, порівняння питання за питанням і перевірка до запуску, чи здатен набір помітити різницю, яка вас цікавить.

Щоб відрізнити зміну на 3 пункти від шуму при 82% «пройшло», потрібно близько 630 незалежних кейсів. Мало в кого стільки є, і стільки не потрібно, бо дві рекомендації Міллера роблять більшу частину роботи. Порівнюйте дві версії покейсно — той самий кейс до і після, — а не одне середнє з іншим: це прибирає різницю між кейсами й нічого не коштує. А коли кейси йдуть групами, наприклад кілька реплік однієї розмови, рахуйте кластерні похибки — у його прикладах вони сягали понад утричі більших за наївні.

Чужі числа: чотири вимірювання, що ввели в оману

Публічні бенчмарки й цифри постачальників — теж оцінювання, яке будують люди під тим самим тиском, і ламаються вони так само. Кожне з цих чотирьох було опубліковане, широко цитоване й хибне щодо того, що, здавалося, вимірює. Жодне не було шахрайством у звичному сенсі; кожне — рішення про те, як збирати чи оцінювати набір.

Де це вироджується

Чесне обмеження в тому, що кожне число на цій сторінці міряє збіг із чиїмось уявленням про «добре», записаним в один момент. Рубрика дрейфує під час читання, експерт розмічає за правилами минулого кварталу, а набір описує збої, які ви вже зустрічали. Оцінювання може сказати, що зміна не погіршила відомого. Воно не може сказати, що фіча добра, і шістнадцятий рядок — що насправді зробили клієнти — лишається єдиним, що на це відповідає.

• Загальні метрики, обрані до того, як хтось прочитав бодай одну розмову, — вони міряють проблеми, яких ніхто не бачив.
• Набір із кейсів, що вже проходять: звітує високе число й не виявляє нічого.
• Суддя-модель на питаннях, які вирішив би код: купівля невизначеності за ціною на кейс.
• Суддя, якого звітують відсотком згоди, і ніхто не перевіряє, чи ловить він бодай якісь збої.
• Один загальний бал з десяти, що усереднює й ховає той єдиний вимір, який зламався.
• Без відкладеного набору: промпт підганяють під набір, доки той не перестане щось передбачати.
• Приріст на 3 пункти на сорока кейсах з одного запуску, оголошений як результат.
• Місце в публічному рейтингу, сприйняте як доказ щодо вашого власного сценарію.
• Незакріплений суддя, що тихо перемасштабовує всі історичні результати.

Коли це застосовувати

Пов’язані сторінки

• QAТестування LLM-продуктівТестування LLM-продукту — це тестування фічі, чия модель по-різному відповідає на те саме питання у двох запусках, хоча більшість перевірок лишаються точними. Сторінка починається з двадцяти збоїв, з якими виходить асистент замовлень, — перевірки, що ловить кожен, і де вона запускається; далі — відсутній тестовий оракул, детермінований шар і його нещасливі шляхи, властивості для відповідей без очікуваного значення, список OWASP 2026 як план тестування, хто чим володіє і пʼять релізів, що пішли не так.
• QAРегресія промптівРегресійне тестування промптів перевіряє, кейс за кейсом, чи не зламала зміна промпту або моделі щось, що працювало до цієї зміни. Сторінка починається з однієї правки промпту, розібраної від початку до кінця, — асистент замовлень, v7 → v8, — далі негативні перескоки, що закріплювати, три запуски на кейс і межа шуму, ворота, оновлення моделі й чотири зміни, що пішли не так.
• РозробкаLLMOpsLLMOps — це практика тримати в продакшені фічу на мовній моделі, де той самий ввід не дає надійно того самого виводу. Вона існує тому, що все, що робить програму придатною до релізу — тест, який падає, дифф, що пояснює зміну, відкат, який повертає вчорашній стан, — припускає, що дає. Сторінка починається з чеклиста готовності до прода на двадцять чотири рядки; далі — чим заміняють кожну практику, чому одиниця розгортання складається з чотирьох речей, а не з однієї, оцінювання як набір тестів, що має містити слід, як поводяться вартість і затримка під справжнім трафіком, і пʼять задокументованих інцидентів.