Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агента, который вызывает внешние инструменты, научили лучше справляться с неполными ответами пользователя. В препринте University of Notre Dame, который не прошёл рецензирование и приводит замеры самих авторов, StaGPO поднял успешность Qwen3.5-2B на ToolWOZ до 76,8% — на 4,8 процентного пункта выше GRPO. Для продуктовой команды это аргумент менять не только симулятор пользователя, но и способ распределять награду между шагами агента.
Почему обучение на слабом пользователе не сработало само
Авторы отделили неполный ответ от других особенностей поведения. Симулятор знал задачу и отвечал как обычно, но каждое предложение с заданной вероятностью заменялось маркером [inaudible]. Симулятор продолжал видеть исходную реплику, поэтому не понимал, что часть ответа не дошла до агента.
Такой подход имитирует потерю данных в канале: пользователь назвал дату, ограничение или второй пункт ответа, но система этого не получила. Он не воспроизводит человека, который сам не знает ответа, противоречит себе или формулирует запрос расплывчато.
Обычное обучение с подкреплением не исправило разрыв. Фиксированная доля пропусков, смесь полных и неполных диалогов и постепенное усложнение давали результаты в пределах разброса между запусками. Иногда агент, обученный на слабом пользователе, хуже обслуживал пользователя с полными ответами.
Прямое указание чаще задавать вопросы тоже не помогло. Агент переспрашивал в пять раз чаще после повреждённой реплики, но успешность не выросла: он не определял, какой именно факт потерян и в какой момент его нужно восстановить.
Причина связана с тем, как GRPO назначает награду. Метод оценивает диалог по конечному результату и передаёт один и тот же сигнал всем действиям внутри траектории. Уточнение потерянной даты и повтор бесполезного вызова API получают одинаковую оценку, если находятся в одном диалоге.
Как состояние диалога превращается в оценку отдельного шага
StaGPO заставляет агента перед каждым действием записывать скрытое состояние. В нём перечислены цель и требования задачи, недостающие сведения, последние вызовы инструментов и их результаты. Пользователь эту запись не видит.
Из состояния строится ключ: текущая область и действие, уже известные поля и результат последнего вызова инструмента. Шаги из разных траекторий с одинаковым ключом объединяются в группу. Так метод сравнивает действия, сделанные в сходной ситуации, даже если тексты предыдущих реплик различаются.
Внутри группы шаг получает дополнительную оценку по тому, насколько быстро и успешно завершилась его траектория относительно остальных. Общая награда GRPO остаётся, но к ней добавляется сигнал для конкретного шага. Отдельная модель, которая предсказывает ценность состояния, для этого не нужна.
Перед обучением StaGPO использует короткую подготовку на готовых диалогах. Она учит модель стабильно записывать состояние, чтобы одинаковые ситуации действительно попадали в общие группы. Без этой подготовки доля сгруппированных шагов снижалась, а метод не превосходил GRPO.
На ToolWOZ версия Qwen3.5-4B со слабым пользователем достигла 81,5%, опередив GRPO на 6,7 процентного пункта. На tau2-bench StaGPO показал лучший результат для обеих моделей, хотя преимущество версии Qwen3.5-4B над ближайшим вариантом осталось в пределах погрешности. Простая запись того же состояния без группировки шагов результата не дала: сработал способ назначать награду, а не дополнительный текст сам по себе.
Когда стоит менять план разработки агента
Работа касается систем, где задача распадается на обязательные поля и вызовы инструментов: бронирование, поддержка клиентов, оформление заказа или изменение записи. Если агент действует при неполных данных, одного набора диалогов с плохой связью недостаточно. Обучение должно отличать полезное уточнение от случайного успеха всей беседы.
Практический первый шаг — фиксировать, какие сведения нужны для каждого действия, какие уже получены и чем закончился последний вызов API. Это позволяет отдельно проверить полные и повреждённые диалоги, а затем решить, нужен ли метод вроде StaGPO. Без такого состояния команда не сможет сформировать группы сравнимых шагов.
StaGPO нельзя считать готовой общей заменой GRPO. Ключ состояния проектируют под конкретную предметную область, а модель генерирует структурированную запись перед каждым действием. Значит, в план обучения придётся добавить подготовочные диалоги, проверку качества состояния и правила его преобразования в ключ.
Границы эксперимента узкие: проверяли Qwen3.5-2B и Qwen3.5-4B на ToolWOZ и розничной части tau2-bench с симулятором gpt-oss-120b. Слабость пользователя создавали удалением предложений с явным маркером потери; естественные пропуски без такого сигнала и разговоры с людьми не проверяли. Для части конфигураций старшей модели провели по одному запуску.
Поэтому работа меняет план там, где сбои похожи на потерю известных полей: плохое распознавание речи, обрезанные сообщения или частичные ответы на составной вопрос. Для пользователей, которые ошибаются, меняют требования или сами не знают нужных данных, эти результаты переносить рано.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
