Как ведущие AI-лаборатории строят RL-агентов в 2026 году (используя идею Карпати об обучении через system prompt)

Изначально опубликовано Avi Chawla в X.

Как Anthropic, OpenAI и DeepSeek сходятся к единой идее: использовать system prompt как функцию вознаграждения. Полный разбор эволюции RL — от RLHF до RULER — с кодом.

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

Описанное выше взаимодействие работает дискретными шагами. На каждом шаге по порядку происходят три вещи:

• Агент наблюдает текущее состояние среды (S). Состояние — это описание ситуации, в которой находится агент, достаточное, чтобы решить, что делать дальше. Например, в шахматах состояние — это позиция на доске, а в диалоговой модели — история беседы на текущий момент.
• Агент выбирает действие (A) на основе того, что видит. Действие — это выход агента, единственный способ, которым он может повлиять на среду. Например, в шахматах действие — это допустимый ход. Для LLM действие — это сгенерированный ответ.
• Затем среда делает две вещи: переходит в новое состояние (S') и выдаёт вознаграждение (R) — скалярное число, оценивающее действие. Начинается следующий шаг, и цикл продолжается.

Если связать эти шаги вместе, получается траектория:

Если читать слева направо, это вся история взаимодействия агента со средой. Каждая четвёрка (S, A, R, S') — это один переход, и значительная часть RL посвящена обучению на таких переходах.

Применение RL к LLM

Когда RL впервые начали применять к LLM, средой были человеческие предпочтения.

OpenAI InstructGPT (2022) представил RLHF (Reinforcement Learning from Human Feedback, обучение с подкреплением на основе обратной связи от людей), где:

• люди ранжировали выходы модели
• эти ранжирования обучали reward model — модель вознаграждения
• а PPO (Proximal Policy Optimization) использовал эту модель вознаграждения для дообучения LLM.

ChatGPT был построен именно на этом пайплайне.

Но люди не могут сидеть в тренировочном цикле и оценивать каждый выход в реальном времени. Если модель генерирует 16 ответов на промпт в течение тысяч тренировочных шагов, это сотни тысяч оценок.

OpenAI решила это, разделив процесс на две фазы.

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

Когда модель вознаграждения была готова, PPO мог выполнять собственно RL-обучение со скоростью GPU. Модель генерировала ответы, reward model оценивала их, а PPO обновлял веса — без обширной необходимости в людях.

Однако цена заключалась в том, что PPO требовал одновременно держать в памяти четыре полноразмерные модели.

• Policy — политика (обучаемая LLM).
• Reference policy — референсная политика (замороженная копия исходной модели, используемая для предотвращения слишком сильного дрейфа обучения через штраф KL-дивергенции).
• Reward model — модель вознаграждения (обсуждавшийся выше аппроксиматор человеческих предпочтений для оценки каждого выхода).
• И critic, также называемый value model — модель ценности (подробнее о ней ниже).

Critic существует, чтобы ответить на один вопрос:

Было ли это вознаграждение хорошим или плохим относительно того, чего мы обычно ожидали бы для этого промпта?

Это нужно потому, что сырое вознаграждение 0,7 само по себе ничего не значит. Например, для простого фактического вопроса, где большинство ответов получают 0,9, оценка 0,7 ниже среднего.

Но для сложного открытого вопроса, где большинство ответов получают 0,4, оценка 0,7 превосходна.

Critic обучается этому базовому уровню, наблюдая тысячи пар (prompt, reward) во время обучения.

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

Это делает сигнал стабильным для промптов разной сложности. Но цена здесь в том, что critic сам является полноразмерной LLM, добавляя ещё одну модель в память.

Для LLM на 7B параметров это означало примерно 28B параметров в памяти одновременно.

Прорыв DeepSeek R1 с использованием проверяемых вознаграждений

В январе 2025 года DeepSeek выпустила R1 с принципиально другим подходом к сигналу вознаграждения.

Вместо обучения reward model на человеческих предпочтениях (фазы 1 и 2 пайплайна RLHF) они использовали RLVR (Reinforcement Learning with Verifiable Rewards, обучение с подкреплением с проверяемыми вознаграждениями).

Это простая верификация на основе правил, где сама среда предоставляет сигнал.

Например:

• Для математических задач верификатор проверял, совпадает ли ответ модели с известным решением.
• Для кода компилятор запускал выход модели и возвращал pass или fail. Бинарные вознаграждения: 1 за правильный ответ, 0 за неправильный.

Здесь не нужны ни человеческие ранжирования, ни явные reward models, поскольку ground truth был доступен (или выводим) и мог использоваться как вознаграждение.

RL-оптимизатором был GRPO (Group Relative Policy Optimization), который убрал большую часть инфраструктуры PPO.

Он полностью удалил модель critic.

Вместо обучения отдельной модели предсказывать ожидаемое вознаграждение для каждого промпта GRPO генерировал несколько ответов на один и тот же промпт (обычно 16) и нормализовал вознаграждения внутри каждой группы.

Если 4 из 16 ответов правильно решили математическую задачу, эти 4 получали положительный advantage, а остальные 12 — отрицательный.

Этот шаг убрал из памяти одну целую полноразмерную модель.

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

Так что четырёхмодельная схема PPO (policy + reference + critic + reward model) схлопнулась всего до двух моделей: обучаемой policy и референсной копии для KL-регуляризации.

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

С этой настройкой DeepSeek R1-Zero, обученный только с GRPO и проверяемыми вознаграждениями (вообще без supervised fine-tuning), вырос с 15,6% до 77,9% на математических задачах AIME 2024.

С majority voting он достиг 86,7%, сравнявшись с OpenAI o1.

Модель самостоятельно развила самопроверку, рефлексию и chain-of-thought reasoning — исключительно из бинарного сигнала правильно/неправильно, и никто не учил её рассуждать шаг за шагом.

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

RLVR с GRPO стал доминирующим подходом для обучения reasoning-моделей в течение 2025 года.

Каждая крупная лаборатория выпустила reasoning-вариант по этому рецепту.

Проблема

Сам по себе GRPO — алгоритм общего назначения.

Ему безразлично, откуда приходит вознаграждение: от математического верификатора, компилятора кода, человека или Python-скрипта.

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

Но очевидное узкое место здесь — откуда берутся эти вознаграждения.

Для математики и кода всё хорошо, потому что среда предоставляет детерминированный сигнал.

Но агенты, взаимодействующие с реальными инструментами и данными, не создают выходов, которые можно сопоставить строкой с золотым ответом.

RAG-агент извлекает контекст и генерирует ответ. Нет единственного правильного ответа, с которым можно сравнить. Агент поддержки клиентов составляет ответ. Нет компилятора, через который можно его прогнать. Агент суммаризации сжимает 20-страничный документ. Существует много допустимых summary, и никакой string-matching верификатор не отличит хорошее от посредственного.

В таких случаях среда не выдаёт вам сигнал вознаграждения так, как это делает математическая задача.

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

Но для большинства агентских workflow результат субъективен или многомерен.

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

Так что, хотя RL-фреймворк подходит, недостающая часть — это scoring function, функция оценки.

Одно решение — писать кастомные reward functions, где Python-код оценивает каждый выход на основе заданных вручную критериев.

• Reward function для RAG может проверять, использовал ли ответ извлечённый контекст (faithfulness), штрафовать содержимое, которого не было в контексте (hallucination), вознаграждать полноту и обрабатывать случаи, когда сам контекст неоднозначен.
• Reward function для использования инструментов может оценивать частичный прогресс в многошаговой задаче, штрафовать лишние API-вызовы и измерять, достиг ли агент корректного финального состояния.

Каждый критерий возвращает частичный score, и они суммируются или взвешиваются в финальное вознаграждение.

Это работает, но создаёт собственный набор проблем.

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

Reward function, которая переоценивает соответствие формату и недооценивает faithfulness, обучит агента производить прекрасно отформатированные галлюцинации.

Reward functions также хрупки. Если вы меняете retrieval pipeline, добавляете новый инструмент или модифицируете system prompt, reward function нужно переписывать.

Отладка тоже проблематична.

Когда агент во время обучения осваивает плохое поведение, причина может быть в reward function, гиперпараметрах обучения, данных или вообще в чём-то другом.

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

Это главная причина, по которой RL широко приняли для проверяемых задач (математика, код, логика), но не для агентских workflow (RAG, поддержка клиентов, использование инструментов, суммаризация).

RLVR дал reasoning-моделям автоматический reward signal общего назначения там, где они могли проверить ответ и вернуть 0 или 1. Для большинства agentic workflows такого эквивалента нет.

Различие не в модели. Одна и та же Qwen 2.5 14B может выполнять обе роли.

Различие в задаче. Можем ли мы проверить, производит ли агент выход, который можно автоматически проверить?

Как к этому подходят AI-лаборатории?

Это не пробел, который замечают только open-source-практики.

Крупные AI-лаборатории сходятся к одной и той же проблеме с разных сторон.

Anthropic показала, что люди в RL-цикле вообще не обязательны.

Их работа Constitutional AI показала: если записать набор принципов («конституцию»), AI может оценивать выходы относительно этих принципов и генерировать preference data для RL-обучения.

AI оценивал собственные выходы по письменным принципам и использовал эти суждения как RL-сигнал. Это был значительный концептуальный сдвиг: документ с правилами заменил армию человеческих оценщиков.

OpenAI внутренне работает над чем-то похожим. Они разрабатывают «Universal Verifiers» — технику для расширения RL за пределы математики и кода в области вроде биологии, медицины и общих знаний, где ответы нельзя проверить простым string match.

Детали не публичны, но направление ясно: нам нужны reward signals общего назначения, которые работают в любой области, а не только там, где есть детерминированные верификаторы.

Карпати тоже указывал в эту сторону.

В 2025 году он утверждал, что нам не хватает крупной парадигмы обучения для LLM — чего-то, что он предварительно назвал «system prompt learning».

Основная идея в том, что system prompt несёт более богатый сигнал, чем скалярное вознаграждение, и RL-обучение должно находить способы использовать этот сигнал, а не полагаться исключительно на вручную написанные reward functions.

RULER

Если вы хотите увидеть это на практике, RULER, встроенный в ART framework от OpenPipe (open-source, 9k+ звёзд), — это reward function общего назначения, которая заменяет весь этот кастомный код оценивания одним вызовом функции.

Она использует LLM-as-judge для ранжирования нескольких траекторий и работает за счёт того же свойства, которое делает GRPO мощным: важны только относительные ранжирования.

Вот как это работает по шагам:

• На каждом тренировочном шаге вы генерируете N траекторий для одного и того же сценария (обычно от 4 до 8).
• RULER отправляет все N в judge LLM (например, o3, o4-mini или даже локальную Qwen3 32B).
• Судья читает system prompt агента, чтобы понять, что агент должен был сделать, затем оценивает каждую траекторию от 0 до 1 относительно остальных.

Два свойства делают это рабочим:

1) Относительное оценивание проще абсолютного.

LLM испытывают трудности с абсолютным скорингом, потому что нет общей калибровки.

Но вопрос «какой из этих 4 ответов лучше всего следует инструкциям system prompt» — это задача сравнения, а LLM стабильно хорошо справляются с такими задачами.

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

2) GRPO всё равно нормализует внутри каждой группы.

