Як оцінювати ШІ-агента? Завдання, траєкторії, надійність і вартість

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

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

Термінологія оцінювання агентів

Посібник Anthropic із пояснення принципів оцінювання агентів пропонує корисний набір термінів:

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

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

Почніть із чіткого опису завдання

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

Для агента підтримки завдання «розв’яжи звернення» надто нечітке. У точнішому описі зазначено дані клієнта, застосовну політику, дозволені способи розв’язання, необхідну комунікацію та зміни, які мають з’явитися в системі обліку. Тоді результат можна оцінити об’єктивно.

Чотири рівні оцінювання агентів

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

1. Якість результату

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

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

2. Якість траєкторії

Чи обрав агент обґрунтований шлях? Оцінювання траєкторії може виявити непотрібний доступ до даних, заборонені інструменти, повторні невдалі спроби, пропущену перевірку, вигадані спостереження або порушення вимог щодо погодження.

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

3. Безпека та дотримання політик

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

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

4. Операційна ефективність

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

Використовуйте різні типи оцінювачів

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

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

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

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

Надійність потребує повторних випробувань

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

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

Два показники надійності відповідають на різні запитання:

• Pass@k: імовірність того, що успішною буде принаймні одна з k спроб. Цей показник корисний, коли прийнятно зробити кілька спроб.
• Pass^k: імовірність того, що успішними будуть усі k спроб. Цей показник відображає стабільність, коли кожен запуск має завершитися успішно.

Система може мати привабливий показник pass@k, але водночас бути непридатною для автоматичної роботи через ненадійність окремих запусків.

Сформуйте репрезентативний набір завдань

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

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

Оцінюйте середовище, а не лише модель

Ефективність агента залежить від визначень інструментів, дозволів, пам’яті, керування контекстом, інтерфейсу користувача, поведінки мережі та оркестрації. Оновлення моделі може усунути одну помилку, водночас виявивши іншу.

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

Поширені помилки під час оцінювання

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

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

Від офлайнового оцінювання до моніторингу в робочому середовищі

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

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

Практична система оцінювання агента

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

До корисної системи оцінювання можна включити:

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

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

Що варто пам’ятати про оцінювання ШІ-агента

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

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