Что такое контекстное окно модели и почему ИИ забывает длинный разговор

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

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

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

Окно, история чата и обучение модели — разные вещи

В документации Anthropic контекст описан как рабочий объём информации для ответа. Он отличается от данных, на которых модель обучалась. Документ, переданный в запросе, не становится постоянным знанием модели после одного разговора.

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

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

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

Что занимает место в запросе

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

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

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

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

Как посчитать бюджет контекста

Начните с лимита выбранной модели именно в используемом API или приложении. Затем узнайте, какой резерв ответа и служебные правила применяет ваш провайдер. Цифра на рекламной странице не всегда описывает ограничения конкретной интеграции.

Для предварительного планирования используйте простую формулу: доступный остаток равен лимиту минус инструкции, история, документы, инструменты и резерв ответа. Это учебная модель бюджета. В рабочем процессе окончательный расчёт выполняет токенизатор или API подсчёта выбранного провайдера, с учётом его правил.

В этом примере 32 000 — выбранное для расчёта число, не характеристика конкретной модели. Если приложение добавит ещё 7 000 токенов документов, плановый бюджет будет превышен на 2 000. Как система отреагирует — вернёт ошибку, сократит данные или остановит ответ — нужно проверить по документации и тесту интеграции.

Не переводите остаток в обещание «поместится сто страниц». Распознанные таблицы, код, язык и формат документа меняют токенизацию. Измеряйте подготовленный текст, который действительно отправляется, а не размер PDF в мегабайтах.

Почему большое окно не гарантирует правильный ответ

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

Поэтому проверку «всё поместилось» дополняют проверкой результата. В учебном договоре цена действует только для одного филиала. Попросите модель назвать цену для другого филиала. Корректный ответ должен учесть ограничение либо сказать, что условия для второго филиала отсутствуют.

Увеличение окна помогает, когда задаче действительно нужно одновременно сравнивать большой набор связанных материалов. Однако добавление всего архива затрудняет понимание причины ошибки. Сначала сравните два запроса: с компактным набором нужных разделов и с полным документом. Запишите, какой вариант точнее на одинаковых вопросах.

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

Что делает сокращение истории

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

Предположим, пользователь написал: «Бюджет 120 тысяч, аренда включена, оборудование покупать нельзя». Плохое резюме сохранит только «обсуждаем запуск проекта с ограниченным бюджетом». Следующий ответ уже не обязан учитывать сумму и запрет покупки, если приложение не передало их отдельно.

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

При приёмке проверьте разговор до и после сокращения. Используйте те же вопросы об обязательных условиях. Если факт потерялся, исправляется механизм сохранения состояния. Бесконечное повторение «пожалуйста, не забывай» в сообщениях делает процесс зависимым от внимательности оператора.

Чем поиск по документам отличается от большой истории

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

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

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

Для долговременной работы с клиентом текущая задача может потребовать одновременно карточку из CRM, несколько фактов из истории и найденный регламент. Каждый источник выполняет свою роль. Не пытайтесь заменить всю эту систему одним длинным разговором, который никто не умеет восстановить после сбоя.

Почему кэширование не увеличивает окно

Повторяемая инструкция или неизменный документ могут обрабатываться через кэширование запросов. В документации Anthropic о prompt caching описано повторное использование префикса запроса для снижения затрат и задержки при подходящих условиях.

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

Если расходы растут, сначала разделите причины. Запросы стали длиннее? Агент делает больше шагов? Кэш редко используется? Пользователи получают более длинные ответы? Одинаковая итоговая сумма может складываться из разных механизмов.

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

Проверка памяти на одном учебном разговоре

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

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

Сохраняйте четыре вещи: вопрос, переданный состав контекста, ответ и перечень пропущенных условий. Для контроля используйте только доступный вход и выход; скрытые внутренние рассуждения модели для такой проверки не нужны.

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

Когда менять модель, а когда процесс

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

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

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

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