Почему контекст ломается раньше, чем кончается окно

Это первая часть серии об управлении контекстом в проектах и системах с AI-агентами. Мы разбираем, почему агенты теряют качество на длинных сессиях, какие техники против этого работают и сколько каждая стоит — по докладам практиков, с цифрами и провалами. Все цифры приведены со слов докладчиков.

Контекст стал главным ограничением

Разговор про AI-агентов долго крутился вокруг моделей: какая умнее, какая дешевле. В продакшене выяснилось, что при прочих равных результат определяет другое — что именно оказалось в контексте в момент решения. Одна и та же модель на одной и той же задаче ведёт себя по-разному в зависимости от того, положили ли вы в окно нужные пятьсот токенов или лишние пятьдесят тысяч.

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

Главная ошибка при переходе к агентам — считать окно контекста складом. Чем больше положили, тем хуже работает: деградация начинается задолго до формального предела.

Про что эта серия

Серия про две связанные вещи, которые обычно обсуждают отдельно:

• Контекст в проекте. Кодовая база, файлы правил, skills, документация — что агент видит, когда работает с вашим репозиторием, и сколько это стоит в токенах.
• Контекст в системе. Продакшн-агент: память, retrieval, разделение на суб-агентов, компакция длинных сессий, измерение деградации.

Материал собран из публичных докладов практиков — конференции AI Engineer, NDC, Developer Summit, разборы инженеров Anthropic, Elastic, Neo4j, Datadog, Arize, Cognition, LangChain, Notion, Tesla, ZS Associates и других. Отбирались выступления, где называют механику и цифры, без общих рассуждений о будущем. Из 41 доклада извлечено около 380 конкретных наблюдений. В серию вошли те, что можно применить или проверить.

Чего здесь нет

Обзора инструментов и советов вида «используйте RAG» здесь нет. Зато есть разбор компромиссов: где retrieval помогает и где не работает по конструкции, когда компакция спасает сессию и когда тихо съедает ваши правила, почему пять инструментов иногда лучше сорока шести.

Отдельно оговорюсь про качество данных. Часть цифр — из лабораторных замеров с методологией (например, тест Chroma на восемнадцати моделях). Часть — из практики отдельных команд, где методологии нет, и это порядок величины, а не измерение. Такие места помечены в тексте. Там, где источники противоречат друг другу — а по компакции они противоречат прямо, — приведены обе позиции: дисциплине примерно год, устоявшегося свода правил ещё нет.

Как устроена серия

Серия состоит из восьми частей и идёт от диагноза к практике. Эта часть объясняет, почему контекст ломается. Дальше идут четыре техники управления: компакция, retrieval, структура и память. Затем серия разбирает контекст, который живёт в кодовой базе, — файлы правил, skills и прогрессивное раскрытие, — и разделение работы между суб-агентами. Завершает серию разбор эксплуатации: как измерять деградацию и во что она обходится, вместе со сводным чек-листом.

Если времени мало, прочтите эту и последнюю части: первая объясняет, почему ваш агент «тупеет» на длинной сессии, а в последней собраны чек-лист и порядок действий.

Серия основана на публичных выступлениях. Все цифры — со слов докладчиков, ссылки на источники приведены прямо в тексте.

Почему контекст ломается раньше, чем кончается окно

Типичный разбор инцидента с агентом выглядит так: он отработал десяток шагов чисто, а потом начал вызывать бессмысленные инструменты, забывать задачу и выдавать мусор. Marina Wyss в своём курсе по context engineering описывает этот сценарий как самый частый и указывает порог примерно на 15–20 шагах — с оговоркой, что это наблюдение практиков, а не измерение. Первая гипотеза команды почти всегда одна: «плохая модель, возьмём поумнее». Вторая — «мало места, возьмём окно побольше». Обе неверны, и это измеренный факт.

Деградация начинается задолго до предела окна

Главный факт, вокруг которого строится всё остальное, дало исследование Chroma. Прогнали 18 фронтир-моделей — GPT-4.1, Claude 4, Gemini 2.5, Qwen 3 и другие — на растущей длине входа. Качество падало у каждой без исключения, и падало непрерывно, без обрыва в точке лимита. Ключевая цифра: модель с окном 200k может показывать заметную деградацию уже на 50k токенов. Ведущая JetBrains в разборе устройства агентов пересказывает тот же замер и формулирует вывод жёстче: это свойство моделей, а не баг харнесса. «Больше контекста» и «лучше контекст» — разные вещи.

Дальше начинаются рабочие правила практиков, и они интересны тем, что расходятся в цифрах, но сходятся в порядке величины.

Dex Horthy из HumanLayer на YC Root Access рассказывал, что весь их процесс построен так, чтобы утилизация окна никогда не превышала 40%: за фазой research следует plan, за plan — implement. Как только приближается граница, план обновляется («это сделано, переходим к следующей фазе») и открывается новое окно. Рабочий объём окна они оценивают примерно в 170k токенов и говорят прямо: чем меньше из них потратишь на работу, тем лучше результат.

