Recursion of Thought

Рекурсивный reasoning через изолированные подконтексты: сложная задача дробится на подзадачи, а их ответы возвращаются в родительский контур.

Recursion of Thought (RoT, «рекурсия мысли») — техника, в которой модель разбивает сложную задачу на подзадачи, решает каждую в отдельном контексте, а затем возвращает результат обратно в родительский контекст. Вместо линейной цепочки рассуждений создаётся стек вызовов, как в рекурсивной программе: отдельный вход в подзадачу, отдельный возврат результата и дальнейшая сборка.

В 2026 году RoT уже разумнее трактовать как orchestration pattern для context management, а не как просто необычный prompt format. Его сильная сторона не только в декомпозиции, а в том, что каждая подзадача получает чистый рабочий контекст и не тянет за собой весь шум родительской трассы.

Представьте матрёшку задач. Вы открываете большую матрёшку и видите внутри задачу поменьше. Решаете её — записываете ответ на бумажке и кладёте обратно в большую матрёшку. Теперь большая задача знает результат маленькой и может продолжить. Если маленькая задача тоже оказалась сложной — внутри неё ещё одна матрёшка. Это и есть рекурсия: каждая подзадача решается отдельно, а ответ «всплывает» наверх. В программировании это называется «стек вызовов» — RoT переносит эту идею на рассуждения языковых моделей.

Суть техники

Обычный Chain of Thought (CoT) строит рассуждение линейно: шаг за шагом в одном контексте. Если задача требует 20 шагов — все 20 шагов должны поместиться в контекстное окно, а модель должна удерживать логику от начала до конца. На длинных цепочках это приводит к потере фокуса и ошибкам.

Recursion of Thought решает проблему иначе: модель рекурсивно делит задачу на части. Встретив сложный подвопрос, она генерирует токен GO — сигнал «открой новый контекст и реши эту подзадачу отдельно». Когда подзадача решена, модель генерирует токен RETURN с результатом — и этот результат подставляется в родительский контекст как готовый факт. Родительский контекст продолжает работу, не зная деталей решения подзадачи — только её ответ.

Линейный CoT
Шаг 1 → Шаг 2 → ... → Шаг 15 → Шаг 16 Все шаги в одном контексте Если задача длинная — контекст переполняется Ошибка на шаге 5 влияет на все последующие Модель теряет фокус к шагу 12-15
Рекурсивный RoT
Задача → GO(подзадача A) → RETURN(ответ A) → GO(подзадача B) → RETURN(ответ B) Подзадача A → GO(подзадача A1) → RETURN(ответ A1) Каждая подзадача решается в чистом контексте Родительский контекст видит только итоговые ответы

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

RoT особенно полезен, когда задача естественно разбивается на вложенные подзадачи: многошаговая математика (вычислить часть → подставить в формулу), анализ длинных документов (разобрать каждый раздел → синтезировать), сложные логические задачи с зависимостями между шагами. Если задача решается за 3-5 линейных шагов — обычный CoT справится лучше.

Как работает Recursion of Thought

Механизм GO и RETURN

В оригинальной статье (Lee et al., 2023) модель дообучается на специальных токенах GO и RETURN. Когда модель «понимает», что текущая подзадача требует отдельного решения, она генерирует <GO> — это сигнал оркестратору запустить новый контекст. Результат из нового контекста возвращается через <RETURN result> и вставляется в исходный контекст на место вызова.

На практике при работе с промптингом (без дообучения) мы эмулируем этот механизм через multi-turn взаимодействие или явные инструкции модели.

Пошаговый алгоритм

Примеры применения

Многошаговая математика

ПромптClaude
Задача: В магазине 3 отдела. В первом 120 товаров, во втором — на 35% больше, в третьем — в 2 раза меньше, чем сумма первых двух. Какова средняя цена товара, если общая выручка 4 500 000 рублей?

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

Формат:
- [GO подзадача]: формулировка
- [РЕШЕНИЕ]: ход решения
- [RETURN]: только ответ

После всех RETURN — финальный ответ.
Ответ модели

[GO подзадача 1]: Сколько товаров во втором отделе, если в первом 120, а во втором на 35% больше? [РЕШЕНИЕ]: 120 × 1.35 = 162 [RETURN]: 162 товара

