Контекстные окна языковых моделей: полное руководство

Один из самых распространённых источников разочарования при разработке с LLM — столкновение с невидимой стеной: запрос, который завершается с ошибкой без объяснений, разговор, который внезапно теряет контекст, или документ, который обрабатывается не полностью. Почти в каждом случае виновник — окно контекста. Понимание того, что такое окно контекста, что означают его ограничения на практике и как умело работать в их рамках, — это основа для создания надёжных AI-приложений.

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

Что такое окно контекста?

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

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

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

Текущие ограничения окна контекста по моделям

Окна контекста резко выросли за последние несколько лет, и цифры продолжают расти по мере совершенствования моделей:

• GPT-4o — 128 000 токенов (~96 000 слов). Достаточно для полного романа или большой кодовой базы.
• Claude 3.5 Sonnet / Claude 3 Opus — 200 000 токенов (~150 000 слов). Anthropic последовательно раздвигает этот предел дальше, чем OpenAI.
• Gemini 1.5 Pro — 1 000 000 токенов (~750 000 слов). По-настоящему беспрецедентное окно контекста, способное вместить целые кодовые базы или часы транскриптов встреч.
• Gemini 1.5 Flash — 1 000 000 токенов, оптимизированный по скорости и стоимости.
• Llama 3.1 (70B / 405B) — 128 000 токенов, доступен через различных провайдеров, включая together.ai и Groq.
• Mistral Large — 128 000 токенов.

Для сравнения: вся эта статья занимает около 1200 токенов. Даже «маленькое» окно GPT-4o в 128 тысяч токенов достаточно для обработки большинства практических документов целиком. Вопрос не только в том, помещается ли ваш контент — но и в том, как модель обрабатывает контент на разных позициях внутри окна.

Что происходит при превышении окна контекста

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

// OpenAI
{
  "error": {
    "type": "invalid_request_error",
    "code": "context_length_exceeded",
    "message": "This model's maximum context length is 128000 tokens. However, your messages resulted in 134291 tokens."
  }
}

// Anthropic
{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "prompt is too long: 201483 tokens > 200000 maximum"
  }
}

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

Проблема «потеряно в середине»

Большое окно контекста не означает, что модель уделяет одинаковое внимание всему его содержимому. Исследования неизменно показывают, что трансформерные модели лучше работают с информацией в начале или конце контекста — это явление называется «потеряно в середине» (lost in the middle).

На практике это значит: если вы используете RAG (генерацию с поиском по базе знаний) и вставляете 20 извлечённых фрагментов документов в середину длинного контекста, модель может не учесть фрагменты на позициях 8–14, даже если они наиболее релевантны. Наиболее важная для вашей задачи информация должна быть размещена либо в самом начале (рядом с системным промптом), либо в самом конце (непосредственно перед вопросом пользователя) контекста.

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

Стратегии работы в рамках ограничений контекста

Разбивка на фрагменты (чанкинг)

Для документов, превышающих окно контекста, разбивайте их на перекрывающиеся фрагменты и обрабатывайте каждый независимо. Используйте небольшое перекрытие (например, 20% от размера фрагмента) для сохранения непрерывности на границах. Это хорошо работает для задач суммаризации, извлечения данных и классификации, где каждый фрагмент относительно самодостаточен.

Суммаризация / сжатие

Для длинных разговоров или истории документов периодически суммируйте старый контент и заменяйте его кратким изложением. Разговор из 50 реплик нередко можно сжать до 300-токенного резюме, сохраняющего ключевой контекст без расхода всей истории. Это особенно эффективно в чат-приложениях, где ранние реплики становятся менее релевантными по мере развития разговора.

Генерация с поиском по базе знаний (RAG)

Вместо того чтобы помещать целые документы в контекст, встраивайте их в векторную базу данных и извлекайте только наиболее релевантные фрагменты в момент запроса. Хорошо спроектированная RAG-система может сделать модель с окном контекста в 128 тысяч токенов эффективно «знающей» о миллионах токенов документации — она просто извлекает нужное для каждого запроса. Это также значительно снижает стоимость по сравнению с использованием длинноконтекстной модели для каждого запроса.

Избирательное включение контекста

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

Как отслеживать использование контекста

Большинство AI-провайдеров возвращают информацию о количестве токенов в своих ответах. Объект ответа OpenAI включает поле usage с prompt_tokens, completion_tokens и total_tokens. Anthropic возвращает input_tokens и output_tokens. Логирование этих счётчиков для каждого запроса даёт видимость тенденций роста до того, как будет достигнут лимит.

Для предварительной проверки перед отправкой запроса используйте инструмент «Окно контекста» BrowseryTools: вставьте промпт и увидите точное количество занимаемых им токенов и процент от окна контекста каждой модели. Это особенно полезно при создании системных промптов или проектировании стратегий извлечения RAG — вы видите влияние своих решений ещё до единственного API-вызова.

Больше — не всегда лучше

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