Неважно, получил ли лучший ответ 0,9 или 0,3 в абсолютных терминах.

GRPO берёт scores внутри группы, вычисляет среднее и стандартное отклонение и нормализует.

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

Примерный walkthrough

Перед тем как переходить к коду, проследим концептуально, что происходит. Допустим, вы обучаете RAG-агента. На каждом тренировочном шаге GRPO генерирует несколько ответов на один и тот же запрос:

В традиционной схеме вы бы написали reward function, чтобы оценить каждый из них:

Каждая из этих вспомогательных функций (uses_context, has_hallucination, is_complete, is_concise) — отдельный инженерный проект.

Вам нужно точно определить, что значит «использует контекст», выбрать пороги, обработать edge cases и всё протестировать.

С RULER вы заменяете всё это на:

Judge LLM читает system prompt («Answer using ONLY the retrieved context. Do not add information not in the context.»), читает все четыре ответа и оценивает их.

System prompt уже неявно определяет faithfulness, hallucination и completeness. Судья применяет эти критерии без реализации их в Python.

Траектории и группы

ART представляет каждый ответ агента как Trajectory — последовательность сообщений (system, user, assistant), упакованную с метаданными, которые нужны GRPO для обучения.

Несколько траекторий для одного и того же сценария образуют TrajectoryGroup. Это единица, которую RULER оценивает и на которой GRPO обучается.

