Контекстное окно — это предельный объём текста, который модель может обработать за один запрос: инструкция, документы, история разговора и её собственный ответ вместе. Измеряется в токенах — кусочках примерно по 2–3 символа русского текста. Окно в 128 000 токенов означает, что в один запрос помещается около сотни страниц А4, и ни строчкой больше.

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

Дальше — модельные расчёты по состоянию на сентябрь 2026 года при ставках 0,20 ₽ за 1 000 входных токенов и 0,60 ₽ за 1 000 выходных. Что технически происходит в момент переполнения и какие три стратегии обрезки существуют, подробно разобрано в большом материале про контекстное окно; здесь — словарная статья: сколько это в страницах, во что превращается в деньгах и что спросить у подрядчика.

Определение через рабочий стол

Что это значитКонтекстное окно

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

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

Ещё одна деталь, о которую спотыкаются на приёмке: ответ модели тоже занимает место на этом столе. Окно ограничивает вход и выход суммарно, поэтому запрос, забитый под завязку, оставляет модели несколько строк на ответ — и она обрывает его на середине фразы. Выглядит это как поломка, а лечится вычитанием: под ответ резервируют место заранее, обычно 1 000–2 000 токенов, и на эту величину уменьшают то, что кладут на вход.

Сколько это в страницах и в репликах диалога

Цифра «128k» ничего не говорит владельцу бизнеса. Переведём три типовых размера окна в величины, которыми можно оперировать при постановке задачи. Расчёт реплик — для клиентского ассистента с постоянной частью запроса 2 820 токенов (инструкция, фрагменты базы и вопрос) и парой реплик по 370 токенов.

ОкноСтраниц А4Пар реплик диалогаЧто помещается на практике
8 000 токенов5–8около 14Один договор без приложений или короткий разговор
32 000 токенов21–32около 78Регламент среднего размера, длинная переписка по сделке
128 000 токенов85–128около 338Договор с приложениями целиком, расшифровки нескольких встреч

Из таблицы видно, что для типичного клиентского диалога окна хватает с огромным запасом: до предела в 8 000 токенов доходят разговоры длиной в четырнадцать пар реплик, а средний разговор в поддержке — пять. Настоящие проблемы с окном начинаются не в чатах, а на документах: там 90 страниц договора съедают его целиком одним движением.

сравнениеchto-takoe-kontekstnoe-okno-modeli--01
Три размера контекстного окна в пересчёте на страницы А4 и пары реплик диалога

Три вложенных прямоугольника разной величины, подписанных снаружи «8 000 токенов», «32 000 токенов», «128 000 токенов». Внутри каждого две строки подписей: сверху «страниц А4: 5–8» / «21–32» / «85–128», снизу «пар реплик: ~14» / «~78» / «~338». В самом маленьком прямоугольнике дополнительно помечен закрашенный сегмент с подписью «постоянная часть запроса — 2 820 токенов». Тонкие чертёжные линии, подписи по-русски.

Для разговоров окна хватает почти всегда — упирается всё в документы

Почему большое окно не заменяет поиск по базе

Соблазн понятный: зачем строить поиск, если можно взять модель с большим окном и класть туда весь документ. Считаем на модельном примере. Юридический отдел задаёт 400 вопросов в месяц по рамочному договору на 90 страниц — это 112 500 токенов. Первый способ: подавать договор целиком. Второй: подавать пять найденных фрагментов вместе с короткой инструкцией — это 700 токенов инструкции, пять фрагментов по 500 и вопрос на 150, всего 3 350.

Цена одного вопроса по договору на 90 страниц, 400 вопросов в месяц
Весь договор в окно: 112 500 входных токенов × 0,20 ₽ / 1 00022,50 ₽ за вопрос
Ответ модели: 400 выходных токенов × 0,60 ₽ / 1 0000,24 ₽ за вопрос
Пять фрагментов и инструкция: 3 350 входных токенов0,67 ₽ за вопрос
Тот же ответ модели0,24 ₽ за вопрос
Месяц при подаче документа целиком: 400 × 22,74 ₽9 096 ₽/мес
Месяц при поиске по фрагментам: 400 × 0,91 ₽364 ₽/мес
ИтогоРазница 8 732 ₽/мес — в 25 раз на одном и том же вопросе

И сразу честная оговорка, которую редко делают продавцы поиска по базе: сама по себе экономия на токенах внедрение не окупает. Поиск по базе на такой объём документов стоит около 192 000 ₽, и 8 732 ₽ в месяц вернут эти деньги за 22 месяца — цифра, ради которой проект не начинают. Настоящая причина строить поиск другая, и она про качество.

