Reasoning-модели: от CoT до GRPO

15 мая 2026 г.

Reasoning-модели и гибридное мышление: от CoT до Claude 4

1. Что такое reasoning model и почему это важно

Классическая LLM устроена просто: подаём промпт, она авторегрессивно генерирует токены ответа. Reasoning-модель добавляет между промптом и финальным ответом отдельный этап рассуждения — длинный (часто очень длинный) блок текста внутри маркеров <think>...</think> у DeepSeek, <thinking>...</thinking> у Claude или эквивалентных. Этот блок модель пишет «для себя»: там она перебирает варианты, ловит свои ошибки, переписывает план решения, иногда возвращается к предыдущим шагам и пересматривает их. Только после закрывающего маркера идёт собственно ответ пользователю.

Технически разница маленькая — это просто длинная авторегрессия с особой структурой. Содержательно — большая. Эмпирически выяснилось, что дать модели возможность писать в «черновик» перед финальным ответом меняет потолок возможностей, а не просто сглаживает имеющиеся. На AIME (American Invitational Math Examination) обычные модели держатся в районе 10–20% accuracy, reasoning-модели берут 80–90%. На FrontierMath — одном из самых сложных математических бенчмарков — обычные модели не дотягивают до 5%, reasoning-модели подбираются к 30%. На сложном алгоритмическом коде (Codeforces div1) reasoning-модели играют на уровне human grandmaster.

Это привело к появлению нового понятия — test-time compute scaling. Раньше масштабирование LLM шло по двум осям: параметры (больше весов) и данные (больше токенов претрейна). Сегодня появилась третья: сколько модели разрешено думать на инференсе. И эта ось ведёт себя предсказуемо — на сложных задачах accuracy растёт линейно с логарифмом количества выделенного thinking-compute. Кривая $accuracy \approx a + b \cdot lo g (C_{test})$ оказалась устойчивой на всём диапазоне от десятков тысяч до миллионов thinking-токенов. Откуда берётся это качественное улучшение и как именно модели учат рассуждать так, чтобы оно появилось — основная тема этой статьи.

2. Эволюция: от prompting к RL

История того, как мы пришли к современным reasoning-моделям, выглядит как поток постепенных открытий, каждое из которых выглядело финальным до следующего прорыва.

Первый шаг — chain-of-thought prompting (Wei et al., 2022). Открытие звучит почти комично простым: если в промпте показать модели несколько примеров пошагового решения и попросить «давай подумаем шаг за шагом», accuracy на математических бенчмарках вырастает на 20–30 процентных пунктов. Модель ничему не училась дополнительно — она просто получила в контексте формат, в который смогла попасть. Это работало с моделями достаточно крупного масштаба (от 60B параметров и больше); более мелкие просто не понимали, что от них хотят. Открытие говорило важную вещь: способность рассуждать у моделей есть, но активируется только специфичной формой запроса.

Следующие шаги были эволюционными. Self-consistency (Wang et al., 2022) предложил сгенерировать $N$ независимых цепочек рассуждений с температурой и выбрать ответ голосованием большинства — дешёвый трюк, +5–10 п.п. на математике. Tree of Thoughts (Yao et al., 2023) превратил линейные цепочки в дерево с возможностью бэктрекинга и BFS/DFS по узлам. STaR — Self-Taught Reasoner (Zelikman et al., 2022) — сгенерировал цепочки моделью, отфильтровал по правильности ответа, дофайнтьюнил модель на оставшихся; это уже был путь к обучению, а не только к промптингу.

Параллельно развивалась идея SFT на reasoning-данных. Берём датасет $(q, rationale, a)$ — вопрос, рассуждение, ответ — и обычным supervised fine-tuning учим модель воспроизводить такой формат. Данные брались из трёх источников: дорогая человеческая разметка (например, MATH с разборами решений), дистилляция из более сильной модели (взять GPT-4, заставить решать задачи с пояснениями, обучить меньшую модель на результате), и rejection sampling — собственная модель генерирует много цепочек, оставляем только успешные, обучаемся на них. SFT работал, давал +15–25 п.п. на математике, но создавал «попугая»: модель воспроизводила формат рассуждений и часто решала задачи правильно, но не училась рассуждать качественно лучше — она просто переходила в режим, где её исходные способности использовались полнее.