Elvin Aghammadzada из DataRobot на AI Engineer ссылается на ту же работу про context rot и называет более ранний порог: производительность начинает падать примерно с 25% занятости окна, то есть у окна на 1M токенов проблемы начинаются где-то с 256K. Он же вводит удобную рамку из двух зон: до ~40% занятости модель находится в «smart zone», дальше — в «dumb zone». Обещание «бесконечного окна» от лабораторий он называет красивой ложью, которая ломает мышление про RAG и MCP.

Стоит сказать честно: и 40%, и 25% — эвристики без опубликованной методики. Aghammadzada своих замеров не приводит, а ссылается на чужую статью. Horthy описывает дисциплину команды из трёх человек. Порядок величины они дают одинаковый: рабочая зона занимает первую треть окна, дальше начинается деградация.

Чем именно портится контекст

У деградации несколько механизмов. Lance Martin из LangChain, опираясь на классификацию Drew Breunig, раскладывает её на четыре режима, и то же деление независимо повторяют Google Cloud в своём обучающем материале: poisoning (в контекст попала галлюцинация и дальше цитируется снова и снова), distraction (контекст так длинен, что модель переопирается на недавнюю историю вместо построения нового плана — начинает пересказывать свои прошлые действия вместо синтеза), confusion (лишние детали уводят в неверный ответ), clash (два куска контекста противоречат друг другу). Лечатся они по-разному, и увеличение окна не лечит ни один.

Lost in the middle. Модели надёжно достают то, что лежит в начале и в конце контекста, а середина проваливается. Marina Wyss приводит цифру: перенос релевантной информации из начала в середину роняет точность более чем на 30 процентных пунктов. Ragunath Jawahar на Developer Summit объясняет практическое следствие: системный промпт и AGENTS.md держатся долго, потому что стоят на переднем крае окна, а вот исходные инструкции агента, засыпанные 50 000 токенов tool-выводов, фактически исчезают. Формально инструкции остаются в контексте, фактически модель их уже не достаёт.

Отвлечение на инструменты. Это самый недооценённый механизм, потому что он срабатывает при полностью свободном окне. Lance Martin ссылается на исследование по RAG-over-tools: качество деградирует примерно после 30 инструментов и полностью разваливается около 100. Marina Wyss приводит бенчмарк, который отделяет проблему бюджета от проблемы рассуждения.

Что произошло: 46 инструментов ломают модель, которой хватало окна

• Кто: бенчмарк GeoEngine, квантованная Llama 3.1 8B — в пересказе Marina Wyss.
• Что делали: дали модели все 46 доступных инструментов, и контекст при этом спокойно помещался в окно.
• Результат: провал бенчмарка. С 19 инструментами та же модель отработала нормально.
• Вывод: инструментов оказалось слишком много для рассуждения, хотя для окна их было достаточно. Пространство решения растёт быстрее, чем способность модели в нём выбирать. Для справки: сорок с лишним определений инструментов — это ещё и около 10 000 токенов до начала работы.

Тот же вывод с другой стороны даёт Carly Richmond из Elastic: в их Elastic Agent Builder агенту выдают 5 инструментов из 24 возможных — и по соображениям безопасности, и чтобы не сбивать с толку. Чем больше инструментов, тем чаще модель выбирает не тот.

Противоречия. Emre, solution architect OpenAI, на Build Hour показывал их в чистом виде: системный промпт говорит «никогда не возвращаю деньги при неактивной гарантии», результат инструмента говорит «VIP-клиентам возврат положен», агент выдаёт полный возврат. Там же он демонстрирует context burst — turn 2 занимает 300–400 токенов, turn 3 после единственного вызова get_refund перепрыгивает за 3000. Отдельно Emre перечисляет источники poisoning, и список неприятный: лоссовая суммаризация, свободноформатная накапливающаяся заметка, старый summary, перетирающий новый. То есть отравление заходит через собственный механизм сжатия — к этому мы вернёмся во второй части серии.

Мусор от поиска. Leonie Monigatti из Elastic отмечает механику, которую легко проглядеть: агент неплохо отсеивает нерелевантную выдачу поиска в моменте — рассуждает над ней и отбрасывает, — но сами результаты остаются лежать в окне. В длинных сессиях накопленный отсев начинает сбивать агента.

Почему «подождём окно побольше» не работает

Dan Biderman, сооснователь Engram (ранее Mosaic, лаборатория Chris Ré в Стэнфорде), в разговоре на Latent Space формулирует это так: можно скормить модели N токенов и не получить ошибки, но это не значит, что она способна рассуждать о них холистически. Все вопросы continual learning и памяти он считает «вопросами длинного контекста в маскировке» и прямо говорит, что эффект деградации сохранится и на окне в 10 миллионов токенов. Если бы окно было бесконечным, ограничением осталась бы порча контекста.

У длинного окна есть и физическая цена. Самая конкретная системная цифра во всей серии — оттуда же, от Biderman: Llama-70B, одна статья Википедии (десятки килобайт текста) разворачивается примерно в 80 ГБ KV-состояния в памяти GPU — при том что все параметры модели в bf16 занимают около 140 ГБ. Состояние от одного документа сопоставимо с самой моделью. Отсюда, кстати, растёт их идея «убить prefill»: перенести работу в обучение заранее и загружать готовое состояние.

