Лучшие практики многошагового reinforcement learning в Amazon SageMaker AI

Обучение многошагового агента в Amazon SageMaker AI для обработки обращений в поддержку или модерации контента означает работу с последовательностью зависимых шагов, а не с одним ответом. Такие агенты читают инструкции, вызывают инструменты, анализируют результаты, выбирают следующий шаг и исправляют ошибки до того, как дать окончательный ответ. Именно эта гибкость делает agentic reinforcement learning (RL) сложным: больше вариантов действий означает больше способов получить награду, не выполнив задачу, а среда, на которой агент обучается, может незаметно испортить обучающий сигнал.

В этом материале AWS делится практиками надежного многошагового RL-обучения. Рассматриваются построение доверенной обучающей среды, внешняя оценка, выравнивание reward с конечной задачей, учет изменений при многотуровом выполнении агента и метрики, по которым видно, когда пора итеративно дорабатывать модель. Примеры основаны на наборе данных SOP-Bench — бенчмарке Amazon Science, который оценивает способность агентов решать задачи по сложным Standard Operating Procedures (SOP) в 12 бизнес-доменах.

Многошаговое reinforcement learning в Amazon SageMaker AI

Amazon SageMaker AI multi-turn RL (SageMaker AI MTRL) предоставляет цикл обучения для agentic-задач. Агент может работать на Amazon Bedrock AgentCore, Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Compute Cloud (Amazon EC2), AWS Fargate или на любой другой инфраструктуре по выбору. Подключение идет через небольшой адаптер, который открывает набор инструментов для rollout server, а SageMaker AI MTRL берет на себя остальное:

• Модульный интерфейс agent-environment, который сохраняет low-code-интеграцию, но дает полный алгоритмический контроль. Пользователь сам задает custom rewards, custom tool loops и формы многошагового диалога.
• Serverless execution, которое упрощает инфраструктуру, позволяя получать agentic RL промышленного масштаба с оплатой за токены без разворачивания и сопровождения GPU-кластеров.
• Асинхронный rollout и сбор trajectories с ограниченной off-policy staleness. Генерация и gradient updates идут параллельно и не слишком расходятся с текущей policy, что ускоряет обучение.
• Нативная библиотека алгоритмов, включающая Proximal Policy Optimization (PPO), Clipped Importance Sampling Policy Optimization (CISPO) и losses на importance sampling (IS), а также несколько group-based advantage estimators (GRPO, GRPO pass@k, RLOO и другие). Это покрывает наиболее важные варианты для многошагового agentic RL.
• Sequence-extension training, чтобы уменьшить wall-clock на длинных многошаговых trajectories.
• Observability trajectories и reward в MLflow, управляемом Amazon SageMaker AI, чтобы можно было читать, что агент сделал по каждому шагу и на каждом этапе обучения.
• Evaluation jobs, которые возвращают reward, pass@k, trajectory metrics и другие показатели до деплоя на endpoint SageMaker AI или в Amazon Bedrock.

Сервис дает цикл обучения, вычислительные ресурсы и orchestration. Но решения, от которых зависит надежность агента, принимает пользователь. Нужно самому построить среду, на которой агент учится, измерять успех вне reward, проектировать reward и решать, как итеративно двигаться дальше, когда кривая перестает расти.

Figure 1: Overview of the SageMaker AI multi-turn RL service

Постройте обучающую среду дешево, воспроизводимо и правдоподобно

Single-turn RL требует prompt и reward function. Multi-turn RL добавляет среду, в которой агент действует между шагами: инструменты, к которым он обращается, и системы, стоящие за ними. Эта среда входит в обучающую схему, и способ ее построения влияет и на то, чему может научиться модель, и на доверие к метрикам.

При обучении агента нужно строить изолированную sandboxed или simulated environment, похожую на production, но отделенную от живого трафика. Tool calls и ответы сохраняют те же схемы и бизнес-логику. Они питаются записанными ответами или изолированным состоянием вместо живых вызовов.