[GO подзадача 2]: Сколько товаров в третьем отделе, если это в 2 раза меньше суммы первых двух (120 + 162 = 282)? [РЕШЕНИЕ]: 282 ÷ 2 = 141 [RETURN]: 141 товар

[GO подзадача 3]: Какова средняя цена, если общая выручка 4 500 000 руб., а всего товаров 120 + 162 + 141 = 423? [РЕШЕНИЕ]: 4 500 000 ÷ 423 ≈ 10 638.30 [RETURN]: ≈ 10 638 руб.

Финальный ответ: средняя цена товара составляет примерно 10 638 рублей.

Анализ длинного текста

ПромптChatGPT
У тебя есть длинный контракт из 5 разделов. Проанализируй каждый раздел рекурсивно.

Метод: Recursion of Thought.
- Каждый раздел — отдельная подзадача (GO)
- Извлеки ключевые обязательства и риски (РЕШЕНИЕ)
- Верни краткое резюме раздела (RETURN)
- В конце — общий анализ из всех RETURN

Раздел 1: Поставщик обязуется поставить оборудование в течение 90 дней. Штраф за просрочку — 0.1% от суммы за каждый день, но не более 10%.
Раздел 2: Покупатель оплачивает 30% аванс, 50% при поставке, 20% после пусконаладки.
Раздел 3: Гарантийный срок — 24 месяца с момента пусконаладки. Поставщик устраняет дефекты за свой счёт в течение 14 дней.
Раздел 4: Форс-мажор: стихийные бедствия, военные действия, санкции. Уведомление — 5 дней.
Раздел 5: Споры решаются в арбитражном суде г. Москвы. Применимое право — РФ.
Ответ модели

[GO Раздел 1 — Сроки и штрафы] [РЕШЕНИЕ]: Срок 90 дней. Штраф 0.1%/день, макс. 10%. При сумме контракта 10 млн руб. максимальный штраф = 1 млн руб. Потолок штрафа фиксирован — риск ограничен. [RETURN]: Поставка 90 дней, штраф до 10% от суммы. Риск: потолок штрафа может не покрыть реальные убытки при длительной просрочке.

[GO Раздел 2 — Оплата] [РЕШЕНИЕ]: 30-50-20 схема. Аванс 30% — стандарт. 50% при поставке — покупатель платит до проверки работоспособности. 20% удержание до пусконаладки — мотивация поставщика. [RETURN]: Схема 30-50-20. Риск покупателя: 80% оплачено до проверки качества. Рычаг: 20% удержание.

[GO Раздел 3 — Гарантия] [РЕШЕНИЕ]: 24 месяца — хорошо для покупателя. 14 дней на устранение — жёсткий срок. Нет уточнения: что если дефект критический и 14 дней — слишком долго? [RETURN]: Гарантия 24 мес., устранение 14 дней. Риск: нет SLA по критичности дефектов.

[GO Раздел 4 — Форс-мажор] [РЕШЕНИЕ]: Перечень стандартный. Санкции включены — актуально. Уведомление 5 дней — разумно. Нет указания максимального срока форс-мажора, после которого контракт расторгается. [RETURN]: Форс-мажор стандартный + санкции. Риск: нет предельного срока форс-мажора.

[GO Раздел 5 — Споры] [РЕШЕНИЕ]: Арбитражный суд Москвы, право РФ — стандарт для российских контрактов. [RETURN]: Юрисдикция РФ, суд Москвы. Рисков нет.

Общий анализ (сборка из RETURN):

  1. Основные риски покупателя: 80% оплаты до подтверждения качества, потолок штрафа может не покрыть убытки
  2. Основные риски поставщика: жёсткий срок устранения дефектов (14 дней), нет градации по критичности
  3. Рекомендации: добавить SLA по критичности дефектов, установить предельный срок форс-мажора (90-180 дней), рассмотреть банковскую гарантию на аванс

Сравнение с другими техниками декомпозиции

