Вы, возможно, слышали о уже нашумевшей Рекурсивной Языковой Модели (Recursive Language Model).

Ходят слухи, что она может снизить потребность в RAG (коротко, это когда в большую языковую модель добавляют контекст из заранее подготовленных документов) для задач с длинным контекстом 🧐. Разбираемся.

Мотивация модели лежит в ограничении контекстного окна топовых LLM: хотите обработать документ на большое число страниц с GPT, а не можете.

Авторы обходят ограничения контекста с помощью 3х основных идей:

1. Промпт — не в контексте, а в переменной окружения Модель не видит весь текст сразу. Он лежит как Python-переменная в REPL, и модель сама пишет код чтобы заглянуть в нужный кусок.

2. Рекурсивный вызов себя Модель может вызвать саму себя (`llm_query`) на подзадаче прямо из кода.

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

В статье авторы тестировали подход на двух топовых моделях — закрытой GPT-5 и открытой Qwen3-Coder-480B-A35B. Отдельно они дообучили маленькую Qwen3-8B в рекурсивном режиме, и она обогнала базовую версию в среднем на 28%, почти догнав GPT-5 на некоторых задачах.

Звучит красиво, но работает ли это на практике, да ещё и с открытой моделью?
Я решила проверить сама.

У нас на сервере крутится GLM-4.7-flash, открытая reasoning-модель от Zhipu AI. Взяла официальный репозиторий авторов и попробовала запустить.
Спойлер: с первого раза не вышло 🙈

GLM-4.7-flash это reasoning-модель: она сначала думает вслух внутри блока <think>...</think>, а потом выдаёт финальный ответ. RLM этого не ожидал: парсер хватал код прямо из середины "мыслей" модели, с отступами от markdown-списков, и падал с IndentationError.
Модель раз за разом писала правильный код, и раз за разом получала одну и ту же ошибку. Она даже начала анализировать проблему с отступами в своих рассуждениях, но это не помогало, потому что баг был не в ней, а в парсере.

Фикс — 2 раза по 2 строчки в parsing.py (в find_code_blocks и find_final_answer): берём только текст после последнего </think>, и всё заработало.

if "</think>" in text:
    text = text[text.rfind("</think>") + len("</think>"):]

В итоге, RLM отработал за 2 итерации: сначала написал код чтобы заглянуть в контекст и вызвал себя через llm_query, потом вернул финальный ответ через FINAL_VAR(summary). Всего 3 вызова модели, ~7 минут (GLM думает медленно — 200+ секунд на итерацию из-за длинных <think> блоков). Интересно, что финальный ответ в summary содержит всю цепочку рассуждений sub-модели вместе с </think> тегами. Это небольшой побочный эффект того что reasoning-модели не были предусмотрены авторами.

Буду тестировать дальше — интересно посмотреть как RLM справится с реально длинными документами, а не абстрактом на 700 символов.

LinkedIn 📱 | Telegram 📱