Разбираю пост Сидни Ранкл из LangChain про новую фичу в…

Разбираю пост Сидни Ранкл из LangChain про новую фичу в Deep Agents — поддержку RLM (recursive language models), концепции, предложенной Алексом Чжаном и исследователями MIT CSAIL. Проблема, которую они решают, знакома всем, кто работал с длинным контекстом: чем больше информации накапливает агент, тем хуже он работает — это называют context rot. Классический пример: агенту нужно посчитать средний размер сделки по 10 000 транскриптов звонков. Если считать «по ходу», сохраняя промежуточный итог в контексте модели, сумма неизбежно начинает плыть по мере роста истории.

Идея RLM в том, чтобы вынести оркестрацию и подсчёты в код, а не держать их в эфемерном окне контекста модели. Модель получает данные как переменную в REPL и пишет код, который сам решает, как разбить задачу, — grep, partition, map, reduce, всё как при работе с большим датасетом. Отличие от обычных саб-агентов в том, что раньше модель решала «что делать дальше» пошагово, на каждом шаге рассуждения, а теперь пишет скрипт, и код гарантирует полный охват задачи (цикл for обойдёт каждый батч по определению, а не «на усмотрение» модели).

Результаты на бенчмарке OOLONG показательны: на контексте 64k токенов обычный агент почти не уступает — 0.58 против 0.67 у RLM-версии. Но на 128k разница резко увеличивается — 0.44 против 0.79, причём обычный агент не просто ошибается, а честно сдаётся и говорит, что не может выполнить задачу. Правда, авторы сами оговариваются: это прикидочный тест без специфической настройки под задачу, так что реальный потенциал RLM, вероятно, недооценён этими цифрами.

Отдельная деталь, которая мне кажется важной: оркестратор и саб-агенты в Deep Agents могут работать на разных моделях — например, фронтир-модель как «дирижёр» с открытыми весовыми моделями вроде GLM 5.2 или Nemotron в роли исполнителей для экономии, или наоборот.