Часть 1. Основы · Глава 3
Контекстное окно
Цели раздела
4 пунктаК концу раздела вы сможете:
- Научиться эффективно работать в рамках ограниченного контекстного окна LLM.
- Понимать, почему модель хуже «удерживает» информацию из середины длинного контекста, и уметь расставлять акценты (важное — в начало и в конец; критические ограничения — дублировать в конце).
- Не терять важную информацию при работе с большими документами.
- Освоить стратегии декомпозиции и сжатия контекста.
Работа с ограниченной памятью модели
Понятие контекстного окна Контекстное окно — это максимальная длина последовательности токенов, которую LLM может обработать за один проход. Оно включает:- Системные инструкции (если используются)
- Историю диалога (все предыдущие сообщения)
- Текущий запрос пользователя
- Генерируемый ответ
Современные модели (ориентир, май 2026):
| Модель / семейство | Контекст (токены) | Где встречается в курсе |
|---|---|---|
Qwen 3.5 (qwen3.5:* в Ollama) | 256 000 | Локально: QA + vision |
Qwen 3 (qwen3:4b, 30b, 235b) | 40K–256K (зависит от тега) | Локально, Groq qwen/qwen3-32b |
DeepSeek-R1 (deepseek-r1:*) | 128 000 (до 160K у 671b) | Локально: логи, рассуждения |
| Llama 3.3 / 4 Scout (Groq, Ollama) | 128K–131 072 | Groq Console, llama3.3:70b |
| Claude Sonnet 4.6 | 1 000 000 | Облако (API) |
| GPT-5.4 / GPT-5.5 (OpenAI API) | ~1 050 000 | Облако (корпоративные чаты) |
| GPT-5.2 и компактные 7–8B | 8K–128K | Старые/лёгкие локальные сборки |
Визуализация контекстного окна
Системная инструкция
роль, правила поведения
3,200
2%История диалога
предыдущие сообщения
16,000
12%Текущий промпт
ваш запрос + контекст
32,000
24%Зарезервировано для ответа
генерируемый LLM текст
79,872
61%Итого использовано (без ответа)
системная + история + промпт
51,200
из 131,072При превышении лимита — старые сообщения вытесняются
Модель «читает» контекст с конца — начало диалога теряется первым. Начните новый чат с кратким резюме предыдущего.
Правило перевода страниц в токены:
500–800, зависит от форматирования
≈ 6 500 токенов(650 / стр.)
- 128K (типично в курсе)влезает
- 32Kвлезает
- 8Kвлезает
Три типа ошибок при неправильном управлении контекстом
- Слишком мало информации → модель «галлюцинирует» и додумывает.
- Слишком много информации → модель «тонет» в деталях и теряет фокус.
- Противоречивая информация → модель путается и даёт непоследовательные ответы.
🧪 Пример для QA: Один запрос «проанализируй все 50 страниц требований и сгенерируй тест-план» — классический тип 2: модель «тонет» в объёме. Решение: пирамидальная подача или разбить на разделы по 5–10 страниц.
Почему середина контекста «теряется»: эффект внимания модели
Исследования показывают: LLM хуже удерживают внимание на информации, расположенной в середине длинного контекста. Механизм внимания (attention) сильнее «привязывается» к началу и концу последовательности — явление известно как lost in the middle (потеря в середине). Для QA это критично: если скопировать в промпт 50 требований подряд, модель лучше «видит» первые и последние пункты, а средние может пропустить или учесть слабее. В результате тест-кейсы или анализ будут неполными именно по тем разделам, что оказались в середине списка.
Разбиение на части не только укладывается в лимит токенов, но и сокращает длину каждого блока — в коротком фрагменте нет «мёртвой середины», и модель обрабатывает его целиком. Пользователи, которые не понимают эту причину, часто не видят смысла в разбиении и копируют весь документ целиком, получая пропуски по средним разделам.
Правило расстановки акцентов в большом промпте:
| Где в промпте | Что размещать | Зачем |
|---|---|---|
| В начало | Главную задачу, роль модели, ключевую терминологию (якоря) | Модель «запоминает» это на весь проход по контексту |
| В конец | Повтор критических ограничений, итоговую инструкцию («учитывай только перечисленное выше»), формат ответа | Информация в конце сильнее влияет на генерируемый ответ |
| Середина | Подробности, перечисления, данные | Здесь внимание модели ослабевает — не полагайтесь на то, что модель «запомнит» единственное упоминание критичного правила из середины |
🧪 Пример для QA: 30 требований в одном промпте. Требования № 15–20 (середина) часто не попадают в тест-кейсы или трактуются неточно. Решение: разбить на 3 блока по 10 требований; либо в начале написать «Особое внимание: требования REQ-15 … REQ-20 (критичные для безопасности)», а в конце повторить: «Обязательно включи тест-кейсы по REQ-15–REQ-20».
Стратегии работы с большими объёмами информации
1. Пирамидальная подача (Pyramid Approach) Стратегия основана на принципе «сначала общее, потом детальное».- 1
Шаг 1
Краткая сводка требований
промптВот требования к модулю X. Сделай из них краткую сводку, выделив основные функции.
- 2
Шаг 2
Граничные и нестандартные сценарии
промптВот сводка. Для каждой функции сгенерируй список граничных значений и нестандартных сценариев использования.
- 3
Шаг 3
Полные тест-кейсы
промптВот граничные значения. Для каждого сценария напиши полный тест-кейс в формате таблицы.
2. Сжатие контекста (Context Compression) Делегирование модели задачи по созданию компактного представления информации.
В приложении есть форма регистрации пользователя. Пользователь должен ввести своё имя, фамилию, адрес электронной почты и пароль. Имя должно быть от 2 до 50 символов, фамилия от 2 до 50 символов, email должен соответствовать стандарту RFC 5322, пароль должен быть не менее 8 символов и содержать хотя бы одну заглавную букву, одну строчную букву, одну цифру и один специальный символ...
Форма регистрации: имя (2-50), фамилия (2-50), email (RFC 5322), пароль (8+, A-Z, a-z, 0-9, спецсимвол)
Упражнение: сжатие контекста
Сожмите следующий текст до 30% от исходного объёма, сохранив все критические требования:
Функция "Применение промокода" позволяет пользователю получить скидку при оформлении заказа. Промокод представляет собой строку длиной от 6 до 12 символов, содержащую только латинские буквы и цифры. Существует три типа промокодов: процентная скидка (5%, 10%, 15%, 20%), фиксированная скидка (500₽, 1000₽, 2000₽) и бесплатная доставка. Промокод не суммируется с другими акциями, требует минимальной суммы заказа 1000₽, не применяется к категории "Акционные" и ограничен одним использованием на пользователя.
Вот документ с требованиями. Сделай из него краткий чек-лист, содержащий все ключевые функции, бизнес-правила и критерии приемки. Используй нумерацию.
3. Якоря терминологии (Anchors) Закрепление в начале диалога ключевой терминологии, определений и правил.
Вступление
Я работаю над проектом [НАЗВАНИЕ]. Наши стандарты:
Терминология
- Пользователь = клиент с подтверждённым email
- Гость = неавторизованный посетитель
- Заказ = Черновик → Оплачен → В обработке → Отправлен
Форматы
- REQ-[МОДУЛЬ]-[НОМЕР]
- TC-[ТИП]-[НОМЕР]
- Даты: ISO 8601
Ограничения
- email ≤ 254, пароль ≤ 128
- Валюты: RUB, USD, EUR
- Мин. заказ: 100 RUB
Строго придерживайся этих стандартов во всех ответах.
4. Декомпозиция задач Разбиение одной сложной задачи на последовательность более простых, связанных подзадач.
Проанализируй все требования и сгенерируй полный тест-план
Шаг 1: "Проанализируй Раздел 1 требований, найди неоднозначности" Шаг 2: "На основе Раздела 1 сгенерируй тест-кейсы" Шаг 3: "Проанализируй Раздел 2 требований..." ...
5. RAG (Retrieval-Augmented Generation) Технология, при которой релевантная информация извлекается из внешних источников и подается в модель по мере необходимости.
🧪 Пример для QA: Система автоматически извлекает релевантные разделы документации при анализе бага, без необходимости копировать весь документ в промпт.
Практический пример
Стратегия "Якорь + Декомпозиция" для анализа спецификации:- 1
Запрос 1
Установка контекста и якорей
промптТы — QA-аналитик для проекта [Название]. Вот контекст проекта: [ЯКОРЯ ТЕРМИНОЛОГИИ] - "Заказ" — сущность покупки - "Промокод" — код скидки 6-12 символов ... Подтверди, что понял контекст, кратко перечислив ключевые термины.
- 2
Запрос 2
Анализ первой части требований
промптВот Раздел 1 требований: [текст] Найди неоднозначности и задай уточняющие вопросы.
- 3
Запрос 3
Генерация тест-кейсов
промптНа основе уточнённых требований Раздела 1 сгенерируй тест-кейсы...
Стратегии управления контекстом (сводная таблица)
| Стратегия | Описание | Пример для QA |
|---|---|---|
| Декомпозиция задачи | Разбиение сложной задачи на несколько простых последовательных запросов | Генерация автотеста: 1) Структура класса, 2) Локаторы, 3) Методы, 4) Сборка |
| "Пирамидальная " подача | Сначала общий контекст, затем детали | 100-страничная спецификация → сводка → работа со сводкой |
| "Якоря " (фиксаторы) | Повторяющиеся инструкции, задающие рамки | "Мы тестируем API платежной системы. Все примеры на Python с pytest " |
| RAG | Извлечение релевантной информации из внешних источников перед генерацией | Автоматический поиск в документации при анализе бага |
| Очистка контекста | Удаление устаревшей информации из истории диалога | Новая сессия для каждого бага |
Материалы к главе
Lost in the Middle (Liu et al.) — как LLM используют длинный контекст
Почему середина длинного контекста «теряется» (lost in the middle).
Reintech — LLM Context Window Optimization
Стратегии оптимизации контекстного окна и обработки длинных документов.
Anthropic — Long context prompting tips
Рекомендации по использованию длинного контекста в Claude.
Redis — Context Window Management for LLM Apps
Гайд по управлению контекстным окном в приложениях на базе LLM.
MLQ.ai — Understanding Tokens & Context Windows
Материалы о стратегиях работы с большими контекстами и методах оптимизации.
Ollama Library
Каталог локальных моделей и размеров контекста.
Groq — Models
Каталог облачных моделей Groq.