Рекурсивные языковые модели (RLM) – парадигма 2026 года

Команда AI for Devs подготовила перевод большого исследовательского материала о рекурсивных языковых моделях (RLM). Авторы разбирают, почему простое увеличение контекстного окна больше не решает проблему долгоживущих агентов, и показывают альтернативу: обучение моделей активному управлению собственным контекстом через context folding и под-LLM. Статья основана на обширных экспериментах и даёт практический взгляд на то, каким может быть следующий шаг в развитии LLM-агентов.

---

Как мы планируем управлять чрезвычайно длинными контекстами

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

Эти возможности требуют использования огромного количества токенов.

Однако именно это и представляет проблему для современных LLM: стоимость обработки растёт линейно с длиной контекста, а качество работы даже у лучших моделей при этом падает. К настоящему моменту хорошо известен феномен context rot — деградация возможностей LLM по мере увеличения размера контекста. И хотя изменения в архитектуре и обучающих данных уже привели и будут продолжать приводить к значительному прогрессу в решении этих проблем, есть один подход, дополняющий оба направления и стабильно дающий кратный эффект для эффективной длины контекста LLM: scaffolding.

Claude Code, Codex от OpenAI и аналогичные TUI-системы обычно строят свой scaffolding на файловых системах и сжатии контекста за счёт LLM-суммаризации через регулярные интервалы. Фактически это приводит к цепочке агентов, связанных друг с другом промптом и состоянием некоторого набора файлов.

Другой подход к проблеме контекста — «сворачивание контекста» (context folding). Его цель — обеспечить непрерывное, нарастающее развертывание рассуждений, при этом управляя самим контекстным окном (а не внешними файлами), чтобы удерживать его коротким. Этот подход совместим с файловым scaffolding: LLM, использующая context folding, снаружи выглядит как обычная LLM, и потому может служить дополнительным способом борьбы с context rot и снижения затрат. Примеры:

• Scaling Long-Horizon LLM Agent via Context-Folding: агент может активно ветвить своё развертывание и возвращаться из ветки; внутри ветки он сохраняет полный предыдущий контекст, но после возврата в контекстном окне остаётся только выбранное самим агентом краткое резюме ветки.

• AgentFold: Long-Horizon Web Agents with Proactive Context Management: каждое действие агента порождает как результат, так и краткое описание действия и рассуждений, приведших к нему. Эти описания могут быть иерархическими — объединяя выводы из нескольких действий в одну точку — либо сохраняться отдельно для каждого действия.

• Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models: система из трёх агентов — Generator, который использует текущую базу знаний для построения развертывания; Reflector, который извлекает уроки и информацию о генерации и о текущем состоянии базы знаний; и Curator, который берёт выводы Reflector и структурированно обновляет базу знаний.

Однако мы в Prime Intellect считаем, что самым простым и гибким методом context folding является рекурсивная языковая модель (Recursive Language Model, RLM), предложенная Алексом Чжаном в октябре 2025 года в виде блог-поста и теперь оформленная как полноценная статья: https://arxiv.org/abs/2512.24601. Сейчас это одно из ключевых направлений наших исследований.

RLM позволяет модели активно управлять собственным контекстом. Этот подход гораздо ближе к The Bitter Lesson, чем описанные выше: он даёт возможность обучать модель напрямую вместе со scaffolding RLM и получать всё более эффективное, выученное управление контекстом; при этом модель вообще не суммирует контекст, а значит, не теряет информацию. Вместо этого она проактивно делегирует контекст Python-скриптам и вспомогательным LLM.

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

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

RLM

Вместо того чтобы напрямую загружать входные данные (потенциально очень большого объёма), RLM позволяет LLM использовать постоянный Python REPL для изучения и преобразования входных данных, а также вызывать под-LLM прямо из этого Python REPL.

Это даёт ряд полезных возможностей:

• Потенциально огромные входные данные — такие как PDF, датасеты или видео — не нужно напрямую загружать в контекст модели, что делает LLM более лёгкой и позволяет избежать context rot

• LLM может искать, фильтровать и преобразовывать контекст с помощью возможностей Python, избегая обработки избыточных данных

• Она может использовать под-LLM — новые экземпляры самой себя — для выполнения отдельных задач и программно передавать им части входных данных

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

Мы в Prime Intellect реализовали собственную версию RLM в verifiers, так что она готова к использованию в любой среде — кроме того, мы предоставляем несколько окружений на базе RLM в Environments Hub — а также для обучения с помощью prime-rl. Это всё ещё экспериментальная разработка в стадии активного развития, однако мы уже внесли в неё свои особенности.

Два наиболее важных изменения, которые нужно понимать для чтения остальной части статьи: (1) инструменты помимо Python REPL могут использоваться, но только под-LLM; и (2) модель может выдавать ответ только через переменную окружения. Подробности следующие:

• Вызовы под-LLM могут выполняться параллельно

  • В REPL модели доступна функция llm_batch, через которую она может обрабатывать батч промптов параллельно

