Context rot: почему агенты теряются в длинных задачах

Разработчики, собирающие ИИ-агентов для многошаговых задач, всё чаще сталкиваются с одним и тем же: агент бодро стартует, а к десятому-пятнадцатому шагу начинает игнорировать инструкции из системного промпта, путать раннее и позднее, дублировать уже сделанное. Явление получило неформальное название context rot — «загнивание контекста». Речь не про баг конкретной модели, а про системное свойство того, как трансформеры работают с длинным вводом.

Маркетинг вокруг больших контекстных окон создал ложное ожидание: раз модель принимает 200 тысяч токенов, значит все 200 тысяч она держит в голове одинаково хорошо. На практике это не так, и цена ошибки — агент, который на длинной задаче ведёт себя хуже, чем на короткой.

Что такое context rot

Термин описывает деградацию качества ответов по мере роста объёма контекста¹. Формально окно вмещает сотни тысяч токенов, но реальное «внимание» модели распределяется по ним неравномерно. Информация в середине длинного ввода обрабатывается хуже, чем в начале и в конце, — этот эффект в исследованиях называют lost in the middle.

Для агента, который ведёт долгий диалог или прогоняет цепочку из десятков инструментальных вызовов, это выглядит так: чем длиннее история, тем выше шанс, что критичная инструкция окажется «в середине» и получит меньше веса. Модель не отказывается её выполнять — она просто перестаёт её замечать.

Большое контекстное окно — это ёмкость бака, а не гарантия, что топливо дойдёт до всех цилиндров. Вместимость и качество внимания — разные метрики.

Почему длинное окно не спасает

Есть несколько накладывающихся причин.

• Неравномерное внимание. Механизм self-attention физически распределяет ограниченный ресурс по всем токенам. Чем их больше, тем меньше приходится на каждый.
• Накопление шума. В длинном диалоге копятся черновики, отменённые ветки, промежуточные результаты. Модель не всегда отличает актуальное состояние от устаревшего.
• Позиционные эффекты. Начало и конец ввода обрабатываются заметно надёжнее середины — это воспроизводится на многих моделях.
• Конфликт инструкций. Системный промпт в начале и свежая реплика пользователя в конце могут противоречить друг другу, и модель выбирает по неочевидной логике.

Как это измеряют

Классический синтетический тест — needle in a haystack: в длинный текст прячут факт («иголку») и просят модель его найти. Он показывает, что чистый поиск факта модели даётся неплохо. Но реальные задачи сложнее поиска одной строки: агенту нужно удерживать несколько условий сразу, сопоставлять их и не терять состояние. Именно на таких многоусловных сценариях деградация проявляется сильнее, чем на простом «найди иголку». Приводить конкретные числа по конкретным моделям без ссылки на публичный бенчмарк не будем — они быстро устаревают и разнятся от прогона к прогону.

Подходы к борьбе

Универсального решения нет, но сложился набор инженерных приёмов. Их комбинируют в зависимости от задачи.

На практике продакшн-агенты почти всегда комбинируют RAG² с суммаризацией и явным блоком состояния. Идея одна: не заваливать модель всем подряд, а подавать в контекст только то, что нужно на текущем шаге.

Практический чек-лист

1. Держите системные инструкции короткими и ставьте их в начало, а самое важное дублируйте ближе к концу ввода.
2. Выносите справочные данные во внешнее хранилище и подтягивайте по релевантности, а не грузите целиком.
3. Раз в несколько шагов сжимайте историю в резюме, сохраняя цели и принятые решения дословно.
4. Ведите отдельный блок «текущее состояние»: что уже сделано, что осталось, какие ограничения.
5. Логируйте, на каком шаге агент начал ошибаться, — обычно это подсказывает, какой объём контекста для вашей задачи безопасен.

Кому это пригодится и кому нет

Пригодится, если вы:

• строите агента, который делает десятки последовательных вызовов инструментов — например, разбирает репозиторий или проводит многоэтапный ресёрч;
• ведёте длинные чат-сессии с накоплением истории (поддержка, ассистент по документам);
• заметили, что качество ответов падает именно на длинных сессиях, а на коротких всё в порядке.

Скорее не ваша проблема, если вы:

• делаете одношаговые запросы с коротким вводом — суммаризацию письма, генерацию сниппета, классификацию;
• работаете с фиксированным небольшим промптом, который не растёт от сессии к сессии;
• ваши задачи умещаются в пару тысяч токенов — до деградации там обычно далеко.

Иными словами, context rot — головная боль тех, кто строит долгоживущих агентов, а не тех, кто дёргает модель разовыми запросами. Прежде чем усложнять архитектуру ретривалом и сжатием, стоит проверить, дошли ли вы вообще до объёмов, где проблема ощутима.

¹ Контекстное окно — максимальный объём текста (в токенах), который модель принимает за один запрос: сюда входят и системный промпт, и вся история диалога, и ответ. Токен — примерно 3–4 символа для русского текста.

² RAG (retrieval-augmented generation) — подход, при котором модель не хранит все знания «в голове», а на каждый запрос подтягивает релевантные фрагменты из внешней базы и отвечает уже с опорой на них.