Контекстное окно — это максимальный объём текста, который модель может принять в одном запросе. Между запросами она не помнит ничего: всё, что выглядит как память о разговоре, на самом деле присылается ей заново каждый раз. При переполнении окна что-то из этого текста приходится выбросить — и то, что именно выбрасывается, определяет и качество ответов, и размер счёта за месяц.
Отсюда симптом, который клиенты описывают как «бот тупит»: агент переспрашивает номер заказа, который человек назвал четыре реплики назад. Технически это не сбой и не плохая модель — это выпавший из окна кусок истории. И отсюда же вторая, менее заметная сторона: та же самая история — главная растущая статья расходов, потому что она отправляется целиком при каждой новой реплике.
Дальше — что именно складывается в окно и в каких пропорциях; три стратегии поведения при переполнении с их последствиями; почему большое окно проблему маскирует, а не решает; счёт за месяц при щедрой и аккуратной настройке на одинаковом потоке; и что записать в требования к подрядчику, чтобы не разбираться с этим после запуска.
Что складывается в окно на каждом запросе
В окно попадают четыре вещи, и три из них постоянные. Системная инструкция — правила поведения агента, стоп-темы, формат ответа: в рабочих системах это 600–1 200 токенов, и они одинаковы на каждой реплике. Найденные фрагменты базы знаний — пять фрагментов по 300–800 слов дают около 2 400 токенов. Сам вопрос — 100–200 токенов. И четвёртое: история разговора, единственная часть, которая растёт.
Ограничение на суммарную длину входа и выхода одного запроса, измеряется в токенах: примерно 2–3 символа русского текста, страница А4 — порядка 1 000–1 500 токенов. Окно в 128 000 токенов — это около 100–130 страниц за один запрос. Всё, что не поместилось, модель не увидит вовсе: она не «частично помнит», а не получает этот текст физически.
Посчитаем рост на модельном примере клиентского диалога. Инструкция 800 токенов, пять фрагментов базы 2 400, вопрос 150, ответ 300. Одна пара «вопрос — ответ» добавляет в историю 450 токенов, и на каждой следующей реплике вся накопленная история уходит в модель заново.
Столбчатая диаграмма из четырёх составных столбцов, подписанных «Реплика 1», «Реплика 5», «Реплика 10», «Реплика 20». Каждый столбец разбит на четыре сегмента снизу вверх: «Инструкция 800», «Фрагменты базы 2 400», «Вопрос 150» — одинаковой высоты во всех столбцах, и «История диалога» — 0, 1 800, 4 050, 8 550 токенов. Итоги над столбцами: 3 350, 5 150, 7 400, 11 900 токенов. Под каждым столбцом вторая подпись — цена реплики: 0,85 ₽, 1,21 ₽, 1,66 ₽, 2,56 ₽. Сегмент «История диалога» выделен тоном.
При цене 0,20 ₽ за 1 000 входных токенов и 0,60 ₽ за 1 000 выходных первая реплика стоит 3 350 × 0,20 / 1 000 + 300 × 0,60 / 1 000 = 0,85 ₽. Десятая — 7 400 входных, то есть 1,66 ₽. Двадцатая — 11 900 входных, 2,56 ₽. Двадцатая реплика дороже первой в три раза при том, что вопрос в ней такой же короткий. Именно поэтому прикидка бюджета чат-бота по цене одного обращения занижает результат в два-три раза: считать надо диалог целиком, а не реплику. Полную раскладку месячного счёта на такую систему мы разбираем в материале про структуру расходов на ИИ-агента.
Пять найденных фрагментов дают 2 400 токенов, пятнадцать — 7 500. На коротком диалоге разница незаметна, на четырнадцати репликах она превращается в основную часть счёта. Число фрагментов подбирается замером: если на контрольных 100 вопросах пять фрагментов дают ту же долю верных ответов, что и пятнадцать, платить за пятнадцать незачем.
Три стратегии при переполнении и их последствия
Когда суммарная длина подходит к границе окна, система обязана что-то сделать. Вариантов ровно три, и подрядчик обязан сказать, какой из них выбран, — потому что каждый ломается по-своему, и увидеть это в демонстрации на трёх репликах невозможно.
| Стратегия | Что происходит | Что теряется | Где применима |
|---|---|---|---|
| Обрезка начала | Из истории выбрасываются самые старые реплики, остальное уходит как есть | Названные в начале факты: номер заказа, имя, суть проблемы | Короткие диалоги до 8–10 реплик, где начало не несёт фактов |
| Сжатие в резюме | Старая часть истории заменяется коротким пересказом на 100–200 токенов | Детали и точные формулировки; резюме пишет та же модель и может ошибиться | Длинные консультации, где важен ход разговора, а не дословность |
| Вынос в отдельное хранилище | Факты из диалога вынимаются в поля (заказ, телефон, статус) и подставляются точечно | Ничего из фактов, но появляется отдельная работа и хранение персональных данных | Клиентские сценарии, где ошибка в номере заказа недопустима |
Три вертикальные колонки одинаковой ширины: «Обрезка начала», «Сжатие в резюме», «Вынос в хранилище». В каждой сверху маленькая схема ленты диалога из десяти квадратов: в первой первые три квадрата затемнены и перечёркнуты; во второй первые пять свёрнуты в один узкий квадрат с подписью «резюме»; в третьей над лентой добавлена карточка с полями «заказ №», «телефон», «статус» и стрелками к отдельным квадратам. Ниже в каждой колонке три строки: «Что теряется», «Стоимость доработки» (0 ₽ / 15 000–30 000 ₽ / 60 000–120 000 ₽), «152-ФЗ» (нет / нет / да, хранение персональных данных). Третья колонка выделена.
На практике рабочая схема почти всегда комбинированная: важные факты вынимаются в поля сразу, как только прозвучали, последние четыре-пять пар реплик держатся дословно, а всё, что старше, сжимается в короткое резюме. Такая настройка стоит 60 000–120 000 ₽ в рамках проекта и одновременно решает обе задачи — и удерживает факты, и не даёт счёту расти без ограничений.
У первых двух стратегий есть общее свойство, которое стоит понимать до выбора: обе теряют данные молча. Модель не сообщает, что часть разговора до неё не дошла, — она отвечает по тому, что получила, и отвечает уверенно. Поэтому единственный способ заметить потерю — журнал, где для каждой реплики записано, сколько токенов ушло в запрос и какие реплики истории в него вошли. Второе следствие: сжатие в резюме выполняет та же самая модель, то есть это ещё один вызов, который стоит денег и может ошибиться. В рабочих системах резюме пересобирают не на каждой реплике, а раз в четыре-пять пар — иначе строка расходов на сжатие догоняет ту, ради которой сжатие затевалось.
Как только имя, телефон и суть обращения сохраняются в отдельную таблицу и живут там дольше самого разговора, появляется полный набор обязанностей по 152-ФЗ: правовое основание, срок хранения, локализация базы в России, порядок удаления. Это не повод отказываться от схемы — это повод заранее записать срок хранения истории диалогов в требования и не оставлять его «бессрочно по умолчанию».
Почему большое окно — не бесплатное решение
Соблазн понятный: если окно большое, можно ничего не выбрасывать и не тратить деньги на настройку. Против этого работают две вещи, и обе измеримы.
Первая — деньги. Стоимость запроса растёт линейно вместе с длиной входа: провайдер тарифицирует каждый отправленный токен, и «на всякий случай положим побольше» оплачивается на каждой реплике каждого диалога. Экономии от большого окна не бывает в принципе — бывает только рост счёта, который не даёт прироста качества. К этому добавляется время ответа: чем длиннее вход, тем дольше модель его обрабатывает, и на десятках тысяч токенов задержка становится заметной человеку в чате.
Вторая — точность. Модель хуже находит нужный факт, если он лежит в середине длинного запроса, чем если он в начале или в конце. Проверяется это за час: берётся 40 контрольных фактов, каждый по очереди кладётся в начало, середину и конец длинного контекста, и задаётся один и тот же вопрос. В нашем модельном замере при 60 000 токенов контекста факт из первой пятой части находился в 38 случаях из 40, из конца — в 36, из середины — в 27. На 8 000 токенов разницы между позициями практически не было.
Двухосевой график. Ось X — позиция факта в контексте от начала к концу, ось Y — число найденных из 40. Сплошная линия «контекст 60 000 токенов» идёт от точки 38 в начале, проваливается до 27 в середине и поднимается до 36 в конце; провал выделен и подписан «середина длинного контекста». Пунктирная линия «контекст 8 000 токенов» идёт почти горизонтально на уровне 38–39. Подпись внизу: «модельный замер на 40 контрольных фактах».
Практический вывод из этого замера один: длинный контекст не заменяет поиск. Если вместо пяти найденных фрагментов класть в запрос сто страниц регламента целиком, качество ответов не вырастет, а упадёт — и одновременно вырастет счёт. Механизм, который позволяет отдавать модели только нужное, разобран в опорной статье раздела про поиск по документам; большое окно — не альтернатива ему, а страховка на случай, когда нужного всё-таки оказалось много.
Как это выглядит для клиента
Проблемы с контекстом почти никогда не выглядят как техническая ошибка. Они выглядят как невнимательность собеседника, и клиент воспринимает их именно так. Три типовых симптома, по которым это узнаётся в журнале.
- Агент переспрашивает то, что уже прозвучало: номер заказа, город доставки, модель товара. Почти всегда это обрезка начала истории, и почти всегда — на шестой-восьмой реплике, а не на второй, поэтому в приёмочной демонстрации это не видно.
- Агент отвечает по первой версии вопроса, хотя человек уже уточнил условия. Признак того, что уточнение попало в сжатое резюме и потеряло детали: в пересказе осталось «клиент спрашивает про возврат», а условие «товар был в акции» исчезло.
- Ответы становятся заметно длиннее и расплывчатее к концу диалога. История заняла большую часть окна, инструкция о формате ответа оказалась в его середине и перестала соблюдаться — это тот же провал точности, только страдает от него не факт, а правило.
Все три ловятся одинаково: в журнале для каждой реплики должно быть записано, сколько токенов ушло в запрос и какая часть истории в него попала. Если этих полей в журнале нет, разбор жалобы превращается в гадание — и это первое, что стоит потребовать от подрядчика. Про остальные причины, по которым клиенты раздражаются на автоматического собеседника, мы писали в отдельном разборе почему бот раздражает клиентов.
Счёт за месяц: 51 600 ₽ против 24 500 ₽
Вводные модельного примера: клиентский ассистент, 1 500 диалогов в месяц, средняя длина диалога 14 реплик. Инструкция 800 токенов, вопрос 150, ответ 300, пара реплик в истории 450 токенов. Сравниваем две настройки на одном и том же потоке. Щедрая: пятнадцать фрагментов базы в каждом запросе (7 500 токенов) и вся история целиком. Аккуратная: пять фрагментов (2 400 токенов), последние четыре пары реплик дословно и резюме на 150 токенов вместо остального.
Две горизонтальные составные полосы одинаковой шкалы, ось X в рублях от 0 до 60 000. Верхняя полоса «Щедрая настройка» длиной 51 555 ₽ разбита на два сегмента: «фрагменты базы, 15 штук» и «история целиком». Нижняя полоса «Аккуратная настройка» длиной 24 510 ₽ разбита на «фрагменты базы, 5 штук», «последние 4 пары реплик» и «резюме 150 токенов». Между полосами фигурная скобка с подписью «разница 27 045 ₽/мес, 324 540 ₽/год». Под диаграммой сноска «1 500 диалогов по 14 реплик, сентябрь 2026».
Арифметику можно повторить на калькуляторе. В щедром варианте каждая реплика несёт 800 + 7 500 + 150 = 8 450 токенов постоянной части плюс историю, которая на четырнадцатой реплике доходит до 5 850; сумма по всем четырнадцати репликам — 159 250 токенов. В аккуратном постоянная часть 3 350 токенов, а история после пятой реплики перестаёт расти и держится на 1 950 токенах (четыре пары плюс резюме); сумма — 69 100. Настройка второго варианта — это два дня работы инженера, около 45 000 ₽, и она окупается меньше чем за два месяца.
Два наблюдения к расчёту. Первое: качество ответов в аккуратном варианте не ниже — при условии, что число фрагментов подобрано замером, а не на глаз. Второе: экономия здесь пропорциональна длине диалога. На коротких обращениях в три-четыре реплики разница между настройками составит единицы тысяч рублей, и заниматься этим не стоит. Порог, за которым работа над контекстом окупается, — примерно от 1 000 диалогов в месяц при средней длине от 8 реплик.
Что писать в требованиях подрядчику
Всё перечисленное настраивается один раз и почти никогда не переделывается потом, потому что переделка задевает и логику агента, и хранение данных. Поэтому четыре пункта ниже должны попасть в техническое задание до начала работ — как это устроено в целом, разобрано в материале про техническое задание на автоматизацию.
- 1Предельная длина истории и стратегия при её превышении, названная явно: обрезка, сжатие в резюме или вынос фактов в поля. Формулировка вида «система корректно обрабатывает длинные диалоги» ничего не значит и не проверяется на приёмке.
- 2Список фактов, которые вынимаются в отдельные поля сразу, как только прозвучали: номер заказа, телефон, город, артикул, суть обращения. Именно эти поля агент не имеет права терять и переспрашивать, и именно по ним проверяется приёмка.
- 3Число фрагментов базы, попадающих в запрос, и обоснование этого числа замером. Разница между пятью и пятнадцатью фрагментами в нашем примере — 27 045 ₽ в месяц, поэтому цифра должна быть подобрана, а не взята по умолчанию.
- 4Состав журнала: для каждой реплики фиксируются длина запроса в токенах, число переданных фрагментов и то, какая часть истории вошла в контекст. Без этих полей ни одна жалоба на «бот забыл» не разбирается, а спор с подрядчиком превращается в обмен мнениями.
И один пункт, который стоит проверить на приёмке отдельно: диалог из 15 реплик. Демонстрации почти всегда идут на трёх-четырёх репликах, где переполнения нет и все стратегии выглядят одинаково хорошо. Проведите один длинный разговор с намеренным возвратом к сказанному в самом начале — этот тест занимает пять минут и показывает больше, чем весь остальной приёмочный сценарий.
Когда об этом можно не думать
Работа с контекстом — не универсальное требование. Есть целые классы задач, где переполнение невозможно физически, и тратить на это бюджет не нужно.
- Однократные операции без диалога: классификация письма, извлечение полей из документа, короткое резюме звонка. История здесь не накапливается вовсе, длина запроса постоянна, и настраивать нечего.
- Диалоги до пяти-шести реплик. В нашем примере это 3 350–5 600 токенов на реплику — до границы окна далеко, обрезка не наступает, и разница между стратегиями остаётся арифметической.
- Меньше 300–400 диалогов в месяц. Даже щедрая настройка даст около 10 300 ₽ в месяц при 300 диалогах, и экономить здесь нечего: 45 000 ₽ на настройку не окупятся за год.
- Внутренний ассистент по регламентам, где каждый вопрос самостоятельный. Сотрудник спрашивает, получает ответ и уходит; история между вопросами не нужна, и её лучше вообще не вести — заодно снимается вопрос о хранении.
Зеркальный признак: думать о контексте нужно, когда одновременно верны три вещи — разговор идёт больше восьми реплик, в нём звучат факты, которые нельзя терять, и таких разговоров больше тысячи в месяц. Если верно только первое, хватит обрезки начала. Если первое и второе, но объём маленький — хватит выноса фактов в поля без сжатия. Полную картину того, из чего складывается счёт за такую систему и какие ещё решения на него влияют, мы разбираем в статье про четыре подхода к подключению модели к данным компании.