• Под-LLM могут быть выданы инструменты

  • Более того, любые инструменты, которые вы передаёте окружению, будут доступны исключительно под-LLM

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

  • Как показано ниже, в наших тестах эта стратегия оказывается весьма успешной

• Можно устанавливать любые pip-пакеты

  • RLM знает, какие пакеты установлены

  • В math-python, например, были установлены numpy, scipy и sympy

  • Стандартная библиотека доступна всегда

  • Выполнение кода происходит в изолированных Sandboxes

• RLM всегда выдаёт ответ только в Python-переменной

  • Переменная ответа инициализируется в начале каждого Sandbox, в котором выполняется Python-код; это словарь с двумя ключами:

    • "content": LLM может записывать в него данные сколько угодно раз, а также удалять или редактировать содержимое на протяжении нескольких шагов

    • "ready": только когда это значение установлено в True, развертывание завершается, а ответ извлекается из "content"

  • В начале каждого развертывания: answer = {“content”: “”, ready: False}

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

В нашей текущей реализации можно передавать и промпт, и дополнительные входные данные. Промпт помещается напрямую в контекстное окно RLM, тогда как дополнительные данные доступны только программно. Единственный способ для RLM увидеть эти данные — вывести их в REPL. Однако, поскольку мы ограничиваем количество символов вывода REPL, которые показываются RLM на каждом шаге (по умолчанию до 8192, значение настраивается пользователем), RLM вынуждена использовать Python и под-LLM для работы с входными данными.

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

Экспериментальная конфигурация

Базовая схема всех наших экспериментов заключается в сравнении трёх вариантов scaffolding в рамках одного и того же окружения:

• Стандартная LLM со всеми инструментами, которые это окружение обычно предоставляет;

• RLM;

• RLM с подсказками, специфичными для окружения (они будут объяснены позже).

Это позволяет понять, как обычная LLM соотносится с RLM и с RLM, которая знает, как именно лучше использовать свой scaffolding в данном окружении. Мы сравниваем напрямую с LLM, потому что по своей сути RLM — это абстракция вокруг одного вызова LLM.

RLM ограничена тайм-аутом на один вызов REPL; если не указано иное, мы устанавливаем его в 120 секунд. Это помогает в случаях, когда RLM пишет неэффективный код, но одновременно ограничивает использование под-LLM.

Окружения

Мы выбрали следующие окружения:

• DeepDive

• math-python

• Oolong

• verbatim-copy

Мы проводим абляционные эксперименты с ними, используя настройки по умолчанию (которые были выбраны до начала экспериментов), а также отдельно варьируем настройки окружений для Oolong и verbatim-copy.

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

DeepDive

DeepDive — это метод сбора данных для задач Deep Research: он проходит по открытым графам знаний, формируя сложные вопросы и проверяемые ответы, а затем обфусцирует вопросы с помощью переформулирования через LLM. Для него существует репозиторий на GitHub и датасет на HuggingFace.

• Версия DeepDive, использованная в этих экспериментах

• deepdive-rlm на Environments Hub

Некоторые примеры:

Для решения подобных задач моделям доступны три инструмента:

• search(query: str); использует Google через Serper. Возвращает пронумерованный список результатов Google и соответствующие URL

• click(index: int); «клик» по одному из результатов предыдущего поиска по его индексу в списке

• open(url: str); открывает указанный URL

Именно эти три инструмента использовались в оригинальной статье. Однако open и click избыточны, причём open является более универсальным инструментом. Поскольку click требует, чтобы не только агент, но и сама функция имела доступ к результатам предыдущего поиска — что в текущей реализации RLM трудно обеспечить, — мы не предоставили инструмент click ни RLM, ни стандартному агенту.

Почему DeepDive?

DeepDive требует сильных навыков работы с инструментами. Его инструменты также генерируют большое количество токенов: open может возвращать десятки тысяч токенов (и это уже с усечением; без него мы наблюдали 1,5 миллиона токенов и больше). Кроме того, задачи часто включают множество последовательных вызовов инструментов. Таким образом, DeepDive проверяет, насколько эффективно модель с использованием RLM-обвязки может задействовать под-LLM с инструментами, насколько сильно это влияет на длину контекста основной RLM и какой ценой в терминах параллельных вызовов под-LLM это достигается.

Дополнительно, для RLM здесь не предусмотрены какие-либо дополнительные входные данные, поэтому это окружение проверяет способность RLM работать как обычная LLM — а именно так она и выглядит снаружи.

Подсказки окружения для DeepDive

	_ENV_TIPS = """
 
<env_tips>
Strategy for deep research tasks:
 
1. **Decompose the question**: Break the main question into multiple smaller, focused research sub-tasks that can be investigated independently.
 
2. **Parallel sub-LLM research**: Use `llm_batch()` to dispatch these sub-tasks in parallel. Each sub-LLM has access to web search tools (search, open) and can:
- Search for relevant information
- Open promising results to read full content
- Extract and summarize key facts
 
2. **Synthesize findings**: After collecting sub-LLM responses, combine and cross-reference their findings. Look for:
- Consistent facts across sources (high confidence)
- Contradictions that need resolution
- Gaps that require follow-up research
 
3. **Iterate if needed**: If the initial research reveals new questions or missing information, dispatch another batch of targeted sub-tasks. Repeat until you have sufficient evidence.
 
4. **Finalize**: Write your synthesized answer to `answer["content"]`, verify it addresses the original question, then set `answer["ready"] = True`.
 
Key insight: Sub-LLMs handle the verbose web content, returning concise summaries. This keeps your context clean while leveraging deep research.
</env_tips>"""

