Хто оцінює оцінювача? Перевірка наборів інструментів для оцінки агентів перед тим, як їм довіряти.
Хто перевіряє набір тестів оцінки? Схильність суддів, оцінювання лише за результатом, приватні моди збоїв та приховані витрати можуть змусити оцінки ШІ брехати. Перевірка самого набору тестів.
Джерела: Nobody Validates the Validator: The Eval Suite Problem in Agent Engineering
У 2026 році майже кожна команда, яка випускає AI-агента, також використовує набір інструментів для оцінки, який включає панелі керування, показники успішності, контрольні точки CI та оцінювачів LLM, які оцінюють результати роботи агентів за певними критеріями. Усе це свідчить про суворість підходу та, здається, визначає різницю між продакшн-системою та демо-версією, яка випадково працювала двічі.
Однак, якщо поставити наступне очевидне запитання, все стає тихіше. Хто перевірив, чи цей набір інструментів справді вимірює правильні показники, чи робить це коректно та чи все ще надає точну інформацію через півроку після його створення? Майже ніхто. Індустрія витратила два роки на створення інструментів для оцінки агентів, але лише почала розробляти інструменти для оцінки цих самих інструментів. Ця прогалина вже проявляється в продакшні кількома передбачуваними способами.
Припущення, яке ніхто не висловлює
За більшістю схем оцінки агентів стоїть невисловлена припущення: успіх означає, що агент повівся правильно, а невдача — що ні. Якщо погодитися з цим, цей набір інструментів стає «чорною скринькою», якій люди автоматично довіряють. Індикатори показують зелений колір, злиття PR відбувається, і команда переходить до наступних завдань.
Дослідження слідів діяльності агентів почали ставити під сумнів цю передумову. Одне з досліджень проаналізувало 58 слідів, які система оцінювання результатів визнала успішними, і виявило, що 83 відсотки з цих випробувань приховували процедурні чи безпекові порушення, які система оцінювання успіху/невдачі ніколи не виявляла. Агент надав правильну відповідь та отримав ідеальну оцінку, проте шлях, яким він діяв, був по суті неправильним. Саме розбіжність між результатом та процесом і є тим, що має виявляти система оцінювання, але саме те, що більшість таких систем за своєю конструкцією не можуть побачити.
Чотири типи збоїв заслуговують на окремі назви. Кожен з них вимагає свого виправлення, і команди зазвичай помічають лише той, який завдав їм шкоди.
Зміна критеріїв оцінювання. Будь-які семантичні аспекти схильні оцінюватися штучним інтелектом, адже перевірка на основі правил не може визначити, чи було „наступної п’ятниці“ перетворено на правильну дату. Але сам штучний інтелект також є моделлю, і моделі змінюються. Команди, які використовують довгострокові системи, часто бачать, як протягом ночі погіршується вся панель контролю за регресією, вони витрачають день на дослідження та зрештою з’ясовують, що оцінки змінилися через оновлення моделі оцінювача, а не через погіршення агента. Фіксація версії моделі оцінювача та хеша фіксованої шкали оцінювання зменшує проблему, але не усуває її повністю, оскільки хостовані кінцеві точки оцінювача постійно змінюються.
Омана результату. Оцінювання лише кінцевого стану приховує цікаву частину процесу виконання завдання. Агент може скористатися неправильним інструментом, чотири рази надіслати той самий неправильний аргумент, але все одно завдяки удачі чи наполегливості дійти правильної відповіді, і система, яка читає лише остаточне повідомлення, вважатиме його успішним.
Приватні моди збоїв. Публічні тестові майданчики, такі як BFCL чи tau-bench, допомагають порівнювати моделі, але вони не можуть виявити збої, які виникають у власному реєстрі інструментів команди: значення null у необов’язковому полі, помилка з часовим поясом у аргументі з датою, розбіжність валют у полі з грошовими даними. Такі збої належать до інструментів команди та ніколи не з’являються у загальнодоступних таблицях лідерів. Якщо покриття тестування повністю запозичується з публічних тестових майданчиків, верифікатор залишається сліпим саме там, де це важливо — у тих частинах системи, які ніхто інший не тестував.
«Сліпа зона» витрат. Найменше обговорювана, але, можливо, найбільш значуща. Система оцінювання може вважати агента точним у кожному з вимірюваних аспектів, не замислюючись над тим, чи може агент сам себе фінансувати. Один відомий випадок стосувався агента, який відповідав усім дванадцяти критеріям якості, проте був вилучений з експлуатації, оскільки кожне успішне вирішення коштувало більше, ніж людський процес, який він мав замінити. Оцінки якості були точними. Однак не існувало жодного показника для оцінки того факту, який вирішив його долю.
Агент з бронювання, який отримав ідеальні оцінки, але зазнав невдачі
Уявіть собі агента з бронювань, якого просять знайти рейси на „наступну п’ятницю“. Із реєстру, що містить десятки інструментів, він обирає правильний, тож вибір інструменту отримує ідеальний бал 1,0. Потім він надсилає дату у вигляді прямої рядка, не обробивши спочатку відносний вираз. API повідомляє про помилку перевірки, і агент чотири рази надсилає ту саму несправну рядкову інформацію, перш ніж вибачитися та завершити роботу.
Цей аналіз дає два показники: ідеальний бал 1,0 за вибір інструменту та 0 за виконання завдання. Жоден з них не вказує, що саме пішло не так: помилкова обробка аргументів, помилкова відповідь API, яку агент так і не прочитав, чи логіка повторних спроб, яка продовжує працювати з незмінним вхідним даним. Детальний аналіз оцінки використання інструментів показав, що перевірка лише того, чи був викликаний правильний інструмент, оцінює намір, а не сам процес виконання, а саме намір не зазнав невдачі.
Це і є вся проблема у скороченому вигляді. Набір інструментів видав два числа — жодне з них не було абсолютно неправильним, але обидва були марними для єдиного важливого запитання: що потрібно виправити?
Практики, які допомагають
Як тільки набір інструментів для оцінки починають розглядати як систему, яка потребує власних перевірок якості, зріла структура роботи змінюється. Кілька звичок допомагають командам, які виявляють проблеми рано, відрізнитися від тих, хто дізнається про них з великими труднощами:
- Власний рівень метаоцінки. У серйозних проектах робота тепер поділяється на оцінку результату, оцінку кожного кроку процесу та рівень, який перевіряє одних оцінювачів проти інших, щоб оцінки окремих експертів не сприймалися без критичного аналізу.
- Перевірка на основі виконання замість порівняння тексту. Найнадійніші тестові сценарії аналізують те, що насправді змінилося у світі. tau-bench читає стан бази даних, SWE-Bench виконує реальні тести, а tau2-bench за допомогою механізму pass-at-k перевіряє, чи агент послідовно досягає успіху під час багаторазових спроб. Вітчизняні набори тестів також повинні слідувати цьому підходу та підтверджувати реальні зміни, незалежно від того, що повідомляє агент.
- Витрати поруч із якістю. У фінансовій сфері обґрунтовується необхідність відстеження витрат на кожен успішний результат як ключового показника разом із точністю; цей показник слід розраховувати з самого початку, а не пізніше, коли керівник бюджету починає ставити запитання.
- Ієрархічний CI. Повні оцінки від початку до кінця коштують дорого, оскільки кожен завдання вимагає двох викликів моделей — агента та оцінювача, а набір зі ста завдань із по п’ять тестів кожне приблизно подвоює вартість CI. Команди, які тримають це під контролем, розділяють швидкі, безкоштовні та детерміністичні перевірки, які виконуються після кожного коміту, від повільних, дорогих оцінок, заснованих на оцінювачі, які запускаються лише тоді, коли зміни торкаються функціоналу агента.
- Набір, який залишається актуальним. У нещодавньому дослідженні галузі більшість респондентів зазначили, що їхні оцінки не відповідають очікуванням, оскільки реальний трафік відхиляється від початкового набору тестів, і підтримка його актуальності стає неконтрольованою. Набір, який не змінювався з моменту запуску, не є безневинним — він оцінює систему, яка вже перестала існувати.
Чотири кроки для набору, який ви вже маєте
Для команди, яка має набір інструментів для оцінки та хоче його перевірити, а не просто довіряти йому, чотири кроки допомагають подолати більшість проблем:
- Візьміть від десяти до двадцяти записів з реальної роботи, які набір інструментів визнав успішними, та вручну прочитайте кожен повний шлях виконання завдання, а не лише результат. Кількість таких успішних випадків, які приховують процедурні помилки, є достовірним показником того, наскільки можна довіряти інформації з панелі керування.
- Визначте версію моделі оцінювача та текст критеріїв оцінки та фіксуйте їх разом із кожним балом, щоб оновлення оцінювача проявлялося як чітко позначена подія, а не як загадкова регресія.
- Від самого початку відстежуйте витрати на кожен успішний результат, навіть до того, як хтось про це попросить.
- Створіть невеликий набір даних для виявлення регресії з реальних проблем у роботі, а не лише з синтетичних випадків. Публічні стандарти визначають мінімальні вимоги, тоді як власна історія інцидентів команди допомагає передбачити наступну проблему.
Ніщо з цього не може замінити повний набір тестів. Це просто припиняє розглядати цей набір як єдиний елемент, який занадто важливий, щоб його перевіряти.
Швидкі відповіді
Що означає перевірка набору тестів eval для агентів? Це означає застосування такої ж ретельної перевірки до системи оцінювання, яку система застосовує до агента, з метою з’ясування, чи справді суддя, критерії оцінювання та процес надання балів вимірюють те, що вони стверджують.
Чому бали, які надає LLM як суддя, змінюються? Суддею є модель. Коли її постачальник її оновлює або замінює на новішу версію, бали можуть змінюватися, навіть якщо оцінюваний агент не змінився.
Чи можуть публічні тестові набори замінити індивідуальний набір тестів? Ні. Вони допомагають порівнювати моделі за спільними завданнями, але не враховують проблеми, пов’язані з власними інструментами, даними та особливими випадками команди.
Чи достатньо високого рівня успішності, щоб залишити агента у експлуатації? Ні, сам по собі цього недостатньо. Агент може демонструвати гарні показники точності та якості дій, проте його все одно можуть видалити, якщо витрати на кожен успішний результат не компенсують цінність, яку він надає.
Як часто слід переглядати чи оновлювати цей набір інструментів? Постійно, у міру змін навантаження в експлуатації. Спосіб використання відхиляється від початкового набору тестів, тому випадки, отримані з реальних помилок, мають надходити регулярно, а не лише під час запуску.
Твердження, що лежить в основі панелі керування
Набір тестів — це не доказ того, що агент працює. Це твердження про те, що означає «працювати», написане тим, хто його створив, оцінюване суддею, чиї критерії можуть змінюватися, на наборі тестів, який починає «старіти» відразу після створення. Вважати це твердження очевидно правдивим — ось чому агенти, які проходять усі показники на панелі керування, все одно провалюють справжнє випробування. Ручний аналіз десяти записів, як описано вище, швидко показує, скільки інформації приховує панель керування.
Пов’язана література
- Оцінка агентів за допомогою бота для бронювання подорожей: результати проти траєкторії, брами та pass^k — приклад оцінки агентів у процесі бронювання подорожей: осі результатів та траєкторії, детерміністичні брами перед вагованими оцінками, 2x2-маトриця та відмінності між pass@k та pass^k.