Устранение избыточности контекста: проблема

Важно отличать избыточность от простой длины диалога. Длинная сессия — это естественно: вы накопили историю обсуждения, и каждый новый запрос должен учитывать предыдущие решения. Избыточность — это лишнее внутри этой истории: файлы, которые загрузили и забыли, выводы команд на тысячи строк, которые уже не имеют значения, повторы одних и тех же ответов. Длина — следствие работы, избыточность — следствие небрежности.

Проблема в том, что избыточность почти не заметна в моменте. Каждый отдельный «лишний» файл кажется безобидным: подумаешь, агент прочитал один конфиг или вывел лишние сто строк лога. Но эти мелочи накапливаются, и к середине длинной сессии значительная часть контекста уже потрачена на то, что не имеет отношения к вашей задаче. Агент продолжает вежливо отвечать, но качество его ответов незаметно снижается, а вы не понимаете, почему.

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

Особенность всех этих источников в том, что они легитимны. Читать файлы, чтобы понять проект, — правильно. Заглядывать в вывод тестов — правильно. Нет ни одного «мусорного» действия в списке выше; проблема не в самих действиях, а в том, что их результаты остаются в контексте навсегда. Файл прочитали и забыли — а он всё ещё там. Лог посмотрели и нашли ошибку — а он всё ещё в окне.

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

wc -l src/payments/*.ts src/utils/*.ts
   340  src/payments/processor.ts
   520  src/payments/refund.ts
   180  src/payments/webhook.ts
   900  src/utils/logger.ts
   410  src/utils/dates.ts
   2350  total

Допустим, эти файлы занимают порядка 4000 токенов. По ходу сессии агент запускает тесты и получает вывод на 500 строк — ещё около 2000 токенов. Затем он дважды правит код, каждый раз перезапрашивая и переоткрывая изменённые файлы, — история диалога растёт. К моменту, когда баг найден, контекст уже содержит 12-15 тысяч токенов, из которых реально полезными для финального решения были, возможно, треть.

Ирония в том, что большую часть этого мусора агент создал сам, следуя здравой логике «сначала изучи, потом делай». Он не виноват — он не умеет выбрасывать отработанные материалы.

Пока вы не вмешиваетесь, сессия будет копить информацию, и пик полезности придётся на начало, а к концу агент будет работать с оговорками «на основе доступного контекста».

Распухший контекст не показывает себя напрямую — в интерфейсе вы не увидите счётчик «мусора». Но есть косвенные симптомы, по которым опытный пользователь определяет проблему за пару минут работы.

1. Замедление ответов. Агент дольше думает над простыми вопросами: ему приходится каждый раз просматривать всё окно, включая балласт.
2. Противоречия с самим собой. Новый ответ забывает более ранние решения: модель «сбивается» из-за лишней информации и перескакивает на нерелевантные факты.
3. Фокусировка на старых деталях. Агент возвращается к ранним обсуждениям, которые давно устарели, и предлагает решения на их основе.
4. «Вежливые» отказы. Ответы вроде «не нашёл в текущем контексте», хотя файл точно читался — он затерялся среди мусора.
5. Рост стоимости. При том же количестве запросов счёт за токены растёт — контекст стал тяжелее.

Один-два таких симптома могут быть случайностью, но появление сразу нескольких — верный маркер того, что сессия перегружена. И здесь важно понимать: справиться с этим простым «напомни агенту, что важно» — нельзя. Контекст по-прежнему заполнен, и даже если агент согласится игнорировать лишнее, токены уже израсходованы.

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

Кроме того, избыточность ускоряет приближение границы Smart Zone: чем больше мусора, тем быстрее заполняется окно и тем раньше вы упираетесь в лимит. Нехватка информации решается одним дополнительным вопросом «прочитай вот этот файл» — это стоит сотни токенов. Избыточность же требует либо новой сессии, либо ручной расчистки — это стоит времени и потери контекста. Поэтому лишний файл в окне вреднее, чем отсутствие файла.

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

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

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

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

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

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

1. Избыточность контекста (context redundancy) — наличие в context window информации, не нужной для текущей задачи, но влияющей на рассуждения модели.
2. Контекст сессии — всё содержимое context window в рамках одной сессии: системный промпт, инструкции, файлы, история диалога.
3. Токен — единица измерения текста, на которую опирается LLM при обработке и ограничении контекстного окна.
4. Context window — максимальный объём текста (в токенах), который модель может обработать за один раз.
5. Smart Zone — продуктивный диапазон заполнения context window, в котором агент рассуждает качественно.
6. Галлюцинация — уверенный ответ модели, не соответствующий фактам, часто усиливающийся при перегруженном контексте.
7. Вводной (input) контекст — все токены, отправляемые модели при каждом запросе, включая накопленную историю.
8. Субагент (subagent) — отдельная сессия с независимым контекстом, используемая для исследовательских задач.
9. Сессия (session) — один непрерывный разговор с агентом, ограниченный context window.
10. Harness — программа-оболочка, через которую пользователь взаимодействует с LLM и управляет агентом.