Оценка агентов с помощью поискового бота для путешествий: результат против траектории, блоки и параметр 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 долларов. Система одобряет запрос, и процесс переходит на второй этап.

На втором этапе каждому оставшемуся показателю присваивается оценка от 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 попытках, что соответствует степени k от вероятности успеха на одну попытку p. По мере увеличения k значение быстро снижается. Предположим, агент успешно выполняет 75% отдельных попыток:

• одна попытка: 75,0%,
• три попытки подряд: примерно 42,2%,
• пять попыток подряд: примерно 23,7%,
• десять попыток подряд: примерно 5,6%.

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

Почему важен этот выбор

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

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

1. Не тестируйте только окончательный ответ. Агент, который приходит к правильному ответу с помощью некорректных рассуждений, представляет риск в производственных условиях.
2. Сочетайте код и оценку с помощью LLM. Используйте детерминистичный код для расчета цен, идентификаторов и проверки наличия, а оценку с помощью LLM — для оценки качества рассуждений, соблюдения плана и соответствия намерениям.

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

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

Надежные агенты появляются не благодаря надежде на правильное поведение модели в текущий момент, а благодаря системе, которая ежедневно проверяет её работоспособность.