Як оцінювати ШІ-агентів: тестові набори, оцінювачі та регресійні перевірки

За кожним чудовим продуктом на основі ШІ стоїть надійний процес оцінювання ШІ-агентів, відомий як evals, що допомагає рано виявляти помилки й забезпечує належну роботу агента. Такі оцінювання критично важливі для ШІ-агентів, які виконують ризиковані дії, як-от оформлення повернення коштів від імені людини.

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

Що означає оцінювати ШІ-агента?

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

Уявіть ШІ-агента із закупівель на виробничому підприємстві, який перевіряє запаси запчастин і готує заявки на їх поповнення. Якщо затверджена деталь недоступна або інформація про постачальника застаріла, чи позначить агент проблему, чи порекомендує незатверджений замінник?

А якщо ви зміните його системний промпт, щоб виправити цю проблему, як дізнатися, що ви не створили іншу?

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

Отже, оцінювання агента може охоплювати кілька аспектів запуску:

• Якість кінцевого результату
• Інформація, яку використовував агент
• Інструменти, які він викликав
• Чи дотримувався він правил, що визначають його поведінку

Поширені метрики оцінювання ШІ-агентів

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

Ось перелік основних метрик оцінювання ШІ-агентів:

• Успішність виконання завдання показує, чи досяг агент бажаного результату; зазвичай її вимірюють як відсоток запусків, що дають коректні результати.
• Правильність дій показує, чи належно агент використовував інструменти, чи вибирав коректні аргументи та чи дотримувався дозволів.
• Якість відповіді оцінює, чи є кінцевий результат точним, повним і корисним. Сюди можуть входити фактична правильність, дотримання інструкцій і те, чи обґрунтовує агент свої рішення наявною інформацією.
• Надійність вимірює стабільність результатів у повторних спробах, за різних вхідних даних і в граничних випадках.
• Вартість і затримка вимірюють ресурси, потрібні для досягнення успішного результату, зокрема час виконання, споживання токенів і виклики інструментів.

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

Крок 1: визначте, як виглядає успішний запуск агента

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

Ось як до цього підходити, за словами Andrey Khomutov, нашого старшого фахівця з науки про дані:

«Почніть із двох запитань: „Що можна вважати виконанням завдання?“ і „Що може зробити на перший погляд успішний запуск неприйнятним?“

Для агентів із технічного погляду це означає перевіряти і результат, і те, як агенти до нього дійшли».

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

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

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

Крок 2. Створіть тестовий набір на основі реальних завдань і збоїв

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

Hamel Husain, ML-інженер у Parlance Lab, і Shreya Shankar, дослідниця ML-систем та оцінювання прикладного ШІ, рекомендують почати з аналізу помилок — методу, запозиченого з машинного навчання й науки про дані. Процес починається з якісного аналізу трасувань виконання агента — записів, що показують введення користувача, виклики інструментів, отриману інформацію та відповідь агента.

1. Перегляньте окремі трасування та анотуйте помилки (відкрите кодування). Попросіть експерта в предметній галузі перевірити запуски агента й коротко записати, що пішло не так. Зосередьтеся на першій суттєвій помилці.
2. Згрупуйте спостереження за типами збоїв (осьове кодування). Коли нотаток буде достатньо, скористайтеся LLM, щоб запропонувати категорії для схожих помилок. Це можуть бути рекомендації несумісних деталей, неточне отримання даних про запаси та невдала передача завдання людині.
3. Підрахуйте випадки. Віднесіть кожне спостереження до певної категорії, а потім за допомогою електронної таблиці або зведеної таблиці обчисліть, як часто трапляється кожен тип збою.
4. Визначте, що виправляти насамперед, зважаючи і на частоту, і на серйозність.
5. Перетворіть важливі збої на тестові сценарії. Збережіть відповідні вхідні дані, початкові умови, очікуваний результат і критерії оцінювання, щоб агента можна було знову протестувати на тому самому сценарії.

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

Ще не запустили застосунок? Синтетичні приклади допоможуть створити початковий тестовий набір, хоча щойно з’являться реальні дані користувачів, варто спиратися на них.

Використання бенчмарків в оцінюванні ШІ-агентів

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

Але бенчмарки не бездоганні. Аудити SWE-bench, огляди бенчмарків від Epoch AI і правильні відповіді, які спершу відхилили в TheoPhysEval, показують, як завдання з помилками чи некоректні очікувані відповіді можуть спотворювати результати оцінювання.

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

Крок 3. Запускайте агента у відтворюваному тестовому середовищі

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

Для початку можна зберігати репрезентативні вхідні дані у файлах JSON і використовувати скрипт Python, щоб виконувати робочий процес агента й перевіряти його результати за допомогою тверджень (assertions). Для агента з управління запасами на нашому виробничому підприємстві відтворюване тестове середовище може виглядати так:

Розгорнути

Щоб налаштувати відтворюване тестове середовище, виконайте такі кроки:

