Оцінка агентів за допомогою бота для подорожей: результат проти траєкторії, переходи та показник pass^k.

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

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

Звичайне програмне забезпечення має детерміністичні тести на одиницю, такі як assert add(2, 2) == 4. Агенти є стохастичними та можуть обирати різні шляхи до однієї мети, тому просте порівняння рядків кінцевого тексту є недостатнім. Оцінка агентів заповнює цю прогалину.

Аналогія з іспитом з математики

Уявіть вчителя, який оцінює іспит, дивлячись лише на кінцеве число. Тут виникають дві проблеми:

1. Удалий здогад. Сам процес є безглуздим – дві арифметичні помилки скасовують одна одну, і відповідь випадково виявляється правильною.
2. Помилка в останньому рядку. Метод є бездоганним, теорема зрозуміла, але через опечатку в кінці замість 42 стоїть 41.

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

• Результат: бізнес-результат, який він досяг.
• Траєкторія: шлях, який він пройшов для досягнення цього результату.

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

Два критерії оцінювання

Будь-якого агента можна перевірити за двома незалежними параметрами.

Що саме перевіряється?

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

Як відбувається оцінювання?

• Детерміністичні перевірки стосуються фактів, на які існує об’єктивна відповідь. Ціна може бути 150 доларів або ні, інструмент міг бути використаний або ні. Для цього використовуються прості твердження коду.

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

Приклад з практики: агент з бронювання подорожей

Візьмемо агента, який займається плануванням маршрутів. Запит: дешевий рейс, три ночі в готелі в Нью-Йорку та трансфер з аеропорту. Для цього він може використовувати інструменти під назвами search_flights, search_hotels, book_flight, book_hotel та book_airport_transfer.

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

Метрики результату перевіряють об’єкти бронювання, які фактично створив агент: вартість квитка, ціну за ніч, трансфер, валюту та дати.

Критерії перед середніми значеннями

Урок, який зазвичай доводиться вивчати на власному горькому досвіді: не кожна метрика підходить для включення до одного середнього балу. Уявіть агента, який має загальний бал 95% завдяки елегантним міркуванням та ідеальному порядку використання інструментів, проте бронює квиток за ціною 1 500 доларів замість 150 доларів. У реальних умовах це не є вдалим виконанням завдання — це фінансова катастрофа.

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

Етап 1 – контрольні перевірки. Спочатку виконуються детерміністичні перевірки критичних полів: цін, дат, валюти, ідентифікаторів оплати та факторів, що впливають на стягнення зборів. Якщо будь-яка з цих перевірок провалюється, весь тест одразу ж вважається невдалим. Жодні хороші логічні міркування не можуть це змінити.

Етап 2 – взвешена оцінка. Лише ті тести, які пройшли всі контрольні перевірки, отримують оцінку якості, яка розраховується на основі інших показників, таких як ефективність інструменту, якість міркувань, дотримання плану та семантична відповідність. Правило просте: якщо тест пройшов контрольні перевірки та його взвешена оцінка досягла або перевищила певний поріг, наприклад 0,85, це означає успішний результат.

Діагностика проблем за допомогою матриці 2×2

Одина цифра „82% рівень успішності“ не надає жодної корисної інформації для виправлення проблем. Вам потрібно знати, чому експерименти провалилися, щоб вирішити, чи потрібно виправляти запит, інструменти чи набір даних. Якщо порівняти результат із траєкторією, з’являються чотири квадранти:

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

Повний трек експерименту

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

// Step 1: Upfront Plan Formulation
Thought: "I need to book budget travel to NYC for 3 days. Plan: 1) Search economy flights, 2) Search budget hotels in NYC, 3) Book flight, 4) Book hotel for matching dates, 5) Book airport transfer."

// Step 2: Tool Call - search_flights
→ call: search_flights({ origin: "SFO", destination: "JFK", cabin_class: "economy", date: "2026-10-10" })
← return:
[
  {
    flight_id: "fl_eco_9921",
    airline: "BudgetAir",
    price: 150.00
  }
]