Настройки по умолчанию

Мы не проводим абляции настроек для DeepDive, то есть никаких специальных настроек по умолчанию для него не требуется.

math-python

math-python предлагает сложные математические задачи и предоставляет LLM Python-инструмент для их решения.

• Версия math-python, использованная в этих экспериментах

• math-env-rlm на Environments Hub

Примеры:

Почему math-python?

Python REPL очень похож на Python-инструмент, который доступен стандартной LLM. Однако между ними есть два принципиальных отличия:

• RLM располагает под-LLM и, следовательно, теоретически может разбивать задачу на подзадачи или поручать под-LLM проверку своей работы

• RLM приходится управлять гораздо более сложным scaffolding. Хотя модель может действовать просто, она должна уметь игнорировать значительную часть этой сложности

Подсказки окружения для math-python

_ENV_TIPS = """
 
<env_tips>
Use Python for calculations. The `sympy` library is available for symbolic math.
</env_tips>"""

Настройки по умолчанию

Как и в DeepDive, мы просто используем настройки окружения по умолчанию.

Oolong

Oolong — это бенчмарк для длинного контекста, у которого есть и страница на GitHub, и датасет на HuggingFace.

• Версия Oolong, использованная в этой статье

• oolong-rlm на Environments Hub

Датасет разделён на три части: synth, synth-with-labels и real:

• synth создаётся путём объединения нескольких существующих классификационных промптов в один большой промпт с последующей просьбой агрегировать некоторую величину

  • Например: взять датасет для классификации писем на «spam» и «no spam», поместить множество примеров в один промпт и попросить модель посчитать, сколько писем со спамом содержится в тексте

• synth-with-labels — это тот же synth, но для каждого подпрампта, из которых сформированы данные, заранее указана классификация (например, «spam» или «no spam»)

• real формируется на основе реальных игровых сессий D&D, которые были записаны, а затем из них была извлечена информация

  • Например: как часто было использовано заклинание xyz?

  • Например: когда произошло событие xyz?

И synth, и real включают множество операций классификации и извлечения данных внутри одного промпта, за которыми следует агрегация результатов. В synth-with-labels требуется только агрегация. Наиболее важным является поднабор real, поэтому именно его мы выбираем в качестве настройки по умолчанию.

Есть одно осложнение: для этих ранних оценок мы берём лишь 50 промптов, однако данные Oolong отсортированы по размеру, и выборка по порядку дала бы только короткие входные промпты. Поэтому мы равномерно случайным образом выбираем подмножество из 50 промптов для каждого из Oolong synth, synth-with-labels и real, используя один и тот же seed генератора случайных чисел для всех вариантов настроек, которые мы аблируем.

Почему Oolong?

Oolong — это сложный бенчмарк с длинным контекстом, с которым испытывают трудности многие модели; именно его использовали в оригинальном блог-посте про RLM. RLM особенно перспективна в этом сценарии, поскольку длинный контекст доступен ей только через Python REPL, где под-LLM могут помогать с классификацией отдельных частей контекста, а сама RLM агрегирует результаты. Поэтому Oolong хорошо подходит для проверки того, насколько эффективно работает разделение между промптом и дополнительными входными данными, а также для оценки возможностей RLM в понимании длинного контекста.

Подсказки окружения для Oolong

	_ENV_TIPS = """
 
<env_tips>
Strategy for long-context information retrieval:
 
1. Split the context into chunks (e.g., by paragraphs or fixed character windows with some overlap)
2. Write a prompt describing what to look for, then append it to each chunk to create a list of prompts
3. Call llm_batch() once with all prompts to scan chunks in parallel
4. Aggregate the relevant findings from the responses
</env_tips>"""

Настройки по умолчанию для Oolong

• поднабор по умолчанию: real

Дословное копирование (verbatim copy)

LLM часто плохо справляются с точным дословным повторением сложных текстов. Это одновременно и следствие обучения, и врождённое ограничение генерации, основанной на семплировании. Чтобы проверить это, мы разработали окружение verbatim copy.

• Версия verbatim-copy, использованная в этой статье

• verbatim-copy-rlm на Environments Hub

Окружение автоматически генерирует данные, которые модель должна скопировать, и предоставляет несколько «ручек» для настройки:

• content_type: как именно генерируются данные

  • "words": последовательности английских слов

  • "json": данные в формате JSON

  • "csv": табличные данные в формате CSV

  • "codes": UUID и буквенно-цифровые коды

  • "mixed": комбинация всех типов в одном промпте (см. mean_fragment_length, чтобы понять, как это реализовано)

  • "all": сбалансированная смесь всех типов; у каждого промпта случайный тип содержимого

