Как AWS обучила поискового агента отвечать за всю траекторию
AWS дообучила поискового агента multi-turn RL: качество выросло на трех из четырех отложенных наборов, а сбои на BrowseComp-Plus сократились с 22,89% до 0,68%. Разбираем награду, данные и ограничения самоотчета.
Поисковому агенту недостаточно один раз выбрать хороший запрос. В реальной задаче он должен решить, какой инструмент вызвать первым, что уточнить после слабой выдачи, когда переключиться с точного совпадения на семантический поиск и в какой момент остановиться. Ошибка на раннем шаге меняет весь дальнейший маршрут. Поэтому качество такого агента определяется не отдельным ответом, а полной последовательностью действий.
AWS показала, как перенести эту логику в обучение модели: команда дообучила Qwen3.6-27B методом multi-turn reinforcement learning в Amazon SageMaker AI. Агент работал с двумя инструментами — лексическим поиском BM25 и векторным поиском — и получал итоговую награду за качество найденного набора документов. По данным самой AWS, после обучения качество выросло на трёх из четырёх отложенных наборов, а доля сбоев на самом сложном тесте резко снизилась. Это интересный инженерный результат, но пока именно самоотчёт поставщика платформы, а не независимый бенчмарк.
Почему награда за всю траекторию меняет задачу
Supervised fine-tuning требует примеров идеальных многоходовых диалогов: кто-то должен заранее показать модели правильные запросы, вызовы инструментов и остановку. Для корпоративного поиска таких трасс обычно мало, а ручное производство дорого. Одноходовое обучение с проверяемой наградой тоже не полностью соответствует задаче: полезность очередного запроса зависит от того, что уже найдено и сколько бюджета осталось.
В схеме AWS награда назначается после завершения всей поисковой траектории. Основная метрика — nDCG@10, которая учитывает релевантность и порядок первых десяти результатов. Если агент упирается в максимальное число ходов или лимит токенов на одном ходе, он получает -1. Тем самым оптимизируются сразу две вещи: качество финальной выдачи и способность закончить работу в заданном бюджете. Модель может получить высокий результат разными маршрутами; от неё не требуют копировать единственную «правильную» цепочку.
Это отличает опыт AWS от двух уже разобранных TheTimeAI подходов к обучению поиска и инструментов. Retrieve-for-Train у Google переносил дорогой поиск направлений в подготовку компактного ретривера, чтобы ускорить последующий ответ. ToolGrad строил проверяемые синтетические примеры вокруг уже успешных вызовов API и обучал single-turn function calling. В эксперименте AWS объект оптимизации другой: многоходовое поведение сохраняется и во время работы агента, а итоговая награда должна научить модель исправлять маршрут после каждого результата и избегать лимитов.
Что именно обучали
Обучающая смесь состояла из шести наборов. FRAMES и Musique содержат многошаговые вопросы, BRIGHT — задачи, где релевантность требует рассуждения, Enterprise RAG имитирует поиск по внутренним документам, ESCI описывает товарную релевантность, а MLQA добавляет многоязычную компоненту. В каждом наборе 5% примеров отложили для валидации. Для теста использовали четыре других набора: FreshStack, WixQA, BrowseComp-Plus и Wands. Такое разделение полезно, потому что итог измеряется на четырёх наборах, не включённых в перечисленную обучающую смесь.
Конфигурация опубликованного запуска выглядит компактно: одна эпоха, глобальный размер батча 128 и до 32 параллельных rollout. Остальные параметры, включая алгоритм и оценивание преимуществ, авторы оставили по умолчанию сервиса. Среда вызывала развернутый endpoint агента, который предоставлял BM25 и vector search. Данные обучения и валидации лежали в Amazon S3, а эксперимент проводился в регионе us-west-2.
Эта простота относится только к настройке показанного job. За тремя числами остаются подготовка индекса, разметка релевантности, преобразование шести наборов в требуемый формат, развертывание endpoint и выбор ограничений по ходам и токенам. Нельзя из короткого фрагмента конфигурации заключить, что агентное RL в целом стало задачей «в три параметра». Скорее SageMaker скрывает часть инфраструктуры и предлагает готовые значения по умолчанию для конкретного управляемого сервиса.
Поисковая среда и проверка результата
Две другие публикации из того же AWS feed помогают провести границы эксперимента. В руководстве по Web Search для Claude Desktop через Bedrock AgentCore основная проблема — безопасно подключить агент к актуальному веб-индексу: IAM Identity Center аутентифицирует пользователя через SAML, Cognito выдаёт JWT, а AgentCore Gateway публикует MCP-инструмент, а пользователь подтверждает его вызов. Это слой доступа и интеграции. MTRL-эксперимент начинается позже: поисковые инструменты уже развернуты, и задача состоит в том, чтобы обучить модель лучше выбирать между BM25 и векторным поиском на протяжении нескольких ходов.
Публикация AWS об Adjudicated Query показывает другую границу: хороший поиск не равен проверенному итоговому решению. Для проверки тысяч договоров AWS предлагает не доверять полноту ranked retrieval, а передать официальный pass/fail детерминированному rules engine. Инвариант «compliant + in-breach + ambiguous + unreadable = scanned» подтверждает, что обработана вся заданная совокупность, тогда как модель лишь выбирает типизированную операцию и пересказывает результат. На этом фоне MTRL улучшает маршрут поиска и соблюдение лимитов, но не доказывает полноту охвата, корректность бизнес-решения или безопасность итогового ответа. Эти свойства должны обеспечиваться архитектурой вокруг агента.
Четыре теста показывают неравномерный эффект
На WixQA nDCG@10 вырос с 0,5725 до 0,6781, а доля сбоев снизилась с 0,67% до 0,17%. Среднее число ходов немного увеличилось — с 4,3 до 4,5. На Wands качество поднялось с 0,5762 до 0,6112 при нулевой доле сбоев у обеих моделей; ходов стало больше, 2,9 против 2,2. Эти два результата показывают, что лучшая выдача не обязательно означает более короткий маршрут.
Самое заметное изменение AWS получила на BrowseComp-Plus: nDCG@10 увеличился с 0,5136 до 0,6354, среднее число ходов сократилось с 7,0 до 6,3, а failure rate — с 22,89% до 0,68%. В таблице AWS неудачей считается, в частности, превышение лимита ходов или токенов, а провалившимся задачам присваивается нулевой nDCG@10. Поэтому улучшение качества и падение failure rate здесь связаны: когда меньше примеров обнуляется из-за лимита, растет и средняя метрика.
FreshStack не поддержал общую картину без оговорок. Доля сбоев снизилась с 0,20% до 0,05%, а среднее число ходов — с 3,1 до 2,8, но nDCG@10 слегка ухудшился: 0,4112 против 0,4089 после обучения. Разница составляет 0,0023 абсолютного значения. AWS не приводит в публикации доверительные интервалы или разброс по повторным запускам, поэтому по этой таблице нельзя определить, является ли регрессия устойчивой. Однако сам знак важен: оптимизация смеси задач не гарантирует прирост на каждом новом домене.
Что можно вывести из падения числа сбоев
Штраф -1 создает прямой стимул не тратить траекторию впустую. Агент учится учитывать не только релевантность очередной выдачи, но и риск не завершить задачу. Снижение failure rate на трёх из четырёх наборов согласуется с этой конструкцией награды; на Wands нулевой уровень 0,00% сохранился. Особенно показателен BrowseComp-Plus, где базовая модель часто не укладывалась в ограничения, а после обучения почти перестала это делать.
Но таблица не раскрывает, как именно изменилось поведение. Из нее нельзя понять, стал ли агент лучше формулировать запросы, раньше переключаться между BM25 и векторным поиском, реже повторять действия или просто быстрее завершать слабые траектории. AWS пишет о наблюдаемости ходов через MLflow, однако в статье нет разбора категорий ошибок и нет примеров траекторий до и после обучения. Поэтому причинное объяснение пока опирается на дизайн награды и агрегированные показатели, а не на опубликованный поведенческий анализ.
Где проходят границы результата
Во-первых, все цифры получены авторами AWS в собственной конфигурации SageMaker AI. Публикация не описывает независимое воспроизведение и не сравнивает MTRL с альтернативной многоходовой системой при одинаковом вычислительном бюджете. Нет данных о стоимости обучения, числе токенов rollout, времени работы, дисперсии между запусками и цене последующего endpoint. Заявление о более дешевой работе небольшой специализированной модели поэтому остается общей мотивацией, а не измеренным экономическим выводом этого эксперимента.
Во-вторых, нулевая или низкая доля технических сбоев не равна корректному ответу. Агент может закончить вовремя и вернуть посредственный набор документов; это видно хотя бы по FreshStack, где надежность улучшилась, а nDCG@10 — нет. Для производственной системы понадобятся отдельные проверки полноты ответа, достоверности синтеза, безопасности запросов и прав доступа. Показанный reward оценивает ранжирование документов, но не доказывает качество финального текста, который агент построит на их основе.
В-третьих, эксперимент зависит от конкретного набора инструментов и среды. Модель видела BM25 и vector search через заранее развернутый endpoint. Перенос на браузер, SQL, внутренние API или инструменты с изменяемым состоянием не проверен. Даже в поиске придется заново определять ground truth, лимиты и штрафы: слишком жесткий штраф за длину может научить агента останавливаться раньше, чем он собрал достаточно доказательств.
Практический смысл эксперимента
Работа AWS дает полезный шаблон для команд, у которых уже есть поисковая среда и измеримая релевантность. Сначала нужно определить итоговую метрику на уровне всего результата, затем отдельно наказать операционные провалы, собрать разнородную обучающую смесь и оставить отдельные наборы, не входившие в обучающую смесь, для теста. Важнее всего отслеживать качество и надежность раздельно: один показатель может расти, пока другой стоит на месте или ухудшается.
Главный вывод не сводится к конкретным процентам. Multi-turn RL позволяет обучать последовательность решений без эталонной траектории для каждого вопроса, если итог можно надежно оценить. Эксперимент AWS показывает, что такой сигнал способен заметно изменить и ранжирование, и соблюдение бюджета ходов. Одновременно FreshStack и нехватка данных о стоимости напоминают: одна награда не превращает поискового агента в универсальную систему. Перед внедрением результат придется воспроизвести на собственном индексе, собственных ошибках и собственных ограничениях.
