Контекстное окно — предельный объём текста, который модель обрабатывает за один раз. В него входит всё: системная инструкция, переданные документы, история диалога и генерируемый ответ.
Измеряется в токенах. Современные модели заявляют от нескольких десятков тысяч до миллиона и более.
Заявленное окно и полезное
Разница, которую стоит понимать до проектирования. Модель принимает заявленный объём, но качественно работает с меньшим.
Наблюдаемая закономерность: информация в начале и в конце переданного текста используется заметно надёжнее, чем в середине. Нужный факт, оказавшийся в середине длинного контекста, модель может пропустить, при этом уверенно ответив.
Почему середина страдает. С ростом числа позиций релевантный сигнал приходится искать среди всё большего объёма постороннего: вес внимания распределяется шире, и вероятность пропустить нужное растёт. Края выигрывают положением — начало читается первым, конец примыкает к вопросу.
Отсюда практика: важное размещают в начале или в конце, а не полагаются на то, что модель найдёт его где угодно.
Что реально помещается
Токены не равны страницам. Страница А4 плотного русского текста — это порядка 700–1200 токенов: кириллица нарезается токенизатором мельче латиницы. Окно на 128 тысяч токенов вмещает около сотни страниц чистого текста — без системной инструкции, истории и ответа.
Прикидка для артефактов. Регламент на 40 страниц — порядка 30–50 тысяч токенов, часовой лог работы агента с вызовами инструментов — десятки тысяч, ход диалога с парой документов — 2–5 тысяч. Это ориентиры для выбора модели и сценария, а не для оплаты: счёт считается по фактическим токенам.
Бюджет промпта. Полезный объём меньше окна: из него вычитаются системная инструкция, история диалога, результаты вызовов инструментов и место под ответ, плюс запас 10–20% на случай длинной генерации. Проектировать сценарий надо от этого остатка, а не от цифры в описании модели.
Как именно текст нарезается на токены и почему русский текст «дороже» — в статье про токены.
Почему большое окно не заменяет поиск
Стоимость. Тарификация идёт по переданным токенам. Загружать весь архив в каждый запрос — прямой способ получить счёт, несопоставимый с пользой. У части провайдеров токены сверх порога — обычно нескольких десятков тысяч — считаются по повышенной ставке: длинный вход дорожает не только объёмом.
Качество. Десять релевантных фрагментов работают лучше двухсот страниц, среди которых нужное надо ещё найти.
Скорость. Время до первого токена ответа растёт вместе с объёмом входа — механизм описан в статье про инференс.
Поэтому связка «поиск плюс небольшой контекст» остаётся дешевле и точнее, чем «всё сразу», даже когда окно позволяет обратное.
Что съедает окно незаметно
Системная инструкция, отправляемая с каждым запросом. Описания доступных функций у агента. История диалога, растущая с каждым ходом. Результаты вызовов инструментов. Место, зарезервированное под ответ.
В агентах именно накопление истории чаще всего приводит к переполнению на длинных сессиях — и проявляется это как внезапная потеря контекста в разговоре.
Симптомы переполнения. Отказ API с ошибкой лимита — очевидный случай; коварнее мягкие: модель «забывает» начало разговора, перестаёт соблюдать формат, теряет ограничения из инструкции. Если качество падает именно на длинных сессиях — первое подозрение на окно, и проверяется оно переносом фактов в начало текста.
Что делают при нехватке
Сжимают историю: старые ходы заменяют кратким пересказом. Сокращают системный промпт. Уменьшают число передаваемых фрагментов, повышая их качество реранкингом. Разбивают задачу на этапы с передачей только результата.
Чем плох пересказ. Сжатие истории в резюме освобождает окно, но теряет детали: точные цифры, имена, оговорки. Поэтому ключевые факты сохраняют дословно — отдельным блоком, а пересдают только периферию диалога.
Этапность вместо одного запроса. Задачу режут так, чтобы каждый этап получал только необходимое: документы сначала превращаются в тезисы, дальше работают тезисы. Плата — дополнительные обращения и потеря деталей на стыках, поэтому этапность применяют там, где нужна устойчивость, а не полнота.
Как проверить фактическую полезную длину
Заявленному значению верить не обязательно — его можно измерить. Приём простой: поместить проверяемый факт в начало, середину и конец длинного текста и задать по нему вопрос.
Если ответы по середине заметно хуже, полезная длина меньше заявленной, и это надо учитывать при проектировании: важное размещать по краям, а не полагаться на равномерность.
Замер стоит повторять при смене модели или её версии: поведение меняется, а заявленные цифры остаются прежними.
Контроль в эксплуатации. Доля запросов, вход которых превышает 80% полезного бюджета, — метрика, за которой следят на постоянной основе: её рост означает, что сценарий расползается и скоро упрётся либо в окно, либо в счёт, и решение — сокращать вход, а не менять модель.
Частые вопросы
Чем больше окно, тем лучше?
Не линейно. Модель принимает заявленный объём, но качественно работает с меньшим: факт в середине длинного контекста используется хуже, чем в начале или конце. Плюс растут стоимость и время ответа.
Можно ли отказаться от поиска, если окно большое?
На небольшой базе — да. На объёмах от сотен документов это дороже и менее точно, чем поиск: платить приходится за каждый переданный токен в каждом запросе, а качество ответа падает из-за обилия постороннего текста.
Почему бот «забывает» начало разговора?
Скорее всего, история диалога вытеснила его из окна. При длинной сессии старые ходы обрезаются или сжимаются, и упомянутое в начале перестаёт быть доступным. Лечится сжатием истории или явным сохранением ключевых фактов.
Сколько страниц помещается в окно на 128 тысяч токенов?
Ориентировочно около сотни страниц А4 плотного русского текста — при условии, что в запросе нет ничего, кроме текста. Реально меньше: системная инструкция, история и место под ответ съедают заметную долю, и рабочий бюджет считают от остатка.
Контекст не переполнен, но качество упало — окно ни при чём?
Всё равно при чём: деградация внимания к середине проявляется задолго до предела. Факт в середине сотни страниц модель использует хуже, чем по краям, без всякой ошибки лимита. Проверяется переносом факта в начало и конец одного и того же текста.
Нужно ли длинное окно, если есть RAG?
Окно в RAG — рабочий инструмент: в него должны помещаться выбранные фрагменты, инструкция и история с запасом. Нужна не максимальная цифра, а достаточная: на типовых сценариях хватает десятков тысяч токенов, а фактическая полезная длина проверяется на своей смеси документов.