Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Предложен способ решать, когда агенту уточнить неоднозначную просьбу, а когда сразу действовать с учётом цены ошибки и возможной коррекции пользователя. В препринте команды National University of Singapore, University of Oxford и A*STAR, который не прошёл рецензирование и содержит замеры самих авторов, REVOIR превзошёл обученную политику на планировании бытовых задач. Для продуктовой команды это не новая модель, а схема принятия решений поверх LLM, которую можно проверить без дополнительного обучения.
Как REVOIR оценивает полезность вопроса
Обычная политика уточнений следит за уверенностью агента: если запрос допускает несколько трактовок, агент спрашивает, пока неопределённость не опустится ниже порога. Такой подход не учитывает, повлияет ли ответ на действие. Можно точно выяснить несущественную деталь и всё равно выполнить задачу так же.
REVOIR оценивает не объём новой информации, а ожидаемое изменение результата. Агент сначала составляет небольшой набор гипотез о намерении пользователя. Например, просьба приготовить завтрак может скрывать предпочтения по ингредиентам, порядку подачи и способу приготовления.
LLM присваивает гипотезам веса по тому, насколько они согласуются с историей разговора. Затем агент предлагает несколько возможных вопросов и действий. Внутренняя модель награды оценивает каждое действие для каждой гипотезы, после чего REVOIR усредняет результат с учётом их весов.
Для вопроса агент моделирует возможные ответы пользователя, обновляет гипотезы и снова выбирает действие. Из ожидаемой награды он вычитает цену вопроса и ответа: пользователю приходится прочитать сообщение, сформулировать пояснение и дождаться следующего шага.
Действие оценивается по той же схеме. Если после него пользователь может внести исправление, REVOIR учитывает информацию из этой коррекции и стоимость повторной работы. Поэтому дешёвая обратимая операция может оказаться выгоднее предварительного вопроса, а необратимая или дорогая ошибка сдвигает решение в пользу уточнения.
На каждом ходе агент сравнивает две величины: ожидаемую награду после вопроса и ожидаемую награду при немедленном действии. Вопрос появляется только тогда, когда его польза покрывает связанные с ним издержки. Расчёт смотрит лишь на один следующий шаг, что делает его выполнимым, но не позволяет полностью планировать длинную цепочку уточнений.
Меньше вопросов не снизило качество действий
Метод проверили на двух задачах. В CondAmbigQA агент отвечал на неоднозначные вопросы, причём в одном варианте ответ завершал диалог, а в другом пользователь мог его исправить. В ADAPT агент планировал бытовые задачи в текстовой среде и должен был учитывать скрытые предпочтения пользователя.
На ADAPT REVOIR удовлетворял 56–59% скрытых предпочтений против 44% у обученной политики ReflectionDPO. При этом он задавал примерно впятеро меньше вопросов. Результат также оказался примерно на 6 процентных пунктов выше политики Always-Ask, которая уточняла запросы постоянно.
В CondAmbigQA возможность исправить ответ изменила поведение агента. Если коррекция стоила дёшево, REVOIR чаще действовал сразу: предварительный вопрос не давал преимущества перед попыткой и последующей поправкой. Когда первый ответ завершал диалог, ценность уточнения возрастала.
У обычных агентов с рассуждением такой зависимости не появилось. Увеличение объёма рассуждений само по себе не научило их выбирать между вопросом и действием; напротив, при большем вычислительном усилии они запрашивали меньше уточнений.
Проверка ограничена симуляторами пользователей, моделью-оценщиком для качества ответов и текстовой средой. В ADAPT вопросы задавались до выполнения физического плана, а не вперемешку с действиями. Такой масштаб показывает работу правила выбора, но ещё не подтверждает его поведение с реальными пользователями и длинными обратимыми процессами.
Что менять в архитектуре продукта
Работа не требует менять основную LLM или сразу собирать данные для дополнительного обучения. REVOIR можно рассматривать как управляющий слой: он хранит гипотезы о намерении, предлагает вопросы и действия, моделирует ответы, а затем выбирает ветку с большей ожидаемой пользой.
Такой слой имеет смысл там, где последствия можно выразить через награду и издержки. Системе нужно различать удачное и неудачное действие, оценивать цену задержки и учитывать стоимость исправления. Без этих величин расчёт сведётся к субъективным оценкам той же LLM.
Для обратимых операций работа предлагает практическое изменение плана: не ставить обязательное подтверждение перед каждым неоднозначным шагом. Если пользователь быстро заметит ошибку, а система безопасно откатит действие, полезнее выполнить наиболее вероятный вариант и принять коррекцию. Для платежей, удаления данных или запуска необратимого процесса соотношение будет другим.
Цена этого подхода — дополнительные вызовы LLM внутри одного пользовательского хода. Агент генерирует гипотезы, вопросы и действия, имитирует ответы и оценивает награду. Поэтому прототип стоит сравнивать не только по доле успешных задач и числу вопросов, но также по задержке и расходу токенов.
Менять продуктовый план целиком рано: метод пока не охватывает полноценное чередование вопросов и внешних действий. Но отдельный эксперимент с политикой «спросить или действовать» уже обоснован, если у процесса есть измеримая цена ошибки, а уточнения заметно замедляют пользователя.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
