Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Оценивать социального ИИ-агента по убедительности разговора недостаточно: он может звучать уместно, но договориться о плане, который нарушает условия участников. В препринте Alibaba Token Hub, Alibaba Group и The University of Tokyo, который не проходил рецензирование и содержит замеры самих авторов, 36% высоко оценённых диалогов не прошли проверку результата. Для продуктовой команды это меняет прежде всего контур испытаний: после разговора надо проверять не только текст, но и выполнимость договорённости.
Как проверить не разговор, а договорённость
Обычная модель-оценщик читает разговор и выставляет баллы за достижение цели, естественность и соответствие роли. Такой подход не проверяет, совпало ли понимание участников и подходит ли итоговый план под их скрытые условия.
HICO-Bench отделяет впечатление от результата. В него вошли 180 бытовых сценариев: распределение расходов, согласование времени, выдача разрешений, выбор допустимого количества и совместное использование ресурсов. У каждого участника есть закрытая карточка с ограничениями, которые собеседник может узнать только из разговора.
После диалога оба агента независимо записывают согласованный план в структурированном виде. Программа проверяет выполнимость: совпадают ли записи, правильно ли выбран тип исхода и соблюдены ли частные условия обеих сторон. Например, доли должны покрывать общий счёт и не превышать предел каждого участника, а встреча — попадать в доступное обоим окно.
Второй тест проверяет обоснованность плана разговором. Модель-оценщик ищет противоречия между репликами и итоговой записью, выдуманные полномочия, бесплодные повторы и служебный текст внутри диалога. Успех засчитывают, только когда пройдены обе проверки.
Каждый сценарий существует в паре вариантов с одинаковым открытым контекстом, но разным частным условием. Правильные планы для них несовместимы. Если агент предлагает одно и то же независимо от доступности человека, бюджета или полномочий, хотя бы один вариант неизбежно проваливается.
Как PaCPO находит полезный ход в разговоре
Итоговая проверка показывает, что разговор закончился правильно, но не объясняет, какая реплика помогла. Это мешает обучению с подкреплением: награда приходит в конце, хотя решающим мог быть вопрос в середине диалога.
PaCPO после каждого хода отдельно просит агента записать предварительный план, не добавляя эту запись в разговор. Затем система проверяет план на обоих вариантах сценария. Пока ключевое частное условие не раскрыто, одинаковый ответ выглядит естественно. После раскрытия планы должны разойтись и соответствовать своим вариантам.
Награду получает ход, после которого такое расхождение стало правильным. Метод не увеличивает общую награду за разговор, а переносит её часть с финала на полезные реплики. Отдельный ограничитель не позволяет начислять баллы до того, как агент действительно узнал различающее условие.
В сравнении 13 LLM хорошо написанный разговор регулярно не совпадал с проверяемым исходом. При обучении Qwen3-8B доля успешных результатов выросла с 20,4% до 28,3%. При одинаковом бюджете диалогов PPO достиг 25%, а GRPO — 26,3%.
Разница проявляется не только в итоговой записи. В одном примере исходная модель ошибочно решила, что окна использования общего стола пересекаются, а собеседник согласился. После PaCPO агент заметил промежуток между окнами. Итоговые записи в обоих разговорах оказались выполнимыми, но лишь второй диалог действительно обосновывал их.
Что меняется в планах продуктовой команды
Ближайшее практическое следствие относится к оценке, а не к смене модели. Если агент согласует расписание, лимиты, доступ или распределение ресурсов, тестовый набор стоит заканчивать машинной проверкой результата. Высокого балла за разговор недостаточно даже тогда, когда оценщик считает цель достигнутой.
Работа предлагает полезную схему испытаний: скрытые условия сторон, структурированная запись результата, программные правила допустимости и отдельная проверка того, что разговор поддерживает итог. Парные варианты помогают обнаружить агента, который выдаёт правдоподобный шаблон вместо того, чтобы выяснить решающий факт.
PaCPO требует более заметных изменений в обучении. Команде придётся создавать пары сценариев с несовместимыми ответами, писать проверяющие программы, извлекать предварительный план после каждого хода и отмечать момент раскрытия частного условия. Такой конвейер оправдан там, где правильный результат можно формализовать и где ошибка в договорённости важнее стилистики ответа.
Границы проверки проходят по структурированным задачам бытовой координации. Выполнимость там определяется правилами, но обоснованность разговора всё ещё оценивает LLM. Дополнительные испытания охватывают самоигру, SOTOPIA, MultiWOZ и CaSiNo: улучшения переносятся за пределы HICO-Bench, однако особенно узким остаётся переход к открытым разговорам, где допустимый итог нельзя записать в фиксированную форму.
Поэтому работа не даёт универсального способа обучить социального агента. Она показывает более прикладную вещь: при формализуемом исходе план нужно сделать отдельным объектом проверки, а обучение — привязать к моменту, когда разговор действительно изменил этот план.
Источники
Иллюстрация: рисунок из статьи «What Makes a Social Agent's Interactions Effective? Learning from Verifiable Outcomes in Paired Worlds», Caixin Kang, Ke Wang, Yuchuan Wu и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