// Step 3: Tool Call - search_hotels
→ call: search_hotels({ city: "New York", checkin: "2026-10-10", nights: 3, max_rate: 150 })
← return:
[
  {
    hotel_id: "ht_manhattan_pod",
    name: "Pod Midtown NYC",
    rate_per_night: 120.00
  }
]

// Step 4: Tool Call - book_flight
→ call: book_flight({ flight_id: "fl_eco_9921", passenger: "Chris Dias", price: 150.00 })
← return:
{
  booking_ref: "BK-FL-7701",
  status: "confirmed"
}

// Step 5: Tool Call - book_hotel
→ call: book_hotel({ hotel_id: "ht_manhattan_pod", nights: 3, rate_per_night: 120.00, guest: "Chris Dias" })
← return:
{
  reservation_id: "RSV-HT-8832",
  status: "confirmed"
}

// Step 6: Tool Call - book_airport_transfer
→ call: book_airport_transfer({ pickup: "JFK", dropoff: "Pod Midtown NYC", fee: 35.00 })
← return:
{
  ride_id: "TX-4402",
  status: "confirmed"
}

// Step 7: Final Synthesized Output Payload
Final Output:
{
  flight: {
    id: "fl_eco_9921",
    cabin: "economy",
    price: 150.00,
    status: "confirmed"
  },
  hotel: {
    id: "ht_manhattan_pod",
    nights: 3,
    rate_per_night: 120.00,
    status: "confirmed"
  },
  transfer: {
    service: "JFK Pickup Shuttle",
    fee: 35.00,
    status: "confirmed"
  },
  total_billed: 545.00
}

Далі система перевіряє критично важливі параметри: ціну перельоту, вартість проживання в готелі за ніч та витрати на трансфер. Припустимо, що всі три значення відповідають очікуваним показникам – 150 доларів, 120 доларів за ніч та 35 доларів. Система схвалює запит, і процес переходить на 2-й етап.

На 2-му етапі кожному з залишених показників присвоюється оцінка від 0 до 1, яка множиться на його вагу; сума всіх ваг дорівнює 1. Наприклад, припустимо, що п’ять показників мають ваги 0,20, 0,20, 0,15, 0,15 та 0,30 та оцінки 1,0, 1,0, 0,8, 1,0 та 0,95 відповідно. Сумарна оцінка з урахуванням ваг становить 0,20 + 0,20 + 0,12 + 0,15 + 0,285, що дорівнює 0,955. Оскільки це значення перевищує порог у 0,85, встановлений перед запуском, процес схвалюється.

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

Вимірювання дисперсії за допомогою pass@k та pass^k

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

У технічному описі Anthropic щодо оцінки агентів описано два показники для контролю цієї варіабельності — pass@k та pass^k.

pass@k: можливості

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

Це підходить для схем із участю людини та систем з автоматичними верифікаторами: три проєкти маршрутів для вибору менеджером подорожей або п’ять кандидатських SQL-запитів, серед яких двигун обирає перший коректний.

pass^k: послідовність

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

• одна спроба: 75,0%,
• три спроби поспіль: приблизно 42,2%,
• п’ять спроб поспіль: приблизно 23,7%,
• десять спроб поспіль: приблизно 5,6%.

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

Чому важливий цей вибір

Коли k дорівнює 1, обидві метрики є ідентичними та дорівнюють базовому рівню успішності. При k, дорівньому 10, вони показують протилежні результати: pass@k наближається до 100%, оскільки достатня кількість спроб зрештою призведе до успіху, тоді як pass^k наближається до нуля, адже десять бездоганних виконань без жодної помилки чи збою інструменту є складним завданням. Вибір метрики, яка відповідає обіцянкам вашого продукту, допомагає відрізнити формальні показники від справжньої надійності.

Практичні рекомендації

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

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

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

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