К этому добавляется простая экономика. Разбор The Working Thesis напоминает, что LLM — «мозг в банке» без состояния: харнесс пересылает весь транскрипт на каждом ходу, и на 50-м круге ты заново отправляешь 49 предыдущих — 50 000 токенов на каждом круге, помноженные на десятки кругов. Manus, по пересказу Marina Wyss, добавляет ценовую сторону: для Claude Sonnet кешированные входные токены стоят 30 центов за миллион против $3 за некешированные — разница в десять раз, а агент делает 30–40 API-вызовов на задачу. Любая правка ранней части контекста инвалидирует кеш и заставляет пересчитать всё.

И даже без денег есть налог на качество: тот же разбор The Working Thesis описывает ситуацию, когда старое сообщение об ошибке всё ещё лежит в транскрипте — и модель принимается чинить баг, починенный тридцать кругов назад.

Окно занято ещё до твоего первого слова

Про это забывают чаще всего. Ragunath Jawahar приводит полную опись «пустого» окна кодинг-агента: системный промпт агента, определения всех встроенных инструментов (имя, описание, параметры), метаданные окружения, файлы правил вроде AGENTS.md и CLAUDE.md, подключённые MCP-серверы, описания skills, memory и preferences, описания суб-агентов. По его оценке, только системный промпт и определения инструментов — это 10–50k токенов в зависимости от конфигурации MCP.

IndyDevDan измерял это на своей конфигурации: 24,1k токенов на MCP-инструменты — 12% всего окна Opus. Узкий конфиг только с Firecrawl обходится в 6k, экономия около 20k на старте. Отдельно у него CLAUDE.md на 23 000 токенов съедал ~10% окна. После урезания до 43 строк файл стал весить ~350 токенов, и на старте свободно 92% окна. Aghammadzada из DataRobot называет ещё более грубую цифру для тяжёлых конфигураций: 15 MCP-серверов — это больше 100 000 токенов за сессию только в определениях инструментов.

Сложите это с порогом «40% — потолок умной зоны», и получится главный практический вывод: при жирной конфигурации разговор стартует уже из тупой зоны, до первого сообщения пользователя. Пользователю этот расход не виден.

Контекст — это бюджет

Sally-Ann Delucia из Arize по итогам года разработки формулирует смещение стека: агенты падают из-за контекста, и context management — это стратегический выбор того, что модель увидит. Aghammadzada говорит то же экономическим языком: контекст — ограниченный ресурс с бюджетом, и каждый нерелевантный файл, лишний веб-поиск или старое сообщение об ошибке отнимает у агента reasoning power.

Полезно, что у бюджета есть приоритет расходов. HumanLayer оптимизируют контекст по четырём осям — correctness, completeness, size, trajectory, — и если их инвертировать, получится иерархия вреда: хуже всего неверная информация, затем отсутствующая, и только на третьем месте лишний шум. Практически это значит: чистку начинают с неправды и лишь потом переходят к объёму. Про четвёртую ось, trajectory, авторы честно говорят, что она «пока чисто на вайбах» — измерять не научились.

И сразу противоположный голос, чтобы не выпрямлять картину. Ian Gotts из экосистемы Salesforce, признавая context rot, утверждает по своей практике обратное: «мы все даём агентам слишком мало контекста, и поэтому у нас проблемы». Противоречие он снимает приоритизацией слоёв — много правил и контекста процесса, мало сырых данных. Методики измерить «достаточно» он не даёт, и это честно отражает состояние дел: направление ясно, метрики нет.

Что с этим делать

Считай стартовый оверхед до релиза. Открой пустую сессию и посмотри разбивку окна (в Claude Code это /context): системный промпт, инструменты, memory-файлы, MCP, skills. Если до первого сообщения занято больше трети, сокращай конфигурацию.

Держи утилизацию в первой трети окна. Ориентир HumanLayer — до 40%, у DataRobot планка ещё ниже. Когда подходишь к границе, фиксируй результат в артефакт и открывай новое окно.

Ревизуй набор инструментов по количеству. Кейс GeoEngine показывает, что вред начинается при свободном окне. Отключи MCP-серверы, которыми не пользуешься. Для конкретной задачи запускай агента с узким конфигом (--mcp-config, --strict-mcp-config).

Ставь важное на края окна. Стабильные инструкции — вверх, актуальное состояние — вниз. Всё, что упало в середину под слоем tool-выводов, считай недоступным, даже если формально оно в контексте.

Чисти сначала неправду, потом объём. Устаревшая ошибка, отменённое решение, неверный ответ, лежащий рядом с исправленным, — вреднее, чем сотня лишних токенов. Если в треде застряла галлюцинация или удалённый кусок кода, который агент воскрешает, тред пересобирают.

Заведи метрику «шагов до деградации». Считай, на каком ходу агент начинает вызывать бессмысленные инструменты. Это дешёвый ранний сигнал: он ловит проблему до того, как о ней сообщат пользователи.