Оцінка агента ШІ: тести, golden set та бенчмарки перед продакшеном

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

Оцінка агента ШІ перед продакшеном — це окрема дисципліна, відмінна від моніторингу поточного стану. Нижче описано, як її побудувати крок за кроком.

Агент — це не просто мовна модель. Він складається з моделі, набору інструментів (tool-use), циклу прийняття рішень і часто бази знань RAG. Кожен з цих елементів може вийти з ладу незалежно від інших. Guardrails можуть працювати коректно, а агент все одно викликатиме неправильний інструмент з правильними правами доступу.

Оцінка RAG вимірює, чи генерує модель відповідь, вірну вихідному документу. Оцінка агента вимірює три додаткові виміри:

• Точність вибору інструмента — чи викликав агент правильний інструмент для даного запиту?
• Коректність параметрів виклику — чи передав він правильні аргументи до інструмента?
• Task success rate — чи завершилося багатоетапне завдання очікуваним результатом?

Ці три виміри можна перевірити перед продакшеном, але лише за умови наявності golden set з закодованими очікуваннями для кожного з них.

Golden set — це набір пар: (запит користувача, очікувана поведінка агента). Очікувана поведінка може мати різний рівень деталізації:

• Рівень відповіді — очікуваний текст або фрагмент для семантичного порівняння
• Рівень інструмента — очікуваний інструмент, який агент повинен викликати
• Рівень параметрів — очікувані аргументи виклику (наприклад, {"order_id": "{{order_id}}", "locale": "uk"})
• Рівень завдання — очікуваний кінцевий стан після багатоетапної послідовності

Для агента обслуговування клієнтів, що покриває статуси замовлень і політику повернень, мінімальний golden set — 200-300 прикладів. Орієнтовний розподіл: 40% покривають типові запити (висока частота), 30% покривають edge case (винятки політики, відсутність даних), 30% покривають запити поза межами компетенції (агент повинен ескалувати або відмовити).

Пастки при створенні golden set:

Надмірне представлення прикладів з документації. Якщо golden set складається переважно з FAQ або інструкцій, які модель бачила під час fine-tuning або в RAG, результати будуть завищені порівняно з продакшеном. Доповніть його реальними анонімізованими зверненнями з попередніх каналів.

Відсутність прикладів помилок інструментів. Golden set повинен містити сценарії, де інструмент повертає помилку (timeout, відсутність запису, некоректний формат). Перевірте, чи агент обробляє їх gracefully, а не галюцинує результат.

Пропуск багатомовних прикладів. Якщо агент обслуговує клієнтів кількома мовами, кожна мова потребує окремого покриття. Моделі поводяться по-різному для запитів мовою меншин.

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

Точність вибору інструмента нижче 90% перед продакшеном — сигнал до перегляду системи промптів або few-shot прикладів, а не до впровадження з надією на покращення. Агенти з некоректним tool-use викликають реальні наслідки (операції з даними, бронювання, платежі), і там немає механізму відкату, аналогічного до некоректної текстової відповіді.

LLM-as-judge — це метод, у якому друга модель оцінює якість відповідей першої. Прискорює оцінку великих обсягів (1 000+ пар на день), але має обмеження, про які варто знати перед тим, як покладатися на нього.

Коли працює добре:

• Оцінка faithfulness (чи відповідь вірна вихідному документу) для систем RAG з чіткими фактами
• Виявлення очевидних галюцинацій та відповідей повністю поза темою
• Порівняння двох версій агента (A/B) на одному наборі запитань

Коли підводить:

• Оцінка коректності параметрів інструментів (вимагає детермінованої валідації схеми, а не мовної оцінки)
• Завдання, що потребують доменних знань, яких модель-суддя не має (право, медицина, специфічні політики компанії)
• Виявлення систематичних помилок власного постачальника (якщо агент і суддя використовують ту саму базову модель, суддя може не помітити помилку)

Калібрування є обов’язковим. Перед автоматичним використанням LLM-as-judge оцініть вручну 50-100 пар, порівняйте з результатами судді та обчисліть кореляцію Пірсона або каппа Коена. Кореляція нижче 0,75 з людською оцінкою дискваліфікує суддю для даного виміру. Патерн калібрування LLM-as-judge описаний у статті про оцінку якості RAG.

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

Регресійні тести — це запуск golden set на новій версії та порівняння результатів з базовим снапшотом. Три кроки, щоб це працювало на практиці:

1. Заморозьте базовий рівень — після проходження оцінки перед продакшеном збережіть результати (faithfulness score, tool accuracy, task success rate) як артефакт версії. Це ваша точка порівняння при кожній зміні.

2. Автоматизуйте запуск golden set — інтегруйте регресійний тест у CI/CD-пайплайн або запускайте вручну перед кожним підвищенням версії. Для продуктивних агентів щотижневий запуск на базовому наборі (50-100 пар) — мінімум.

3. Визначте пороги деградації — не кожне погіршення на 1 відсотковий пункт вимагає блокування. Встановіть пороги: падіння faithfulness більше ніж на 3 відсоткові пункти або tool accuracy нижче порогу PASS блокує підвищення. Дрифт між послідовними тестами, а не одноразовий результат — сигнал до аудиту.

Патерн виявлення дрифту якості з часом описаний у статті про моніторинг агента ШІ. Вплив зміни промпту на якість розглядається у статті про prompt engineering для компаній.

Агент може галюцинувати не лише в тексті відповіді, але й у параметрах виклику інструмента. Приклад: агент викликає create_refund(order_id="ORD-12345") для замовлення, якого не існує в системі, оскільки витлумачив ID з тексту розмови, а не з реального запису.

Захист від такого типу помилок вимагає валідації на боці інструмента (не лише на боці агента):

• Інструмент повертає помилку 404 або код помилки, якщо запис не існує
• Агент має інструкцію в системному промпті: «Якщо інструмент повернув помилку, не намагайся повторити з іншими параметрами. Ескалуй до людини.»
• Складний structured-output з валідацією JSON Schema перед передачею до інструмента

Стаття про аудит безпеки асистента ШІ охоплює повний спектр тестів безпеки перед продакшеном, включаючи тести на ін'єкції та надмірні права доступу інструментів.

Опишіть агента, якого хочете протестувати перед продакшеном, і модель вкаже структуру golden set, метрики для вашого діапазону та пороги PASS, адаптовані до ризику процесу (playground: PII маскуються, нульове збереження):

Для агента з вузьким діапазоном (2-3 інструменти, один процес) мінімум — 150-200 пар. Для багатофункціональних агентів (5+ інструментів, кілька процесів) оптимальний діапазон — 400-600 пар. Менше 150 пар — покриття edge case'ів занадто низьке, щоб результати мали прогностичну цінність. Важливіший склад набору, ніж його розмір: 30% прикладів поза межами компетенції та 30% edge case'ів необхідні, щоб golden set виявляв реальні проблеми, а не лише підтверджував роботу happy path.

Ні. Без калібрування невідомо, чи суддя вимірює те саме, що й людина. У проектах, які покладалися на невідкалібрований LLM-as-judge, оцінки були завищені на 8-15 відсоткових пунктів порівняно з оцінками доменних експертів. Калібрування вимагає 50-100 пар, оцінених вручну, та порівняння з результатами судді. Якщо кореляція Пірсона нижче 0,75, змініть модель-суддю або метод вимірювання для цього виміру.

Спочатку ізолюйте, на якому етапі багатоетапної послідовності виникає помилка: точність вибору інструмента, коректність параметрів чи інтерпретація результату інструмента. Якщо точність вибору інструмента стабільна, а параметри погіршилися, проблема полягає в тому, як нова модель екстрагує дані зі структури діалогу. Рішенням зазвичай є додавання few-shot прикладів до промпту або суворіша валідація structured-output перед викликом. Стаття про чому проекти ШІ провалюються описує системні причини регресій після зміни конфігурації.

Без історичних звернень golden set створюється з трьох джерел: (1) документація процесу та FAQ продукту, (2) інтерв'ю з консультантами обслуговування клієнтів про типові та складні запити, (3) синтетичні дані, згенеровані з опису процесу. Синтетичні дані потребують верифікації доменним експертом перед включенням до golden set, оскільки LLM генерує приклади з власних пріоритетів, які можуть не відповідати реальному розподілу запитів. Blueprint агента допомагає визначити діапазон інструментів та сценаріїв, які мають бути покриті.

Щотижня для впроваджень з обсягом понад 500 запитів на день, раз на два тижні для менших. Обов’язково перед кожною зміною: базової моделі, системного промпту, набору інструментів та бази знань RAG. Автоматичний запуск golden set у CI/CD при кожному pull request, що змінює конфігурацію агента, є стандартом для продуктивних систем. Патерн безперервного моніторингу описаний у статті про моніторинг якості агента ШІ.