Инициализация reward=0.0 — это placeholder.

• После возврата ruler_score_group поле reward каждой траектории обновляется score'ом судьи.
• Объекты Choice и ChatCompletionMessage — стандартные типы OpenAI, так что если вы уже используете OpenAI SDK для inference, это те же самые объекты, с которыми вы уже работаете.

Два конкретных примера

У RULER есть два уровня API.

1) Низкоуровневая функция ruler работает с обычными словарями сообщений, так что ART-специфичные объекты не нужны.

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

Посмотрим на минимальный пример с тремя траекториями для одного и того же RAG-запроса.

Ниже мы определили три списка сообщений: один faithful, один hallucinate, и один полностью игнорирует контекст.

Затем запускаем скоринг:

Это даёт следующий вывод:

Обратите внимание: мы не писали checker для faithfulness и не кодировали детектор hallucination.

System prompt говорил: «Use the retrieved context to answer user queries accurately», и судья применил это как критерии оценки.

Галлюцинированный ответ получил 0,45 (не ноль), потому что частично использовал контекст. Часть про 30-дневный возврат была правильной.

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

Это тонкое различие, которое потребовало бы значительной инженерной работы, чтобы закодировать его в rule-based reward function.

Более того, scores распределены по диапазону 0–1: 0,97, 0,45, 0,05 — в отличие от бинарного pass/fail.

