Тестування штучних інтелект-агентів за результатом: перевірка стану замість довіри до відповідей
Навчіться оцінювати штучних інтелектуальних агентів, які використовують інструменти, шляхом перевірки кінцевого стану, слідів дій та їхньої достовірності, включаючи таймаути, випадки відсутності дій та надійність повторних спроб.
Джерела: Your AI Agent Says “Done.” Did Anything Actually Happen?
Коли агент ШІ відповідає «Готово», це речення є твердженням, а не підтвердженням. Оцінка, яка бере до уваги лише останнє повідомлення, може помилково вважати химерний успіх проходженням завдання. Цей посібник показує, як тестувати агентів, що використовують інструменти, з точки зору того, що насправді змінилося у світі: як визначати завершення завдання, які докази перевіряти, як керуватися таймаутами та ситуаціями, коли агент не повинен нічого робити, а також як вимірювати надійність, а не лише удачний демонстраційний випадок.
Впевнена відповідь — не доказ
Візьмемо просте запитання до асистента з планування: перенести зустріч на четвер після обіду. Асистент ввічливо та без вагань відповідає, що зустріч вже о 15:00. Потім ви переглядаєте календар, і захід знаходиться саме там, де й раніше.
Існують також інші ймовірні варіанти: захід перенесли о 15:00 у іншому часовому поясі, або з’явився зовсім новий захід, тоді як первинний залишився на місці, що залишило користувача з двома варіантами. Цей приклад вигаданий, але проблема тестування є дуже реальною: якщо оцінювати лише текст, створений агентом, усі три випадки невдач виглядатимуть так само, як успіх.
Корисний підхід до мислення полягає у наступному: для агента відповіддю є звіт про виконану роботу, а звіт може бути неправильним. Система, яка оточує модель, тобто її інфраструктура, визначає, чи може вона діяти надійно (ми розглядаємо цей аспект у статті про те, звідки насправді походить надійна поведінка агента). Оцінювання — це крок, який підтверджує, чи справді ця система виконала свої функції.
Спочатку складіть договір про прийняття
„Перемістити мою зустріч“ здається простим завданням, поки ви не спробуєте сформулювати критерії прийнятності для нього.
У розглянутому прикладі припустимо, що користувач вибрав одну подію, вказав дату та часовий пояс та схвалив її оновлення. Необхідним результатом є не просто наявність якоїсь зустрічі о 15:00, а те, щоб ця сама подія починалась у вказаний час, зберігала свою початкову тривалість та список учасників, і щоб жодна інша подія не зазнала змін. Якщо запит є неоднозначним або у асистента немає дозволів, правильною дією є запитання, а не здогадки.
Ці правила стосуються цього гіпотетичного продукту. Інший продукт може надсилати сповіщення, вимагати прямої згоди або по-іншому ставитися до учасників. Важливо те, щоб угода була зафіксована письмово. Без неї один оцінювач хвалить асистента за ініціативу, тоді як інший вважає ту саму дію несанкціонованою зміною, і ваші оцінки стають непереконливими.
Тому кожен випадок оцінки має вказувати:
- початковий стан середовища;
- запит користувача;
- дії, які агент може виконувати;
- умови, які мають бути дотримані після цього; та
- те, що має залишатися незмінним.
Останній пункт легко забути. Хороший тест визначає як мету, так і межі, що її оточують.
Три погляди на одну дію
Кожен запуск агента можна проаналізувати з трьох точок зору, причому кожна з них виявляє різні проблеми.
- Вихідні дані: повідомлення, яке бачив користувач. Чи є воно точним та корисним, і чи відображає воно незавершену роботу замість того, щоб її приховувати?
- Траєкторія: спостережувана послідовність викликів інструментів, результатів їх роботи, схвалень, повторних спроб та перевірок. Чи обрав агент правильну подію, дотримувався своїх повноважень та реагував належним чином у разі збою інструменту?
- Результат: фактичний стан календаря після завершення спроби.
Посібник Anthropic з оцінки агентів також робить розмежування між транскрипцією та кінцевим станом середовища та застерігає від оцінювання кожного коректного рішення за однією фіксованою послідовністю кроків. Такий баланс варто запровадити. Слідкуйте за тим, як поводився агент, але не наполягайте на своєму улюбленому шляху, якщо порядок дій насправді не є частиною умов завдання.
Конкретно кажучи, два агенти можуть обробляти календар за різними алгоритмами та все одно доходити до одного й того ж правильного результату; обидва мають отримати позитивну оцінку. З іншого боку, пропуск обов’язкової процедури схвалення є невдачею, навіть якщо календар у підсумку виглядає правильно. Результат визначає, чи було завдання виконано, умови — чи це було дозволено, а записи операцій пояснюють різницю між ними.
Перевіряйте стан середовища через незалежний канал
Щоб перевірити тест календаря, прочитайте збережену подію через авторизований інтерфейс, який не має жодного відношення до власної відповіді агента. Агенту заборонено оцінювати власні завдання.
Порівняйте поля, які насправді визначають правильність, із очікуваним станом:
- стабільний ідентифікатор події;
- час початку та кінця, а також часовий пояс;
- список учасників;
- сусідні події, які мають залишитися незмінними.
Уникайте порівняння за назвою події. Два зустрічі можуть мати однакову назву, і збіг у назві може помилково підтвердити неправильну подію.
Ця ідея існувала ще до сучасних фреймворків агентів. Инструмент τ-bench оцінює розмови з використанням інструментів, порівнюючи кінцевий стан бази даних із анотованим бажаним станом, тоді як WebArena вимірює, чи завдання функціонально виконані у реалістичних веб-середовищах. Обидва є прикладами досліджень, спрямованих на оцінку того, що сталось, а не того, що було сказано.
Дізнайтеся, що насправді обіцяє сигнал успіху
Успішна відповідь API є корисним доказом, але лише тоді, коли ви знаєте, що вона гарантує. Статус „Accepted“ може означати, що запит було додано до черги, а не оброблено. Банер успіху у браузері може з’явитися ще до того, як базові дані будуть збережені.
Для асинхронних систем заздалегідь вирішіть, як довго буде чекати верифікатор та який стан вважатиметься завершеним. Якщо ви зовсім не можете спостерігати за станом, запишіть результат як неперевірений. Не вважайте його автоматично успішним, але й не припускайте протилежного. Ця третя категорія стає вкрай важливою, як тільки запити починають тайм-аутуватися.
Найскладніший момент: відразу після тайм-ауту
Тайм-аут нічого не говорить про те, чи досягла оновлення своєї мети. Запит міг зазнати невдачі ще до того, як дістатися до сервісу календаря, або ж він міг успішно виконатися, але лише відповідь загубилася по дорозі назад.
Агент, який реагує створенням нової замінної зустрічі, може залишити користувача з двома подіями. Це робить поведінку відновлення першокласним тестовим випадком. Надійна послідовність відновлення виглядає так:
- Знову прочитайте цільову подію.
Якщо після цього результат все ще невідомий, правильним кроком може бути зупинка та пояснення користувачеві причин невизначеності. Чітке пояснення краще, ніж штучний успіх. Такий підхід також використовується у звичайному проектуванні бекенду; деталі з серверної сторони можна знайти у ключах ідемпотентності для Node.js POST-кінцевих точок.
Оцінюйте як сам стан, так і формулювання. Фраза «Я не зміг підтвердити оновлення» є правдивою навіть у разі, якщо сервіс впроваджує зміни через мить. Твердження «Нічого не змінилося» є непідтвердженим у точно такій самій ситуації. Невизначеність — це закономірний результат, з яким агент мусить впоратися, а не прогалина, яку він має заповнити впевненістю.
Підберіть оцінювача до запитання
Різні запитання вимагають різних оцінювачів.
- Детерміністичний код для точних фактів: ідентифікатори, часові мітки, набір дозволених змін, кількість дублікатних подій.
- Оцінювач на основі моделі з чіткою шкалою для оцінки якості комунікації: чи розрізняв асистент завершену роботу та спроби її виконання, чи описував наступні кроки без вигадування деталей?
У документації з оцінки LangSmith правила коду, людський огляд та оцінювання на основі моделей розглядаються як окремі варіанти. Вам не потрібна ця платформа, щоб отримати переваги від їх розділення.
Один антипаттерн заслуговує особливої уваги: передача другій моделі впевненої відповіді агента та запитання про те, чи завдання виконано успішно. Оцінювач буде переконаний тією самою впевненістю, яка обманула вас. Натомість надайте оцінювачеві докази, які насправді потрібні для вирішення питання, та дозвольте йому відповісти «недостатньо доказів».
Треба розділяти критичні збої від показників якості. Не дозволяйте недозволеним змінам календаря затьмарюватися приємним тоном чи точністю формулювань. Корисно використовувати компактну таблицю оцінок: правильний результат, дотримання меж, достовірний звіт, належне відновлення. Вказуйте затримку та витрати поруч із нею, а не об’єднуйте все в одне незрозуміле число.
Включіть випадки, коли правильною відповіддю є нічого не робити
Розумний набір початкових сценаріїв для асистента календаря включає:
- звичайну перенесення зустрічі;
- дві події з однаковою назвою;
- запит без вказання часового поясу;
- відмову у дозволі;
- таймаут від сервісу календаря;
- оновлення, яке вже було застосоване до запуску агента;
- запит на підготовку пропозиції змін без їх реалізації.
Цей останній випадок захищає вас від прихованої упередженості. Якщо кожен тест винагороджує зовнішні зміни, ви починаєте обирати агента, який діє занадто поспішно.
Проводьте тести, які змінюють стан у ізольованих тестових облікових записах або контрольованих середовищах, та скидайте налаштування між окремими спробами. Результати попереднього тестування ніколи не повинні створювати враження успіху наступного тестування.
Цей список є лише відправною точкою, а не статистично достатньою вибіркою. Розширюйте його, ґрунтуючись на тому, про що насправді просять ваші користувачі, де полягають справжні ризики та які проблеми виникають на практиці. Видаляйте особисті дані з налаштувань, які плануєте використовувати знову, та обмежуйте доступ до записів, що містять приватну інформацію.
Вимірюйте послідовність, а не найкращу демонстрацію
Проводьте кожен випадок більше одного разу та фіксуйте кожну спробу, включаючи таймаути та випадки, коли перевірка провалилася.
τ-bench ввів показник повторних спроб — pass^k, який визначає, чи досягає агент успіху у всіх k спробах, а не принаймні в одній. Опубліковані результати моделей є історичними та не повинні розглядатися як рейтинг поточних агентів, проте урок залишається: «може досягти успіху» та «досягає успіху стабільно» — це різні властивості, і одна успішна спроба свідчить лише про першу з них.
Панель керування першим продуктом може відстежувати:
- швидкість правильного завершення;
- кількість несанкціонованих дій;
- твердження про успіх без підтримки даних;
- належну передачу справ на вищий рівень;
- затримку;
- витрати на кожне правильно завершене завдання.
Необхідно чітко визначати знаменник. Чи враховуються запити користувачів, окремі спроби чи повторні спроби? Ті самі дані можуть давати дуже різні показники залежно від обраного підходу.
Прочитайте ці числа разом. Зміна, яка підвищує рівень завершення завдань, але водночас збільшує кількість несанкціонованих дій, не є справжньою перемогою. Так само не є хорошим варіантом агент, який уникає всіх ризиків, відмовляючись від кожного корисного завдання. Порівняйте версії для однакових випадків із однаковими бюджетами та оприлюдніть кількість випадків, які ви пройшли, та ступінь різниці у результатах між цими прогонами. Кілька досліджень є занадто малою кількістю, щоб можна було отримати точні показники надійності в реальних умовах.
Перетворюйте кожну невдачу на тест на регресію
Коли випадок провалюється, спочатку з’ясуйте, що саме пішло не так: чи це агент, інструмент, середовище чи система оцінювання. Неправильний тест не є доказом несправності моделі.
Тоді необхідно визначити мінімальний випадок, який можна відтворити, та зафіксувати всі елементи, які можуть на нього вплинути: завдання, бажаний стан, засіб оцінювання, конфігурацію моделі, інструкції та умови використання інструментів. Якщо щось з цього змінюється, потрібно знову пройти відповідні тести. Фіксація бажаного стану має таке ж значення, як і фіксація конфігурації моделі; наша стаття про фіксацію версій у наборах для оцінки LLM детальніше розглядає це питання.
Офлайн-тести та безперервний моніторинг відповідають на різні запитання. Ретельно підготовлені тести перед випуском допомагають зрозуміти, чи безпечна певна зміна для впровадження; оцінка реальних взаємодій дозволяє виявити проблеми у реальних умовах. Документація LangSmith описує обидва підходи та рекомендує включати дані про проблеми у продакшн назад до набору тестів.
Для асистента календаря такий цикл може починатися зі звітів користувачів про дублюючіся події, додавати в набір випадки втрати відповіді та перевіряти, чи фікс правильно працює, перш ніж розпочати його ширше використання.
Ключові висновки
- Розглядайте статус „Готово“ як твердження, яке потрібно підтвердити, а не як доказ.
- Складайте контракт для кожного випадку: початковий стан, запит, дозволені дії, необхідний кінцевий стан та те, що не повинно змінюватися.
- Оцінюйте результат, дотримуйтесь встановлених меж та використовуйте трекінг для пояснення відмінностей.
- Перевіряйте через незалежний, авторизований шлях читання та зберігайте статус „неперевірено“ як чесний результат.
- Явно тестуйте випадки тайм-аутів, дублікатів та відсутності дій; саме там зазнають невдачі надійні агенти.
- Не враховуйте критичні збої у середніх показниках якості та вимірюйте надійність повторних спроб.