• target_length: длина каждой повторяемой последовательности в символах. Достигается за счёт генерации с запасом и ��оследующего усечения до нужной длины

• mean_fragment_length: средняя длина фрагментов

  • Мы «перегенерируем» данные для каждого промпта, создавая гораздо более крупный батч, чем требуется

  • Допустим, у нас 4 исходных промпта на один итоговый промпт

  • Тогда мы берём случайный срез из каждого из этих 4 промптов и склеиваем их вместе

  • mean_fragment_length задаёт средний размер таких срезов (который случайно колеблется на ±50%)

  • Приятный эффект в том, что при "mixed" итоговый промпт составляется из срезов разных типов данных, что может приводить к странной токенизации и «кривым» текстам; хотя даже при одном типе данных это может быть полезно, например ломая синтаксис JSON необычным образом

Вся случайность контролируется через seed, который мы сохраняем одинаковым во всех экспериментах.

Почему verbatim copy?

Теоретически RLM может помочь и здесь: модель может записать свою лучшую попытку дословно скопировать входной текст в answer["content"], не устанавливая answer["ready"] = True, вывести результат, а затем исправить ошибки с помощью точечных функций на Python. Простого answer["content"] = answer["content"].replace("<erroneous>", "<fixed>") может быть достаточно. Обычный reasoner тоже мог бы выписывать части строки, которые нужно повторить несколько раз, прямо в процессе рассуждения, но в этом нет смысла: финальный ответ всё равно будет выдан одним проходом целиком.

Это помогает исследовать, насколько полезен возврат ответа через переменную.

Подсказки окружения для verbatim copy

	_ENV_TIPS = """
 
<env_tips>
Strategy for verbatim copying:
 
1. Write your initial attempt to answer["content"]
2. Print answer["content"] to see exactly what you wrote
3. Compare carefully with the original text - look for typos, transpositions, missing characters
4. Fix any errors using string operations (slicing, replacement, etc.)
5. Only set answer["ready"] = True after you have verified correctness
</env_tips>"""

Настройки по умолчанию для verbatim-copy

• content_type = "all"

• target_length = 500

• mean_fragment_length = 20

Модели

Основные абляционные эксперименты мы проводим с GPT-5-mini. Причина в том, что предварительные эксперименты показали: он лучше использует scaffolding RLM, чем Open source модели, которые мы тестировали. Кроме того, API OpenAI значительно стабильнее, чем API OpenRouter.

Open source модели, которые мы всё же аблируем в конце, запускаются через OpenRouter, с настройками по умолчанию: z-ai для GLM 4.6 и GLM 4.5 Air и nebius/fp8 для INTELLECT-3. Мы также пробовали использовать DeepSeek-v3.2 через google-vertex, однако модель постоянно применяла неверный формат вызова функций, что делало результаты недействительными. Мы также пытались провести абляции для Mimo-v2-flash от Xiaomi, но лимиты по запросам оказались слишком жёсткими, чтобы получить осмысленные результаты.

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

Сравнение, которое нас интересует, — это сравнение между LLM и RLM; абсолютные показатели не имеют значения, важны только относительные.

Результаты

Мы представим результаты в трёх разделах:

• По всем окружениям — с использованием настроек по умолчанию для каждого окружения (только GPT-5-mini);

• Внутри отдельных окружений — более детальный разбор поведения некоторых конкретных окружений (только GPT-5-mini);

• Для разных моделей.

Каждый график будет сопровождаться командой, с помощью которой его можно воспроизвести из ветки verifiers sebastian/experiment/rlm, запускаясь из корневой директории verifiers.

Результаты по всем окружениям

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

Средняя награда по окружениям и прирост RLM относительно стандартного бейзлайна

Средняя награда по 50 rollout’ам для разных окружений (uv run environments/plot_results.py -m gpt-5-mini -I reward):

Прирост средней награды по сравнению с LLM (uv run environments/plot_results.py -m gpt-5-mini -I lift):

В целом RLM имеет тенденцию повышать итоговую награду. Исключения двоякие:

Для math-python награда с RLM существенно ниже, чем без неё. Поскольку RLM допускает ровно тот же самый способ решения задач окружения, что и обычная LLM (у которой также есть доступ к Python-инструментам с теми же предустановленными библиотеками), этот разрыв в качестве указывает на переобучение под бенчмарк при использовании стандартного Python-инструмента. Мы предполагаем, что модель, корректно обученная работать с RLM, сможет как минимум сравняться по качеству с моделью без RLM.

Для DeepDive RLM показывает худший результат, чем LLM, за исключением случая, когда ей явно задают стратегию решения задач Deep Research: разбивать вопрос на несколько меньших исследовательских подзадач, поручать их под-LLM и затем итеративно объединять результаты до завершения. Это служит для нас свидетельством того, что значительная часть потенциальной производительности теряется из-за неэффективного использования scaffolding. И здесь, опять же, проблему должно решить обучение.

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