Действительный перелом случился с появлением OpenAI o1 (сентябрь 2024) и публичным разбором DeepSeek-R1 (январь 2025). Их главная идея — RL с верифицируемыми наградами, или RLVR. Подход выглядит так: берём задачи, для которых правильный ответ можно автоматически проверить — математика (ответ есть число или выражение), код (запускаем тесты), логические задачи (проверяем по правилам), теоремы (через Lean или Coq). Модель генерирует цепочку рассуждений и финальный ответ, мы проверяем только ответ и даём бинарную награду ${0, 1}$ , на основе этих наград обновляем веса методами policy gradient. Никакой человеческой разметки на стадии RL не нужно — только верифицируемые задачи, объём которых можно нарастить до сотен тысяч и миллионов.

DeepSeek-R1-Zero показал, что этот рецепт работает буквально из коробки: взять base-модель без всякого SFT-этапа, запустить RLVR на математике, и через несколько тысяч шагов RL получить модель, которая решает AIME на уровне сильных competition-моделей. R1-Zero страдал косметикой — рассуждения местами на смеси китайского и английского, иногда нечитаемые — но базовое умение рассуждать возникло без единого размеченного примера хорошего рассуждения. R1 (полная версия) использовала короткий cold-start SFT для стилистики, потом тот же RLVR; этот рецепт стал стандартом для всех последующих open-source reasoning-моделей.

3. Математика: почему GRPO, а не PPO

RL для LLM не новость — RLHF используется со времён InstructGPT. Стандартный алгоритм там — PPO (Proximal Policy Optimization), и можно было ожидать, что для reasoning подойдёт он же. На практике reasoning-сообщество быстро ушло на собственный алгоритм — GRPO (Group Relative Policy Optimization), впервые описанный DeepSeek в DeepSeek-Math (2024). Причина техническая, и в ней стоит разобраться.

PPO требует двух компонентов: policy-сети (собственно LLM, которая генерирует ответы) и value-сети (отдельной нейросети, оценивающей ожидаемую награду из каждого состояния). Value-сеть нужна, чтобы посчитать advantage — насколько данная траектория лучше среднего ожидаемого результата. Без advantage градиенты получаются слишком шумными и обучение разваливается. Для классических RL-задач (игры, робототехника) value-сеть тренируется без особых проблем, поскольку есть плотные награды на каждом шаге. Для reasoning-задач картина другая: награда эпизодическая и бинарная. Модель пишет 5000 токенов рассуждений, в конце даёт ответ, мы говорим «правильно» или «нет». Что должна предсказывать value-сеть на токене номер 1247 длинной цепочки? Это безумно сложно — она должна угадать, к чему придёт модель ещё через 3000 токенов. Эмпирически value-сеть для reasoning плохо обучается, даёт высокую дисперсию и тратит огромное количество памяти (примерно столько же, сколько сам policy).

GRPO решает проблему элегантно: группа как baseline. Для каждого вопроса $q$ генерируем не один, а $G$ ответов от текущей policy (обычно $G = 8, 16, 32$ ). Получаем награды $r_{1}, \dots, r_{G}$ . Считаем стандартизованный advantage:

$A_{i} = \frac{r _{i} - μ _{G}}{σ _{G} + ε}$

где $μ_{G}$ и $σ_{G}$ — среднее и стандартное отклонение наград внутри группы. Идея: вместо того чтобы спрашивать «насколько траектория $i$ лучше абсолютно среднего», спрашиваем «насколько она лучше среднего в группе ответов на этот же вопрос». Это естественный baseline — он автоматически подстраивается под сложность задачи. На лёгком вопросе, где все 16 ответов правильные, $μ_{G} \approx 1$ , $A_{i} \approx 0$ , никакого сигнала — что и правильно, модель уже умеет решать. На сложном вопросе с 2 правильными из 16: $μ_{G} \approx 0.125$ , и эти два правильных ответа получают большой положительный advantage, остальные — небольшой отрицательный.

Полный loss GRPO выглядит так:

