Контекстное окно — это предельный объём информации, с которым языковая модель работает за одно обращение. В это окно должны помещаться переданные материалы и создаваемый ответ. Поэтому размер документа — только часть расчёта.
Допустим, специалист хочет подготовить для менеджеров памятку на основе русскоязычной инструкции Битрикс24 о сделках. Он передаёт модели текст инструкции, вопрос и предыдущие уточнения. Разберём, как оценить объём такого запроса и оставить место для ответа.
Что именно ограничивает контекстное окно
Одно обращение для подготовки памятки выглядело бы так: выбранный текст инструкции и вопрос специалиста передаются модели, затем модель составляет ответ. Доступное место нужно оценивать именно для этого обращения.
Здесь полезно различать три вещи:
- Знания из обучения — то, что модель усвоила до работы с вашим запросом. Размер окна не показывает объём этих знаний.
- Сохранённая переписка — история, которую хранит приложение. Наличие старого сообщения в чате само по себе не означает, что приложение передаст его при следующем обращении.
- Контекст обращения — информация, фактически доступная модели в этом запросе. Для расчёта важно установить, какие материалы и предыдущие сообщения вошли именно в него.
Результат генерации тоже занимает место в окне. Если модель использует внутренние рассуждения (reasoning), правила их учёта нужно проверять для конкретной модели и способа обращения к ней.
Подбор информации для запроса — отдельная задача, которой занимается контекстная инженерия. Здесь нас интересует объём информации. Чтобы сравнить его с ограничением модели, сначала нужна общая единица измерения: количества страниц документа для этого недостаточно.
Почему размер документа считают в токенах
Для такого расчёта объём текста измеряют в токенах. Токен может соответствовать целому слову, части слова или отдельному символу. Токенизатор — программа, которая разбивает текст на эти единицы по определённым правилам. Поэтому число слов само по себе ещё не даёт числа токенов.
Вот результат локального измерения учебной фразы «Сделка создана.» в tiktoken 0.12.0 с кодировкой o200k_base:
«С» | «дел» | «ка» | « создан» | «а» | «.»
Получилось 6 токенов. В четвёртый фрагмент входит пробел перед «создан»; точка тоже занимает отдельный токен. Это разбиение относится к названной кодировке. Переносить его на токенизаторы Яндекса, GigaChat или других моделей нельзя.
Количество страниц зависит от оформления документа. Среднее число символов или слов на токен тоже не заменяет точный счёт. Для бюджета нужны конкретный текст и подходящий для выбранной модели счётчик.
Значит, в задаче с памяткой нужно посчитать токены в тексте инструкции Битрикс24. Затем нужно учесть остальные части обращения: одна инструкция ещё не составляет весь запрос.
Что занимает окно помимо документа
Вход запроса может включать указания для модели, вопрос пользователя, выбранные предыдущие сообщения, содержимое документа, описания инструментов и полученные от них результаты. Считать нужно те части, которые действительно передаются при обращении.
Загрузка файла ещё не доказывает, что модель получит весь его текст. Например, по документации OpenAI на 9 октября 2026 года инструмент File Search в Responses API извлекает релевантную информацию из предварительно загруженных файлов. Это пример конкретного способа передачи материала. Как материал передаётся в другом чате, нужно выяснять отдельно. В нашем учебном расчёте принято другое условие: весь извлечённый текст инструкции Битрикс24 включён в один запрос.
После измерения доступного входа можно предварительно оценить остаток:
Остаток = применимый предел окна − измеренный вход − выбранный резерв выхода.
Резерв выхода — место, которое мы планируем оставить для генерации. Его нужно сопоставить с отдельным верхним пределом выхода, допустимым для выбранной модели и настроек запроса. Ни резерв, ни этот предел не означают, что видимый ответ обязательно получится такой длины. Учёт внутренних рассуждений, прошлых блоков рассуждений и материалов вроде изображений зависит от модели и API. Результаты инструментов, переданные модели, также нужно отличать от ограничения на создаваемый ею ответ.
Если скрытые инструкции приложения или другие составляющие неизвестны, записываем их отдельно как неизвестные. Подставлять вместо них ноль нельзя: полученный остаток ещё не подтверждает, что весь запрос будет принят.
Теперь можно сравнить два варианта с одной инструкцией и разным объёмом истории. Это покажет, сколько места остаётся для выбранного резерва выхода в каждом варианте.
Как оценить, поместится ли документ: пример с инструкцией Битрикс24
Возьмём русскую инструкцию «Сделки: что это и как с ними работать» и оценим запрос для подготовки памятки менеджерам. Весь извлечённый текст включён в один запрос; меняется только объём синтетической истории — короткой или искусственно увеличенной.
В tiktoken 0.12.0 с кодировкой o200k_base инструкция занимает 2559 токенов. Объединённый видимый текст запроса с короткой историей — 2637, с увеличенной — 6683. Документ уже входит в эти суммы: прибавлять 2559 повторно не нужно. Счёт относится к o200k_base; переносить его на Яндекс, GigaChat, Claude или Gemini нельзя.
Для сравнения примем окно 8192 токена и резерв выхода 2000 токенов. Это арифметические допущения, а не лимиты Битрикс24, BitrixGPT или выбранной модели. Измерен только видимый текст: служебное оформление сообщений API, скрытые инструкции, инструменты и reasoning остаются за пределами подсчёта.
Все значения в таблице указаны в токенах.
| Показатель | Короткая история | Искусственно увеличенная история |
|---|---|---|
| Условное окно | 8192 | 8192 |
| Измеренный объединённый текст | 2637 | 6683 |
| Остаток после текста | 5555 | 1509 |
| Выбранный резерв выхода | 2000 | 2000 |
| Остаток после резерва | 3555 | −491 |
Во втором варианте измеренный вход помещается в условное окно: 6683 меньше 8192. После текста остаётся 1509 токенов, поэтому для выбранного резерва в 2000 токенов не хватает 491 токена ещё до учёта неизвестных составляющих. Значение −491 показывает нехватку места для резерва, а не зафиксированную ошибку API. Остаток 3555 в первом варианте тоже предварительный: неизмеренные части могут его уменьшить.
При такой нехватке можно сократить ненужный вход, пересмотреть резерв с учётом требуемой памятки или изменить способ передачи материала, затем пересчитать бюджет.
Примечание к расчёту. Инструкция обновлена 22 июля; для расчёта использован её снимок от 9 октября 2026 года. Из HTML извлечён текст вкладок для компьютера и мобильного приложения, без изображений и связанных документов. История увеличена с одного до 120 повторений учебного сообщения. Нормализация, точные тексты и скрипт сохранены в методике расчёта. Выполнен только подсчёт: генерации памятки, проверки её качества и испытания API не было.
Что происходит, когда контекстное окно переполняется
Универсальной реакции нет. Приложение может хранить длинную переписку, но перед очередным обращением менять состав передаваемой истории. Поэтому видимая длина чата ещё не объясняет, что получит модель.
В документации конкретных систем встречаются разные механизмы:
- Отказ или остановка. Сервис отклоняет слишком большой вход либо прекращает генерацию при достижении ограничения. Это не обеспечивает продолжение обработки всего материала.
- Обрезание. Старые элементы удаляются из передаваемого контекста.
- Сжатие. Подробная история заменяется сокращённым представлением, которое используется в следующих обращениях.
Обрезание и сжатие меняют информацию, доступную модели. Их наличие и условия включения нужно проверять в выбранном инструменте: общего автоматического режима для всех чатов нет.
Конкретный пример — Responses API Яндекс AI Studio. По документации на 9 октября 2026 года при truncation=auto сервис может удалять старые сообщения и вызовы инструментов, если объём истории превышает размер окна. Системные указания модели — system prompt — и список инструментов сохраняются. При этом Яндекс предупреждает: даже с включённым обрезанием запрос и ответ в некоторых случаях могут не поместиться.
Документация Claude API на ту же дату различает две ситуации. Если один только вход превышает окно, API возвращает ошибку. Для Claude 4.5 и новее запрос принимается, если вход помещается в окно, но вместе с заданным пределом генерации max_tokens превышает окно. Если при этом генерация достигает границы окна, она останавливается.
Даже когда приложение приняло нужный материал, правильность будущей памятки остаётся отдельным вопросом.
Почему большой контекст не гарантирует правильный ответ
Поместить материал в окно и правильно использовать нужные сведения — разные задачи. Подсчёт токенов помогает оценить вместимость, но не показывает, какие действия и условия модель сохранит в ответе.
В исследовании Lost in the Middle (2023) результаты часто были лучше, когда нужная информация находилась в начале или конце контекста, и заметно ухудшались, когда её требовалось найти в середине. В RULER (2024), где использовались синтетические задачи разной сложности, у большинства протестированных моделей результаты существенно снижались с увеличением длины контекста.
Эти наблюдения относятся к исследованным моделям и условиям. Они объясняют, почему вместимость и качество нужно проверять отдельно, но не позволяют заранее оценить современную модель на вашей инструкции.
Для предполагаемой памятки по Битрикс24 нужна отдельная проверка после генерации: сопоставить ответ с исходной инструкцией и установить, сохранены ли необходимые менеджерам действия и условия их выполнения. Наличие свободного места в окне эту проверку не заменяет.
Примечание к источникам. Результаты обеих работ изложены по их аннотациям; полного разбора методик и независимого повторения исследований здесь нет.
Как оценить свой материал перед отправкой
В готовом чате начните с опубликованных ограничений приложения и правил работы с файлами. Если состав передаваемого контекста недоступен, по одному видимому тексту нельзя подтвердить полный бюджет запроса. При работе через API состав запроса и средства подсчёта проверяет разработчик или интегратор.
Для одного документа последовательность остаётся общей; недоступные сведения отмечайте как неизвестные:
- Установите, что будет передано. Уточните приложение и модель, передачу полного текста или фрагментов, состав истории — насколько это позволяет ваш способ работы.
- Проверьте ограничения. Найдите опубликованные пределы окна и выхода, правила обработки истории и файлов.
- Измерьте известный вход. Используйте точный текст и подходящий для модели счётчик, если он доступен.
- Выберите резерв выхода. Соотнесите его с нужным результатом и допустимым пределом ответа.
- Запишите предварительный остаток и неизвестное. Расчёт возможен для известных величин; недоступные части нельзя считать нулевыми.
- При нехватке измените материал и пересчитайте. Уберите нерелевантный вход или историю, обоснованно пересмотрите резерв либо измените способ передачи. После сокращения проверьте, сохранились ли необходимые сведения.
Для интегратора пример средства подсчёта есть в документации GigaChat: на 9 октября 2026 года метод /tokens/count позволяет считать токены переданного текста с указанием модели. Такой подсчёт не оценивает будущий ответ, текстовый файл или изображение. Передачу извлечённого текста нужно отличать от передачи файла-вложения.
Техническое примечание. В примере той же документации total_tokens — тарифицируемая сумма после вычитания кешированных токенов, а не полный размер контекста. Смысл показателей отчёта зависит от провайдера.
Требуемый результат задайте через формулировку запроса. Для памятки сначала оцените доступный бюджет, а после получения ответа сверьте необходимые действия и условия с инструкцией. Вместимость обращения и пригодность текста для работы проверяются отдельно.