Использование токенов

uv run environments/plot_results.py -m gpt-5-mini -I tokens_breakdown

В DeepDive и Oolong RLM расходует значительное количество токенов под-LLM, при этом доля токенов генерации по отношению к токенам промпта в вызовах под-LLM существенно выше, чем у основной модели (как для LLM, так и для RLM). Это указывает на то, что под-LLM позволяют масштабировать «токены размышлений» при гораздо меньшей длине контекста осно��ной модели.

При использовании под-LLM длина контекста основной модели заметно снижается: в DeepDive это сразу бросается в глаза, но то же самое справедливо и для Oolong. Почему это не так явно видно в Oolong: для обычной LLM API отклоняет длинные входные промпты Oolong, поскольку они превышают размер контекстного окна. Такие запросы учитываются как использовавшие ноль токенов. К этому мы вернёмся подробнее позже.

Для math-python RLM с подсказками выполнила один вызов под-LLM в одном rollout’е; однако это не оказывает заметного влияния на генерацию токенов, поэтому можно считать, что GPT-5-mini фактически не использует под-LLM для math-python.

Эффективность токенов основной модели

Эффективность токенов основной модели определяется как средняя награда, делённая на среднее количество токенов в траекториях основной модели (примечание: для стандартной LLM траектория основной модели — это весь rollout целиком, тогда как для RLM она не включает вызовы под-LLM). Мы нормализуем это значение относительно эффективности LLM, чтобы сделать результаты сопоставимыми между разными окружениями. Итоговые результаты: uv run environments/plot_results.py -m gpt-5-mini -I efficiency

RLM существенно повышает эффективность в DeepDive, где большая часть токенов обрабатывается под-LLM и не учитывается в счётчике токенов основной модели.

Для Oolong также следовало бы ожидать заметного роста токенной эффективности RLM по сравнению с LLM, поскольку это ещё одно окружение с очень длинным контекстом, где RLM получает доступ к данным исключительно через Python REPL. Смешанные результаты объясняются упомянутыми выше отклонениями длинных промптов Oolong на уровне API. Поскольку более длинные задачи сложнее, но видит их только RLM, в этой конфигурации LLM оказывается в выигрышном положении.

И math-python, и verbatim-copy демонстрируют существенное падение токенной эффективности. В обоих случаях полный промпт целиком попадает в контекст модели, однако причины снижения эффективности различаются:

• в math-python RLM просто рассуждает неэффективно и неудачно, что и объясняет падение качества при увеличенном числе токенов основной модели;

• в verbatim-copy RLM, напротив, улучшает результат, но стратегия решения принципиально отличается от LLM: LLM выдаёт ответ одним проходом, тогда как RLM вынуждена вызывать инструмент для формирования ответа и часто делает это многократно, постепенно улучшая результат.

Время выполнения по окружениям

uv run environments/plot_results.py -m gpt-5-mini -I timing

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

• Для DeepDive и Oolong это связано с ростом общего токенного бюджета, который в основном оплачивается под-LLM. Хотя их вызовы можно распараллеливать, GPT-5-mini делает это не всегда (что указывает на дополнительный потенциал повышения эффективности за счёт обучения), а даже когда параллелизация есть, ограничения API и сам увеличенный суммарный объём токенов всё равно дают о себе знать. Самое важное — использование под-LLM приводит к резкому росту числа токенов генерации.

• Для math-python причина проста — основная RLM тратит больше времени на (неэффективные) рассуждения.

• Для Needle in Haystack общее число токенов у RLM сильно снижается (и при этом нет вызовов под-LLM). Однако LLM может выдать ответ буквально в одном токене. RLM же сначала пишет код для решения задачи, а затем — код для выдачи финального ответа. Это означает, что в этом окружении почти все токены LLM уходят на prefill, тогда как у RLM значительная часть тратится на декодирование.

• Для verbatim-copy причина — увеличенное число вызовов инструментов и шагов, о которых мы говорили выше.

Награда vs токены

uv run environments/plot_results.py -m gpt-5-mini -I scatter

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

• DeepDive: хорошо видно, насколько сильно у RLM сжимается контекстное окно при сохранении качества.

• math-python: наличие RLM-обвязки, несмотря на то что она допускает ровно то же поведение, что и стандартная LLM-обвязка, явно делает модель менее умной и менее эффективной в этой задаче.

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

• Verbatim copy: RLM улучшает результат пропорционально увеличению потребления токенов.

Итоги по всем окружениям

В целом эти результаты убеждают нас в полезности RLM как для сокращения длины последовательностей основной модели — что позволяет выполнять более долгую связную работу, — так и для повышения качества за счёт масштабирования под-LLM, использования Python для выполнения части работы и итеративного улучшения ответа.

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

Кратко (TL;DR) — всё это сводится к следующему графику:uv run environments/plot_results.py -m gpt-5-mini

Результаты по отдельным окружениям

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

math-python

