Multi-Turn Reinforcement Learning (MTRL) в Amazon SageMaker AI обучает модель по результату всей многошаговой задачи, а не по размеченным промежуточным шагам. Вы задаёте только способ оценки результата, правильную траекторию описывать не нужно. Это и делает подход пригодным там, где эталонный путь либо неизвестен, либо слишком дорог в разметке. AWS показала рабочий пайплайн в практическом гайде.
Демо построено на Wordle. Агент, игровая среда и reward-функция развёрнуты на Amazon Bedrock AgentCore, а датасет содержит одну колонку: загаданное слово. На каждом rollout SageMaker AI вызывает агент, тот играет партию, обращаясь к обучаемой policy-модели, и по завершении эпизода возвращает одну награду.
Измеренный результат: на gpt-oss-20b solve rate вырос с 61 до 84% на отложенных словах при default reasoning effort и с 15 до 69% при low effort, на котором шло обучение. Обучающие токены обошлись примерно в $339.
Что такое Multi-Turn RL и зачем обучать модель на итоговой награде
Схема с промежуточной разметкой требует эталона для каждого хода. Для многошаговых агентных задач это быстро превращается в проблему: разметчик должен знать не просто правильный ответ, а правильное действие в каждой точке состояния среды.
Чем MTRL отличается от обучения на размеченных шагах
Обучение на размеченных шагах упирается в три ограничения. Стоимость разметки растёт вместе с длиной эпизода: шесть ходов надо разметить в шесть раз подробнее, чем один. Ошибка на раннем шаге уводит агента в состояние, которого в обучающей выборке не было, и дальше он действует вслепую. Главное: для многих задач единственно верной последовательности попросту не существует.
Аналогия с шахматами здесь точная. Цель партии — мат, а конкретная последовательность ходов зависит от ответов соперника. Размечать «правильные» ходы бессмысленно: их десятки, и лучший зависит от текущей позиции.
MTRL переворачивает постановку. Награда одна, в конце эпизода, а модель сама ищет траектории, которые к ней ведут. Промежуточные шаги никто не оценивает, поэтому и размечать нечего: в датасете лежит только вход задачи.
В примере AWS обучение построено на GRPO (Group Relative Policy Optimization) и обновляет LoRA-адаптер поверх базовой модели, а не всю сеть, поэтому прогон укладывается в разумный бюджет. Конкретные гиперпараметры в доступном фрагменте публикации не раскрыты, их стоит смотреть в коде примера. Как GRPO ведёт себя на gpt-oss-20b в другом сценарии, разбирали в материале SFT или GRPO для gpt-oss-20b.
Почему Wordle — удобный учебный пример, а не бизнес-кейс
Wordle подходит для MTRL по трём причинам: правил мало, каждая догадка зависит от обратной связи по предыдущей, а исход оценивается объективно. Игрок за шесть попыток угадывает скрытое пятибуквенное слово, буквы подсвечиваются зелёным (верная позиция), жёлтым (буква есть, но в другом месте) и серым (буквы в слове нет). Проверять результат можно кодом, без человека в контуре.
Дальше начинается честная часть. Frontier-модели играют в Wordle хорошо, так что как бизнес-задача игра бесполезна. Ценность MTRL в другом: сделать небольшую дешёвую модель сильной в многошаговом процессе, специфичном для вашей компании, на котором публичные модели не обучались. Внутренний workflow, разбор заявок по регламенту, последовательность вызовов внутренних API: везде правильная траектория зависит от данных, которых нет в открытом доступе.
Как устроен пайплайн: SageMaker AI, AgentCore и reward-функция
Система разделена на две части. SageMaker AI владеет training job и policy-моделью. AgentCore хостит агента, среду Wordle и reward-функцию. Разделение удобно тем, что обучение и среда живут независимо: среду можно менять и перезапускать, не трогая тренировочный цикл.
Роль Amazon Bedrock AgentCore и AWS Lambda forwarder
На каждом rollout MTRL-сервис обращается к AgentCore runtime с одной строкой обучающих данных, в которой лежит одно загаданное слово. Агент внутри проигрывает партию и отдаёт награду.
Агент может жить и на вашей инфраструктуре: в Amazon EKS, на Amazon EC2 или в AWS Fargate. Тогда промпты от SageMaker AI идут через AWS Lambda forwarder, который пересылает вызовы в ваш сервис. Выбор между AgentCore и собственным хостингом — вопрос операционных издержек и сетевой связности, а не функциональности: логика среды и reward-функции в обоих случаях ваша.
Что происходит на одном rollout
- SageMaker AI берёт одну строку датасета, то есть одно загаданное слово.
- Вызывает AgentCore runtime с этой строкой.
- Агент стартует эпизод и на каждом ходе обращается к обучаемой policy-модели.
- Среда проверяет догадку и возвращает обратную связь: какие буквы на месте, какие есть в слове, каких нет.
- Эпизод завершается (слово угадано или кончились шесть попыток), reward-функция возвращает одну награду.
- GRPO обновляет LoRA-адаптер по группе таких rollout.
Ключевой момент в пятом пункте: награда одна на всю партию. Никакой разметки по ходам не появляется, а длина эпизода определяется поведением модели, а не заранее заданным сценарием. Именно поэтому стоимость прогона зависит от того, как долго модель возится с задачей.
Результаты прогона на gpt-oss-20b: цифры и стоимость
Прогон шёл на gpt-oss-20b, оценка — на отложенных словах, которых не было в обучении. Цифры из гайда AWS:
| Режим reasoning effort | До MTRL | После MTRL |
|---|---|---|
| default | 61% | 84% |
| low (режим обучения) | 15% | 69% |
Две строки показывают разные вещи. Рост 15 → 69% на low effort отражает, насколько модель подтянулась именно в том режиме, где шло обучение: базовое качество там было почти нулевым, и прирост огромный. Строка с default effort отвечает на другой вопрос: не деградировала ли модель при более вдумчивом режиме рассуждений. Ответ отрицательный, 61 → 84%.
Почему serving-настройки важнее обучающих при оценке
Модель, которая отлично играет в режиме обучения, может провалиться в проде, если там другие параметры генерации. Поэтому в гайде оценка вынесена в отдельный шаг и проводится при serving-настройках, то есть в тех условиях, в которых модель будет работать.
Конкретные значения reasoning effort и temperature для замера в доступном фрагменте публикации не приведены. Если вы сравниваете свои результаты с цифрами выше, берите параметры из кода примера: при других настройках сравнение некорректно, а «красивая» метрика в обучающем режиме легко превращается в тыкву на проде. Это типичная ловушка при оценке RL-прогонов.
Из чего складывается счёт: prefill, sample и train токены
Оплата в MTRL разбита по типам токенов: prefill (обработка входа), sample (генерация во время rollout) и train (само обновление весов). Платить приходится за весь цикл, а не только за обучение в узком смысле. Длинный эпизод на шесть ходов генерирует заметно больше sample-токенов, чем один вопрос-ответ, и стоит пропорционально дороже.
Итог прогона в гайде: около $339 за обучающие токены. Отдельно идёт runtime-часть AgentCore: в описании примера фигурирует порядка $79, но в доступном фрагменте источника эта сумма не подтверждена, поэтому сверяйте её с полным текстом публикации и своими метриками. Практический ориентир для бюджета простой: стоимость растёт от длины эпизода и числа rollout, а первые прогоны стоит делать на маленькой выборке и коротких задачах.
Подготовка датасета и дизайн reward-функции без типичных ошибок
Датасет в примере минимальный: одна строка — одно загаданное слово. Никаких размеченных шагов и «правильных» догадок. Это принципиальное отличие от SFT-пайплайнов, где нужны пары «вход — эталонный ответ» на каждый шаг.
Как выглядит reward-функция для Wordle
Награда завязана на объективный исход: угадано слово за шесть попыток или нет. Такая функция живёт на AgentCore и возвращает одно число по завершении эпизода.
Соблазн добавить частичный кредит за совпавшие буквы понятен, и это классический способ испортить обучение. Модель начинает собирать «много зелёных букв» вместо того, чтобы решать задачу: промежуточная награда расходится с целью, и агент честно подгоняет метрику, а не игру. Общее правило: если промежуточная награда противоречит итоговой, вы получите агента, который хорошо подгоняет вашу метрику и плохо делает работу.
В MTRL вы задаёте именно способ оценки результата, а не траекторию. Пример аккуратной детерминированной reward-функции, которая балансирует recall и precision, разбирали в кейсе кастомизации Qwen3-8B через SFT и RLVR.
Авторы гайда отдельно делятся ошибками дизайна reward и сбоями обучения, с которыми столкнулись. Это честный сигнал: с первого прогона не заработает. Типичные грабли выглядят так:
- слишком разреженная награда: сигнал настолько редкий, что модель не находит связи между действиями и результатом;
- слишком щедрая награда: модель находит чит-стратегию, которая проходит проверку, но не решает задачу;
- награда за промежуточные шаги, противоречащая цели;
- несогласованность оценки между rollout: среда или reward дают разный результат на одинаковых действиях, и GRPO учится на шуме.
Мониторинг обучения в MLflow
Пайплайн включает мониторинг в MLflow: кривые награды, поведение модели по эпизодам, метрики на валидации. Смотреть стоит не только на среднюю награду, но и на распределение. Модель может выучить узкий набор слов и выдать хорошее среднее при провале на отложенной выборке.
Оценка на held-out словах — обязательный шаг. Без неё цифры не значат ничего: рост награды на обучающих эпизодах одинаково хорошо описывает и обучение, и запоминание.
Поддерживаемые модели и регионы: что проверить до запуска
MTRL доступен не для всех моделей и не во всех регионах, и это первое, что стоит проверить, чтобы не упереться в блокер на старте. В примере используется gpt-oss-20b. Полный перечень моделей и регионов AWS обновляет, поэтому сверяйте его с актуальной документацией SageMaker AI и текстом гайда, а не с пересказами.
Минимальный список проверок перед планированием: модель есть в списке поддерживаемых; выбранный регион поддерживает MTRL; Amazon Bedrock AgentCore доступен в этом же регионе; хватает квот на инстансы для training job; датасет и артефакты лежат в S3, к которому у ролей есть доступ. Отдельно стоит уточнить, как в вашем регионе считается оплата: разбивка по prefill, sample и train токенам означает, что бюджет зависит от того, сколько ходов генерирует модель.
Данные при этом остаются у вас: по данным гайда, датасеты, агент и обученная модель хранятся в вашем аккаунте AWS и не используются для обучения базовых моделей.
IAM-роли и деплой агента: ловушки, которые тормозят запуск
Связка двух сервисов почти всегда упирается в права доступа. В описании гайда разбор ловушек IAM и деплоя агента заявлен, но конкретный их список в доступном фрагменте публикации не приведён, поэтому ниже — типовые места, где ломается доступ в такой схеме.
- У роли training job в SageMaker нет права вызывать AgentCore runtime, и rollout падает на первом же запросе.
- Trust policy между сервисами не разрешает нужную связку: роль существует, политики выглядят правильными, вызов не проходит.
- AWS Lambda forwarder, если агент живёт на EKS, EC2 или Fargate, не имеет прав дотянуться до вашего сервиса.
- Нет доступа к S3, где лежит датасет и куда пишутся артефакты обучения.
Порядок отладки: сначала лог вызова от SageMaker к агенту, потом ответ агента на ручной запрос, и только потом код обучения. Если агент не отвечает на тестовый вызов из консоли, тренировочный цикл точно не запустится, и разбираться в гиперпараметрах бессмысленно.
Чек-лист перед первым запуском
- Модель и регион поддерживаются, квоты на инстансы есть.
- IAM-роли для SageMaker AI и AgentCore созданы, trust policy между ними настроена.
- Агент задеплоен и отвечает на тестовый вызов.
- Reward-функция возвращает осмысленное число на ручном примере: угаданное слово даёт одну награду, проигрыш другую.
- В датасете только входы задачи (загаданные слова), без размеченных шагов.
- MLflow подключён, кривые и метрики пишутся с первого rollout.
Кому подходит MTRL, а когда это оверинжиниринг
Wordle — учебный пример, и frontier-модели играют в неё хорошо. Смысл MTRL в другом: сделать небольшую дешёвую модель хорошей в многошаговом процессе, специфичном для вашего бизнеса, на котором публичные модели не обучались.
Подход оправдан, когда задача действительно многошаговая, эталонную траекторию задать нельзя или слишком дорого, результат оценивается объективно, а на руках есть небольшая модель, которую нужно подтянуть под конкретный процесс.
Оверинжиниринг начинается в обратных случаях: задачу уже решает frontier-модель из коробки; награду нельзя сформулировать объективно и приходится судить вкусовщиной; эпизоды длинные и дорогие, а данных для held-out мало. Сюда же относится ситуация, когда процесс меняется каждые две недели: reward придётся переписывать вместе с ним.
Ограничения стоит держать в голове до старта. Цифры 61 → 84%, 15 → 69% и $339 получены в конкретном прогоне на gpt-oss-20b и не переносятся автоматически на другие модели и задачи. Отладка reward-функции часто занимает больше времени, чем сам запуск обучения. Узкий датасет грозит переобучением на конкретные формулировки. Для long-horizon сценариев полезно заранее понять, что модель умеет без дообучения, о подходах к такой оценке писали в разборе GLM-5.3 и post-training для кода и длинных задач.
Как перенести подход на свой многошаговый процесс
- Выберите процесс с объективной проверкой результата: тест, валидатор, сравнение с эталоном.
- Сформулируйте reward, которую нельзя обмануть, не решив задачу.
- Соберите датасет из входов задачи, а не из траекторий.
- Запустите малое число rollout на коротких эпизодах, чтобы увидеть реальную стоимость.
- Мерьте результат на held-out в serving-настройках, а не в режиме обучения.
Весь код примера лежит в сопутствующем репозитории aws-samples, ссылка на него есть в публикации AWS. Это рабочая отправная точка: среду Wordle можно заменить своей, оставив схему «датасет → rollout → агент → reward → обновление адаптера».
Самый дешёвый способ понять, нужен ли вам MTRL: возьмите 20–50 своих многошаговых задач с объективной проверкой, прогоните базовую модель в serving-настройках и сравните с frontier-моделью. Если разрыв критичный, а эпизод короткий, обучение на итоговой награде даёт шанс закрыть его дешёвой моделью без разметки каждого шага.