Агент работает полчаса, а потом выдаёт ответ, который противоречит инструкции из начала диалога. Или внезапно обрывает текст на середине. Или начинает переспрашивать то, что вы уже объяснили пять сообщений назад. Это не баг конкретной модели и не случайность — это физика работы трансформеров, с которой рано или поздно сталкивается каждый, кто строит что-то сложнее простого чат-бота.
Хорошая новость: с этим можно работать. Плохая: волшебного решения нет, и «бесконечная память» — маркетинговый термин, а не техническая реальность. Разберём, что происходит внутри, и что с этим делать на практике.
Что такое контекстное окно и почему оно разное у моделей
Контекстное окно — это максимальное количество токенов, которое модель видит за один вызов. Токен — примерно три-четыре символа русского текста или четыре-пять английского. В окно входит всё: системная инструкция, история диалога, текущий запрос пользователя и место под ответ модели.
Разные модели имеют разные размеры окна. Это не просто маркетинговая характеристика — это архитектурное ограничение, которое влияет на память, внимание и стоимость вычислений. Большое окно требует больше памяти GPU и обрабатывается дольше. Именно поэтому модели с большим контекстом обычно тратят баланс заметно быстрее — каждый токен в окне стоит вычислительных ресурсов.
Важный момент, который часто упускают: длина окна — это не длина памяти. Модель не «помнит» прошлые разговоры. Она видит только то, что передано в текущем запросе. Если вы не передали историю — модель работает с чистого листа. Если передали слишком много — часть будет обрезана или проигнорирована.
Почему длинный диалог не равно длинная память
Когда вы используете чат-интерфейс или агентный фреймворк, история диалога накапливается и передаётся в каждом следующем запросе. На первый взгляд это выглядит как память. Но это иллюзия.
Каждый вызов API — отдельный и независимый. Фреймворк (или ваш код) собирает все предыдущие сообщения и передаёт их снова. Чем длиннее диалог, тем больше токенов уходит на историю — и тем меньше остаётся на новый ответ и на то, чтобы модель «уделила внимание» нужным частям.
Трансформеры работают через механизм внимания: модель смотрит на весь контекст, но не одинаково. Информация в середине длинного контекста обрабатывается хуже, чем в начале и конце. Это известный эффект, который называют «потерей в середине» (lost in the middle). Инструкция, которую вы написали в начале системного промпта, к двадцатому сообщению может фактически перестать влиять на поведение модели — не потому что окно переполнено, а потому что механизм внимания её «не замечает».
Что происходит при превышении лимита
Когда суммарный объём токенов превышает размер окна, происходит одно из трёх:
Жёсткий обрыв с ошибкой. API возвращает ошибку — обычно с кодом 400 и сообщением вида context_length_exceeded или maximum context length. Это честный сценарий: вы точно знаете, что что-то пошло не так.
Тихое усечение. Некоторые реализации и прокси-шлюзы молча обрезают историю с начала или середины, чтобы уложиться в лимит. Модель отвечает, но без части контекста. Никакой ошибки — просто странное поведение.
Деградация качества. Окно технически не переполнено, но заполнено под завязку. Модель «теряет» инструкции из системного промпта, начинает противоречить себе, перестаёт следовать заданному формату. Это самый коварный случай — внешне всё работает, но результат ненадёжен.
Распознать переполнение в ответе API можно по полю finish_reason. Если оно равно length вместо stop — модель оборвала ответ из-за лимита токенов на выходе. Это отдельная проблема: даже если контекст влезает, ответ может быть обрезан, если вы не задали достаточный max_tokens.
Таблица симптомов: что происходит и что менять
| Симптом | Причина | Что менять |
|---|---|---|
| Ответ обрывается на середине предложения | Достигнут лимит max_tokens на выход |
Увеличить max_tokens или разбить задачу на части |
API возвращает ошибку context_length_exceeded |
Контекст превышает размер окна модели | Сократить историю, нарезать документ, сменить модель |
| Агент игнорирует инструкцию из системного промпта | Длинная история вытесняет внимание к системному промпту | Повторить ключевые инструкции в конце каждого запроса |
| Модель «забывает» факты из начала диалога | История слишком длинная, начало обрезается или игнорируется | Пересказывать состояние перед каждым новым шагом |
| Ответ противоречит предыдущему шагу | Потеря в середине контекста | Держать ключевые факты в системном промпте, а не в истории |
| Модель переспрашивает то, что уже объяснено | Тихое усечение истории прокси или фреймворком | Логировать реальный контекст, который уходит в запрос |
| Качество падает к концу длинного документа | Механизм внимания слабее в середине | Суммаризировать по частям, не гнать весь документ за раз |
Практика: как структурировать длинную задачу
Разбивайте на этапы с явными контрольными точками
Длинная задача — это не один гигантский промпт. Это последовательность коротких вызовов, каждый из которых решает одну понятную подзадачу. После каждого шага сохраняйте результат во внешнее хранилище (файл, базу данных, переменную в коде агента) и передавайте только нужную часть в следующий вызов.
Пример: вместо «напиши мне полный технический план на 50 страниц» — «составь список разделов», затем «напиши раздел 1», затем «напиши раздел 2 с учётом этого резюме раздела 1».
Держите ключевые факты в системной инструкции
Системный промпт — это самое устойчивое место в контексте. Всё, что критично для выполнения задачи (роль агента, формат ответа, ключевые ограничения, глоссарий терминов), должно быть там, а не в истории диалога. История — это временное, системный промпт — это постоянное.
Если задача многошаговая, обновляйте системный промпт между вызовами: добавляйте в него итоги предыдущих шагов в сжатом виде.
Пересказывайте состояние перед новым шагом
Перед каждым новым этапом добавляйте в запрос краткое резюме: что уже сделано, какие решения приняты, что важно помнить. Это дешевле, чем тащить всю историю, и надёжнее — вы сами контролируете, что попадает в контекст.
Шаблон такого резюме может выглядеть так:
Контекст задачи:
- Цель: [одно предложение]
- Сделано: [список]
- Ключевые решения: [список]
- Текущий шаг: [одно предложение]
Практика: как работать с большими документами
Нарезка на фрагменты
Не передавайте весь документ в один вызов. Разбейте его на логические фрагменты — по разделам, абзацам или фиксированному числу токенов с перекрытием (overlap). Перекрытие нужно, чтобы не потерять смысл на границах фрагментов.
Обрабатывайте каждый фрагмент отдельно, сохраняйте результат, затем агрегируйте. Это работает для суммаризации, извлечения данных, перевода.
Поиск по своему индексу
Если документ большой и вам нужно отвечать на вопросы по нему — не гоните весь текст в контекст. Постройте векторный индекс (embedding + vector store), ищите релевантные фрагменты по запросу и передавайте только их. Это называют RAG (retrieval-augmented generation). Такой подход позволяет работать с документами любого объёма, не упираясь в лимиты окна.
Суммаризация по частям
Если нужен общий вывод по длинному тексту — суммаризируйте иерархически. Сначала суммаризируйте каждый фрагмент, потом суммаризируйте суммаризации. Это называют map-reduce подходом. Качество хуже, чем при обработке всего текста целиком, но это честный компромисс — и он работает.
Выбор модели под длинный контекст
Разные модели в каталоге NeuroZal API имеют разные размеры окна и разное поведение при работе с длинным контекстом. Несколько практических наблюдений:
Gemini Flash — хороший выбор для задач с длинным контекстом при умеренном расходе баланса. Модели серии Gemini изначально проектировались под большие окна.
Claude Sonnet и Opus — сильны в следовании инструкциям даже на длинном контексте. Claude лучше многих других моделей удерживает инструкции из системного промпта при заполненном окне. Но Opus тратит баланс заметно быстрее — это нужно учитывать.
GPT-4o-mini и DeepSeek Flash — разумный выбор для рутинных задач с умеренным контекстом. Тратят баланс экономнее, но окно меньше.
Тяжёлые модели (GPT-5.6, Claude Opus 5, Grok 4.6) — максимальное качество, но и максимальный расход. Гнать в них длинный документ целиком — это не только технически рискованно (переполнение), но и неоправданно по расходу баланса. Аккуратная нарезка с более лёгкой моделью часто даёт сопоставимый результат и тратит баланс заметно меньше.
Общее правило: большой контекст — это дорого. Не потому что провайдер жадный, а потому что вычислительно это честно дороже. Аккуратная нарезка и управление контекстом — это не костыль, а профессиональный подход.
Честные ограничения: чего не существует
Бесконечной памяти не существует. Любая модель работает в рамках конечного окна. Всё, что выходит за его пределы, либо обрезается, либо не передаётся вообще.
Большое окно не гарантирует хорошее внимание. Эффект «потери в середине» реален. Модель с большим окном не обязательно лучше обрабатывает информацию, которая оказалась в середине длинного контекста.
Агентные фреймворки не решают проблему автоматически. LangChain, AutoGen и другие фреймворки предлагают стратегии управления памятью, но они тоже опираются на те же механизмы: суммаризацию, нарезку, внешние хранилища. Магии нет.
Суммаризация теряет детали. Когда вы сжимаете историю, чтобы освободить место в контексте, часть информации уходит безвозвратно. Это честный компромисс, который нужно осознавать при проектировании агента.
Практический итог
Контекстное окно — это не баг и не недоработка. Это фундаментальная характеристика архитектуры, с которой нужно работать осознанно. Большинство проблем с «забывчивостью» агентов решаются не сменой модели, а правильной архитектурой задачи: явными контрольными точками, пересказом состояния, хранением ключевых фактов в системном промпте и нарезкой больших документов на управляемые фрагменты.
Смена модели на ту, что с большим окном, — это иногда правильное решение, но не первое. Сначала убедитесь, что вы не гоните в контекст лишнее.
Если вы строите агентов или автоматизируете работу с документами через API, подключиться к NeuroZal API можно через https://api.neurozal.ru/v1 — шлюз совместим с OpenAI SDK, один ключ открывает весь каталог из 46 моделей. Личный кабинет с журналом запросов и расходом по каждому ключу — на https://api.neurozal.ru/panel. Документация — на https://neurozal.ru/docs.
Важно: NeuroZal API — это ключ для программ, редакторов кода, агентов и автоматизации. Это не аккаунт ChatGPT или Claude с логином и паролем, он не подключается в мобильном приложении ChatGPT и не заменяет подписку Plus. Модель выбирает пользователь: один ключ открывает весь каталог моделей.