Симулированные среды рекомендуются как стартовая точка, потому что типичный прогон дает много тысяч rollouts, и каждый делает несколько вызовов инструментов. Например, batch size 128 при group size 8 дает 1 024 rollouts на шаг. Направлять такой трафик в живые системы опасно для клиентов. Без симуляции exploration может привести к реальным побочным эффектам: агент, обучающийся методом проб и ошибок, может возвращать деньги, удалять записи или запускать workflow, которые не были задуманы. Кроме того, живые данные меняются под вами, поэтому одна и та же trajectory оценивается по-разному в разных прогонах. Чтобы вычислять reward, нужно знать правильный исход, а значит, вам требуется фиксированный размеченный набор задач или надежная judge model независимо от того, куда ведут tool calls.

То, как именно строится simulated environment, зависит от того, что делают ваши инструменты. Для большинства сценариев подходят три паттерна:

• Read-only tools: воспроизведение записанных ответов по ключу из входных параметров. Такие инструменты помогают агенту извлекать информацию, нужную для задачи. Например, в SOP-Bench customer service task содержит десять mock tools (validateAccount, getAuthenticationDetails, createSessionAndOpenTicket и так далее), и каждый возвращает детерминированный ответ из fixture, например конкретную строку CSV по аргументам tool call.
• Stateful tools: seeded sandbox, который хранит состояние в течение эпизода. Когда агент что-то записывает и потом читает это обратно, среде нужна память. Паттерн такой: выделять per-episode ресурсы в начале rollout и регистрировать все, что создает агент. Затем все это нужно удалить в блоке try/finally по завершении эпизода — при terminal action, при достижении max_turns или при сбое. Никакое состояние не должно перетекать в следующий rollout.
• Verifiable outcomes: реальное выполнение в изолированной симуляционной среде. Когда результат агента — код, SQL или математика, его можно запускать в изолированной среде. Для кода используйте Docker exec, для SQL — in-memory SQLite на каждый rollout, для математики — обычный Python eval. Реальное выполнение, детерминированное для экземпляра: один и тот же ввод плюс одно и то же sandbox-состояние дают один и тот же результат. Например, AgentCore Code Interpreter предоставляет управляемые изолированные среды для выполнения кода.

Какой бы паттерн ни подошел, зафиксируйте два свойства:

• Воспроизводимость: один и тот же инструмент, вызванный с одинаковыми аргументами, возвращает одинаковый результат, поэтому reward для идентичной trajectory стабилен, а оценка сопоставима между прогонами.
• Представительность: строите среду на основе реальных схем и распределений данных, чтобы поведение, которому учится модель, переносилось в production.

Перед началом обучения проверьте, что среда настроена правильно:

• Tool calls с одинаковыми аргументами дают один и тот же результат, что подтверждается запуском одной и той же instance дважды и сравнением rollout messages.
• Состояние на уровне rollout изолировано (отдельный temp directory, отдельные IDs, отдельное DB connection).
• Доступные инструменты совпадают с production-средой, включая схемы запросов и ответов инструментов.

Настройте внешнюю оценку до начала обучения

Когда среда уже готова и проверена, нужно до написания reward function организовать способ измерять успех. Эта метрика должна напрямую отражать конечную цель. RL буквально оптимизирует сигнал reward, поэтому если reward — единственное число, на которое вы смотрите, вы не сможете отделить прогресс в задаче от прогресса в удовлетворении критериев reward. Нужна внешняя оценка, которой можно доверять, чтобы она направляла решения по мере итераций над reward, seed-ами среды и hyperparameters.

Паттерн

Разверните отложенную held-out evaluation, которая оценивает результат, важный для деплоя, и делает это независимо от reward. На практике это небольшой код: он берет модель, прогоняет ее через rollout server на фиксированном test split и возвращает один показатель task-success rate. Оценка может быть минимальной, лишь бы была честной.

Для SOP-Bench evaluation — это exact-match по финальному JSON-объекту внутри <final_output>: каждое поле в ответе агента должно совпасть с ground-truth, иначе rollout получает ноль. Reward function может считать partial credit и weighted components. Оценка — нет.

Перед любым обучением зафиксируйте baseline. Прогоните базовую модель и reference model (подойдет frontier model, размещенная в Amazon Bedrock) через одну и ту же оценку. Это покажет две вещи: насколько далеко базовой модели еще расти и как выглядит хороший результат для этой задачи.

Антипаттерн