RULER создаёт градиент, отражающий относительное качество. GRPO может использовать этот градиент, чтобы применять пропорциональные обновления: сильно подкреплять faithful-поведение, мягко подавлять паттерн галлюцинации (поскольку он был частично правильным) и сильно подавлять поведение, игнорирующее контекст.

2) Функция ruler выше подходит для понимания и экспериментов, но тренировочный цикл ART работает с объектами Trajectory и TrajectoryGroup.

Они содержат поле reward, которое читает GRPO, debug logs для инспекции и структуру, которую ожидает model.train().

После этого высокоуровневая функция ruler_score_group выполняет конвертацию.

Ниже посмотрим на тот же RAG-сценарий, структурированный так, как вы использовали бы его в реальном training pipeline, теперь с 4 траекториями вместо 3.

Теперь у нас 4 траектории вместо 3. Четвёртая — подробный, но точный ответ, который использует только извлечённый контекст, но оборачивает его в ненужные слова/предложения.

Далее определяем наши Trajectories и Groups, как обсуждали ранее:

Наконец, запускаем скоринг:

С debug=True RULER печатает сырое рассуждение судьи с фактическими scores.

Вот это сырое рассуждение:

А это scores (в ранжированном виде):

Если присмотреться...

• Краткий faithful-ответ (0,98) набрал чуть больше, чем verbose, но точный ответ (0,96). Оба использовали только извлечённый контекст, оба были корректны, но system prompt говорил «Answer using ONLY the retrieved context», и краткая версия делала это более прямо. Судья распознал многословность как небольшую проблему качества, а не проблему корректности. Это тонкое различие, которое было бы трудно закодировать в scoring function: как написать правило «технически правильно, но излишне многословно, штрафовать на 0,02»?
• Галлюцинированный ответ упал с 0,45 в первом эксперименте до 0,20 здесь. Разница — в system prompt. Первый эксперимент говорил «Use the retrieved context to answer accurately». Этот говорит: «Do not add information that is not in the context.» Более строгая инструкция дала более строгую оценку. Судья адаптировался автоматически. Если вы ужесточаете system prompt, RULER ужесточает оценивание соответственно, без изменения scoring code.
• Ответ, игнорирующий контекст, получил 0,05 в обоих экспериментах. Когда ответ прямо есть в извлечённом контексте, а агент говорит «I'm not sure», двусмысленности нет независимо от формулировки system prompt.

