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

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

Это не человеческая забывчивость и не признак того, что модель «устала». Причина обычно в том, какие данные приложение отправило в очередном API-запросе и поместились ли они в доступный контекст.

Как устроено контекстное окно

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

• системная инструкция;
• сообщения пользователя и ассистента;
• добавленные документы или фрагменты базы знаний;
• результаты вызова инструментов;
• описание доступных функций;
• место, зарезервированное под новый ответ.

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

Факт: контекстное окно ограничено у любой модели. Конкретный предел зависит от семейства, модели и API. Проверять его нужно в документации или каталоге выбранной модели, а не оценивать по длине переписки на экране.

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

Почему начало разговора пропадает

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

Есть и другие причины:

• история обрезается по количеству сообщений, а не по смыслу;
• длинный документ вытесняет часть диалога;
• результаты инструментов занимают место вместе с сообщениями;
• под ответ зарезервировано слишком много токенов;
• краткое содержание диалога составлено неточно;
• важное требование было упомянуто один раз и затерялось среди деталей;
• при следующем API-запросе приложение не передало нужную реплику.

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

Как проверить, что именно видит модель

Сначала запишите исходные требования в явном виде. Затем попросите модель повторить их перед выполнением задачи.

Готовый промпт:

Ниже будет переписка и рабочее задание.

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

Задание:
[вставьте задачу]

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

Для проверки длинного документа можно использовать второй промпт:

Прочитай документ и составь карту фактов.

Для каждого факта укажи:
- формулировку без домыслов;
- раздел документа;
- влияет ли факт на итоговый вывод.

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

Документ:
[вставьте текст]

Если приложение работает через OpenAI-совместимый API, минимальный запрос может выглядеть так:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.kosareva.cloud/v1",
)

messages = [
    {
        "role": "system",
        "content": "Отвечай только по переданным данным. Не заполняй пробелы догадками."
    },
    {
        "role": "user",
        "content": "Проект использует PostgreSQL. Запомни это ограничение."
    },
    {
        "role": "assistant",
        "content": "Принято: проект использует PostgreSQL."
    },
    {
        "role": "user",
        "content": "Предложи схему хранения задач и перечисли исходные ограничения."
    },
]

response = client.chat.completions.create(
    model="MODEL_ID",  # ID возьмите из каталога моделей
    messages=messages,
    temperature=0,
    max_tokens=800,
)

print(response.choices[0].message.content)

Если удалить из messages реплику про PostgreSQL, модель не обязана знать об этом ограничении. Наличие сообщения в интерфейсе само по себе не означает, что оно отправлено в API.

Как управлять длинным диалогом

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

Полезно разделить данные на несколько слоёв:

1. Постоянные правила: роль модели, запреты, формат ответа.
2. Состояние задачи: принятые решения, ограничения и открытые вопросы.
3. Недавние сообщения: реплики, нужные для текущего шага.
4. Материалы по запросу: только относящиеся к задаче фрагменты документов.
5. Проверка ответа: список условий, которые модель должна подтвердить.

Старую переписку обычно сворачивают в структурированное резюме. Лучше сохранять не пересказ разговора, а факты: что решили, что отклонили, какие значения нельзя менять и что ещё требуется выяснить.

После важных этапов можно отправлять такой промпт:

Обнови состояние задачи по переписке.

Верни разделы:
- подтверждённые требования;
- принятые решения;
- отклонённые варианты и причины;
- неизвестные данные;
- следующий шаг.

Не добавляй новых решений. Сохрани точные имена, ограничения
и форматы из исходных сообщений.

Резюме стоит хранить отдельно и проверять перед заменой старых сообщений. Ошибка в нём будет переноситься в следующие запросы как исходный факт.

Чего не стоит ждать от большого контекста

Увеличенное контекстное окно не превращает чат в долговременную память. Оно также не гарантирует точный поиск одной детали в большом массиве текста.

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

GPT, Claude, Gemini, Grok, DeepSeek, Qwen, Kimi и MiniMax могут по-разному вести себя на длинных входных данных. Выбирать семейство только по заявленному размеру окна не стоит: проверьте его на собственных документах, типичных вопросах и правилах оценки.

FAQ

Видит ли модель весь предыдущий чат?

Только если приложение передало его в текущем запросе или использовало поддерживаемый API-механизм хранения состояния. В обычной схеме разработчик сам управляет историей сообщений.

Почему модель забывает факт, который есть в переписке?

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

Можно ли просто всегда отправлять всю историю?

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

Как понять, какая модель подходит для длинных документов?

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

Вывод

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

Модели доступны по API на kosareva.cloud с оплатой в рублях по факту за токены и без абонентской платы. Выбрать ID модели и посмотреть условия можно в каталоге, после чего протестировать несколько вариантов на собственном наборе длинных диалогов.