Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Поисковых агентов научили точнее формулировать промежуточные запросы и отсеивать лишние результаты, не переобучая основной модуль рассуждения. В препринте, который не прошёл рецензирование и содержит замеры самих авторов, QREF повысил среднюю долю верных ответов WebSailor на 33,55% относительно исходного агента. Для продуктовой команды это вариант улучшить уже работающий DeepSearch через отдельную прослойку между рассуждением и веб-поиском.
Ошибочный запрос портит всю поисковую цепочку
DeepSearch-агент чередует рассуждение с поиском: формулирует промежуточный запрос, получает страницы или фрагменты, уточняет гипотезу и запускает следующий поиск. Даже сильная модель может потерять найденное ограничение, составить слишком общий запрос или отправить несколько почти одинаковых запросов.
В разобранных траекториях 47,04% пакетов запросов содержали хотя бы одну такую ошибку. Пакет здесь означает несколько запросов, которые агент отправляет на одном шаге. Категории назначала модель-оценщик, а часть разметки независимо проверили люди; оценки хорошо совпали.
Ошибки влияли не только на объём лишней выдачи. Неудачные траектории накапливали почти втрое больше неэффективных пакетов, причём разрыв появлялся уже после первого поиска. Общий запрос возвращал шум, следующий шаг строился на слабых материалах, и проблема усиливалась по мере продвижения агента.
Из этого следует практический диагноз: если агент умеет рассуждать, но регулярно теряется во внешних источниках, замена основной LLM может не устранить причину. Сначала стоит проверить, сохраняют ли запросы ограничения из текущего рассуждения и дополняют ли они друг друга.
QREF правит запрос до поиска и выдачу после него
QREF ставит вокруг поискового инструмента два модуля. Уточнитель получает исходную задачу, текущую цепочку рассуждения и подготовленный агентом пакет запросов. Он делает каждый запрос самостоятельным, возвращает пропущенные ограничения, разделяет составные задачи и убирает дубли.
Модуль не должен добавлять факты, которых ещё нет в рассуждении. Его задача — перевести текущее намерение агента в форму, подходящую поисковой системе. Он также может сохранить исходный запрос без изменений, если тот уже достаточно точен.
После поиска фильтр сопоставляет каждый фрагмент с исходной задачей, текущим шагом рассуждения и активным запросом. Он оставляет материалы, которые помогают определить сущность, проверить факт или сузить набор кандидатов, а общие, повторяющиеся и посторонние результаты не возвращает агенту.
Уточнитель сначала обучили на примерах, подготовленных GPT-5.2, а затем дообучили с подкреплением в реальном веб-поиске. Награда зависела не от красоты формулировки и не только от конечного ответа: модель получала её, когда новый запрос находил нужные сущности лучше исходного. Фильтр построили на Qwen3-8B.
Такое разделение позволяет не менять параметры и архитектуру основного агента. Интеграция всё же требует доступа к его текущему рассуждению, перехвата поисковых действий и возможности заменить выдачу до следующего шага.
Командам стоит тестировать прослойку раньше замены агента
QREF проверили на BrowseComp, BrowseComp-ZH, GAIA и HLE с агентами WebSailor-32B и TongyiDeepResearch. Это задачи с многошаговым поиском по открытой сети, а не корпоративным хранилищам или закрытым базам знаний. Поиск выполнялся через Serper API, страницы извлекались через Jina Reader API.
На TongyiDeepResearch средний относительный прирост доли задач, решённых с первой попытки, составил 11,04%. Доля пакетов с недостаточно конкретными поисковыми ориентирами сократилась на 95%. Уточнитель без фильтра стабильно улучшал исходный агент, а один фильтр давал смешанный результат; вместе модули работали лучше.
Обычной инструкции для дополнительной LLM оказалось недостаточно. Подключённый без обучения Qwen3-8B на большинстве сочетаний агента и теста уступал специально обученным вариантам, иногда и исходной системе. GPT-5.2 показал лучшее общее качество, но создавал больше запросов и приносил больше нерелевантных материалов.
Работа меняет план разработки там, где уже есть агент с приемлемым рассуждением и слабым поисковым контуром. Вместо дорогого переобучения всей системы можно отдельно собрать журнал промежуточных запросов, разметить типовые сбои и проверить уточнитель с фильтром на том же наборе задач.
Решение не сводится к ещё одному системному запросу: результат дал отдельный обученный компонент с наградой за найденные материалы. Авторы сравнивают точность и число поисковых действий, но не сводят задержку и стоимость дополнительных вызовов в единый расчёт. Поэтому перед внедрением нужен собственный замер качества, времени ответа и расхода API на реальных поисковых сценариях продукта.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
