τ-bench: Измерение надежности ИИ-агентов в реальных сценариях использования инструментов

Потратив недели на изучение цепочек рассуждений в таблицах и преобразования текста в SQL, я захотел взглянуть на ситуацию шире и задаться другим вопросом: насколько хорошо современные агенты справляются со своими задачами, когда они включены в реальный операционный цикл с живым пользователем? τ-bench дает самый честный ответ, который я когда-либо видел, и цифры в нем отрезвляют.

Статья

Яо, Шинн, Разави и Нарасимхан — все из Принстона и Sierra Research — опубликовали τ-bench (arXiv:2406.12045, июнь 2024 г.), чтобы заполнить пробел, который кажется очевидным в ретроспективе: большинство бенчмарков для агентов просто дают модели задачу и оценивают ее финальный ответ в изоляции. Реальное развертывание выглядит иначе. Агента службы поддержки прерывают, задают ему уточняющие вопросы, предоставляют противоречивую информацию и ожидают от него соблюдения бизнес-политик на протяжении всего открытого диалога перед внесением любых изменений в базу данных.

τ-bench объединяет два прикладных домена обслуживания клиентов — ритейл и авиаперевозки — в среду симуляции, где одна языковая модель играет роль пользователя, а другая — агента. Агент получает доступ к API конкретного домена (отменить заказ, изменить место, применить купон) и документу с правилами, определяющему, какие действия разрешены в определенных условиях. Оценка не учитывает промежуточные шаги: она сравнивает конечное состояние базы данных с аннотированным целевым состоянием. Авторы также вводят pass^k — метрику надежности, которая показывает, какую долю испытаний агент проходит стабильно на протяжении k независимых попыток решения одной и той же задачи.

Ключевые идеи

• pass^k как честная метрика: одиночный показатель pass@1 слишком шумный. pass^k показывает вероятность того, что агент добьется успеха в каждом из k повторных запусков одной и той же задачи — это прокси-метрика того, можно ли доверять ему в продакшене.
• «Обрыв согласованности»: GPT-4o в ритейле набирает 0,604 балла в pass@1, но к pass@4 показатель падает до 0,383. Это означает, что примерно в 60% задач агент терпит неудачу хотя бы один раз за четыре попытки — вряд ли такого агента можно считать безопасным для продакшена.
• Авиаперевозки сложнее ритейла: показатель pass@1 у GPT-4o падает с 0,604 (ритейл) до 0,420 (авиа). Claude 3.5 Sonnet (версия октября 2024 года) справляется лучше — 0,692 (ритейл) / 0,460 (авиа) в pass@1 — но его показатели pass@4 все равно достигают лишь 0,462 и 0,225 соответственно.
• Вызов функций (function calling) выигрывает у ReAct: вариант GPT-4o с использованием вызова функций (pass@1 = 0,420 в авиаперевозках) превосходит как Act (0,365) и ReAct (0,325) на той же архитектуре, что позволяет предположить: структурированные API инструментов уменьшают количество ошибок, вызванных форматом.
• Симуляция пользователя — это переменная: авторы используют языковую модель для симуляции пользователя, что вносит свою дисперсию. Более слабая модель симуляции пользователя может занижать или завышать баллы агента в зависимости от того, насколько точно она воспроизводит состязательное поведение пользователя.
• Оценка состояния БД позволяет избежать накрутки баллов за частичный успех: сравнение конечного состояния, а не шагов диалога, означает, что агент, который выполнил правильное действие, а затем случайно отменил его, не получает баллов — и это правильное решение для систем с правом записи.

Что выдерживает критику, а что нет

Концепция pass^k действительно полезна, и я ожидаю, что она переживет этот конкретный бенчмарк. Решение оценивать состояние базы данных, а не сходство на уровне токенов, является верным — оно напрямую измеряет, выполнил ли агент задачу, а не то, сказал ли он правильные вещи.

Однако домены по дизайну узки. Ритейл и авиаперевозки процедурно чисты: документы политик конечны и написаны специально для бенчмарка, API невелики и четко специфицированы, а симулятор пользователя по умолчанию склонен к сотрудничеству. Реальные документы политик двусмысленны; реальные пользователи лгут, ошибаются и сопротивляются отказам. Авторы бенчмарка признают это — само существование τ²-bench (arXiv:2506.07982) в качестве продолжения, расширяющего модель до Dec-POMDP с двойным управлением, где пользователь также манипулирует состоянием среды, является признанием того, что оценка с одним управляющим субъектом недооценивает сложность.

Также возникает вопрос, что на самом деле измеряет pass^k. Если симуляция пользователя сама по себе стохастична, дисперсия в k испытаниях смешивает несогласованность агента с несогласованностью симулятора. В статье это отмечается, но два этих источника дисперсии не разделяются полностью. Для критически важных приложений хотелось бы понимать причины сбоев: игнорирует ли агент правила, неверно интерпретирует намерения пользователя или просто выбирает неправильный формат вызова инструмента?

Таблица лидеров на llm-stats.com теперь показывает модели вроде Step-3.5-Flash с результатом 0,882, что выглядело бы как колоссальный прогресс, если не заметить, что настройки оценки, вероятно, изменились: новые записи, судя по всему, оцениваются с использованием других версий симулятора пользователя и, возможно, других наборов задач. Сравнение разных записей в развивающихся бенчмарках всегда сомнительно.

Почему это важно для ИИ в финансах

Агент с правом записи в Beancount, которого я имею в виду, структурно идентичен агентам, оцениваемым в τ-bench: у него есть специфические инструменты (добавить транзакцию, скорректировать баланс, перекатегоризировать запись), ограничения политик (не изменять закрытые периоды, не допускать отрицательных балансов, следовать плану счетов) и пользователь, дающий инструкции на естественном языке в ходе диалога, который может длиться много ходов.

Вывод о pass^k — самый прикладной результат для нас. Если современная модель вроде Claude 3.5 Sonnet достигает pass@4 всего 0,462 в ритейле — относительно мягком домене — нам стоит ожидать аналогичной или худшей согласованности при записи в бухгалтерскую книгу, где ошибки накапливаются в транзакциях, а нарушения политик могут быть не сразу заметны. Проектирование с учетом согласованности в k попытках с самого начала — а не просто оптимизация pass@1 — меняет архитектуру: это аргумент в пользу консервативного использования инструментов (спрашивать перед записью, а не после), явных шагов проверки политики перед любым вызовом API и отдельного агента-верификатора, который проводит аудит предложенных изменений в БД перед их фиксацией.

Методология оценки по состоянию базы данных также напрямую переносима. Структурированный формат файлов Beancount позволяет легко сравнивать ожидаемое состояние книги с фактическим после сессии записи, предоставляя нам тот же тип объективного сигнала оценки, который используется в τ-bench.

Что почитать дальше

• τ²-bench (arXiv:2506.07982): продолжение, расширяющее среду до систем с двойным управлением, где пользователи также вызывают инструменты; это напрямую применимо, если мы рассматриваем пользователя как активного участника корректировки книги, а не как пассивного просителя.
• AgentEval / GAIA (arXiv:2311.12983): бенчмарк GAIA оценивает общих ИИ-ассистентов в реальных задачах, требующих просмотра веб-страниц и использования инструментов; полезное дополнение к узкоспециализированному τ-bench.
• WorkArena (arXiv:2403.07718): оценивает агентов в задачах реального корпоративного ПО в ServiceNow; этот домен ближе к бухгалтерским рабочим процессам, чем ритейл или авиаперевозки, и заслуживает внимания с точки зрения дизайна задач.