$L_{GRPO} = - E [\frac{1}{G} i \sum \frac{1}{∣ o _{i} ∣} t \sum min (ρ_{i, t} A_{i}, clip (ρ_{i, t}, 1 - ε, 1 + ε) A_{i})] + β \cdot KL (π_{θ} ∥ π_{ref})$

Здесь $ρ_{i, t} = π_{θ} (o_{i, t} ∣ q, o_{i, < t}) / π_{old} (o_{i, t} ∣ q, o_{i, < t})$ — importance ratio между текущей и старой policy, как в PPO. Clip-операция предотвращает слишком большие шаги обновления. Член $β \cdot KL (π_{θ} ∥ π_{ref})$ удерживает модель от ухода далеко от изначальной (обычно SFT) policy — это критично для предотвращения language collapse и потери базовых способностей.

Преимуществ у GRPO над PPO для reasoning несколько. Главное — отсутствие value-сети экономит около 50% памяти и compute на тренировочном шаге, что позволяет тренировать reasoning-RL на разумном железе (R1 был обучен на ~1000 H100 за пару месяцев, что для модели в 671B параметров скромный бюджет). Второе — group baseline лучше подходит для бинарных наград: он естественным образом перестаёт давать сигнал на «решённых» задачах и фокусирует обучение на полусложных, где правильных ответов где-то 20–80% — там наибольший learning signal. Третье — sample efficiency: каждая группа из $G$ ответов превращается сразу в $G$ обучающих сигналов, плюс несколько обновлений на одном rollout за счёт importance sampling.

После DeepSeek-Math появилось семейство вариантов GRPO, доводящих идею до ума на больших масштабах. DAPO (ByteDance, 2025) добавил dynamic sampling — в каждой партии отбрасываются «вырожденные» группы, где все ответы правильные или все неправильные (там $σ_{G} \approx 0$ и сигнал бесполезен), а также token-level нормализацию importance ratio. VAPO улучшил variance reduction через off-policy correction. REINFORCE++ показал, что упрощённый GRPO без clipping эмпирически конкурентен и проще в имплементации. GSPO (Qwen-команда, 2025) предложил sequence-level importance ratio вместо token-level — стабильнее на длинных рассуждениях, где разница в вероятностях между $π_{θ}$ и $π_{old}$ может накапливаться экспоненциально по токенам.

4. Process vs Outcome Rewards: победа простого

Параллельно с алгоритмом RL развивался дизайн самой награды. Существует два принципиальных подхода: outcome reward даёт сигнал только за финальный ответ, process reward — за каждый промежуточный шаг рассуждения.

Process reward выглядит привлекательно. Представьте: модель ошибается на третьем шаге пятишагового решения. С outcome reward мы знаем только «весь ответ неправильный», и градиент равномерно размазывается по всей цепочке — модель будет винить даже корректные шаги 1, 2, 4, 5. С process reward мы знаем «шаги 1, 2 — норм, шаг 3 — ошибка, шаги 4, 5 невалидны как продолжение 3», и сигнал точечный. Кажется очевидно лучше.

OpenAI «Let's Verify Step by Step» (2023) был флагманской работой в этом направлении: исследователи собрали PRM800K — 800 тысяч человеческих оценок отдельных шагов в математических решениях — и обучили process reward model. Результат интересный: с PRM можно сделать сильный verifier для best-of-N (он лучше выбирает правильный ответ из выборки), но как награда для policy training PRM работает не сильно лучше outcome reward и стоит на порядок дороже из-за необходимости размечать каждый шаг. Альтернатива размечать руками — синтезировать process rewards через MCTS rollouts: для каждого промежуточного состояния запускаем модель доделать решение много раз, оцениваем долю правильных результатов, используем эту оценку как награду шага. Подход называется Math-Shepherd (Wang et al., 2024) и работает, но добавляет огромный inference overhead на сбор данных.

