Ацэнкі агентаў на прыкладзе бота для падарожжаў: вынік супраць траекторыі, фільтры і pass^k

Агенты не проста ўтвараюць запыткі да API. Яны размышляюць, выбіраюць інструменты на лету, ствараюць багатыя планы дзеяння і рашаюць задачы з нечыясным выходам, якія раней захоплялі гадзіны часу людзя. Але як толькі ўсё пераходзіць у рэжым працы, з’яўляецца некомфортны вопыт: як вы ведаеце, што усё працуе?

Не сёння, пад час вашага улюбленага дэманстрацыйнага запытку, а наступной тыдзень, пасля таго, як хтось зменіў інструкцыі сістэмы, дадаў новы інструмент, заменіў базовую мадэль або пасправіў запытак. Чы не вылечыла гэтая змена адну проблему, але тыхама нарабіла трохце іншых?

Звычны програмнае забезпечэнне мае дэтэрміністычныя тэсты на елементы, такія як assert add(2, 2) == 4. Агенты ж ёсць верагатыстычнымі і можу праходзіць разнымі шляхамі да аднаго тыяжэла, таму простая парадоражнае порашчатка фінальнага тэксту недастаткова. Функцыя eval для агентоў заполняе гэты праслой.

Аналагія з экзаменам па матэматыцы

Уявіце вучыльніка, які оцэнюе экзамен, прыглядаючыся толькі да фінальнага рэзултата. Тут выходзяць две проблемы:

1. Ўдачны ўдзячэнне. Працэс вырахунку ёсць безглуздым: два арыфметычныя памылкі анулююцца, і адпаведны адказ выходзіць правільным проста з віпадку.
2. Памылка ў пасляпэднім кроце. Метадыка ўсё правільная, тэза разумелая, але памылка ў самым канцы прыводзіць да таго, што замест 42 пішо 41.

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

• Рэзультат: бізнес-рэзультат, які ён даў.
• Траекторыя: шлях, які ён праехаў, каб даў гэты рэзультат.

Проста кажучы, ацэнкаванне агента — гэта ацэнкаванне рэзультата плюс ацэнкаванне траекторыі, якія меркаюцца ў рамках адной тэставанняя з вікорыстаннем сумесці жорсткых перакрыцэнняў коду і гнеклівых крытэрыяў ацэнкі.

Две праметры для ацэнкі

Кожны агент можа быць пераглянуты па двух незалежных вімерах.

Што аналізуецца?

• Перагляды рэзультатаў спрашваюць, чы існуе правільны канечны рэзультат — напрыклад, праві рэйс, правы тарыф на гасцінючы або правы запіс бронівання.
• Перагляды траекторыі спрашваюць, чы агент дасягнуў меты надзеямо: чы інструменты былі вызваны ў разумной парадзе, чы былі перэданы праваматныя параметры, чы не было бесканцовых цыклів.

Як ацэнюецца?

• Дэтэрміністычныя перагляды абарачваюць факты, на якія ёсць об’екtyўны адказ. Цэна можа быць 150 долераў або нея, інструмент мога быць вызваны або нея. Для этага выкарыстоўваюцца простыя тэзы коду.

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

Прыклад працы: агент з броніравання паездак

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

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

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

Крокі перад аблікаваннем сярэжнікаў

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

Ёнколі сільныя рэзультаты логічных выводам не павінны маскаваць крытычныя прычыны некальканняў у бізнесе, ацэнка можа выконваліцацца у два этапы.

Этап 1 – контрольныя пункты. Спачатку выконвуцца дэтэрміністычныя пераканальвання для крытычных поль: цэн, дат, валют, ідэнтыфікатораў вырачоўкі і фактораў, якія запускаюць налогаванне. Калі хоць адна з такіх пераканальванняў не прыме, весь тэст негайна абарачваецца неудачай. Ніякія хорашыя логічныя выводы не можуць гэта змяніць.

Этап 2 – вагованая шкала. Толькі тэсты, якія праўільна перайшлі ўсе контрольныя пункты, атрымуюць бал за якасць, які вырачваецца на адной з засталых метрык: эфектыўнасць інструмента, якасць логічных выводам, адпаведнасць плану і семантычная зусімнасць. Правіла простыя: якшо тэст праўільна перайшоў усе контрольныя пункты і яго вагованы бал стоіць на рэвэлі 0,85 або вышэй, значыць тэст прымножаны.

Дыягнастыка некальканняў за дапамою 2x2 матрыцы

Адзін показначальнік „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. Заўсёды запускайце весь комплекс тэстоў, калі змянюецца запіт чы мадэль, ўплыв такім чынам будзе выяўлены раней, чым яго пазнаюць корыстувальнікі.

Надзея на тое, што мадэль будзе працаваць правільна сёння, не дапамагае стварыць надзяйныя агенты. Іх стварае сістэма, якая ўсё дні пераканваецца, што мадэль дэйсна працуе правільна.