Context length exceeded: как сократить запрос и проверить результат
Как найти источник переполнения context window, сократить историю, файлы и tool results по приоритету и проверить качество повторного ответа.
Содержание
Context length exceeded: как сократить запрос и проверить результат
Context length exceeded исправляют не случайным удалением половины prompt, а учётом общего бюджета. Сначала определите модель и размер каждого компонента запроса, затем уберите механические дубли, нерелевантную историю и тяжёлые tool results. После повторной отправки проверьте не только отсутствие ошибки, но и сохранность обязательных фактов и полноту ответа.
Из чего складывается context window
Контекст — это рабочая память одного запроса, а не только последний пользовательский prompt. Упрощённо:
system instructions
+ conversation history
+ current message
+ images and documents
+ tool definitions
+ tool results
+ output / thinking budget
= total context usageДокументация Anthropic о context windows прямо включает system prompt, все сообщения, изображения, документы, определения инструментов, tool results и генерируемый ответ. Prompt caching меняет стоимость повторно используемых токенов, но не удаляет их из окна.
Не фиксируйте в коде «универсальный лимит»: context window и поведение при переполнении зависят от выбранной модели и API. Проверяйте текущую карточку модели в день настройки.
Найдите самый тяжёлый компонент
| Компонент | Что измерить | Безопасное сокращение |
|---|---|---|
| System instructions | Повторы правил и длинные примеры | Объединить дубли, оставить обязательные ограничения |
| История | Токены по сообщениям и старым веткам | Удалить нерелевантные ветки или заменить проверяемым summary |
| Файлы и RAG-фрагменты | Размер каждого документа, дубли и низкорелевантные chunks | Снизить top_k, дедуплицировать, передавать нужные разделы |
| Tool definitions | Неиспользуемые инструменты и длинные описания | Передавать только инструменты текущего шага |
| Tool results | Полные JSON, логи, HTML, base64 и повторные ответы | Оставить необходимые поля, ссылки и идентификаторы; крупное хранить вне prompt |
| Output budget | max_tokens и thinking budget | Выделить реалистичный запас, разбить большой результат на этапы |
Для Claude доступен отдельный Token Counting API, который умеет учитывать сообщения и инструменты до отправки запроса. Для другого провайдера используйте его собственный счётчик, если он есть. Локальный tokenizer полезен для раннего предупреждения, но его оценку нельзя выдавать за гарантированный серверный расчёт другой модели.
Откройте текущую API-документацию BetterToken, выполните один короткий тестовый запрос и найдите его в Dashboard. Сопоставьте input, output и cache tokens до и после сокращения контекста: уменьшение input tokens подтверждает, что исправление попало в реальный вызов. Dashboard не показывает полный prompt и не заменяет token counting до отправки; это постфактум-проверка собственного запроса.
Порядок сокращения без потери смысла
1. Удалите механические дубли
Проверьте повторяющиеся system-правила, один и тот же файл в нескольких сообщениях, дубли RAG-чанков, повторно вставленные схемы и полные логи. Это самый безопасный этап: он уменьшает объём без изменения задачи.
2. Уберите нерелевантную историю
Разделите долговременные факты и временный ход беседы. Сохраните цели, принятые решения, обязательные ограничения и открытые вопросы. Старые рассуждения, отменённые варианты и уже обработанные tool results можно убрать или свернуть в структурированное summary.
Плохое summary говорит «обсуждали интеграцию». Полезное фиксирует конкретно: выбранный endpoint, версию схемы, принятые ограничения, подтверждённые факты и следующий шаг.
3. Сократите файлы, RAG и tool results
Передавайте релевантные разделы вместо полного документа. В tool result сохраняйте поля, необходимые следующему шагу, а не весь HTTP-ответ или лог. Нельзя удалять источники и обязательные данные только ради прохождения запроса: лучше разбить работу на несколько проверяемых этапов.
4. Выделите место для ответа
Вход и выход используют общий бюджет. Если запрос почти заполняет окно, модель может не получить достаточно места для полного ответа. Уменьшите необязательный input, задайте реалистичный output budget или разделите результат на части. Не сокращайте критические факты раньше механических дублей.
5. Смените модель только после измерения
Модель с большим контекстом может быть правильным выбором для документа, который нельзя безопасно разделить. Но переход на большее окно без устранения дублей просто откладывает следующую ошибку и может ухудшить информационную плотность.
Минимальная проверка до отправки
components = count_by_section(request)
estimated_input = sum(components)
reserved_output = requested_output_budget
if estimated_input + reserved_output approaches current_model_window:
remove exact duplicates
drop irrelevant history
compact tool results and retrieved chunks
count again
send only after required facts and constraints remain presentСлово approaches здесь намеренно не заменено фиксированным процентом. Запас зависит от точности счётчика, модели, thinking и поведения конкретного API.
Как проверить исправление
Сравните повторный запрос с контрольным списком:
- API больше не возвращает
context length exceededилиprompt is too long. - Ответ завершён штатно, а не оборван из-за исчерпания output budget.
- В ответе присутствуют все обязательные факты, ограничения и требуемый формат.
- Цитаты или ссылки всё ещё соответствуют переданным источникам.
- Tool calls используют правильные аргументы, а важные результаты не потеряны при сжатии.
- Новое input usage действительно ниже исходного.
Если ошибка исчезла, но модель забыла ключевое ограничение, исправление не прошло. Верните обязательный блок, а место освободите за счёт менее релевантной истории или тяжёлого tool result. Если ответ обрывается, отдельно проверьте output budget: это уже другая часть того же общего окна.
Короткий вывод
Рабочая последовательность такова: определить модель → посчитать компоненты → убрать точные дубли → вынести нерелевантную историю → сжать файлы и tool results → оставить место для ответа → повторить запрос → проверить качество. Такой порядок лечит причину и не превращает контекст в случайно обрезанный набор фактов.
