Знання — 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) · референс-імплементація