Context Window

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

Коротко

Коротко. Context window — это рабочее поле модели на время одного запроса. Если в нём лежат инструкции, переписка, несколько документов и описания инструментов, все они делят общий бюджет. То, что приложение не передало в текущий вызов, модель прочитать не может.

Что это такое

Контекстное окно часто называют оперативной памятью LLM. Сравнение полезное, но не буквальное: модель не хранит внутри окна отдельные файлы и мысли. Она получает одну последовательность токенов и вычисляет связи между её частями.

В контекст могут входить:

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

Точный способ подсчёта зависит от API. У одной модели вход и выход делят общий предел, у другой дополнительно указан отдельный максимум ответа. Поэтому одна цифра в таблице провайдера не всегда описывает весь доступный объём.

Почему окно ограничено

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

Кроме технического лимита есть предел обучения. Если модель редко видела очень длинные и хорошо размеченные примеры, простое расширение допустимой длины не научит её уверенно связывать детали на огромном расстоянии.

Что происходит между сообщениями

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

Когда переписка становится длинной, интерфейс может:

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

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

Пример бюджета

Внутренний помощник отвечает по документации компании. Один запрос условно состоит из таких частей:

инструкция и формат ответа        10%
история короткого диалога         15%
фрагменты найденных документов    45%
описания и результаты инструментов 10%
текущий вопрос                     5%
запас под ответ                   15%

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

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

Эффективный контекст

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

Проверка зависит от задачи. Для анализа договора важно найти условие в середине и правильно связать его с приложением. Для кода — проследить вызов через несколько файлов. Для диалога — не потерять раннее ограничение после длинной переписки.

Тест с одной спрятанной фразой, или needle in a haystack, проверяет поиск детали, но не заменяет сложную работу с документом. Модель может найти уникальный код и при этом плохо сравнить две близкие формулировки.

Почему длинный контекст иногда мешает

• Шум. Нерелевантные фрагменты конкурируют с нужными сведениями.
• Противоречия. В старой и новой версии документа могут быть разные правила.
• Потеря позиции. Важная деталь оказывается среди большого числа похожих мест.
• Цена и задержка. Модель каждый раз должна обработать длинный вход.
• Скрытые инструкции. Загруженный документ может содержать prompt injection.
• Обрезка. Приложение способно сократить контекст без очевидного сообщения пользователю.

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

С чем часто путают

• Контекст и память. Контекст существует внутри текущего вызова; память — механизм приложения, который выбирает сведения для будущих вызовов.
• Контекст и параметры. Параметры — обученные веса модели. Контекст — временные данные запроса.
• Контекст и RAG. RAG ищет информацию снаружи и добавляет найденные фрагменты внутрь окна.
• Длинное окно и хорошее рассуждение. Возможность принять большой файл не гарантирует правильного вывода по нему.
• Лимит модели и лимит интерфейса. Приложение может разрешать меньше, чем базовый API, или тратить часть окна на свои инструкции и инструменты.
• Токены и слова. Их соотношение меняется вместе с языком, кодом и токенизатором.

Как проектировать длинный запрос

Спокойная последовательность обычно выглядит так:

1. оставить только инструкции, влияющие на результат;
2. найти релевантные фрагменты, а не загружать архив целиком;
3. сохранить заголовок, источник и дату каждого фрагмента;
4. отделить недоверенный текст документов от системных правил;
5. оставить место под нужный формат ответа;
6. проверить поведение на коротких, средних и почти предельных запросах;
7. измерить качество, задержку и стоимость вместе.

Если документ нужно разобрать целиком, его можно обрабатывать частями, строить промежуточные заметки и затем сводить их. Такой процесс сложнее одного огромного запроса, зато позволяет проверить, откуда появился каждый вывод.

Частые ошибки и заблуждения

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

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

«Модель одинаково хорошо видит каждую позицию». Качество может меняться внутри длинной последовательности. Это проверяют на своём типе документов, а не предполагают по максимальному числу токенов.

«Любой старый ответ остаётся в чате». Интерфейс может пересказать или отбросить историю. Важное решение лучше хранить в явном документе или состоянии приложения.

«Расширение окна не меняет расходы». Длинный вход требует больше обработки и памяти для KV-кэша. Конкретная зависимость определяется архитектурой и тарифом.

Частые вопросы

Что будет, если превысить лимит? API может вернуть ошибку, обрезать вход по заданному правилу или ограничить ответ. Чат-приложение может сократить историю заранее. Точное поведение описано в документации конкретного интерфейса.

Где узнать размер окна? В карточке точной модели или документации API. Название семейства недостаточно: разные версии и точки доступа могут иметь разные пределы.

Можно ли перевести токены в страницы? Только приблизительно. Надёжный расчёт делает токенизатор выбранной модели на самом документе.

Можно ли расширить окно локальной модели? Некоторые архитектуры допускают изменение позиционных настроек или дообучение на длинных последовательностях. Это может увеличить технический лимит и одновременно ухудшить качество, поэтому результат проверяется отдельными тестами.

Когда нужен RAG, если окно и так большое? RAG полезен не только из-за лимита. Он выбирает актуальные фрагменты, сохраняет ссылки на источники и помогает не смешивать весь корпус в одном запросе.

Главное

Контекстное окно — ограниченное рабочее поле LLM. Большой предел помогает читать длинные материалы, но не заменяет поиск, память приложения и проверку качества. Удачный контекст содержит достаточно сведений для решения задачи, ясно отделяет источники от инструкций и не заставляет модель искать одну важную строку среди ненужного архива.