1. Збережіть репрезентативні вхідні дані. Фіксуйте реальні події або тестові сценарії в тій самій структурі, у якій їх отримує ваш застосунок у продакшені. У нашому сценарії ви зберегли б у файлі JSON запит на технічне обслуговування з ідентифікатором обладнання, потрібною запчастиною й датою обслуговування, а також знімок даних про запаси й затверджені деталі.
2. Виконайте робочий процес. Пропустіть кожен набір вхідних даних через агента, зокрема його кроки отримання даних, виклики інструментів і генерування відповіді.
3. Запишіть результат і трасування. Фіксуйте кінцевий результат і відповідні проміжні дії (як-от пошук у даних про запаси), щоб бачити не лише те, чи агент зазнав збою, а й де саме.
4. Повторюйте сценарії залежно від серйозності збою, його частоти та складності виправлення проблеми. LLM-застосунки недетерміновані (на однакових вхідних даних вони можуть давати різні результати), тому один успішний запуск не гарантує, що наступний теж буде успішним. Наводьте частку успішних спроб і аналізуйте збої.

Для цього Khomutov радить вимірювати pass@1 (як часто агент досягає успіху з першої спроби) і pass@k (імовірність досягти успіху принаймні раз за визначену кількість спроб). Якщо ви наводите pass@k, зазначайте кількість спроб, адже одна правильна відповідь серед кількох не означає, що агент знає, яку з них вибрати.

Коли ваш застосунок зростатиме, використовуйте фреймворк для тестування, як-от pytest, щоб упорядковувати й запускати тести, і подумайте про зберігання великих тестових наборів даних і результатів у базі даних.

Крок 4. Виберіть відповідного оцінювача для кожної перевірки

Оцінювач (англ. grader; його також часто називають evaluator) — це механізм у вигляді фрагмента коду, LLM, що керується рубрикою оцінювання, або людини-рецензента, який перевіряє відповідь чи дію агента за визначеним критерієм. Оцінювач повертає вердикт «пройдено/не пройдено» і пояснення з посиланням на відповідні докази.

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

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

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

Як поєднувати оцінювачів?

Запитайте себе: «Чи можна перевірити результат за відомим правилом або очікуваним значенням, чи для цього потрібне судження, як у людини?»

• Якщо результат можна перевірити точно, почніть з оцінювача на основі коду. Такі оцінювачі також можуть перевіряти структуровані результати, допустимі значення полів, аргументи інструментів або кінцевий стан бази даних.
• Якщо для перевірки потрібно інтерпретувати контекст, використовуйте підхід «LLM як суддя».
• Для рішень, що стосуються специфіки галузі або є спірними, залучайте людей-рецензентів.

Важливо! LLM-оцінювач може хибно інтерпретувати докази або неправильно застосувати рубрику. Тому потрібен додатковий етап оцінювання: калібрування за людськими судженнями.

Калібруйте LLM-оцінювача за людськими судженнями.

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

Ось п’ятикроковий процес калібрування оцінювача:

1. Зберіть приклади вхідних даних, відповідей і відповідних трасувань агента.
2. Попросіть експерта в предметній галузі незалежно оцінити, чи відповідає кожен приклад критерію оцінювання.
3. Запустіть LLM-оцінювача на цих прикладах.
4. Порівняйте судження людини й моделі.
5. Дослідіть розбіжності та вдоскональте рубрику оцінювача, перш ніж тестувати його на нових прикладах.

Khomutov також наголошує на важливості окремої перевірки послідовності LLM-оцінювача:

«Дайте йому той самий збережений запуск і ті самі файли кілька разів, не перезапускаючи агента. Так можна відокремити варіативність у роботі агента від варіативності в оцінюванні».

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

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

Крок 5. Порівнюйте версії та виконуйте регресійні перевірки

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

Саме тут стає в пригоді регресійне тестування.

Регресійне тестування — це повторний запуск раніше успішних тестових сценаріїв після зміни промпту, моделі чи робочого процесу агента, щоб переконатися, що зміна не спричинила нових збоїв.

1. Відтворіть початковий збій, використавши збережені вхідні дані з тестового набору.
2. Внесіть цільову зміну у промпт, модель чи робочий процес.
3. Повторно запустіть тест, що не проходив, щоб перевірити, чи проблему розв’язано.
4. Запустіть інші тести, щоб переконатися, що зміна не порушила поведінку, яка раніше працювала успішно.
5. Перегляньте результати й дослідіть усі нові збої.

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

Крок 6. Відстежуйте продуктивність ШІ-агента в робочому середовищі

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

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

Цей процес ітеративний і охоплює чотири взаємодоповнювальні напрями роботи:

• Запускайте відкаліброваних LLM-суддів на трасуваннях із робочого середовища. Відбирайте реальні взаємодії з агентом і застосовуйте до них оцінювачі, які ви вже перевірили на відповідність оцінкам людей.
• Відстежуйте частоту збоїв із часом. Використовуйте категорії збоїв, визначені під час аналізу помилок, щоб кількісно оцінювати повторювані проблеми.
• Продовжуйте переглядати трасування вручну. Автоматичні оцінювачі виявляють лише ті проблеми, на які їх розраховано. Вручну перевіряйте вибірки реальних взаємодій з агентом, щоб виявляти нові помилки або незвичні запити користувачів.
• Використовуйте A/B-тестування для вимірювання бізнес-результатів (лише коли це доречно). Порівнюйте різні промпти, моделі або робочі процеси за такими метриками, як виконання завдань, задоволеність користувачів і час вирішення. Це допомагає визначити, чи покращує зміна реальний досвід роботи з продуктом, а не лише чи проходить вона окремі тести.

Важливе зауваження: оцінювання не мусять бути відшліфовані до досконалості. Їм достатньо бути настільки якісними, щоб допомагати покращувати ваш продукт.

Поширені хибні уявлення про оцінювання ШІ-агентів

• Оцінювання — це просто модульні тести. Це не так: модульні тести — це невеликі автоматизовані перевірки, які є лише однією частиною оцінювання. Оцінювання також охоплює якісний аналіз помилок, оцінки людей, моніторинг у робочому середовищі та експерименти для вимірювання якості застосунку.
• Платформа для оцінювання може зробити все за вас. Готові інструменти можуть автоматизувати деякі перевірки, але не здатні визначити, які режими збоїв (типи помилок або небажаної поведінки агента) важливі для вашого продукту.
• Можна доручити LLM оцінювати все. Це велика омана. Аналіз помилок під керівництвом людей і калібрування оцінювачів залишаються необхідними, адже LLM бракує бізнес-контексту, потрібного для виявлення всіх проблем.
• A/B-тестування або просто використання агента замінює оцінювання. Неправильно. A/B-тести можуть показати, яка версія працює краще за вибраними метриками, але самі по собі не можуть пояснити глибинні проблеми.

Поширені запитання про оцінювання ШІ-агентів

1. Чим оцінювання ШІ-агентів відрізняється від оцінювання LLM?

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

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

2. Ключові метрики для оцінювання ШІ-агентів

Метрики оцінювання ШІ-агентів поділяються на дві широкі категорії:

• Метрики технічної продуктивності: частка успішно виконаних завдань, правильність дій, якість відповідей, надійність (pass@1 і pass@k), затримка, використання токенів і вартість одного успішно виконаного завдання.
• Метрики бізнесу та користувацького досвіду: задоволеність клієнтів (CSAT), частка вирішених звернень, частка ескалацій, коефіцієнт конверсії, час виконання завдання та інші результати, специфічні для ролі агента.

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

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

3. Які інструменти найкраще підходять для оцінювання ШІ-агентів?

Серед поширених варіантів:

• Фреймворки для тестування: твердження (assertions) у Python і pytest корисні для запуску відтворюваних тестових випадків і перевірки точних умов, наприклад чи вибрав агент правильний інструмент або чи повернув дійсний ідентифікатор деталі.
• Фреймворки для оцінювання ШІ-агентів: DeepEval і набір інструментів agent-eval від Google підтримують складніші оцінювання, зокрема трасування виконання, оцінювачі на основі LLM і автоматизоване регресійне тестування.
• Платформи для оцінювання та спостережуваності: LangSmith, Arize Phoenix і MLflow допомагають командам аналізувати поведінку агентів, керувати наборами даних для оцінювання, порівнювати версії агентів і відстежувати продуктивність у робочому середовищі.

4. Як автоматизувати оцінювання ШІ-агентів?

Автоматизувати оцінювання ШІ-агентів можна, створивши відтворювані тести, застосувавши автоматичні оцінювачі та інтегрувавши ці перевірки в робочі процеси розробки й експлуатації:

1. Створіть набір даних для оцінювання: зберіть репрезентативні завдання користувачів, очікувані результати, відомі збої та трасування виконання агента. Додайте граничні випадки, як-от невдалі виклики інструментів, відсутню інформацію та несанкціоновані дії.
2. Автоматизуйте виконання тестів і оцінювання: використовуйте фреймворки на кшталт pytest або DeepEval, щоб запускати тестові випадки й застосовувати перевірки на основі коду або LLM-оцінювачі. Перш ніж покладатися на оцінки LLM-оцінювачів, перевірте їх на відповідність оцінкам людей.
3. Інтегруйте оцінювання в CI/CD: автоматично перезапускайте регресійні тести, коли розробники оновлюють промпти, моделі, інструменти або робочий процес агента. Порівнюйте результати з базовим рівнем і встановлюйте порогові значення якості, які блокують випуски в разі невдачі критичних перевірок.
4. Застосовуйте відкалібровані оцінювачі до вибіркових трасувань із робочого середовища, відстежуйте частоту збоїв та інші метрики продуктивності й досліджуйте нові помилки за допомогою ручного перегляду.