Оцінювання AI

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

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

• Кейси з продакшну

  Кожна скарга, кожна негативна оцінка, кожна дивна відповідь. Це найцінніше джерело — і єдине, що росте в міру користування продуктом.

• Кейси, які ніхто не пройде

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

• Кейси, які ламати не можна

  Захищений набір: відмови, регульовані формулювання, точна поведінка, обіцяна клієнту. Будь-яка регресія тут блокує реліз незалежно від середнього.

• Кілька легких

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

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

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

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

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

Як правильно використати модель як суддю

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

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

Далі — калібрування. Нехай людина розмітить пʼятдесят кейсів за тим самим записаним критерієм, запустіть суддю на тих самих пʼятдесяти й виміряйте, як часто вони збігаються. Нижче грубої згоди суддя міряє не ваш критерій, і рубрику треба переписати; за високої згоди ним можна користуватися в масштабі й перевіряти щокварталу. Звітуйте це число згоди поруч із кожним результатом оцінювання, бо оцінка 0,86 від некаліброваного судді — не вимірювання, а чутка з десятковою комою.

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

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

Антипатерни, які варто назвати

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

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

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

• QAТестування LLM-продуктівТестування LLM-продукту — це тестування фічі, яка може двічі відповісти на те саме питання по-різному, а кожна ваша практика тестування припускає, що той самий ввід дає той самий вивід. LLM-фіча це ламає, і звична реакція — вирішити, що її не можна тестувати. Це неправда, і дорога неправда. Більшість важливого в LLM-фічі досі перевіряється точно, та частина, що ні, стає вимірюванням проти порога, а робота тестувальника зміщується від написання кроків до визначення, якою є добра відповідь. Ця сторінка — про це зміщення і про те, що робити в понеділок після нього.
• QAРегресія промптівРегресія промптів — це те, як ви дізнаєтесь, чи не погіршила фічу правка промпту. Промпт — це шматок продакшн-конфігурації, який будь-хто може відредагувати в текстовому полі, у якого немає ні системи типів, ні компілятора, ні диффу, який хтось прочитає, і який змінює поведінку всієї фічі. Тож регресійне тестування тут не є опційним — але воно не може бути перевіркою рівності, бо вивід рухається сам. Тут — що означає регресія, коли результати оцінюють, що треба закріпити, щоб порівняння було чесним, як відрізнити справжню зміну від шуму семплінгу і що має блокувати реліз.
• РозробкаLLMOpsLLMOps — це практика тримати в продакшені фічу, побудовану на мовній моделі, і вона існує тому, що все, що робить програму придатною до релізу — тест, який падає, дифф, що пояснює зміну, відкат, який повертає вчорашній стан, — припускає, що той самий ввід дає той самий вивід. LLM-функції це припущення ламають, тож практики доводиться перебудовувати навколо цього. На цій сторінці — що заступає набір тестів, чим насправді є артефакт розгортання, що записувати на кожному виклику і як поводяться вартість і затримка, коли приходить справжній трафік.