RLM: почему LLM-агент забывает цель и как это исправить

20.01.2026 • Хабр

В материале на Хабре разбирается подход RLM (Recursive Language Model): использование LLM через Python REPL и рекурсивные sub-вызовы. Идея в том, чтобы снизить проблемы длинного контекста и удерживать цель в многошаговых сценариях без изменения самой модели.

Материал перечисляет 10 проблем LLM-приложений и показывает, как RLM пытается обходить их без модификации модели.
RLM описывается как способ использовать любую LLM через Python REPL: данные остаются в Python, а модель пишет код и вызывает sub-LLM для отдельных шагов.
Приводится сравнение схем: «огромный контекст → LLM → ответ» и «данные в Python → код → sub-LLM → ответ».
Идея приписывается Alex Zhang (октябрь 2025); отдельно упоминается production-ready реализация.
Для проблемы Context Rot говорится, что на 150K токенов модель работает заметно хуже, чем на 10K, из-за «размывания» внимания.
В части про стоимость заявляется экономия токенов в 10–50 раз при работе с большими документами за счёт обработки только релевантных чанков; также упоминается RLM-Toolkit как бесплатный проект под Apache 2.0 с поддержкой 75+ провайдеров.

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

На что обратить внимание: Эффект RLM опирается на то, как формируются чанки, критерии релевантности и итоговые summary, потому что именно они попадают в финальный синтез. В примере про goal drift ключевой приём — каждый sub-LLM со свежим контекстом, но это увеличивает число вызовов и может менять цену и сложность трассировки. Отдельно описаны механики верификации фактов через внешние источники и локальная обработка, когда модели показываются только агрегаты.

Коротко

Подход RLM полезен там, где агент работает шагами: цель подаётся заново в каждом sub-вызове, чтобы снизить риск «goal drift».
Если в пайплайне много промежуточных попыток, RLM предлагает передавать в «главную» модель только структурированные summary, снижая загрязнение контекста.
Для ошибок фактов в статье предлагается верификация через внешние источники (например, knowledge graph или вычисления в Python), а не доверие одному ответу.
В сценариях с чувствительными данными идея в том, что LLM видит агрегаты, а raw data остаются локально; это меняет требования к инфраструктуре и доступам.
При оценке стоимости важно помнить, что экономия достигается ценой множества sub-вызовов: баланс «число вызовов vs размер контекста» будет разным.

FAQ

Зачем это важно: какую проблему RLM пытается решить в работе с LLM-приложениями и многошаговыми агентами, по описанию в статье?

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

Что в статье называют RLM (Recursive Language Model) и чем его схема с Python REPL и sub-LLM отличается от «огромного контекста» в промпте?

RLM описывается как способ держать данные в Python и использовать LLM для генерации кода и выполнения sub-задач. В отличие от промпта с документом целиком модель видит только нужные куски.

Какие сбои длинного контекста описаны на примерах (Context Rot и Lost in the Middle) и как RLM предлагает обходить их через подгрузку данных по запросу?

Для этих проблем предлагается не грузить весь документ в контекст, а разбивать данные на чанки и читать их по запросу из Python. Так снижается эффект «середины» длинного промпта, где информация игнорируется.

Что говорится про доступность RLM-Toolkit: лицензия, стоимость и поддержка провайдеров моделей, если ориентироваться на текст материала?

В материале сказано, что RLM-Toolkit бесплатный и распространяется под Apache 2.0. Также заявляется поддержка 75+ провайдеров, включая OpenAI, Anthropic, Google, Ollama и локальные серверы.

PubMag