Чтобы проверить идею использования под-LLM в math-python, упомянутую выше, мы добавили вторичный промпт с подсказками для окружения:

_ENV_TIPS_SUB_LLMS = """
 
<env_tips>
Use `llm_batch()` for reasoning steps: breaking down the problem, validating intermediate results, and checking your logic. Use Python for numerical calculations.
</env_tips>"""

Затем мы запускаем те же самые абляции, что и раньше (с тем же seed генератора случайных чисел, а значит, с тем же порядком данных), но варьируем тайм-аут каждой команды LLM: 120 секунд (значение по умолчанию, использовавшееся во всех остальных экспериментах), 300 секунд и 600 секунд.

Идея заключалась в том, что увеличенное время позволит модели более щедро использовать под-LLM. И что важно — модели всегда сообщается тайм-аут на одну команду и фактическое время выполнения каждого вызова REPL, так что теоретически она может понять, что при более длинном тайм-ауте стоит активнее использовать параллельные вызовы под-LLM.

Как и прежде, каждая конфигурация тестируется на одних и тех же 50 промптах.

Ниже мы приводим графики с наиболее важными статистиками этих абляций:

uv run environments/math_python/plot_results.py -m gpt-5-mini -I ablation

Мы быстро видим три результата:

• Использование под-LLM для математики делает GPT-5-mini слабее;

• Это почти не снижает потребление токенов основной модели (оно всё ещё значительно выше, чем у LLM);

• Добавляются токены под-LLM, но в очень небольшом объёме, поскольку GPT-5-mini в режиме RLM, по-видимому, использует под-LLM крайне редко даже при наличии дополнительного промпта;

• RLM передаёт под-LLM очень мало контекста: там почти одни токены генерации и крайне мало токенов промпта, что указывает на возможный потенциал для улучшений.

Остаётся открытым вопрос, поможет ли обучение модели активному использованию scaffolding RLM и интенсивному применению под-LLM улучшить эти показатели. Если да, то проблема, скорее всего, лишь в отсутствии обучения под эту конкретную конфигурацию. Если нет — возможно, математика просто не та область, которая сильно выигрывает от многоагентной системы.

Oolong

uv run environments/oolong/plot_results.py -m gpt-5-mini -a  

Мы уже видели, что использование RLM повышает награду.

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

• Для синтетических данных с метками RLM легко превосходит LLM;

• Для синтетических данных Oolong RLM работает хуже LLM, причём тем сильнее, чем больше ей рекомендуют полагаться на под-LLM;

• Однако для реальных данных (которые являются самыми сложными и самыми важными) RLM значительно превосходит LLM, что демонстрирует полезность опоры на под-LLM при работе со сложными данными.

Также можно посмотреть на подграфик «Награда vs длина контекста». Под длиной контекста здесь понимается только длина входных данных, которые целиком находятся в контексте LLM, но для RLM доступны лишь через Python-переменную. Этот график показывает одно из сильных мест RLM: LLM превосходит любую RLM только на данных с самым коротким контекстом.

Менее очевидно, что именно вызывает провал точности на средних длинах контекста. Посмотрим на тот же подграфик, но с разбиением по поднаборам:
uv run environments/oolong/plot_results.py -m gpt-5-mini -I context_binned_by_subset

Мы видим, что провал возникает из-за отсутствия сэмплов из Synth+Labels в этих бинах, а также из-за странного всплеска качества RLM на самых длинных контекстах. Для наиболее важного поднабора — real — RLM существенно превосходит LLM при длине контекста около 1,5 млн символов (~300–400 тыс. токенов). За этой границей уже ни одна модель не справляется.

Наконец, графики использования токенов промпта и токенов генерации показывают, что RLM использует больше токенов, чем LLM. Подсказки по решению Oolong приводят к тому, что RLM помещает меньше токенов промпта в собственное контекстное окно и вместо этого передаёт их под-LLM, что может объяснять слегка худший результат RLM+tips по сравнению с RLM. Под-LLM также генерируют значительно больше токенов при наличии подсказок.

Чтобы понять, какие стратегии использует RLM для разных поднаборов, приведём среднее число токенов по поднаборам (верхний ряд — токены промпта, нижний — токены генерации):uv run environments/oolong/plot_results.py -m gpt-5-mini -I tokens_by_subset

Видно, что для synth-поднабора RLM использует значительное количество токенов промпта, особенно при наличии подсказок, и почти все токены генерации приходятся на под-LLM. Впрочем, мы уже видели, что повышенное потребление токенов по сравнению с LLM объясняется тем, что последняя просто не потребляет и не генерирует токены ни для каких, кроме самых коротких, контекстов в synth-разделе.

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

Наконец, для поднабора real RLM использует существенно больше токенов. RLM+tips удаётся удерживать потребление токенов основной модели сравнительно ниже, чем у RLM без подсказок, однако при этом она тратит больше токенов через под-LLM.

Verbatim-copy

Для verbatim-copy, помимо уже рассмотренных результатов, есть ещё три интересных графика.