Глубина вложенности подзадач (макс. уровней)
CoT1%
Least-to-Most2%
Decomposed Prompting2%
RoT5%
ХарактеристикаCoTLeast-to-MostDecomposed PromptingRoT
Изоляция контекстовНетЧастичнаяДа (специализированные обработчики)Да (чистый контекст на каждую подзадачу)
Рекурсивная вложенностьНетНетНетДа — подзадача порождает подподзадачи
Управление глубинойНетЛинейная последовательностьФиксированнаяДинамическая (стек вызовов)
Контекстное окноВсё в одномНакопление в одномРаспределеноРаспределено по уровням стека
Сложность оркестрацииНетНизкаяСредняяВысокая (стек + маршрутизация)
ПромптClaude
Задача: Рассчитай NPV инвестиционного проекта.
Данные: инвестиция 5 млн руб., ставка дисконтирования 12%, денежные потоки за 4 года: 1.2, 1.8, 2.1, 2.5 млн руб.

Метод: Recursion of Thought.
Каждый дисконтированный поток — отдельная подзадача [GO].
В конце собери NPV из всех [RETURN].
Ответ модели

[GO CF1]: Дисконтированный поток года 1: 1 200 000 / (1 + 0.12)^1 [РЕШЕНИЕ]: 1 200 000 / 1.12 = 1 071 428.57 [RETURN]: 1 071 429 руб.

[GO CF2]: Дисконтированный поток года 2: 1 800 000 / (1 + 0.12)^2 [РЕШЕНИЕ]: 1 800 000 / 1.2544 = 1 435 153.58 [RETURN]: 1 435 154 руб.

[GO CF3]: Дисконтированный поток года 3: 2 100 000 / (1 + 0.12)^3 [РЕШЕНИЕ]: 2 100 000 / 1.404928 = 1 494 726.07 [RETURN]: 1 494 726 руб.

[GO CF4]: Дисконтированный поток года 4: 2 500 000 / (1 + 0.12)^4 [РЕШЕНИЕ]: 2 500 000 / 1.57351936 = 1 588 635.68 [RETURN]: 1 588 636 руб.

[СБОРКА]: NPV = -5 000 000 + 1 071 429 + 1 435 154 + 1 494 726 + 1 588 636 NPV = 589 945 руб.

NPV положительный (≈590 тыс. руб.) — проект окупается при ставке 12%.

Без ограничений модель может уходить в слишком глубокую рекурсию, декомпозируя тривиальные подзадачи. Установите максимальную глубину (обычно 3-4 уровня) и укажите в промпте: «Если подзадача решается за один шаг — решай сразу, без GO». Это аналог базового случая (base case) в рекурсивном программировании.

Как понимать Recursion of Thought в 2026

Если смотреть на современный стек, RoT стоит рядом с:

  • hierarchical agents
  • planner-worker workflows
  • context compaction и step isolation
  • tool-based decomposition

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

Где техника реально полезна

RoT оправдан, когда:

  • подзадачи естественно вложены друг в друга
  • решение одной ветки не должно засорять остальные
  • длинная трасса иначе начинает съедать контекстное окно
  • результат подзадачи можно безопасно свести к компактному return-value

Такие сценарии часто встречаются в document analysis, long-form synthesis, legal review, financial modelling, hierarchical planning и multi-stage agents.

Где RoT не нужен

У техники есть и типичные anti-patterns:

  • рекурсивная декомпозиция ради самой декомпозиции
  • слишком мелкие подзадачи, где overhead выше пользы
  • ситуации, где нужен не новый контекст, а просто лучшее структурирование текущего

Хорошее практическое правило: если подзадача не выигрывает от изоляции контекста, нет смысла открывать для неё отдельный frame. В этом случае проще использовать обычный decomposition workflow без рекурсивной оркестрации.

Реализация через multi-turn API

В отличие от техник, работающих в одном промпте, RoT естественно ложится на multi-turn взаимодействие. Каждая GO-операция — это новый вызов API с чистым контекстом, а RETURN — это передача результата обратно в родительский вызов.

Управление стеком контекстов

from openai import OpenAI
from dataclasses import dataclass, field

client = OpenAI()


@dataclass
class RotFrame:
    """Фрейм стека рекурсии — один уровень задачи."""
    task: str
    depth: int
    result: str | None = None
    subtask_results: dict[str, str] = field(default_factory=dict)


ROT_SYSTEM = """Ты решаешь задачи методом Recursion of Thought.

Если задача сложная — разбей её на подзадачи. Формат:
[GO подзадача_id]: формулировка подзадачи

Если задача простая (решается за 1-2 шага) — реши напрямую.

Когда все подзадачи решены, собери финальный ответ из их результатов.

Правила:
- Каждая подзадача должна быть самодостаточной
- Не включай в подзадачу лишний контекст из родительской задачи
- Подзадач не более 5 за один вызов
- Если получены результаты подзадач — используй их как факты"""