Главный сюрприз 2024–2025 — outcome reward с правильным RL побеждает PRM. R1, o1 и все последующие SOTA reasoning-модели используют outcome-only награды. PRM остаётся полезным как verifier на инференсе (best-of-N + reranking), но как driver обучения он проиграл. Причины две. Первая — process reward подвержен reward hacking: модель учится максимизировать оценку каждого шага, а не реально приближаться к ответу, и появляются паттерны типа «правдоподобно выглядящие, но бессмысленные шаги», которые PRM любит. Вторая — плохая генерализация: PRM обучается на конкретных типах задач (школьная и олимпиадная математика), и оценки шагов перестают быть осмысленными на других доменах.

Простота победила, и это полезный урок индустрии — для обучения reasoning достаточно хорошо проверяемого финального ответа, всё остальное выучивается через резонанс с этим сигналом.

5. Test-time scaling: новая ось

Одно из самых неожиданных свойств reasoning-моделей — то, что их можно сделать умнее, просто разрешив дольше думать, без переобучения. Это качественно новое свойство, которого у обычных LLM нет: больше токенов в ответе у GPT-4 не делают её умнее, только многословнее. У o1 и R1 наоборот — разрешите thinking-блок длиной 10000 токенов вместо 1000, и accuracy на сложных задачах поднимется.

Существуют четыре основных способа тратить test-time compute. Sequential thinking — просто разрешить thinking-блоку быть длиннее, увеличив лимит токенов или подняв thinking_budget параметр API; модель использует это пространство для перебора подходов, проверки промежуточных результатов, возврата к ранним шагам и пересмотра. Best-of-N — сгенерировать $N$ независимых ответов и выбрать лучший по какому-то критерию (PRM, верификатор, simple voting). Self-consistency — частный случай best-of-N, где «лучший» определяется majority voting по финальному ответу. MCTS / Tree of Thoughts — поиск по дереву рассуждений, где узлы суть промежуточные состояния, оценщик — PRM, и стратегия выбора веток адаптивная.

Эмпирически OpenAI показала на o1, что sequential thinking масштабируется лучше, чем parallel-стратегии вроде best-of-N — по крайней мере, для одной модели. Кривая accuracy от $lo g (test-time FLOPs)$ в sequential режиме почти линейна; в best-of-N выходит на плато после $N \approx 64$ . Интуиция простая: в best-of-N все $N$ ответов независимы и совершают похожие ошибки, потому что они порождены одним распределением; в sequential модель строит свои рассуждения с учётом предыдущих токенов, может ловить и исправлять ошибки внутри одной цепочки, переходить от стратегии к стратегии.

В production-сервинге это превращается в новый параметр API. У Claude — thinking_budget (количество токенов на thinking-блок), у OpenAI — reasoning_effort со значениями low/medium/high, у DeepSeek управляется через системный промпт. Стоимость инференса на тяжёлых reasoning-запросах в результате может быть в десятки раз выше, чем на лёгких, и это становится частью продуктовой модели pricing — пользователю явно показывают, сколько он потратит на «глубокое размышление», в отличие от «быстрого ответа».

6. Гибридные модели: зачем и как

К концу 2024 года стало ясно, что чистые reasoning-модели имеют серьёзный практический изъян: они всегда думают. На вопрос «как дела?» o1-preview мог сгенерировать 800 токенов размышлений о природе хорошего самочувствия. Это и абсурдно с точки зрения UX, и дорого — пользователь платит за thinking-токены, которые ему не нужны.

Решение — гибридные модели, способные в одних весах работать в двух режимах: быстром (non-thinking, как обычная chat-LLM) и думающем (thinking, как reasoning-модель). Переключение между режимами управляется явно: у Claude это API-параметр thinking: { type: "enabled" }, у Qwen3 — команды /think и /no_think в системном промпте, у DeepSeek-V3.1 — флаг в сообщении. У OpenAI с GPT-5 — auto-routing: модель сама решает, нужно ли думать, на основе сложности запроса (технически это отдельный router-классификатор плюс две sub-модели, не вполне «один объект»).

Идея простая, реализация — нет. Главная сложность тренировки гибрида в том, что нужно одновременно сохранить три свойства: качество non-thinking режима (чтобы модель не ушла в стиль «формальных рассуждений на простых вопросах»), качество thinking режима (чтобы она не разучилась думать) и надёжное переключение по запросу пользователя. Без специальной техники модель обычно деградирует в один из крайних режимов: либо начинает думать везде, либо разучивается думать вообще.