Использовать training reward или метрику, производную от него, как меру успеха. Это может казаться естественным, но чтобы поймать reward hacking, нужна внешняя оценка. Для многошаговых агентов это особенно важно: reward за tool calls учит агента вызывать как можно больше инструментов. Reward, штрафующий количество шагов, учит агента отвечать до того, как он собрал нужную информацию. В обоих случаях training reward растет, а реальный успех в задаче падает.

Перед началом обучения проверьте, что evaluation надежна:

• Evaluation — это одна функция, score(rollout) -> float, которая оценивает именно то, что вы поставляете в продакшн.
• Baseline evaluation не равна нулю на базовой модели, которую вы собираетесь дообучать (если равна нулю, см. следующий раздел про то, как обеспечить base model foothold).
• Проведите evaluation на frontier model, чтобы иметь продвинутый baseline для сравнения.

Спроектируйте хороший reward function для многошагового RL

Проектирование reward — одна из самых сложных открытых задач в RL. Та же гибкость, которая позволяет агенту решать реальные задачи, дает ему и способы удовлетворить reward, не выполняя саму задачу. Каждый добавленный компонент, каждый скорректированный вес, каждый formatting bonus — это еще одна поверхность, на которую агент может взобраться, не решая задачу. Модель оптимизирует то, что вы записали, а не то, что вы имели в виду. По умолчанию используйте один и тот же scoring rule для обучения и оценки и отходите от него только тогда, когда у вас есть конкретная причина.

Возьмем SOP-Bench. Бенчмарк ожидает ответ как JSON-объект внутри тегов <final_output>:

{
 "aircraft_ready": "true",
 "mechanical_inspection_result": "success",
 "electrical_inspection_result": "success",
 "component_incident_response": "success",
 "component_mismatch_response": "success",
 "cross_check_reporting_response": "success"
}

Бенчмарк ставит 1, если все поля совпадают, и 0 иначе. Обучение и оценка обычно разделяют это правило и различаются только тем, что наблюдают вокруг него. Trainer получает один reward — скаляр или список скаляров — на rollout. Evaluation запускается реже на фиксированном split, поэтому там можно смотреть больше метрик: точность по полям, completion rate (выдал ли агент вообще <final_output>), распределение tool calls, исчерпание turn budget, соблюдение формата.

Есть две реальные причины отходить от базового scoring rule бенчмарка, и обе требуют более плотного reward.

Первая — алгоритмическая. RL вычисляет learning signal из дисперсии между группой из group_size rollouts на один prompt с использованием group-based advantage method (advantage_method). Дефолт сервиса group_based — это GRPO. Доступны и другие методы, например rloo и grpo_passk. Полный список есть в документации. Бинарная оценка может эту дисперсию схлопнуть: если все rollout в группе получают один и тот же score, относительный сигнал равен нулю и группа не дает gradient. Когда rollout/reward/valid_mean — среднее по группам без нулевого advantage — опускается ниже rollout/reward/mean, а модель замирает, именно этот разрыв и есть симптом.

Вторая — скорость сходимости. Даже когда групповая дисперсия здоровая, dense reward дает модели gradient к частичному прогрессу на каждом rollout, а не только на полностью успешных. Rollout, в котором правильно сделаны пять из шести полей, показывает модели, что значит быть ближе к цели. Бинарный score этого не сообщает.

Плотный reward для задачи SOP-Bench оценивает каждое поле отдельно и возвращает reward как скаляр или список скаляров (per-turn rewards) плюс metrics dictionary.

class SOPBenchReward:
 """Dense per-field reward for the SOP-Bench aircraft-inspection task.
    Returns a scalar in [0, 1] plus a metrics dict surfaced in MLflow."""
    ground_truth: dict[str, str]
    format_coef: float = 0.1 # format is a small shaping term, not the objective
async def __call__(self, history: list[Message]) -> tuple[float, dict[str, float]]:
        fields = parse_final_output(last_assistant(history))   # JSON inside <final_output>
        emitted = float(fields is not None)
        if fields is None:                                     # no parseable answer
return self.format_coef * (emitted - 1), {"completion": 0.0, "field_acc": 0.0}
        matched = sum(1 for k, v in self.ground_truth.items()
                      if str(fields.get(k)).strip().lower() == str(v).strip().lower())
        field_acc = matched / len(self.ground_truth)           # partial credit: 5/6 > 0
        reward = field_acc + self.format_coef * (emitted - 1)  # correctness dominates
return reward, {"completion": emitted, "field_acc": field_acc}

