Context Window

Контекстное окно — объём токенов, который модель «видит» за один вызов (system + история + результаты инструментов). В 2026 норма — 1M токенов, но контекст не бесплатен и растёт квадратично в агентной петле.

Суть

Это самый «горячий» вид памяти агента (Agent Memory): только то, что в окне сейчас, влияет на ответ. Всё, что не влезло, нужно хранить снаружи (vector DB, summary, pointers).

Зачем это нужно

Понимание окна объясняет две вещи: (1) почему агент «забывает» цель на длинной дистанции и (2) почему каждый шаг агента дороже предыдущего — API биллится по полному контексту на каждом шаге.

Как работает

  • Квадратичный рост стоимости: шаг 1 — 500 токенов, шаг 10 — в 8–10× больше (история + tool results накапливаются). Отсюда нужен лимит шагов max_iterations (см. Agent CostControl).
  • Свыше ~200K input у многих моделей включается long-context тариф ×1.5–2.
  • Оптимизация: Prompt Caching (−90% на повторяющиеся system-промпты), обрезка/суммаризация истории, memory pointers.
  • Больше окно ≠ всегда лучше: на больших контекстах падает retrieval («забывания»); это критерий в Model Selection.
  • Компактизация (компрессия) контекста — «отдельная наука»: по мере роста (шаг 1 → шаг 15) часть оставляем как есть (system prompt, схемы tools), часть сжимаем (накопленные user/assistant-сообщения, memory/RAG-вставки). Цель — удержать важное в окне, не раздувая стоимость.
  • Context anxiety и context resets (Harness, Anthropic): на длинных задачах модель не только теряет связность к концу окна, но и проявляет «контекстную тревогу» — преждевременно сворачивает работу у мнимого предела. Лечится сбросом контекста: чистый агент + структурированный handoff-артефакт с состоянием и следующими шагами. Отличие от компактизации: compaction суммирует историю на месте (тревога остаётся), reset даёт «чистый лист» ценой оркестрации и латентности. Подробнее — Generator Evaluator.
  • Тревога оказалась свойством конкретной версии модели, а не устройства окна. Выражена она была у Claude Sonnet 4.5; на Opus 4.5 то же поведение не воспроизвелось, и сбросы превратились в мёртвый груз, а на Opus 4.6 авторы отказались от них совсем и вернулись к одной непрерывной сессии с компактизацией. Практический вывод шире случая: обвязка кодирует предположения о том, чего модель не умеет сама, и при смене модели её надо перепроверять — иначе система тащит сложность, оплачивающую уже несуществующую проблему.
  • Рост окна и оптимизации: от 2K (GPT-2) до 2M+ токенов (современные). Attention оптимизируют через Flash Attention, Ring Attention, sparse attention; есть линейные по длине альтернативы трансформеру — Mamba, RWKV. Память на длинный контекст — это в т.ч. KV Cache (растёт линейно с длиной).

Lost in the middle: где именно проседает внимание

Кривая внимания по длине контекста не плоская: модель хорошо держит начало и конец, а середина проседает. Практическая граница, за которой эффект становится заметным, — примерно 8K–32K токенов, дальше растёт риск, что нужный факт окажется в «слепой зоне», физически присутствуя в окне. Сама форма кривой подтверждена внешним замером, а вот эта числовая граница пришла из одного учебного материала и внешним источником не подтверждается — тем более что она зависит от доли релевантного в контексте, а не от абсолютной длины (см. эксперимент ниже).

Отсюда два следствия, которые часто путают.

Первое. Больше документов не значит лучше ответ. Качество растёт с объёмом контекста до какого-то предела, а затем начинает падать — этот разворот воспроизводится в замерах на разных моделях. Значит, наращивать top_k в поиске бесконечно бессмысленно: с какого-то момента вы добавляете шум, а не знание.

Второе. Размер окна и полезный размер окна — разные величины. Заявленный миллион токенов не означает, что туда стоит класть миллион: цена и латентность растут линейно, а точность после определённой длины — нет.

Отсюда четыре стратегии работы с длинным контекстом, которые применяют вместе, а не по отдельности: сжатие старой истории суммаризацией, скользящее окно из последних N сообщений, поиск нужного вместо укладывания всего (RAG) и вынос части работы в субагентов с чистым окном.

Как найти свою точку разворота

Публичные замеры «lost in the middle» говорят, что деградация есть, но не где она у вас: она зависит от доли релевантного в контексте, а не от абсолютной длины. Измеряется одним экспериментом на своих данных.

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

Точка разворота — та длина, на которой доля правильных ответов начинает падать при неизменном содержании. Дальше это рабочий потолок: наполнять контекст сверх него бессмысленно, вместо этого включается отбор — реранкинг (Reranking) или сжатие.

Связано с

  • Agent Memory — окно как один из 4 видов памяти
  • Agent CostControl — квадратичный рост → лимиты
  • Model Selection — размер окна как критерий выбора
  • KV Cache — память на контекст растёт линейно с длиной
  • Prompt Caching — кэш статического префикса в окне