Як оцінити AI-агента, перш ніж дозволити йому діяти

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

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

Визначте базовий рівень для порівняння

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

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

Складіть репрезентативний набір завдань

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

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

Перевіряйте весь шлях виконання

Фінальна відповідь — лише один із результатів роботи агента. На шляху до неї можуть бути пошуки, виклики інструментів, передавання завдання, повторні спроби й погодження. У рекомендаціях OpenAI щодо оцінювання агентів ці кроки фіксують у traces — журналах виконання, а інструменти оцінювання, graders, допомагають відповісти на конкретні запитання: чи правильно обрано інструмент? Чи коректні аргументи? Чи вчасно передано завдання? Чи порушено правило безпеки?

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

Обережно використовуйте автоматичні graders

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

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

Перевіряйте безпеку та відновлення

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

Rollback — відкат змін — теж потрібно тестувати. Задокументований rollback, який жодного разу не виконували, залишається припущенням. У staging переконайтеся, що дії залишають записи для аудиту й можуть бути скасовані без шкоди для іншого стану системи.

Розширюйте повноваження поетапно

Практична послідовність може бути такою:

1. offline-оцінювання на фіксованих прикладах;
2. робота з актуальними даними лише в режимі читання;
3. shadow mode паралельно з реальним процесом;
4. обмежені дії у staging за погодженням;
5. вузько визначені дії у production з моніторингом і rollback;
6. розширення повноважень лише тоді, коли це обґрунтовано новими доказами.

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

Оцінювання має тривати

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

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

Про послідовність упровадження читайте в матеріалі «Від AI-демонстрації до надійного робочого процесу». Про проєктування повноважень — у статті «Безпека AI-агентів».

Першоджерела

• OpenAI: Evaluate agent workflows
• OpenAI: Testing agent skills systematically with evals
• NIST AI Resource Center
• NIST Generative AI Profile

Примітка про джерела й адаптацію: стаття спирається на концепції оцінювання з AI Agents in Depth: Design Principles and Engineering Practice авторства Bojie Li та співавторів, поширюваної за Apache License 2.0, а також на наведені першоджерела. Матеріал самостійно переписано, реорганізовано й розширено для Stariy.com.