Агент сообщает reward через update_reward, а metrics dictionary (completion, field_acc) появляется в MLflow. Чтобы учитывать отдельные шаги, а не только весь trajectory, update_reward также принимает список по шагам, который сочетается с advantage method group_based_per_turn, так что reward function может возвращать одно значение reward на каждый turn.

• Проверяйте reward на реальных ответах до начала обучения. Reward parser, который более снисходителен, чем evaluation, — это тоже форма reward hack. В одном из наших прогонов SOP-Bench reward принимал более свободный формат вывода, чем бенчмарк: простой wrapper <final_response> получал credit, хотя бенчмарк читает только <final_output>. Обучение сделало ровно то, о чем мы его попросили: модель научилась убирать тег, который нужен бенчмарку, reward вырос, но внешняя оценка упала.
• Сначала добейтесь, чтобы у base model была точка опоры. RL улучшает то, что базовая модель уже умеет хотя бы в части случаев. Оно не создает способности из ничего. Если базовая модель дает ноль успешных trajectories на вашей задаче, reward-сигналу нечего усиливать, и обучение застревает.

SageMaker AI MTRL может запускать такой baseline как managed evaluation job. MultiTurnRLEvaluator повторно проигрывает агента на held-out prompt set и сообщает eval/reward и pass@k. Если модель уже обучалась, один вызов с evaluate_base_model=True оценивает базовую и дообученную модель рядом. Поскольку pass@k порогует reward по success_threshold, установка success_threshold=1 дает строгий success rate: долю rollouts с идеальным reward вместе со средним значением.

from sagemaker.train.evaluate import MultiTurnRLEvaluator

# With Bedrock AgentCore
evaluator_base = MultiTurnRLEvaluator(
    model="openai-reasoning-gpt-oss-20b",
    dataset="s3://my-bucket/eval-prompts.parquet",
    agent_config="arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent",
    s3_output_path="s3://my-bucket/eval-output/base/",
    mlflow_resource_arn="arn:aws:sagemaker:us-west-2:123456789012:mlflow-tracking-server/my-mlflow",
    role="arn:aws:iam::123456789012:role/SageMakerRole",
    accept_eula=True,
)

execution = evaluator_base.evaluate()
execution.wait()

В указанном s3_output_path вы найдете метрики evaluation, которые также можно посмотреть в MLflow вместе с evaluation trajectories. О reward-based evaluation для fine-tuned и base models см. документацию по Model evaluation.

Важно помнить различие: evaluation job оценивает rollouts собственным reward function агента, поэтому измеряет held-out generalization, а не независимость от reward. Слишком мягкий reward parser и здесь выглядит здоровым, потому что метрика — это сам reward. Отдельная проверка, которая ловит ошибки reward-parser, остается независимой: нужно оценивать те же rollouts более строгим независимым parser-ом (для SOP-Bench — exact-match scorer бенчмарка) и сравнивать результаты. Можно даже запустить такой строгий scorer как отдельный evaluation job, направив MultiTurnRLEvaluator на агента, чей reward является этой независимой метрикой.

За более подробным разбором reward design, sparse versus dense rewards, judge models, multi-objective shaping и trade-offs между ними см. SageMaker AI reward design best practices.

Прежде чем доверять reward, проверьте:

• Training reward и evaluation используют одно и то же базовое scoring rule, если только у вас нет измеримой причины расходиться, и эта причина задокументирована.
• Reward возвращает float в [0, 1] (или [-1, 1], если допускаются отрицательные regression terms).
• Reward на 100 baseline rollouts имеет дисперсию (не все 0 и не все 1). Если нет, это как раз тот измеримый сигнал, который оправдывает shaping или отдельный data curriculum.
• Ни один baseline rollout не получает на training reward больше, чем на eval. Если получает, reward слишком щедро вознаграждает то, что external eval не засчитывает.
• Если reward состоит из нескольких компонентов, убедитесь, что каждый логируется отдельно в MLflow, чтобы можно было видеть расхождение по каждому терму.

Учитывайте, что меняется, когда агент работает много шагов

Многошаговому агенту приходится решать проблемы, которых single-turn не видит. Их стоит спроектировать заранее, до начала обучения.