Награда по типу содержимого

Мы аблируем тип содержимого, который по умолчанию был "all" (то есть случайная смесь перечисленных ниже типов): uv run environments/verbatim_copy/plot_results.py -m gpt-5-mini -I reward_by_content_type

Данные в формате JSON явно оказываются самыми сложными и при этом сильнее всего выигрывают от использования RLM. Это противоречит аргументу, который выдвигался ранее: будто бы основная проблема RLM связана с экранирующими символами в вызовах инструментов. Наоборот, именно в JSON эти символы используются чаще всего.

Фактически RLM превосходит LLM для всех типов содержимого, кроме codes (где данные представляют собой множество UUID-кодов, склеенных вместе). Является ли это исключение случайным — неясно, однако при размере выборки 50 на режим и тип содержимого оно выглядит вполне правдоподобным.

Награда по длине содержимого

Мы также аблируем общую длину сгенерированного содержимого: uv run environments/verbatim_copy/plot_results.py -m gpt-5-mini -I length

Наблюдается тенденция: чем длиннее данные, тем ниже награда, хотя наклон зависимости небольшой, а точки данных довольно шумные. RLM строго доминирует над LLM, тогда как RLM+tips превосходит LLM почти везде, за исключением очень коротких и очень длинных данных (причём то, что это именно такие длины, почти наверняка является случайностью).

Награда vs длина фрагмента

Наконец, мы варьируем длину фрагментов: uv run environments/verbatim_copy/plot_results.py -m gpt-5-mini -I fragmentation

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

Этот график показывает, что чёткой зависимости между длиной фрагмента и наградой нет; эта модификация, по всей видимости, не оказывает существенного влияния — по крайней мере для RLM. Для стандартной LLM более мелкая фрагментация, напротив, чаще приводит к худшим результатам, увеличивая разрыв в качестве между ней и RLM.

Результаты для других моделей

Хотя в наших экспериментах GPT-5-mini оказался лучшим пользователем RLM, мы также провели абляции с другими моделями. В частности, нас интересовали возможности Open source моделей, значимость которых будет расти по мере перехода к генерации данных для SFT.

ДИСКЛЕЙМЕР: ещё раз подчеркнём, что это не измерение абсолютного качества какой-либо модели на каком-либо бенчмарке. Мы не прикладывали никаких усилий к оптимизации результатов моделей за счёт подбора гиперпараметров и нас интересует исключительно относительное соотношение между LLM, RLM и RLM+tips.

GLM 4.6

uv run environments/plot_results.py -m z-ai/glm-4.6

В DeepDive RLM даёт модели колоссальный прирост качества (почти в два раза), а также ещё более сильный рост эффективности токенов основной модели, что указывает на хорошо сжатое контекстное окно у RLM. Это сжатие также видно на графике «Награда vs токены». Однако, когда мы даём RLM те же подсказки, которые слегка помогали GPT-5-mini, качество резко падает — до уровня чуть выше половины от результата LLM. Эффективность токенов основной модели у RLM+tips всё ещё выше, чем у LLM, но причина такого поведения хорошо видна на графиках времени выполнения и количества вызовов под-LLM: получив указание активно использовать под-LLM, GLM 4.6 буквально останавливается, чтобы делать именно это.

Для math-python видно, что, как и у GPT-5-mini, использование RLM снижает качество. Однако, в отличие от GPT-5-mini, GLM 4.6 достигает этого не за счёт более долгих и «глупых» рассуждений, а просто за счёт того, что рассуждает меньше, что видно на графике «Награда vs токены».

В Oolong GLM 4.6 как стандартная LLM получает нулевую награду, но с использованием scaffolding RLM — ненулевую. Подсказки делают результат немного лучше, но при этом значительно увеличивают число вызовов под-LLM. Если посмотреть на это подробнее
(uv run environments/oolong/plot_results.py -m z-ai/glm-4.6 -I context_binned):

RLM показывает неплохие награды вплоть до довольно длинных контекстов — примерно до ~1,75 млн символов, но за этой границей награда падает до нуля. LLM же всегда получает нулевую награду. Примечание: здесь рассматриваются данные поднабора real.

В verbatim-copy RLM-обвязка ухудшает результаты, за исключением случая, когда GLM 4.6 получает подсказки по её использованию — тогда награда слегка увеличивается. По какой-то причине применение RLM снижает количество токенов генерации в этом датасете; вероятнее всего, из-за уменьшения объёма рассуждений (которые в этом окружении всё равно бесполезны).

GLM 4.5 Air

uv run environments/plot_results.py -m glm-4.5-air

Результаты в целом следуют общим тенденциям, за исключением DeepDive, где GLM 4.5 Air работает хуже с RLM, чем без неё, несмотря на то что выполняет значительное число вызовов под-LLM. Это ещё один сигнал в пользу того, что обучение со scaffolding RLM способно раскрыть значительный потенциал роста качества.

INTELLECT-3

uv run environments/plot_results.py -m prime-intellect/intellect-3