Эти оценённые траектории — ровно то, что ожидает model.train(), так что посмотрим на это дальше.

Полный training loop

Чтобы действительно обучать с этими scores, вы заменяете захардкоженные ответы реальным model inference.

ART gather_trajectory_groups берёт на себя orchestration.

По сути, для каждого сценария он генерирует группу траекторий, используя текущие веса модели, оценивает их с помощью RULER и собирает результаты для GRPO:

На каждом шаге модель генерирует 4 ответа на сценарий, используя текущие веса, RULER ранжирует их относительно друг друга, а GRPO подкрепляет высоко оценённое поведение и подавляет низко оценённое.

Агент с каждой итерацией лучше следует инструкциям system prompt.

За несколько шагов модель изучает паттерны, которые получают хорошие scores (faithfulness, краткость, groundedness в контексте), и разучивает паттерны, которые получают плохие scores (hallucination, игнорирование контекста, многословность).

И обратите внимание: нигде в этом коде не была определена reward function.

Кастомные rubrics

Для большинства задач system prompt даёт достаточно сигнала, чтобы RULER эффективно оценивал. Но когда нужны более специфичные критерии оценки, RULER поддерживает custom rubrics:

Rubric — это естественный язык, а не Python, поэтому итерировать по нему быстро.

Вы просто меняете предложение, перезапускаете и проверяете scores.

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

Применение к непроверяемым задачам

RULER — инструмент общего назначения. Он работает с любой задачей, не только со свободно формулируемыми задачами, где custom rewards болезненны.

Практический вопрос — когда RULER даёт ценность по сравнению с более простыми альтернативами.

Для полностью детерминированных задач (вернул ли SQL-запрос правильные строки?) бинарный верификатор дешевле и даёт более чистый сигнал.

Для полностью субъективных задач (хороший ли summary?) RULER — единственный автоматический вариант. Для задач между этими полюсами (нашёл ли агент правильный ответ И хорошо ли его объяснил?) можно комбинировать оба подхода:

RULER сохраняет любые rewards, которые вы назначаете во время rollout, в отдельной метрике, так что можно накладывать LLM-judge scoring поверх детерминированной верификации, не теряя ни один из сигналов.

Практические детали

Вот несколько практических наблюдений, которые я собрал на основе использования RULER:

→ Вам не нужна самая дорогая модель в роли судьи. Более дешёвые модели вроде Qwen3 32B часто работают хорошо. Также можно использовать Claude, локальные модели через Ollama или любую модель, поддерживаемую LiteLLM. Выбор — это компромисс между стоимостью и качеством, а не жёсткое требование.

→ Рекомендуемый диапазон — от 4 до 8 траекторий на группу. Меньше 4 даёт судье слишком мало материала для сравнения. Больше 8 может запутать судью и увеличить стоимость без пропорциональной пользы.

→ Когда все траектории в группе имеют один и тот же system prompt и user message (обычно так и есть), RULER автоматически дедуплицирует общий префикс. Судья видит общий контекст только один раз, а затем разные ответы. Это существенно сокращает расход токенов для длинных system prompts или многоходовых разговоров.

→ RULER кэширует ответы судьи на диск. Если вы повторно запускаете те же траектории, он не будет снова обращаться к API. Это важно при отладке, когда вы итерируете по system prompt или rubric.

Узким местом в применении RL к агентам никогда не был алгоритм оптимизации.

GRPO хорошо справляется с этим.

Узким местом всегда был reward signal.

RLVR решил это для проверяемых задач, позволив среде напрямую оценивать выходы.

RULER решает это для любой задачи (проверяемой или непроверяемой), позволяя LLM-судье оценивать выходы относительно друг друга.

Полная реализация находится в репозитории ART, вместе с Colab notebooks, которые пошагово проходят training loop от начала до конца.

Репозиторий: https://github.com/OpenPipe/ART (не забудьте поставить звезду ⭐️)

На этом всё!

Если вам понравился этот tutorial:

Ищите меня → @_avichawla

Каждый день я делюсь tutorials и insights о DS, ML, LLMs и RAGs.