def solve_rot(
    task: str,
    model: str = "gpt-4o",
    max_depth: int = 3,
    depth: int = 0,
) -> str:
    """Рекурсивно решает задачу через RoT."""
    if depth >= max_depth:
        # Базовый случай — решаем напрямую
        resp = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": "Реши задачу напрямую, без декомпозиции."},
                {"role": "user", "content": task},
            ],
            temperature=0.3,
        )
        return resp.choices[0].message.content

    # Шаг 1: попросить модель декомпозировать или решить
    resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": ROT_SYSTEM},
            {"role": "user", "content": task},
        ],
        temperature=0.3,
    )
    answer = resp.choices[0].message.content

    # Шаг 2: извлечь подзадачи [GO ...]
    import re
    subtasks = re.findall(
        r"\[GO\s+(\w+)\]:\s*(.+?)(?=\[GO|\Z)",
        answer,
        re.DOTALL,
    )

    if not subtasks:
        # Модель решила задачу напрямую
        return answer

    # Шаг 3: рекурсивно решить каждую подзадачу
    results = {}
    for sub_id, sub_task in subtasks:
        results[sub_id] = solve_rot(
            sub_task.strip(),
            model=model,
            max_depth=max_depth,
            depth=depth + 1,
        )

    # Шаг 4: собрать результаты и попросить финальный ответ
    return_context = "\n".join(
        f"[RETURN {sid}]: {res}" for sid, res in results.items()
    )

    resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": ROT_SYSTEM},
            {
                "role": "user",
                "content": (
                    f"Исходная задача: {task}\n\n"
                    f"Результаты подзадач:\n{return_context}\n\n"
                    "Собери финальный ответ из результатов подзадач."
                ),
            },
        ],
        temperature=0.3,
    )
    return resp.choices[0].message.content


# Пример
result = solve_rot(
    "Сравни TCO (total cost of ownership) за 3 года: "
    "вариант A — собственный GPU-кластер (8×A100, аренда стойки), "
    "вариант B — OpenAI API (500K запросов/день, GPT-4o). "
    "Учти: железо, электричество, персонал, API-стоимость, масштабирование.",
    max_depth=3,
)
print(result)

Преимущества и ограничения

Плюсы

  • Преодолевает ограничения контекстного окна — каждая подзадача работает в чистом контексте
  • Изоляция ошибок: сбой в подзадаче не отравляет весь ход рассуждения
  • Естественно ложится на multi-turn API — каждый GO это отдельный вызов
  • Модульность: подзадачи можно решать разными моделями (дешёвая для простых, мощная для сложных)
  • Масштабируемость: глубина рекурсии адаптируется к сложности задачи

Минусы

  • Больше API-вызовов и задержка — каждая подзадача требует отдельного запроса
  • Оркестрация сложнее, чем для линейных техник — нужен код управления стеком
  • Оригинальный RoT требует дообучения (GO/RETURN токены) — промптинг лишь эмулирует
  • Риск избыточной декомпозиции: модель может дробить тривиальные задачи
  • Потеря глобального контекста: подзадача не видит «общую картину» родительской задачи
Используйте маршрутизацию моделей по глубине рекурсии. Верхний уровень (декомпозиция и сборка) — мощная модель (GPT-4o, Claude Sonnet). Глубокие уровни (простые вычисления) — дешёвая модель (GPT-4o-mini, Haiku). Это может сократить стоимость на 40-60% без потери качества.

Связанные техники

  • Least-to-Most Prompting — линейная декомпозиция от простого к сложному, без рекурсивной вложенности
  • Decomposed Prompting — модульная декомпозиция со специализированными обработчиками для каждого типа подзадач
  • Chain of Thought — линейное пошаговое рассуждение в одном контексте
  • Program of Thoughts — генерация кода для вычислительных подзадач, хорошо сочетается с RoT
  • Branch-Solve-Merge — параллельная декомпозиция без вложенности, подходит для независимых подзадач

Проверьте себя

Проверьте себя

1. Что происходит при генерации токена GO в Recursion of Thought?

2. Чем RoT принципиально отличается от Least-to-Most Prompting?

3. Какой аналог из программирования лучше всего описывает механизм RoT?