Среды обучения с подкреплением и способы их создания

13 марта 2026 г.

13 марта 2026 г.

Авторы: Дэниел, Майкл, а также представители NVIDIA: Шашанк Верма, Силендран Арунагири, Крис Винг, Брайан Ю

Обучение с подкреплением (RL) формировало сферу ИИ на протяжении десятилетий: от ранних систем управления до игровых агентов и, в последнее время, больших языковых моделей, которые обучаются посредством взаимодействия. По своей сути RL работает путем обучения модели реагировать и получать обратную связь, совершенствуя модель с течением времени.

Однако по мере того, как ИИ становится агентным, способным к многошаговым рассуждениям, использованию инструментов и принятию решений, мы вступаем в «Эру опыта», где прогресс движим системами, которые учатся на собственном опыте, а не просто на статических данных. RL должно эволюционировать от оптимизации отдельных ответов к формированию поведения на протяжении целых траекторий. В этом контексте обучение происходит через взаимодействие со «средами», которые определяют допустимые действия, изменения состояний и критерии успеха.

Рабочий процесс RL объединяет модель политики, алгоритм обучения и среду, а также метод проверки ответов агента. Этот цикл взаимодействия позволяет агентам планировать, адаптироваться и восстанавливаться после неудач.

В этом блоге рассматривается, как RL развивается для агентного ИИ, почему среды играют центральную роль в этом сдвиге и как открытые инструменты, такие как Unsloth, NVIDIA NeMo RL, NVIDIA NeMo Gym и NVIDIA NeMo Data Designer, помогают разработчикам эффективно создавать такие рабочие процессы RL.

Сравнение SFT и RL

Прежде чем создавать среду, важно понять, когда RL является подходящим инструментом.

Контролируемое дообучение (SFT) лучше всего подходит, когда вы можете предоставить четкие целевые модели поведения с помощью демонстраций или пар «инструкция-ответ». Это отлично подходит для обучения формату и стилю. Однако у SFT есть ограничения.

• Имитация вместо адаптивности. Когда набор данных невелик, модели учатся имитировать ответ, а не изучать процесс его достижения.

• Хрупкость. Модели SFT часто испытывают трудности, когда сценарии выходят за рамки их обучающего распределения, поэтому набор данных должен быть разнообразным и обширным.

Обучение с подкреплением (RL) становится лучшим выбором по мере роста сложности. Вместо того чтобы говорить модели «скажи именно это», вы предоставляете цель и способ её проверки. Это позволяет модели исследовать пути рассуждений, делая её устойчивой к граничным случаям. Это, как правило, хорошо работает для таких задач, как математика, написание кода и вызов инструментов, а также для других задач, имеющих четкий путь к проверке ответа.

На практике SFT и RL не являются взаимоисключающими, и часто применяется гибридная стратегия.

• SFT для «разогрева» RL. Используйте качественный набор демонстраций, чтобы обучить шаблон чата, формат вызова инструментов и общую читаемость. Это поможет RL не тратить время на изучение формата вашего набора данных.

• RL для масштабирования. Переходите к RL, чтобы позволить модели исследовать и исправлять ошибки самостоятельно. Именно в ходе этой «пост-тренировочной» доработки по-настоящему формируются навыки рассуждения и устойчивость.

Например, семейство моделей NVIDIA Nemotron 3 использует SFT в качестве существенного первого этапа для подготовки модели перед переходом к доработке с помощью RL. Окончательный выбор зависит от вашего вычислительного бюджета, доступности данных и уровня обобщения, требуемого от вашего агента. Индустрия в целом движется к выделению больших вычислительных мощностей на этапах RL, особенно по мере того, как среды RL становятся более сложными и доступными.

От алгоритмов к средам и рост RLVR

Традиционно стандартом были методы RL, такие как PPO (Proximal Policy Optimization). Однако их ресурсоемкость, требующая использования нескольких сложных и вычислительно затратных моделей, таких как модели вознаграждения и критика, привела к переходу к более масштабируемым алгоритмам.

Современные рабочие процессы все чаще используют более эффективные методы, такие как DPO и GRPO, для решения различных аспектов улучшения моделей.

Прямая оптимизация предпочтений (DPO) полностью обходит цикл RL, рассматривая согласование как задачу классификации на статических данных предпочтений.

• Тип вознаграждения. Попарное. Оно опирается на размеченные предпочтения («Ответ А > Ответ Б»).