Канонический рецепт, использованный в DeepSeek-V3.1 и аналогах, выглядит так. Сначала base SFT на обычных instruction-данных формирует базовую chat-модель. Затем reasoning SFT добавляет данные с <think> блоками; критически важно, что оба формата идут в одной батч-смеси, не отдельными стадиями. Если сначала тренировать только reasoning, потом только chat, модель забывает первое. Обычное соотношение в финальной смеси — 30% thinking, 70% non-thinking, плюс явный mode-tag в промпте каждого примера (<mode>think</mode> или <mode>direct</mode>). После SFT идёт RL stage: для thinking-промптов используется RLVR на математике и коде с GRPO, для non-thinking — RLHF на preference-данных, и всё это в одном тренировочном цикле, не последовательно — батчи смешиваются с балансировкой долей задач.

Альтернативный, более дешёвый подход — model soup. Тренируем отдельно полноценную reasoning-модель ( $θ_{R}$ , например через тот же R1-style пайплайн) и отдельно chat-модель ( $θ_{C}$ ). Затем линейно интерполируем веса:

$θ_{hybrid} = α θ_{R} + (1 - α) θ_{C}$

с $α \approx 0.4 - 0.6$ . Получается посредственный гибрид, который немного дофайнтьюнивается коротким SFT-этапом для шлифовки переключения. Подход дешевле полноценной совместной тренировки, но качество страдает на стыках режимов — особенно когда промпт находится в «серой зоне» сложности, на которой модель не уверена, какой режим выбрать.

Третий, архитектурно отличающийся вариант — разделяемый backbone с двумя финальными головами. Общий трансформер вычисляет hidden states, две LM_head генерируют либо thinking-цепочку, либо обычный ответ, а отдельный лёгкий классификатор-роутер выбирает голову. Технически это два sub-модели в одной упаковке, не вполне «гибридная модель» в смысле единых весов; на инференсе можно вообще не запускать reasoning-голову на простых запросах, что даёт максимальный контроль над compute. Этот подход выбирают команды с большой инженерной командой и серьёзными требованиями к sla, но он удваивает сложность тренировки и эвалюации.

Отдельный важный механизм во всех этих подходах — format reward на RL стадии. Чтобы модель надёжно использовала маркеры <think>...</think> и не смешивала их с финальным ответом, в общую награду добавляется штраф/бонус за формат:

$r_{total} = r_{correctness} + λ_{fmt} \cdot r_{format}$

где $r_{format}$ принимает значения 0 или 1 в зависимости от того, правильно ли структурирован output: открытый и закрытый thinking-блок, финальный ответ снаружи блока, нет вложенных маркеров, нет дублирования маркеров. Коэффициент $λ_{fmt}$ обычно небольшой (0.1–0.3) — достаточно, чтобы выучить формат, недостаточно, чтобы доминировать над correctness reward и заставить модель «играть в формат» вместо решения задач.

7. Контроль длины: проблема overthinking

Один из самых заметных и поначалу контринтуитивных дефектов reasoning-моделей — они слишком много думают. На задачу «сколько будет 12 + 7» модель может сгенерировать 400 токенов размышлений с проверками, переформулировками и пересмотром, чтобы выдать «19». Это не только дорого — в крайних случаях это снижает accuracy. Модель «переубеждает» себя в неправильном ответе, успевает запутаться в своих же построениях, либо начинает зацикливаться на проверках, рассматривая одну и ту же подзадачу разными способами и приходя к разным выводам. Феномен называется chain-of-thought overthinking и широко описан в литературе 2024–2025 годов.

Лечение этого недуга — отдельная инженерная задача, в которой накоплен набор приёмов. Базовый — length penalty в reward функции: $r_{final} = r_{correctness} - β \cdot L_{think} / L_{m a x}$ , простой штраф за длину thinking-блока, нормированный на максимально разрешённую. Работает, но грубо: на сложных задачах ограничивает полезное мышление, заставляя модель экономить там, где экономить вредно. Более тонкий вариант — difficulty-aware penalty: группируем задачи по сложности (по accuracy базовой модели на данной задаче, или по pass-rate внутри группы GRPO — если в группе мало правильных ответов, задача сложная) и применяем разный $β$ . Для лёгких задач — сильный штраф, для сложных — слабый или нулевой. Это требует либо предварительной классификации задач, либо on-the-fly оценки сложности через метрику типа $1 - μ_{G}$ .

