Context Window

Context window — это всё, что модель видит за один запрос. За пределами окна — ничего не существует.

Что входит в контекст

┌─────────────────────────────────────────┐
│  System prompt                          │
│  ─────────────────────────────────────  │
│  Message 1 (user)                       │
│  Message 2 (assistant)                  │
│  Message 3 (user)                       │
│  ...                                    │
│  ─────────────────────────────────────  │
│  Новый запрос                           │
│  ─────────────────────────────────────  │
│  [место для ответа модели]              │
└─────────────────────────────────────────┘
         всё это = context window

Размеры у популярных моделей (2025)

Модель	Context	Примерный объём текста
GPT-4o	128K	~300 страниц A4
GPT-4o mini	128K	~300 страниц A4
Claude Sonnet 4.5	200K	~500 страниц A4
Claude Opus 4.6	200K	~500 страниц A4
Gemini 1.5 Pro	1M	~2500 страниц A4
Gemini 1.5 Flash	1M	~2500 страниц A4
Llama 3.1 70B	128K	~300 страниц A4
Mistral Large	128K	~300 страниц A4

Проблема "Lost in the Middle"

Большой контекст ≠ равномерное качество по всему тексту.

Исследования показывают: модели лучше всего помнят начало и конец контекста, хуже — середину.

Начало     Середина     Конец
  ↑            ↓          ↑
хорошо      плохо      хорошо

Практика: самую важную информацию клади в начало системного промта или в конец, непосредственно перед запросом.

Стратегии работы с ограничениями

1. Sliding Window — скользящее окно

Храним только последние N сообщений. Старая история обрезается.

Запрос 1:  [sys] [M1] [M2]
Запрос 2:  [sys] [M1] [M2] [M3] [M4]
Запрос 3:  [sys]      [M2] [M3] [M4] [M5] [M6]
                 ↑
             обрезали M1

Плюс: просто реализовать
Минус: теряется ранний контекст

2. Summarization — суммаризация истории

Когда история превышает порог — сжимаем старые сообщения в краткое резюме.

[sys] [Резюме первых 20 сообщений] [M18] [M19] [M20] [новый]

Плюс: сохраняется суть разговора
Минус: теряются детали, нужен дополнительный LLM-вызов

3. RAG — вместо длинного контекста

Вместо того чтобы класть весь документ в контекст — индексируем его и достаём только релевантные куски.

Вопрос → поиск по индексу → топ-5 релевантных фрагментов → контекст

Плюс: масштабируется на любой объём знаний
Минус: сложнее, нужна инфраструктура, качество зависит от поиска

4. Chunking + Map-Reduce

Для обработки длинного документа:

1. Разбиваем на чанки
2. Обрабатываем каждый чанк отдельно
3. Собираем результаты

Документ → [Чанк1] [Чанк2] [Чанк3]
               ↓       ↓       ↓
           Ответ1  Ответ2  Ответ3
               ↓       ↓       ↓
           [Финальный синтез]

Плюс: обходим лимит контекста
Минус: теряются связи между чанками

5. Prompt Caching

Anthropic и OpenAI поддерживают кэширование повторяющихся частей промта.

[Большой системный промт — кэшируется] ← платишь 1 раз
[История] [Новый запрос]               ← платишь каждый раз

Кэш живёт 5 минут (Anthropic) или 1 час (OpenAI). Экономия до 90% стоимости на system prompt.

Контекст и стоимость

Стоимость запроса прямо пропорциональна количеству токенов.

Длинная история (50K токенов) × $3/1M = $0.15 за ОДИН запрос

При 1000 запросах в день это $150/день только на input-токены.

Правило: чем длиннее история — тем дороже каждый следующий запрос.

Как проверить что контекст не переполнен

# Anthropic
response = client.messages.count_tokens(
    model="claude-sonnet-4-5",
    system=system_prompt,
    messages=messages
)
print(response.input_tokens)  # сколько токенов займёт запрос

# Оставить запас для ответа
MAX_CONTEXT = 200_000
RESPONSE_RESERVE = 4_000
if response.input_tokens > MAX_CONTEXT - RESPONSE_RESERVE:
    # обрезать историю

Резюме

Концепция	Суть
Context window	Всё что видит модель за раз
Lost in the middle	Середина контекста помнится хуже
Sliding window	Обрезаем старую историю
Summarization	Сжимаем историю в резюме
RAG	Достаём нужное вместо полного контекста
Prompt caching	Платим за повторный контент один раз