• Эффективность. Вычислительно легкий и стабильный метод, что делает его идеальным для задач согласования, таких как безопасность, тон и стиль.

Однако DPO не хватает явной оптимизации вознаграждения или исследования. Он учится на фиксированных парах предпочтений, что не позволяет ему открывать новые стратегии или оптимизировать долгосрочные результаты. Кроме того, поскольку алгоритм DPO моделирует относительное предпочтение вывода, а не вознаграждение за траекторию, он менее эффективен для агентных рабочих процессов, требующих многошаговых рассуждений и использования инструментов.

Чтобы устранить эти ограничения в агентных доменах, разработчики обращаются к алгоритмам, использующим проверяемые вознаграждения.

Одним из таких алгоритмов является Group Relative Policy Optimization (GRPO), который представляет собой оптимизированную версию PPO. В этой конфигурации тяжелые модели критика заменяются генерацией групп выводов и их оценкой с помощью детерминированного верификатора.

• Тип вознаграждения. Обычно бинарный (0 или 1), но также поддерживает непрерывные значения (от -∞ до +∞). Хотя он лучше всего работает, когда среда может программно сказать «Да» или «Нет» (например, проверяя, проходит ли модульный тест), он также поддерживает сложные вознаграждения, где оценки могут превышать 1 для обеспечения более детальной обратной связи.

• Эффективность. Исключение модели ценности и модели вознаграждения из PPO значительно снижает нагрузку на память и является ключевым фактором масштабирования способностей к рассуждению.

Этот более широкий сдвиг в сторону проверяемой корректности отличается от любого отдельного алгоритма. Хотя проверка может способствовать улучшениям даже в контролируемых условиях, например, при выборке с отклонением (rejection sampling), она занимает центральное место в парадигме обучения с подкреплением на основе проверяемых вознаграждений (RLVR). Заменяя субъективную оценку явными проверками, такими как правильность ответа агента или вызов нужных инструментов, RLVR смещает центр тяжести с оптимизатора на среду. Алгоритмы, такие как GRPO, просто предоставляют эффективный механизм для оптимизации на основе этих сигналов среды.

В RLVR среда становится контрактом между обучением и поведением.

Давайте теперь более конкретно определим, что мы подразумеваем под средой.

Что такое среда?

Среда — это все, что находится вне абсолютного контроля агента. Среда определяется задачей, которую должен выполнить агент, действиями, которые он может предпринять, и состоянием мира, которое агент наблюдает и на которое воздействует. Среда также определяет, как оценивается эффективность работы агента, включая то, что составляет успех и как назначается вознаграждение.

Прежде чем мы пойдем дальше, важно официально представить ключевую терминологию.

Прогон (Rollout). Процесс выполнения политики в среде для получения опыта. Он подчеркивает акт сбора данных путем пошагового прохождения среды, выполнения действий и записи происходящего.

Траектория. Результирующая последовательность состояний, действий и вознаграждений, полученная в результате прогона (rollout). Этот термин подчеркивает сами данные или упорядоченную запись произошедших событий. На практике большинство кодовых баз и статей рассматривают эти термины как синонимы, поскольку один прогон создает ровно одну траекторию, и когда люди говорят «траектория», они обычно подразумевают, что она получена в результате выполнения стратегии (policy).

Проблемы создания и масштабирования сред

• Отделение сред от обучения. Многие рабочие процессы обучения с подкреплением (RL) тесно связывают логику среды с конвейером обучения, что затрудняет интеграцию сложных циклов агентов, итеративную доработку дизайна среды и проведение контролируемых абляционных исследований.

• Последовательное представление агентных траекторий. Сообщество сегодня широко использует Chat Completions, но этот интерфейс был разработан для взаимодействия без сохранения состояния (stateless) за один ход. Однако агентные прогоны включают в себя чередующиеся рассуждения, вызовы инструментов и текст на протяжении нескольких ходов. Без схемы, которая поддерживает это нативно, вам придется каждый раз вручную парсить и сериализовать выходные данные модели для каждой среды.

• Управление ресурсами. Среды часто зависят от внешних ресурсов, таких как изолированное выполнение (sandboxed execution), базы данных, API и многое другое. Каждый прогон требует изолированных экземпляров, и эти экземпляры должны надежно инициализироваться и очищаться.

• Масштабируемость. Обучение может потребовать тысяч параллельных прогонов. Экземпляры среды должны масштабироваться соответствующим образом, обеспечивая распределение, балансировку нагрузки и отказоустойчивость.