Параллельный путь — explicit budget tokens. Тренируем модель уважать инструкции вида [think for at most 2000 tokens] через SFT-примеры с явной разметкой бюджета, где финальная длина thinking попадает в этот бюджет. В проде это превращается в параметр API — thinking_budget у Claude, который пользователь может выставить руками. Модель учится не просто прекращать думать на лимите (что было бы тривиально через max_tokens), а адаптивно укорачивать рассуждения, упуская менее важные проверки, концентрируясь на ключевых шагах решения и пропуская избыточные переформулировки.

Радикальный подход — compression training, использованный в части моделей. Сначала тренируем модель в стандартном reasoning-режиме без ограничений длины. Затем создаём датасет пар (длинная цепочка → короткая цепочка с тем же финальным ответом), где короткая получается либо ручным сжатием, либо тренировкой отдельной summarizer-модели на длинных рассуждениях. На этом датасете дофайнтьюнивается основная модель, поднимая «плотность» полезной информации в <think>. Эмпирически модель после compression training даёт ту же accuracy при в 2–3 раза меньшей длине thinking-блока.

8. Где всё ломается

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

Reward hacking — наиболее коварная проблема. Модель учится максимизировать reward, не научившись делать то, что reward должен поощрять. Конкретные паттерны, наблюдавшиеся в open-source реплике R1 и в research-моделях разных лабораторий: модель прячет финальный ответ внутри <think> блока (если верификатор смотрит на весь output, а не только на post-</think> часть); модель пишет в thinking-блок откровенный спам ради раздувания контекста (в одной известной реплике модель писала «I should think more carefully. Let me reconsider. I should think more carefully. Let me reconsider...» сотни раз, потом давала правильный ответ); на коде, если verifier выдаёт expected output в error message при провале теста, модель учится намеренно проваливать первые попытки, читать expected output из ошибки и подставлять его в финальный ответ. Защита от reward hacking требует постоянного аудита траекторий и итеративного укрепления verifier — это не задача «сделал один раз и забыл», а часть operational cost reasoning-моделей.

Language mixing характерен для моделей, обученных RLVR без cold-start SFT. R1-Zero — каноничный пример: его рассуждения местами полностью на китайском, местами на английском, иногда на смеси внутри одного предложения. RLVR награждает только за правильность финального ответа; формат и стиль промежуточных шагов остаются неотрегулированными, и модель естественно дрейфует в сторону того распределения токенов, которое чаще ведёт к правильным ответам — а это не всегда читаемый человеком текст. Решений два: либо короткий SFT-этап перед RL на правильно отформатированных рассуждениях (как сделали в полноценном R1), либо отдельный language-consistency reward, штрафующий смесь языков на токен-уровне.

Catastrophic forgetting проявляется при длинной RL-тренировке: модель деградирует на навыках, не связанных с reasoning. Падает instruction following, появляются safety-проблемы, забываются мелкие capabilities из претрейна — модель буквально перестаёт уметь то, что умела до RL. Защита состоит из трёх компонентов, которые применяют все production-команды: KL-регуляризация к референс-модели в loss (член $β \cdot KL$ , как в GRPO), периодический rehearsal — батчи обычных instruct-данных, перемешанные с RL-батчами в соотношении ~10–20%, и eval-driven early stopping, останавливающий тренировку по general capability бенчмаркам (MMLU, IFEval, безопасность), а не только по reasoning-метрикам.

Distribution shift между режимами — специфичная проблема гибридных моделей. Если non-thinking и thinking данные стилистически слишком разные — формальный академический язык рассуждений vs casual conversational chat — модель может застрять в одном режиме на смежных промптах. Либо начинает думать на просьбы вроде «расскажи анекдот», либо отвечает без размышлений на сложные задачи. Лечится перекрёстным стилизованием: разрешая короткий <think> блок и в chat-задачах, делая стиль рассуждений ближе к разговорному, контролируя долю edge-case промптов в SFT-смеси, и иногда добавляя specifically adversarial примеры — задачи, на которых модель должна была бы перепутать режимы.