Context растет на каждом шаге, и turn budgets — часть reward design. Каждый tool call расширяет conversation: сам вызов, его аргументы, результат и рассуждение модели между ними. Длинные trajectories быстро накапливают context, а MTRL использует sequence-extension training, чтобы удерживать wall-clock под контролем по мере их роста. Задача, которой нужно восемь последовательных вызовов, может просто не уместиться до завершения. Эту ситуацию ограничивают два бюджета: max_turns, который контролирует цикл агента, и per-turn token budget, который сервис задает через sampling_max_tokens (rollout) и val_sampling_params.sampling_max_tokens (evaluation). Подбирайте оба параметра под требования задачи и то, что вы сможете обслуживать в production.

Для SOP-Bench восемь turns и budget в 2 048 токенов на turn покрывают каноническую процедуру с запасом (sampling_max_tokens допускает до 8 192). Практическое правило: если человек решает задачу за N turns, задайте в цикле агента max_turns = ceil(N * 1.5). Правильный turn budget — это наименьший, который позволяет агенту завершить задачу с небольшим запасом. Следите за rollout/tokens/response_max: если ответы группируются у потолка, это сигнал. Если более 5 процентов rollouts упираются в него, увеличьте sampling_max_tokens. Иначе сигнал молчит: модель учится на обрезанной trajectory, но не видит reward, который получила бы за завершение.

Отделяйте завершение от правильности

Trajectory, который завершился неправильным ответом, и trajectory, который не завершился вовсе, — это разные ошибки. Если смешать их, будет неясно, где именно ломается модель. Семейства метрик rollout и val в MLflow дают оба сигнала отдельно:

Высокий val/reward/pass_k_1 при низком completion rate (rollouts достигают max_turns до появления <final_output>) означает, что модель правильно проходит простые пути, но буксует на сложных, и это намекает на настройку turn budget. Высокий completion rate при низком val/reward/pass_k_1 означает, что она отвечает бегло, но неправильно, и это намекает на redesign reward. Эти два сбоя требуют разных исправлений, поэтому их полезно разделять.

Перед тем как фиксировать turn budget, проверьте:

• max_turns в цикле агента откалиброван под задачу, а не оставлен случайным default.
• Менее 5 процентов training rollouts достигают sampling_max_tokens на одном turn.
• Менее 10 процентов training rollouts достигают max_turns без финального ответа.
• Completion (финальный ответ выдан) и correctness (финальный ответ верен) отслеживаются в MLflow как отдельные метрики.

Следите за метриками обучения

Когда evaluation, environment и reward уже настроены и проверены, можно начинать обучение. SageMaker AI MTRL предоставляет высокоуровневые конструкции MultiTurnRLTrainer и MultiTurnRLEvaluator, чтобы обучать и оценивать агента:

from sagemaker.train import MultiTurnRLTrainer
from sagemaker.train.evaluate import MultiTurnRLEvaluator

trainer = MultiTurnRLTrainer(recipe="<per-model starter recipe>", role=..., dataset=...)
trainer.train()                                  # step 6: watch rollout/reward and completion in MLflow

evaluator = MultiTurnRLEvaluator(model=trainer, dataset="<held-out split>",
                                 evaluate_base_model=True)   # step 7: val/reward + pass@k, base vs fine-tuned
evaluator.evaluate().wait()
print(trainer.get_mlflow_url())                  # read the trajectories where reward and evaluation disagree

Во время обучения следите за rollout/reward/mean рядом с completion rate и открывайте несколько trajectories в MLflow (на вкладке Traces), чтобы рост reward при неизменном completion не прошел незамеченным. На evaluation важен именно разрыв: если rollout/reward/mean растет, а val/reward/mean стоит на месте, reward hacked. Откройте эти trajectories и сравните, что reward зачел, а что засчитала evaluation. Эта разница и направляет итерацию reward design: ужесточить reward parser, пересобрать компонент, отобрать данные и запустить еще раз. Каждая следующая итерация быстрее предыдущей, потому что environment и evaluation остаются фиксированными. Меняются только reward и данные, а per-model starter recipes в MTRL дают уже настроенную точку старта.

Например, в одном из наших ранних подходов мы пытались обучить агента сразу на всех задачах SOP-Bench, из-за чего задачи конкурировали между собой, а reward колебался:

Figure 2: Reward fluctuating when trying to train all SOP-Bench tasks together

