Запуск агента — це лише перший крок.Автор статті: elune
Переклад статті, джерело: ME News
Запуск агента — це лише перший крок.
Справжнім викликом є визначення: чи він стабільний, чи правильний, чи не відбувається тихого деградування через зміну запиту або оновлення моделі.
Наступні 10 методів оцінки варто знати кожному інженеру з ІІ.
1. Золотий набір тестів｜Golden Set
Підготуйте набір фіксованих та заморожених тестових випадків.
Після кожного змінення підказок, моделі, інструментів або робочого процесу повторно запускайте цей набір прикладів, щоб визначити, чи став система кращою, чи вона тихо перестала працювати в певних сценаріях.
Це найпростіша базова лінія в системі оцінки агента.
Рекомендований інструмент: OpenAI Evals
Може використовуватися для створення набору тестів, які можна повторно запускати, та порівняння продуктивності різних моделей або версій системи.
2. Суддя на основі LLM | LLM як суддя
Використовуйте іншу велику мовну модель для оцінки відкритих відповідей за заздалегідь написаними критеріями.
Цей метод особливо ефективний, коли завдання не має єдиного правильного відповіді і не може бути оцінено за допомогою зіставлення рядків або фіксованого виводу.
Наприклад, модель-суддя може оцінити, чи є відповідь точна, повна, релевантна та чи відповідає вона вимогам користувача.
Рекомендований інструмент: OpenEvals
Надаємо готові оцінювачі для застосунків LLM, що дозволяють швидко створити автоматизований процес оцінки.
3. Багатовимірна оцінка | Rubric Scoring
Не давайте агенту лише загальну «оцінку якості».
Слід оцінювати окремо:
- Правильність
- Цілісність
- Стиль вираження
- Безпека
- Час відгуку
- Вартість виклику
Комплексна оцінка може приховати справжні проблеми.
Наприклад, зниження загальної оцінки може бути не через неправильну відповідь, а через раптове збільшення вартості виклику інструментів; зростання загальної оцінки також може базуватися на зниженні безпеки.
Рекомендований інструмент: DeepEval
Підтримує створення користувацьких індикаторів та незалежне оцінювання різних вимірів якості.
4. Оцінка траєкторії｜Trajectory Eval
Оцінюйте не лише фінальну відповідь, надану агентом, але й весь процес виконання завдання.
Включаючи:
- Чи вибрано правильний інструмент?
- Чи викликаються інструменти в логічному порядку?
- Чи повторювати некоректні дії
- Чи пропущено необхідні кроки?
- Чи правильно коригуються рішення на основі результатів інструментів?
Агент може в кінцевому підсумку отримати правильну відповідь, але проміжні етапи будуть неефективними, хрупкими або навіть ризикованими.
Рекомендований інструмент: AgentEvals
Можна перевірити дії, рішення та виклики інструментів агента в повній траєкторії виконання.
5. Інструментальні модульні тести | Tool Unit Tests
Напишіть окремі тести для кожного інструменту, використовуваного агентом.
Використовуйте фіксований вхід, щоб перевірити фіксований вихід, не залучаючи модель.
Так можна розділити питання:
Чи проблема в інференсі агента, чи в нижчому рівні інструментів, інтерфейсів або сервері MCP?
Тільки переконавшись у надійності самого інструменту, має сенс оцінювати, чи правильно Agent викликав інструмент.
Рекомендований інструмент: MCP Inspector
Може використовуватися для перевірки та тестування MCP Server, параметрів інструментів та результатів повернення.
6. Набір регресійного тестування | Regression Suite
Зберігайте минулі реальні випадки виконання та повторюйте їх після кожного оновлення підказок, моделей або набору інструментів.
Потім порівняйте результати нової та старої версій, перевірте:
- Чи провалився спочатку правильний завдання
- Чи змінився формат виводу?
- Чи збільшується виклик інструментів?
- Чи зросли затримки та витрати?
- Чи деградують деякі крайні випадки?
Краща середня продуктивність нової версії не означає, що вона не порушила старі функції.
Рекомендований інструмент: Promptfoo
Підтримує запуск повторюваних наборів оцінок, виявлення регресійних проблем та інтеграцію процесів перевірки в CI.
7. A/B-тестування у виробничому середовищі｜A/B Testing in Production
Випадково розподілити реальний користувацький трафік між двома різними версіями та порівняти їхню продуктивність у реальних умовах.
Можна протестувати:
- Два набори підказок
- Дві моделі
- Два робочих процеси агента
- Різні комбінації інструментів
- Різні стратегії відповідей
Офлайн-версія з вищим рейтингом не обов’язково призводить до вищої успішності користувачів.
Насправді важливими є реальні результати, такі як відсоток виконаних завдань, рівень прийняття користувачами, коефіцієнт перетворення, відсоток передачі на людину та відсоток вирішення питань.
Рекомендований інструмент: GrowthBook
Надає функції вимикачів, контролюваних експериментів та аналізу продукту.
8. Ручна перевірка | Human Review
Періодичний відбір реальних записів виконання для оцінки людськими рецензентами.
Ручний контроль може виявити проблеми, які були пропущені автоматизованими оцінками, а також використовуватися для калібрування суддів LLM.
Потрібно перевірити з особливою увагою:
- Чи збігаються оцінки моделі з людськими судженнями?
- Чи є критерії оцінювання достатньо чіткими?
- Чи віддає модель-суддя перевагу довгим відповідям?
- Автоматична оцінка на наявність пропущених серйозних помилок
Автоматизована оцінка не може повністю замінити людське судження.
Рекомендований інструмент: Argilla
Допомагайте команді збирати ручні відгуки, перевіряти вихідні дані моделі та перетворювати результати у високоякісні набори даних.
9. Тіньовий запуск｜Shadow Run
Запустити кандидатську версію у реальному трафіку, але не відображати її вивід користувачам.
У виробничому середовищі все ще використовується стара версія, тоді як нова версія виконується лише у тиловій частині для порівняння їхньої продуктивності.
Цей спосіб підходить для високоризикованих оновлень, наприклад:
- Змінити основну модель
- Перепишіть системний підказку
- Підключення нових зовнішніх інструментів
- Змінити логіку прийняття рішень Agent
- Розширити права інструментів
Тіньове виконання допомагає команді виявити проблеми у реальному трафіку до офіційного запуску, уникнувши при цьому прямого впливу на користувачів.
Рекомендований інструмент: Langfuse
Відстежуйте виробничі запуски, порівнюйте варіанти та моніторте результати оцінки.
10. Тестування червоною командою | Red Teaming
Атакуйте свою власну систему до того, як це зроблять зловмисники.
Діапазон тестування включає:
- Втеча з ловушки
- Prompt injection
- Утечка конфіденційних даних
- Обхід прав
- Зловживання інструментами
- Шкідливі файли або вміст веб-сторінки
- Непередбачувана зовнішня дія
Червоні команди особливо важливі для агентів, які можуть звертатися до баз даних, надсилати електронні листи, змінювати файли, виконувати код або отримувати доступ до внутрішніх систем.
Рекомендований інструмент: Garak
Сканування безпечних вразливостей і небезпечних дій у системі LLM.
Офлайн-оцінка показує: система працює нормально в тестовому середовищі.
Онлайн-оцінка показує: система продовжує працювати нормально після запуску.
Ви зараз, можливо, не потребуєте відразу налаштувати всі 10 механізмів оцінки.
Більш практичний підхід:
Проведіть аналіз останньої несправності Agent, а потім пріоритетно впровадьте два методи оцінки, які могли б виявити цю проблему раніше.
Часто достатньо спочатку створити золотий набір тестів, а потім додати регресійне тестування або випадкову перевірку вручну, щоб уникнути великої кількості простих помилок.
Варто зберегти.