Наша собственная модель INTELLECT-3 демонстрирует те же тенденции, что и другие модели. Она сильно выигрывает от подсказок окружения и использует большое количество токенов (сопоставимое с GPT-5-mini, но при меньшей средней награде). По какой-то причине она почти полностью неспособна использовать RLM в math-python, хотя в других окружениях делает это без проблем.

Как и в случае с GPT-5-mini, мы провели более детальные абляции с INTELLECT-3 для Oolong и verbatim-copy.

INTELLECT-3: Oolong

Как и у GPT-5-mini, RLM показывает лучшие результаты, чем чистая LLM, причём INTELLECT-3 особенно выигрывает от подсказок. Аналогично GPT-5-mini, RLM работает хуже на синтетических данных, но лучше — на наиболее важных реальных данных (а также на synth-with-labels).

Также, как и у GPT-5-mini, LLM достигает ненулевой награды только для самых коротких промптов, тогда как RLM сохраняет качество на гораздо более широком диапазоне размеров входных данных (uv run environments/oolong/plot_results.py -m prime-intellect/intellect-3 -I context_binned_by_subset).

Картины поведения очень похожи на те, что наблюдались у GPT-5-mini. Аналогичны и распределения токенов промпта и генерации по поднаборам (uv run environments/oolong/plot_results.py -m prime-intellect/intellect-3 -I tokens_by_subset).

INTELLECT-3 способна удерживать средний размер контекстного окна RLM, несмотря на то что RLM успешно тестируется на входах значительно большего размера, чем LLM. Качество RLM также масштабируется с числом токенов под-LLM — по крайней мере на реальных данных.

INTELLECT-3: verbatim-copy

uv run environments/verbatim_copy/plot_results.py -m prime-intellect/intellect-3 -I reward_by_content_type

Интересно, что INTELLECT-3 страдает от scaffolding RLM для всех типов содержимого без исключения, если ей не дать подсказки окружения. Однако с подсказками она стабильно улучшает свои результаты по всем типам данных.

RLM или внимание к длинному контексту для долго работающего агента?

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

Масштабирование внимания и сворачивание контекста — это дуальная задача: оба подхода пытаются решить вопрос о том, что следует «забывать», обращаясь к прошлому. Одно из ключевых различий заключается в том, что масштабирование внимания решает эту проблему с точки зрения языкового моделирования. Новые архитектуры внимания обучаются эффективной работе с контекстом на этапе предобучения или дообучения. В то же время сворачивание контекста, реализованное через обучение с подкреплением, учит модель управлять своим контекстом, исходя из результатов задач, на которых она обучается.

Мы считаем, что для по-настоящему долго работающих агентов необходимы и эффективное внимание, и сворачивание контекста. Улучшенные механизмы внимания откладывают наступление феномена context rot, а сворачивание контекста позволяет модели активно управлять своим контекстом, расширяя пределы того, на что способен один лишь механизм внимания.

Резюме и выводы

Scaffolding для работы с чрезвычайно длинными контекстами становится всё более важным для LLM, и сворачивание контекста — перспективное направление в этой области. В настоящее время мы считаем, что рекурсивная языковая модель (RLM) является лучшим методом для реализации context folding благодаря своей простоте и одновременно высокой гибкости и расширяемости.

Мы реализовали вариацию RLM в verifiers в виде экспериментального окружения RLMEnv, что позволяет использовать её по принципу plug-and-play в любом окружении verifiers. Мы провели абляции с GPT-5-mini на четырёх окружениях и обнаружили, что RLM помогает в задачах с длинным контекстом и при интенсивном использовании инструментов, требующем большого числа токенов. Мы подтвердили корректность наших проектных решений и видим большой потенциал для дальнейшего обучения RLM.

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

Будущ��я работа

Мы планируем дальше развивать нашу реализацию RLM и проводить больше экспериментов. В частности:

• Сейчас RLM имеет глубину рекурсии ровно 1; мы планируем сделать возможным уменьшение глубины рекурсии до 0 (что даст обычную LLM с Python REPL, содержащим входные данные и доступ ко всем пользовательским инструментам), а также произвольное увеличение глубины, чтобы под-LLM могли вызывать дальнейшие под-LLM;

• Мы планируем упростить для пользователей определение собственных функций, которые RLM сможет использовать в своём REPL;

• Хотя пользователи уже могут устанавливать произвольные pip-пакеты, и модель уведомляется о том, какие пакеты доступны, она не всегда знает их в деталях; мы планируем упростить добавление описаний пакетов без необходимости переписывать весь промпт;

• Снаружи RLM выглядит как обычная LLM: на вход подаётся текст, на выходе получается текст; однако мы планируем сделать сжатие контекста между несколькими ходами «ассистент — пользователь» естественной частью RLM;

• Мы улучшим мультимодальную поддержку, а также поддержку пользовательских типов данных (основная сложность здесь — взаимодействие с Sandboxes; мы рассчитываем решить эту проблему в ближайшее время);

• Мы будем обучать модели использовать RLM, начиная с небольших моделей.

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

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!