Ваша LLM забывает всё через 10 минут. Это не баг, это context rot
Представьте агента, который работает с вами неделю. В понедельник вы обсудили архитектуру проекта. Во вторник - выбрали стек технологий. В среду - набросали API. К четвергу модель уже путает, где endpoint, а где база данных. К пятнице она предлагает использовать MongoDB для хранения JWT токенов.
Это не глупость. Это context rot - системная деградация понимания в длинных сессиях. Токены накапливаются, внимание рассеивается, важная информация тонет в шуме.
Context rot - это не просто "модель забыла". Это качественное ухудшение: модель помнит факты, но теряет связи между ними. Как человек, который знает все слова в книге, но не понимает сюжета.
Традиционные решения? Увеличивать контекст. 128K, 1M, 10M токенов. Но это как лечить ожирение, растягивая желудок. Проблема не в размере, а в управлении.
Рекурсивные языковые модели: когда LLM обучает саму себя
RLM - это не "ещё один фреймворк". Это смена парадигмы. Вместо пассивного потребления контекста модель активно им управляет.
Представьте архитектора, который не просто строит дом, но и проектирует инструменты для его постройки. А потом использует эти инструменты, чтобы спроектировать ещё лучшие инструменты.
Звучит как научная фантастика? Посмотрите на DroPE - хак, который заставляет LLM читать в 10 раз больше. Тот же принцип: меняем не данные, а способ их обработки.
Три столпа RLM: folding, scaffolding, под-LLM
1 Context Folding: как сложить контекст в оригами
Context folding - это не сжатие. Это переупаковка.
Вместо того чтобы хранить 1000 токенов диалога, модель создаёт 100-токенное резюме. Но не просто "суммаризация", а структурированное представление с мета-информацией:
- Какие решения были приняты
- Какие альтернативы рассматривались
- Какие противоречия остались неразрешёнными
- Как менялись требования со временем
Проблема в том, что обычные LLM для суммаризации теряют нюансы. Они создают "среднюю температуру по больнице".
Решение? Обучить модель специально для folding. Дать ей понять, что важно сохранить, а что можно отбросить. Это ближе к пониманию цели, чем к механическому сокращению.
2 Scaffolding: строительные леса для мышления
Scaffolding - это внешняя структура, которую модель использует для организации контекста. Представьте менеджера проекта, который создаёт:
- Дорожные карты (что уже сделано, что в процессе, что планируется)
- Матрицы ответственности (кто за что отвечает)
- Графы зависимостей (если изменим A, затронем B и C)
- Журналы решений (почему выбрали X, а не Y)
Модель не просто запоминает - она структурирует. И когда приходит новый запрос, она не ищет в куче токенов, а обращается к нужному разделу scaffolding.
Scaffolding решает проблему interpretation drift. Если сегодня модель интерпретировала требование как X, а завтра как Y, scaffolding фиксирует первоначальную интерпретацию и причины выбора.
3 Под-LLМ: специалисты вместо универсалов
Главная LLM - это CEO. Она не должна разбираться в деталях налогового кодекса или тонкостях WebSocket.
Вместо этого она создаёт под-LLM:
| Тип под-LLM | Задача | Пример |
|---|---|---|
| Эксперт по домену | Глубокое понимание конкретной темы | Специалист по PostgreSQL оптимизациям |
| Аналитик решений | Сравнение альтернатив | Redis vs Memcached для кэширования сессий |
| Архивариус | Ведение истории и контекста | Хранение всех принятых решений с обоснованиями |
Каждая под-LLM обучается на лету для своей задачи. И когда CEO-LLM получает вопрос про индексы в PostgreSQL, она делегирует его эксперту по БД.
Пошаговый план: как обучать свою RLM
Теория - это хорошо. Но как это сделать на практике?
1 Начните с малого: один навык управления контекстом
Не пытайтесь сразу создать полноценную RLM. Возьмите одну задачу:
- Суммаризация технических дискуссий
- Отслеживание изменений требований
- Ведение журнала решений
Обучите модель делать это хорошо. Используйте KEF или аналогичные фреймворки для прокачки reasoning.
2 Создайте цикл рекурсивного улучшения
Модель должна оценивать качество своей работы и улучшать её. Простой промпт-инжиниринг не сработает. Нужна архитектура:
# Псевдокод цикла улучшения
while needs_improvement(current_output):
# Анализ ошибок
error_analysis = analyze_errors(current_output, ideal_output)
# Создание улучшенной инструкции
improved_instruction = generate_better_instruction(
current_instruction,
error_analysis
)
# Перегенерация с улучшенной инструкцией
current_output = generate_with_instruction(improved_instruction)
Ключ в том, что модель сама создаёт инструкции для себя. Это и есть рекурсия.
3 Добавьте механизм делегирования
Научите главную модель определять:
- Когда задача требует специалиста
- Какого именно специалиста создать
- Как сформулировать задачу для него
- Как интегрировать результат обратно
Это сложнее, чем кажется. Модель должна понимать границы своей компетенции. Та же проблема, что и в понимании реальных целей пользователя.
4 Тестируйте на длинных сессиях с контролем качества
Не оценивайте по одному запросу. Создайте тестовые сценарии:
- Недельное планирование проекта
- Многоэтапное исследование с уточнениями
- Диалог с меняющимися требованиями
И измеряйте не "нравится/не нравится", а конкретные метрики:
| Метрика | Как измерять | Целевое значение |
|---|---|---|
| Консистентность решений | Противоречия в ответах через время | Менее 5% |
| Сохранение контекста | Может ли ответить на вопросы из начала сессии | Более 90% точности |
| Качество делегирования | Правильный выбор эксперта для задачи | Более 85% |
Ошибки, которые сломают вашу RLM (и как их избежать)
Ошибка 1: Слишком много рекурсии
Модель создаёт под-модель, которая создаёт под-под-модель... И зацикливается. Решение - лимит глубины рекурсии и мониторинг.
Всегда добавляйте максимальную глубину рекурсии. 3-4 уровня обычно достаточно. Больше - и модель тратит больше времени на организацию работы, чем на саму работу.
Ошибка 2: Под-LLM становятся слишком специализированными
Эксперт по "оптимизации PostgreSQL запросов с JOIN из 5 таблиц на SSD дисках" бесполезен для большинства задач. Решение - баланс специализации и универсальности.
Ошибка 3: Scaffolding становится сложнее основного контекста
Бывает: модель создаёт такие сложные структуры для управления информацией, что сама в них путается. Решение - регулярная "уборка" и упрощение scaffolding.
RLM vs RAG: не конкуренты, а союзники
Многие спрашивают: зачем RLM, если есть RAG?
RAG решает проблему внешних знаний. RLM решает проблему внутреннего управления контекстом.
Идеальная система: RAG предоставляет факты из базы знаний, RLM управляет тем, как эти факты используются в длинной сессии.
Представьте юриста: RAG - это его библиотека законов. RLM - это его способ вести дело, помнить все нюансы, не путать показания свидетелей.
Аппаратные требования: нужен ли монстр?
RLM кажутся требовательными. Но это не всегда так.
Если вы используете под-LLM стратегически - только для сложных задач - то можно обойтись даже чистым CPU. Главная модель работает постоянно, под-модели запускаются по необходимости.
Для серьёзных проектов посмотрите на сборки с несколькими GPU или даже V620 с 96 ГБ VRAM.
Но начинать можно с малого. RLM - это в первую очередь архитектура, а не вычислительная мощность.
Что дальше? Долгоживущие агенты, которые помнят всё
RLM - это шаг к агентам, которые работают с вами неделями, месяцами. Которые помнят не только что вы делали вчера, но и почему вы приняли те решения.
Следующий барьер - эмоциональный контекст. Как модель запоминает не только факты, но и настроение, приоритеты, стиль работы? Это уже область неочевидных решений LLM.
Мой прогноз: через год RLM станут стандартом для любого серьёзного агента. Context rot будут лечить не увеличением контекста, а умным управлением им. И те, кто освоит эту парадигму сейчас, получат преимущество.
Начните с одного навыка. Обучите модель хорошо делать одну вещь. Потом добавьте рекурсию. Потом - делегирование. Не пытайтесь прыгнуть выше головы.
И помните: лучшая RLM - та, которую вы не замечаете. Она просто работает, пока контекст не сгнил.