После того как мы сузили данные до одной задачи (aircraft_inspection), стало видно, что validation reward снижался, хотя rollout reward уже насытился. В нашей формуле reward максимальное значение было 5.0, но reward остановился примерно на 3.7:

Figure 3: Reward stalling and validation reward dropping

Модель не получала полный reward на aircraft_inspection, и Task Success Rate на внешнем бенчмарке для fine-tuned модели оказался ниже, чем у базовой. Нужно было просмотреть rollout trajectories, чтобы понять почему. Пример SOP в one-shot не совпадал с ground-truth данными задачи в двух местах. В нем отсутствовало поле cross_check_response, которое требовалось данными, поэтому модель не могла выдать полный ответ, а также output был завернут в другой тег, чем ожидала evaluation. Мы привели пример в соответствие с данными и убрали неразрешаемое поле, чтобы reward и evaluation измеряли одно и то же.

Figure 4: Healthy reward signals for the aircraft_inspection task of SOP-Bench

При измерении Task Success Rate (TSR) дообученной модели GPT-OSS 20B относительно внешнего бенчмарка мы увидели рост TSR на 13 процентов и увеличение per-field accuracy примерно на 16 процентов на задаче aircraft_inspection, что подтвердило: reward function согласован с внешней оценкой.

Как это собрать в единый цикл итераций

Ранее описанные элементы складываются в один training loop, который выполняется в том же порядке, в каком они были представлены. Сначала строятся environment и evaluation, потому что это фиксированная основа, от которой зависит каждый следующий шаг. Затем reward проектируется с учетом этой оценки, и только после этого начинается обучение и чтение метрик. Фиксированность первых этапов и делает каждый проход быстрым, поэтому основная работа уходит в reward и данные. Рабочая последовательность выглядит так:

1. Соберите representative task data и разделите ее на train, validation и held-out test sets.
2. Постройте training environment на основе production schemas: hermetic, seeded, reproducible.
3. Разверните external evaluation на test set, вычисляемую независимо от reward.
4. Зафиксируйте baseline, прогнав базовую модель и frontier reference model через evaluation. Если базовая модель получает ноль, остановитесь и упростите задачу, прежде чем идти дальше.
5. Спроектируйте reward, а затем проверьте его на реальных выходах базовой модели до любого обучения.
6. Запустите обучение, отслеживая rollout/reward, completion rate и примеры trajectories, чтобы понимать, что модель производит во время training.
7. Оцените обученную модель внешней evaluation. Просматривайте trajectories, особенно те, где reward и evaluation расходятся.
8. Корректируйте reward, environment или data и запускайте цикл снова.

Когда кривая замирает или рушится, прежде чем настраивать что-либо еще, пройдите эти шаги по порядку:

Меняйте только один параметр за раз и наблюдайте метрики 25–50 training steps (gradient updates) на каждое решение. В наших прогонах большинство сбоев удавалось четко идентифицировать примерно за 30 steps, если параметры менялись осознанно.

Вывод

Качество reward и качество evaluation куда сильнее влияют на то, получится ли полезный агент, чем сам алгоритм или набор hyperparameters. Reward — единственный сигнал, который оптимизирует модель, а отдельная evaluation показывает, учится агент задаче или учится reward. Хорошо спроектированный reward и evaluation, совпадающая с конечной задачей, способны дать полезного агента; без них даже сильный алгоритм приводит к модели, которая хорошо выглядит на обучении и проваливается в production.

SageMaker AI multi-turn RL берет на себя большую часть операционной работы и сложности распределенного agentic RL-обучения, абстрагируя hardware, orchestration и training engine. С SageMaker AI multi-turn RL вы сосредотачиваетесь на создании точной среды, где Strands Agents и AgentCore могут помочь перевести production environment в agentic-формат, а затем на reward design, evaluation и настройке параметров.

Чтобы начать работу с agentic RL, можно пройти пример notebook для настройки MTRL. См. документацию SageMaker AI multi-turn RL для рекомендаций по сервису и reward design best practices для более глубокого разбора темы reward, а также этот AWS blog post о GRPO с verifiable rewards. Наконец, SOP-Bench paper and dataset — источник примера, который использовался в материале.

Материал — перевод статьи с английского.

Оригинал: Best practices for multi-turn reinforcement learning in Amazon SageMaker AI