Знания — RLM (извлечение без индекса)

Что и зачем

RLM (Recursive Language Models) — это стратегия инференса, а не модель и не ещё один RAG-движок: вместо того чтобы запихивать длинный вход в промпт, вход хранится как переменная во внешнем окружении (REPL / файловая система), а корневая LLM программно просматривает, грепает и режет его — рекурсивно вызывая суб-LLM только на нужных кусках и композируя их ответы. Результат (MIT CSAIL, arXiv:2512.24601): маленькая корневая модель с RLM-циклом обходит большую модель с полным промптом на входах 10M+ токенов при сравнимой или меньшей цене за запрос — потому что ни одна модель не читает вход целиком.

Для нас RLM — второй путь извлечения: LightRAG отвечает из индекса, построенного заранее; RLM отвечает по сырым данным без ингестии вообще, платя в момент запроса.

RLM vs LightRAG — два пути к данным

	LightRAG (индекс)	RLM (без индекса)
Стоимость заранее	Дорогая ингестия — LLM-извлечение на каждый чанк	Ноль — ингестии нет
Стоимость запроса	Дешёвый (граф + вектор)	Выше — peek/grep + вызовы суб-LLM на каждый запрос
Какие данные	Курируемый, стабильный корпус — каталог, правила, документы	Сырые, свежие, неиндексированные — огромная выгрузка, лог, экспорт, вся история чата
Латентность	Низкая	Выше (агентный цикл на запрос)
Когда выигрывает	Спросят много раз — индекс окупается	Спросят один раз — или данные только что появились

Правило выбора: базу будут спрашивать много раз? Индексируй (LightRAG). Разовый вопрос по чему-то большому или данные только что пришли? RLM. Оба пути имеют одну поверхность для потребителя — MCP-инструменты — поэтому агент выбирает путь под вопрос, как уже выбирает режим извлечения.

RLM — радикальное продолжение идеи «дешёвого пути» из масштабирования: naive vector-RAG пропускает граф; RLM пропускает индекс целиком.

Как это ложится на нашу архитектуру

Схема из статьи переносится один-в-один на двухплоскостной рантайм — с одним жёстким ограничением: у worker'а нет LLM (принято — ключи LLM никогда не попадают в под, MCP sampling выключен). Поэтому RLM-цикл живёт в мозге, а worker служит окружением:

Понятие из статьи RLM	В Agentfy 2.0
Корневая LM — ведёт цикл, никогда не читает весь вход	Ход orchestrator в api (мозг)
REPL-окружение — держит вход как переменную	Workspace worker'а — файл на диске, управляется через exec / file по MCP-каналу тулов
peek / grep / slice	Вызовы exec (head, grep, split, jq, …) — по каналу 3 возвращаются фрагменты, никогда весь файл
Рекурсивный вызов суб-LM	spawn_agent (под-задача = ещё один эфемерный запуск api) для больших кусков; дешёвый вызов system/llm для маленьких
Композиция частичных ответов	Обычный LLM-цикл корневого хода

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

Куда подключается

1. Задачи worker'а над данными больше окна (основной случай). «Проанализируй этот экспорт на 500 МБ» — файл никогда не влезет в контекстное окно. Мозг ведёт RLM-цикл: положить файл в workspace worker'а, grep/резать через exec, раздать куски в spawn_agent / system/llm, скомпозировать. Это паттерн использования worker'а, а не новый инструмент.

2. Холодный старт знаний — режим извлечения rlm. Магазин подключился и загрузил каталог; графовая ингестия займёт часы очереди и токены. С режимом rlm у MCP-инструмента знаний агент отвечает по сырым документам сразу, пока индекс строится в фоне — потом запросы мигрируют на дешёвый индексированный путь. Закрывает разрыв холодного старта у стены ингестии.

3. Память чата (будущее). RLM-проход по полной истории чата, когда нужен точный ответ, а не семантическое попадание — «какой размер клиент называл три недели назад?». Возможное дополнение к pgvector-поиску в Памяти; направление, а не обязательство.

Ограничения и бюджет

• Глубина рекурсии ограничена 1 (корень → суб-вызовы, не глубже) — как в статье; держит цену и отладку в норме.
• Бюджет токенов на запрос — та же философия, что у бюджетов ингестии в runtime/task: RLM-запрос — это ограниченный расход LLM, а не открытый цикл.
• Латентность реальна: RLM-ответ — это агентный цикл (секунды+), а не lookup. Не отправляйте в RLM вопросы, на которые уже отвечает готовый индекс.
• Дешёвого корня достаточно. Главный результат статьи получен с маленькой корневой моделью; корень в основном пишет команды grep/slice. Для точки 2 по умолчанию — дешёвая модель из system/llm.

WARNING

RLM (декабрь 2025) ещё моложе LightRAG. Сам паттерн прост и полностью наш end-to-end — но прогоните качество ответов по типам данных (выгрузки каталогов, логи, истории чатов) прежде чем обещать это в продукте.

Смотрите также

• Знания — обзор — индексированный путь и место знаний в системе.
• LightRAG — индекс: ингестия, workspaces, бэкенд хранилища.
• Worker — использование — двухплоскостное разделение, на котором едет RLM; почему у worker'а нет LLM.
• Короткая память — дешёвая вспомогательная модель, которую RLM переиспользует для суб-вызовов.
• Статья RLM (arXiv:2512.24601) · референс-имплементация