MADS учит диалоговых агентов не ломаться: 1095 диалогов, 66% с «плохими» сценариями

Диалоговые агенты, которые бронируют, оформляют возвраты и меняют тарифы через вызов функций, хорошо работают, пока пользователь вежлив и чётко формулирует запрос. Реальные пользователи так себя ведут не всегда. Авторы препринта arXiv:2610.12757 предлагают MADS (Multi-Agent Dialog Simulation) — конвейер синтетических данных, который сознательно строит диалоги с недружелюбным и неконструктивным собеседником. На его основе собран MADS-Bench: шесть доменов, 55 персон, 1095 диалогов. Примерно 66% разговоров содержат сценарии, где агент легко ошибается.

Почему существующих бенчмарков не хватает

По оценке авторов, популярные наборы для проверки function calling недопредставляют состязательные траектории. Там много «счастливых путей»: пользователь называет все параметры, не меняет решение и не спорит. Модель, обученная на таких данных, получает мало опыта общения с человеком, который уходит от вопросов, противоречит себе или давит на агента.

Разрыв получается замкнутым. Собрать реальные неудачные диалоги дорого и непросто с точки зрения приватности. Размечать их вручную ещё дороже. Поэтому в обучающих выборках таких случаев мало, а агент проваливается именно там, где от него требуется надёжность.

Как устроен MADS

MADS работает как мультиагентная симуляция. Несколько LLM-ролей разыгрывают разговор, причём одна из них играет пользователя с заданной персоной и поведенческим профилем. В диалог по замыслу инжектируется враждебное или неконструктивное поведение. Затем траектории проходят валидацию, и в набор попадают только проверенные. Отсюда формулировка авторов о «валидированных траекториях, отражающих реалистичные несчастливые пути».

В аннотации не раскрыто, какие именно модели играют роли и по каким критериям идёт валидация. Это ключевой вопрос к полному тексту статьи, потому что от него зависит реалистичность данных.

Что внутри MADS-Bench и как проверяли модели

Параметры набора из аннотации:

• 6 предметных доменов;
• 55 персон пользователей;
• 1095 диалогов, то есть в среднем около 20 на персону и около 180 на домен;
• примерно 66% разговоров с failure-prone сценариями, это порядка 720 диалогов.

Для оценки устойчивости авторы используют двухэтапное обучение. Сначала идёт supervised fine-tuning (SFT) на сгенерированных траекториях. Затем применяется reinforcement learning with verifiable rewards (RLVR), где награда считается проверяемым способом. Для агентов с вызовом функций это естественный выбор: корректность вызова, аргументов и итогового состояния системы можно проверить программно, без субъективного судьи.

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

Что с этим делать практикам

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

Сам MADS-Bench имеет скромный размер, всего 1095 разговоров. Это скорее стенд для сравнения подходов, чем большой обучающий корпус. Ценность работы в методе: он показывает, как систематически производить данные о том, где агенты ломаются. Остаётся дождаться полного текста, кода и цифр по результатам обучения.