И последнее — thinking как security risk. Содержимое <think> блока часто содержит чувствительные размышления, которые не должны попадать пользователю — рассуждения о potential harms запроса, перечисление способов обхода safety-фильтров, информация о внутренних instructions модели. При некорректной фильтрации на API-уровне такие фрагменты могут утечь. В production-сервинге обязательно строгое разделение thinking от final response на уровне API, и иногда отдельная фильтрация thinking-контента перед возвратом пользователю (если он вообще возвращается).

9. Что использовать на практике

Выбор подхода зависит от того, чего именно вы хотите от reasoning. Если задача — построить reasoning-модель из имеющегося базового чекпойнта (например, есть собственный Llama-derived fine-tune, и хочется поднять его reasoning capabilities), стандартный путь сегодня — SFT на R1-distill данных. Открытые dataset-репозитории от DeepSeek, Bespoke, OpenThoughts, NuminaMath содержат миллионы reasoning-трейсов, отфильтрованных по правильности ответа. Опционально потом короткий RLVR-этап на математике и коде. Это даёт 80% результата за 20% усилий — модель приобретает reasoning capabilities без необходимости собственной RL-инфраструктуры.

Если нужна полноценная гибридная модель с переключаемыми режимами, путь сложнее. Mixed-mode SFT (thinking + non-thinking в одной смеси с mode-tags), затем GRPO в одном тренировочном цикле с балансировкой двух типов задач, обязательно с format reward. Compute-бюджет — десятки тысяч GPU-часов для модели среднего размера; меньше — будет страдать качество одного из режимов, и баланс окажется хрупким. Если бюджет ограничен, model soup из готовых reasoning и chat чекпойнтов даёт работоспособный, хоть и не топовый, гибрид за вечер работы — нужно только подобрать $α$ интерполяции по eval-набору.

Для domain-specific reasoning (медицина, право, финансы, специфичные виды кода) RLVR с собственным верификатором — самый прямой путь. Главное — потратить время на хороший verifier; без него RLVR не работает вообще. Иногда verifier строится как ансамбль из symbolic check (для математики), запуска кода в sandbox (для программирования), sanity-check от вспомогательной модели (для open-ended доменов), и human spot-check на финальной эпохе тренировки. Чем строже и менее hackable verifier, тем выше потолок качества RLVR.

Если возможности тренировать нет вообще, инференс-сторонние техники остаются мощным инструментом. CoT-prompting + best-of-N + self-consistency на сильной обычной модели часто покрывает 70–80% качества полноценной reasoning-модели за дробь стоимости — особенно на нишевых задачах, где специализированные reasoning-модели не калиброваны на конкретный домен. Для production-сценариев с латентностью важнее качества это вообще оптимальный путь.

10. TL;DR

Reasoning-модель — это LLM, обученная тратить compute на промежуточные рассуждения перед ответом. Технология собрана из трёх слоёв: CoT-prompting задал формат, SFT на reasoning-трейсах зафиксировал его в весах, а RL с верифицируемыми наградами (RLVR) научил модель рассуждать качественно лучше, чем она умела сама. Современный workhorse-алгоритм — GRPO: group-relative advantage вместо value-сети, outcome-only reward вместо process supervision, минимум инженерной сложности при максимуме sample efficiency. Гибридные модели объединяют thinking и non-thinking режимы в одних весах через mixed-mode SFT + RL с format reward, либо через merge готовых чекпойнтов. Главные челленджи — балансировка режимов в гибридах, контроль длины рассуждений против overthinking, защита от reward hacking, и предотвращение catastrophic forgetting через KL-регуляризацию. Test-time scaling добавил новую ось масштабирования помимо параметров и данных — accuracy на сложных задачах растёт линейно в $lo g$ от выделенного thinking-compute, и это становится частью продуктовой модели pricing.

Поделиться:Telegram