NVIDIA NeMo Gym

NeMo Gym — это библиотека с открытым исходным кодом для создания и масштабирования сред RL, проверенная в бою при разработке семейства моделей Nemotron 3.

NeMo Gym разработан для решения этих проблем путем обеспечения четкого отделения сбора прогонов от обучения, стандартизации траекторий с использованием OpenAI Responses API и предоставления инфраструктуры для управления жизненным циклом ресурсов, которая масштабируется до тысяч параллельных сред.

В NeMo Gym задачи определяют, что должен выполнить агент. Ресурсы предоставляют внешнее состояние, с которым взаимодействует агент, например, инструменты, базы данных, изолированное выполнение, а также логику проверки, которая оценивает производительность. Интерфейс модели (Model Interface) управляет генерацией, создавая действия модели на каждом ходу, такие как текст, вызовы инструментов или код. Агент координирует каждый прогон, вызывая модель для генерации действий, обновляя состояние среды через серверы ресурсов и собирая итоговое вознаграждение.

Рисунок 1: Архитектура NeMo Gym, которая работает совместно с фреймворком обучения RL, иллюстрируя отделение оркестрации прогонов среды от обучения и генерации модели.

NVIDIA NeMo Gym интегрируется с библиотеками обучения RL, такими как NeMo RL, Unsloth, Hugging Face TRL и другими, которые реализуют алгоритмы обучения (например, GRPO) для обновления модели. NeMo Gym собирает траектории прогонов и вознаграждения из среды и передает их в фреймворк обучения, который управляет обновлениями стратегии и предоставляет обновленную модель для следующего раунда прогонов.

Путь пользователя RLVR: от бенчмаркинга до обучения

Прежде чем написать первую строку кода, важно понять двухфазный путь специалиста по RLVR.

Рисунок 2: В рабочем процессе RLVR подготовка среды предшествует обучению модели и формирует его.

Фаза 1: Подготовка среды

• Бенчмаркинг: Оцените вашу базовую модель, чтобы выявить конкретные пробелы в возможностях (например, она не справляется с многошаговыми математическими задачами или галлюцинирует аргументы инструментов).

• Определение возможностей: Сопоставьте эти сбои с целевыми возможностями.

• Разработка среды: Адаптируйте существующую среду или создайте новую.

• Генерация задач: Подготовьте данные для создания разнообразных наборов задач, которые задействуют среду. Это часто включает синтетическую генерацию данных (SDG).

• Профилирование вознаграждений: Проведите «санитарную проверку» среды, запустив прогоны на разных моделях (включая крупные передовые модели), чтобы убедиться, что выходные данные среды согласуют целевую возможность с реальными возможностями.

Фаза 2: Обучение модели

• Оптимизация: Обучите модель с использованием алгоритма, такого как GRPO, который использует проверяемые сигналы среды для обновления весов.

• Валидация: Убедитесь, что производительность в конкретной среде улучшается, и, что более важно, что это приводит к улучшениям в более широких прикладных бенчмарках.

Ключевой вывод заключается в том, что подготовка среды — это способ определить, что означает «лучше». Фаза обучения просто оптимизирует сигнал, который вы создали.

Для целей этого поста в блоге мы будем исходить из того, что у вас есть хорошее понимание возможности или бенчмарка, который вы хотите улучшить в модели. В следующем разделе рассматриваются, в частности, концепции, связанные с пунктом 1.3 выше, то есть создание среды.

Создание среды RL для обучения модели

NeMo Gym, библиотека с открытым исходным кодом в рамках фреймворка NVIDIA NeMo, определяет и координирует среды RL и генерирует масштабируемые, проверяемые данные прогонов, в то время как Unsloth использует эти прогоны для эффективного обучения RL.

В экосистеме NeMo Gym создание среды опирается на три фундаментальных столпа, кульминацией которых является обучение модели, выполняемое через интегрированный фреймворк RL.

1. Подготовка задач

Агенты должны сталкиваться с разнообразным набором сценариев, чтобы специализироваться и совершенствоваться в данной задаче. Например, в среде «Рабочий помощник» данные задачи состоят из бизнес-запросов на естественном языке, которые требуют от агента автономной навигации по имитируемым базам данных и инструментам в течение нескольких шагов. Простой одношаговый пример запроса пользователя и ожидаемого ответа:

Запрос пользователя:

«Отправь электронное письмо на адрес john.smith@atlas.com с темой 'Встреча команды' и текстом 'Давайте встретимся завтра в 14:00, чтобы обсудить проект'.»

«Отправь электронное письмо на адрес john.smith@atlas.com с темой 'Встреча команды' и текстом 'Давайте встретимся завтра в 14:00, чтобы обсудить проект'.»

Ожидаемый вызов инструмента:

При нехватке данных, специфичных для задачи, разработчики могут обратиться к синтетической генерации данных (SDG) с использованием таких инструментов, как NeMo Data Designer, чтобы программно создавать запросы задач и, возможно, соответствующие эталонные ответы. Для эффективного обучения вам нужны тысячи разнообразных промптов, которые задействуют инструменты среды. Например, если вы создаете среду для программирования, вы можете использовать LLM для генерации 5000 уникальных задач по Python, в то время как детерминированный скрипт генерирует модульные тесты (эталонные данные), используемые для проверки ответов.

Понимание задачи — это первый шаг в проектировании самой среды.

2. Дизайн среды

Возвращаясь к левой части Рисунка 1, дизайн среды состоит из трех основных компонентов:

• Сервер агента: Центральным компонентом дизайна среды является сам агент. Агент координирует всю логику взаимодействия, такую как вызов модели и использование инструментов. Он выступает в качестве каркаса, который связывает все воедино, управляя циклом диалога (отправка модели, выполнение вызовов инструментов, повторение).

• Сервер ресурсов: Этот компонент размещает инструменты, поддерживает состояние сессии и вычисляет вознаграждение.

• Интерфейс модели: он предоставляет стандартизированный интерфейс для взаимодействия с бэкендом генерации.

2.1 Сервер агента

Взгляните на пример псевдокода сервера агента ниже. Он отправляет диалог модели, получает ответ и, если модель вызывает какие-либо инструменты, направляет эти вызовы на сервер ресурсов, а затем возвращает результаты обратно модели. Этот процесс повторяется до тех пор, пока модель не ответит обычным текстовым сообщением (без вызова инструментов), не достигнет лимита токенов или не превысит max_steps.

Важно отметить, что вы можете использовать существующего агента в NeMo Gym, принести своего собственного или создать совершенно нового. Таким образом, этот цикл может выглядеть совершенно иначе в зависимости от вашей настройки. Например, MiniSWEAgent делегирует логику выполнения внешней системе, работающей в Docker-контейнерах, а затем преобразует вывод обратно в формат NeMo Gym.

Существующие агенты также могут поставляться с предопределенными инструментами, что позволяет использовать их напрямую. Затем вы можете легко использовать сервер ресурсов, чтобы дополнить агента любыми дополнительными внешними инструментами, которые ему могут понадобиться.

2.2 Сервер ресурсов

Сервер ресурсов — это «мир», с которым взаимодействует агент. В NeMo Gym он реализован как легковесное приложение на FastAPI. Он предоставляет инструменты в виде HTTP-эндпоинтов (например, POST /search_database), которые модель может вызывать с помощью стандартных схем инструментов, совместимых с OpenAI, а также логику расчета вознаграждения.

Критически важно, что эти серверы управляют сессиями. Поскольку агентное развертывание включает в себя несколько шагов, среда должна «помнить», что произошло на предыдущих этапах. NeMo Gym использует session_id для поддержания изолированного состояния для каждого параллельного развертывания.

2.3 Логика верификации

Верификатор — одна из самых важных частей проектирования среды. Часто это детерминированная функция, которая оценивает конечное состояние развертывания и возвращает сигнал вознаграждения.

Два распространенных способа проектирования таких вознаграждений:

• Сопоставление траекторий: сравнение конкретных вызовов инструментов и аргументов агента с «золотым путем». Это проще реализовать, но метод может быть хрупким, если существует несколько правильных способов решения задачи.

• Сопоставление состояний: проверка конечного результата (например, совпадает ли конечное состояние базы данных с эталонным) независимо от того, как агент к нему пришел. Это более надежный подход, используемый для сложных сред, таких как Workplace Assistant.

Другие основные способы проектирования логики верификации включают выполнение в «песочнице» (запуск сгенерированного кода или артефактов против модульных тестов), использование LLM в качестве судьи (для семантической или открытой оценки) и обучение моделей вознаграждения (для учета предпочтений человека) и другие.

Некоторые лучшие практики проектирования логики верификации включают:

• Предпочитайте бинарные вознаграждения: хотя может показаться интуитивно понятным начислять частичные баллы за промежуточные шаги, строгие бинарные сигналы (успех/неудача) обычно дают наиболее стабильные и эффективные цели оптимизации для таких алгоритмов, как GRPO.

• Профилируйте свои сигналы вознаграждения: прежде чем приступать к крупномасштабному обучению, оцените свою среду на нескольких моделях с разной производительностью (например, небольшая базовая модель против большой передовой модели). Если передовая модель не может стабильно превосходить базовую, ваша логика верификатора или определения задач, вероятно, требуют перекалибровки.

3. Обучение модели

После создания сред обучение агента продолжается путем генерации развертываний через повторяющееся взаимодействие между моделью политики и средой. NeMo Gym организует этот процесс, запуская среды в масштабе, управляя состоянием сессии и создавая структурированные траектории развертывания, аннотированные вознаграждениями от логики верификации.

Эти развертывания затем потребляются фреймворком обучения с подкреплением (RL), таким как Unsloth, NeMo RL или HuggingFace TRL, который применяет алгоритм оптимизации (например, методы типа GRPO или PPO) для обновления весов модели. Ознакомьтесь с руководствами по запуску GRPO с NeMo RL и NeMo Gym, а также по обучению RL с Unsloth и средой Sudoku в NeMo Gym.

Фреймворк обучения остается отделенным от реализации среды, что позволяет командам менять оптимизаторы, стратегии масштабирования или аппаратные бэкенды без изменения логики среды.

Обучение следует итеративному циклу: генерация развертываний, проверка результатов, обновление политики и повторная оценка производительности. Это разделение генерации развертываний и оптимизации обеспечивает масштабируемые и гибкие рабочие процессы RL в различных доменах и инфраструктурах.

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

RL на основе сред и открытая экосистема

Рабочие процессы RL, управляемые средой, все чаще определяют то, как обучаются агентные системы в исследованиях и индустрии. Разделяя определение среды, генерацию развертываний и оптимизацию, команды могут быстрее итерировать и масштабировать обучение с подкреплением, не связывая жестко логику вознаграждения с одним фреймворком обучения.

Этот шаблон уже применяется в реальных системах. Например, семейство моделей NVIDIA Nemotron 3 было преимущественно доработано с использованием структурированного RL в интерактивных средах, где логика верификации отдавала приоритет правильным траекториям и использованию инструментов, а не одношаговым ответам. Те же абстракции среды, которые использовались в этой работе, теперь доступны как открытые библиотеки и интегрируются с несколькими фреймворками обучения RL.

Среды RL также разрабатываются для прикладных областей. Например, Edison Scientific интегрировала NeMo Gym со своей средой Aviary для обучения научных агентов, которые исследуют гипотезы, запускают симуляции и получают детерминированную обратную связь от предметно-ориентированных сред. См. также публикацию NVIDIA о том, как обучать научных агентов с помощью обучения с подкреплением.

Сегодня интерактивные среды, созданные с помощью NeMo Gym, генерируют проверяемые данные развертывания, которые могут быть использованы такими библиотеками, как Unsloth, HuggingFace TRL, NeMo RL и другими стеками на базе PyTorch. Эта интероперабельность позволяет практикам выбирать оптимизаторы, стратегии памяти и аппаратные бэкенды независимо от дизайна среды, поддерживая масштабируемый агентный ИИ от исследований до продакшена.

Заключение и ресурсы

В эпоху агентного ИИ среда определяет контракт для интеллекта. Вот как вы можете начать работу уже сегодня:

• Unsloth + NeMo Gym: блокноты RL для Sudoku и обучения в нескольких средах с Unsloth и NeMo Gym.

• Учебные пособия по среде NeMo Gym и обучению помогут вам создавать собственные среды RL и использовать их с предпочитаемым вами фреймворком обучения RL.

• NeMo Gym GitHub: основная библиотека для создания и оркестрации проверяемых сред RL.

💕 Спасибо!

Огромное спасибо NVIDIA за создание этого образовательного блога вместе с нами. Также спасибо, что читаете и используете Unsloth — мы ценим это. 🙏

Как всегда, обязательно присоединяйтесь к нашей странице в Reddit и серверу Discord за помощью или просто чтобы выразить свою поддержку! Вы также можете подписаться на нас в Twitter и на нашу рассылку на: Substack.

Спасибо за прочтение!

Дэниел и Майкл Хан 🦥 12 марта 2026 г.