Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Инструментального агента научили самому искать сведения, без которых он не выполнит задачу, даже если пользователь о них не упомянул. В препринте IBM и Weizmann Institute of Science, который не рецензировался и где числа получили сами авторы, вопросник на Qwen3-8B обошёл модель в 15 раз крупнее на двух из трёх наборов задач. Для продуктовых команд это способ сократить уточнения у пользователя, не отдавая оценку поведения ещё одной LLM.
Граф потребностей разделяет поиск вширь и вглубь
Пользователь может попросить изменить размер ботинок в заказе, назвать имя и индекс, но не помнить почту и номер заказа. Обычный агент снова запрашивает недостающие поля. Проактивный сначала находит профиль по известным данным, затем извлекает из него заказ и только после этого ищет подходящий товар.
Первый переход авторы называют горизонтальной проактивностью: агент берётся за потребность, которую уже можно сформулировать из текущего состояния. Вертикальная проактивность начинается, когда найденные сведения открывают следующую потребность. Номер заказа нельзя было искать осмысленно, пока агент не нашёл профиль.
Чтобы измерять оба поведения, для задачи строят граф потребностей. Его узлы обозначают обязательные фрагменты сведений, а связи показывают, какие сведения становятся доступны только после предыдущих. По журналу работы можно проверить, сколько независимых ветвей продвинул агент, насколько глубоко прошёл по цепочке и остановился ли после сбора всего необходимого.
Модель-оценщик для этого не нужна: результат поиска сопоставляют с эталонными фрагментами из набора данных. Одинаковый бюджет запросов не позволяет выдать настойчивость за качество — агент должен находить больше за то же число обращений к поиску.
Q&D учит вопрос по его последствиям
Метод Q&D делит агента на модуль вопросов и фиксированный модуль черновика. Первый формулирует следующий поисковый запрос или решает остановиться. Второй добавляет найденные сведения в черновик, но во время обучения не меняется, поэтому результат каждого шага можно связать именно с выбранным вопросом.
Обучающий запуск разветвляют в одном состоянии и продолжают с несколькими вариантами вопроса. Предпочтение получает вариант, после которого агент раньше собирает обязательные сведения, отвечает на задачу или приносит больше полезных данных за ход. Если граф показывает, что работа не закончена, вопрос ставят выше остановки.
Так Q&D создаёт обучающие пары из последствий действий, а не из оценок отдельной LLM или заранее написанных правильных запросов. Граф нужен при подготовке данных и проверке, но обученный модуль его не получает. Поэтому вопросник можно перенести в среду, где известны инструменты и состояние задачи, но нет эталонной схемы прохождения.
Метод проверяли на отложенных частях MuSiQue, StrategyQA и 2WikiMultiHopQA. Поиск работал через BM25 по приложенным к задачам документам; Q&D сравнивали с той же Qwen3-8B в режиме подсказки, GPT-OSS-120B, Claude Opus 5 и PAR2-RAG. Отдельно вопросник без дообучения встроили в агента поддержки на розничных и авиационных сценариях τ2-bench с имитируемым клиентом.
Менять всю модель рано, а контур поиска — уже можно
При одинаковом числе поисковых запросов полнота обязательных сведений выросла на 11,2 процентного пункта в MuSiQue, на 7,0 в StrategyQA и на 5,0 в 2WikiMultiHopQA. В наборе с наиболее длинными цепочками агент собрал 90% нужных сведений против 78% у той же модели с подсказкой. Он также проходил глубже по зависимостям и охватывал больше независимых ветвей.
Результат не сводится к более длинным или частым вопросам: сравнение выравнивало затраты на поиск, а дополнительные проверки учитывали объём запросов. В розничных сценариях вопросник чаще завершал задачи, реже возвращал работу клиенту и превзошёл более крупную GPT-OSS-120B. В примере с ботинками базовый агент все ходы повторно просил почту или номер заказа, а обученный восстановил всю цепочку через доступные инструменты.
Работа пока не даёт основания менять основную LLM только ради проактивности. Дополнительные сведения не всегда улучшали итоговый ответ, а решение об остановке обучалось хуже, чем выбор следующего вопроса. На MuSiQue агент иногда находил глубокий фрагмент раньше его формальной предпосылки, потому что поиск случайно возвращал связанный документ.
Практическое изменение касается архитектуры. Если агент работает с заказами, заявками, расследованиями или внутренним поиском, стоит отделить выбор следующего запроса от подготовки ответа и вести явное состояние найденных потребностей. Q&D показывает, что небольшой специализированный вопросник может отвечать за навигацию, пока более крупная модель собирает черновик и финальный текст.
Для внедрения понадобится журнал траекторий и задачи, где можно определить обязательные сведения и их зависимости. Если такой разметки нет даже на обучающей выборке, применить метод напрямую не получится. Но сам способ проверки полезен и без Q&D: сравнивать агентов следует при равных затратах на поиск, отдельно измеряя охват ветвей, глубину и своевременную остановку.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