Модель хуже находит нужное, когда оно лежит в середине длинного запроса. В нашем модельном замере на 30 контрольных вопросах по тому же договору подача документа целиком дала 21 верный ответ из 30, а подача пяти найденных фрагментов — 26 из 30. Плюс время: запрос на 112 500 токенов обрабатывается заметно дольше, и юрист ждёт ответа десятки секунд вместо двух-трёх. Механику поиска, который отбирает эти пять фрагментов, мы разбираем в статье про эмбеддинги и векторный поиск.

сравнениеchto-takoe-kontekstnoe-okno-modeli--02
Весь договор в окно против пяти фрагментов: 22,74 рубля и 21 из 30 против 0,91 рубля и 26 из 30

Две колонки сравнения. Левая подписана «Весь договор в окно»: под ней три строки — «112 500 токенов», «22,74 ₽ за вопрос», «21 верный ответ из 30». Правая подписана «Пять найденных фрагментов»: «3 350 токенов», «0,91 ₽ за вопрос», «26 верных ответов из 30». Под колонками общая подпись «400 вопросов в месяц: 9 096 ₽ против 364 ₽». Числа «21 из 30» и «26 из 30» показаны маленькими шкалами-полосками. Тонкие чертёжные линии, подписи по-русски.

Длинный запрос дороже и точнее не становится — нужный пункт теряется в середине

Симптомы упора в окно, которые видит бизнес

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

  • Агент забыл условие из первого сообщения. Клиент назвал город в начале разговора, к десятой реплике агент спрашивает его снова. Начало истории вытеснено, и вытеснено молча.
  • Ответ по устаревшей версии регламента. В запрос попали фрагменты сразу нескольких редакций, действующая оказалась в хвосте и не поместилась. Со стороны выглядит как ошибка модели, а на деле — как ошибка отбора.
  • Пункт из середины длинного документа не находится. Тот самый эффект: 21 верный ответ из 30 вместо 26. Особенно заметно на договорах с приложениями и на длинных технических условиях.
  • Ответ приходит заметно медленнее. Время обработки растёт вместе с длиной запроса. Если «бот стал тормозить» совпало по времени с расширением базы знаний — почти наверняка выросло число фрагментов в каждом запросе. Другие причины раздражения клиентов разобраны в отдельной статье.

Что делают вместо расширения окна

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

  1. 1Сжатие истории. Последние одна-две пары реплик дословно, остальное — резюме на 120–200 токенов. Диалог перестаёт расти после третьей реплики, и до предела окна дело не доходит никогда.
  2. 2Вынос неизменных правил в короткую инструкцию. Если правило одинаково для всех обращений, его место в инструкции, а не в подставляемых фрагментах. Инструкцию при этом надо чистить: она разрастается сама собой.
  3. 3Поиск по базе вместо загрузки документа целиком. Пять фрагментов вместо 90 страниц — это и дешевле, и точнее. Как устроен такой поиск и что в нём делает заказчик, разобрано в статье про RAG.
  4. 4Журнал длины запроса. Для каждой реплики фиксируется, сколько токенов ушло в модель и что именно вошло в контекст. Без этих полей жалоба «агент забыл» не разбирается вообще — остаётся только гадать. Как складывается стоимость этих токенов, посчитано в материале про токены и счёт.
Три вопроса подрядчику до подписания

Первый: какой объём диалога сохраняется дословно и что происходит с остальным? Второй: что система делает при превышении окна — обрезает молча, сжимает или отказывается отвечать? Третий: где это видно в журнале? Если на третий вопрос нет внятного ответа, первые два тоже проверить будет нечем.

Когда об окне можно не думать

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

  • Разговоры короче пяти реплик. По арифметике из таблицы это 2 820–4 300 токенов на запрос — до предела в 8 000 далеко, обрезка не наступает, все стратегии ведут себя одинаково.
  • Задача без диалога вовсе. Классификация одного письма, разбор одного документа, извлечение полей из счёта — здесь каждый запрос независим, история не копится. Такие задачи мы собираем как извлечение данных из договоров, и окно там ограничивает только размер самого документа.
  • Поток меньше 1 000 обращений в месяц. Даже полная разница между аккуратной и небрежной настройкой останется в пределах нескольких тысяч рублей — это дешевле, чем работа по оптимизации. Достаточно потребовать, чтобы длина запроса писалась в журнал: пригодится, когда объём вырастет.

Большое окно не делает модель внимательнее. Оно позволяет положить перед ней больше бумаг — и оплатить каждую из них на каждом запросе.