Контекстное окно

Зачем это знать

• Понять, почему длинный диалог с ассистентом начинает противоречить сам себе
• Понять, за что растёт счёт, когда объём работы остался прежним
• Отличать задачу, где хватит одного запроса, от задачи, где нужен поиск по базе

Что такое контекстное окно простыми словами

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

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

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

Как это работает

1. Всё собирают в одну стопку. Перед каждым обращением система складывает вместе инструкцию, найденные документы, историю разговора и новый вопрос. Модель получает это одним куском.
2. Стопку меряют в токенах. У разных моделей лимит отличается на порядки — от десятков тысяч токенов до миллиона. Грубый ориентир для прикидки: тысяча токенов — это примерно страница-полторы русского текста, и тот же текст на английском занимает в полтора-два раза меньше токенов. Точный счёт зависит от модели, поэтому объём своих документов считают счётчиком той модели, с которой работают.
3. Лишнее отсекают. Когда стопка перестаёт помещаться, из неё убирают самое старое — обычно начало переписки. Реже применяют сжатие: старые реплики заменяют короткой сводкой.
4. Модель читает стопку целиком и отвечает. За чтение вы платите как за входные токены, за ответ — как за выходные, и выходные дороже.
5. Следующее обращение начинается с нуля. Собственной памяти между запросами у модели нет. Память создаёт система вокруг неё: она каждый раз заново подкладывает переписку в стопку и каждый раз заново её оплачивает.

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

Пример из практики

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

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

Что это даёт бизнесу

• Счёт становится объяснимым. Расходы растут вместе с длиной каждого обращения: тысяча коротких запросов обходится дешевле сотни длинных. Чистка контекста уменьшает счёт без переписывания системы, поэтому с неё разумно начинать разговор об экономии.
• Меньше повторной работы людей. Ассистент, теряющий данные из начала диалога, возвращает задачу оператору. Каждый такой возврат — это время сотрудника и повторный рассказ клиента о том, что он уже излагал.
• Понятная граница проекта. Размер окна сразу отвечает на вопрос, хватит ли одного запроса или нужна отдельная система поиска по документам. Это проекты разного срока и разной цены, и выяснять это лучше до подписания договора.
• Риск становится видимым. Обрезка контекста происходит молча. Если система записывает такие случаи, вы узнаёте о потере данных из отчёта, а не из жалобы клиента.

Когда без этого можно обойтись

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

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

Что важно проверить

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

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