Context window — что такое контекстное окно в LLM и как с ним работать

Почему контекстное окно (Context window) важно

• Качество ответа. В контексте лежат факты/правила, от которых зависит точность; если ключевой фрагмент не попал в окно — его как бы «не существует» для модели.
• Стоимость и скорость. Чем больше окно, тем выше вычислительные затраты: внимание (attention) обычно масштабируется квадратично по длине последовательности.
• UX и дизайн продукта. От окна зависят сценарии: объём документов в чат-боте, длина «системного промпта», стратегии суммаризации и RAG.
• Риски «галлюцинаций». Плохая подборка контекста (дубликаты, нерелевант) или перегруз окна повышают вероятность ошибок рассуждений.

Токены, символы и «сколько это в словах»

LLM оперируют токенами — кусочками текста (слоги, морфемы, части слова, знаки препинания). Преобразование «текст → токены» зависит от конкретного токенизатора. Универсальной формулы нет, но удобны практические оценки:

• для русского: 1 000 токенов ≈ 650–900 слов (сильная зависимость от длин слов/морфологии и доли пунктуации);
• для английского: 1 000 токенов ≈ 700–800 слов;
• по символам: 1 токен ≈ 3–5 символов (но варьируется).

Отсюда грубые ориентиры:

• 4k токенов — это около 2,5–3,5 тыс. русских слов;
• 8k токенов — около 4–6 тыс. русских слов;
• 32k токенов — около 18–24 тыс. русских слов;
• 100k+ токенов — уже объём книги/большого отчёта.

Оценки ориентировочные: на реальном тексте цифры плавают из-за токенизатора, языка, плотности знаков.

Из чего «состоит» контекст во время инференса

KV-кэш (key-value cache) — это «оперативная память» на шаге генерации: он хранит матрицы, чтобы повторно не пере-считывать внимание к уже обработанным токенам. Однако кэш не даёт «бесконечного контекста»: если токены «выпали» из окна, модель перестаёт их учитывать при вычислении нового шага.

Позиционные представления и «геометрия» длинного контекста

Чтобы понимать позицию токена в последовательности, модели используют позиционное кодирование (positional encoding). На практике встречаются:

• Абсолютные схемы (реже в современных LLM);
• Релятивные (relative) — устойчивее к сдвигам;
• Ротационные (RoPE) — популярный вариант, хорошо переносимый;
• Интерполяции/масштабирования (NTK/YaRN/PI-скейлинг) — техники, расширяющие эффективную длину окна за счёт подстройки частот или интерполяции позиций.

Даже при «удлинённом» окне работают эффекты, которые стоит учитывать:

• «Lost in the middle». Информация в середине очень длинного контекста часто вспоминается хуже, чем в начале и в конце. Помогают якоря (signposts), оглавление, повтор ключевых тезисов ближе к концу.
• Порядок документов. Что ближе к концу — часто весомее. В задачах поиска ставьте самое релевантное ближе к хвосту окна или продублируйте краткий реферат в конце.
• Согласованность формата. Смешение стилей и разметок (таблица/код/сплошной текст) ухудшает извлечение фактов и «цепочки мыслей».

«Большие окна» (100k–1M): мифы и практика

Рост максимального окна не гарантирует линейного роста качества извлечения фактов. Пользовательские ограничения:

• Цена: внимание по всей последовательности остаётся дорогим — растёт память и время.
• Шум: длинные окна провоцируют «воду» и дубликаты; полезно адаптивно сокращать и дедуплицировать.
• Эффект затухания: конкретные модели могут хуже вспоминать «иголку в стоге» без явных якорей.

Отсюда практический вывод: RAG (динамическая выборка релевантных фрагментов) почти всегда эффективнее, чем «просто залить всё» в окно.

Когда расширять окно, а когда — улучшать подборку контекста

Расширяйте окно, если:

• нужны длинные последовательности (юридические договоры, главы книг) с локальными перекрёстными ссылками;
• у вас строго форматированные артефакты (таблицы, код, лог-трейсы), где порядок и близость важны;
• вы проектируете агентные цепочки, где системный промпт «тяжёлый», а ещё надо добавлять факты.

Сосредоточьтесь на подборке (RAG), если:

• источников много и они повторяются/перекрываются;
• запрос «узкий», но документы «широкие» (не нужен весь PDF, достаточно точного фрагмента);
• вы строите поисковый ассистент: правильный ранжировщик важнее тотального включения всех материалов.

RAG и контекстное окно: как подружить

RAG (Retrieval-Augmented Generation) минимизирует давление на окно: прежде чем формировать ответ, система ищет и подбирает только релевантные куски. Типичные элементы:

• Индексирование: разбиение источников на чанки (части) и построение поискового индекса (семантический/лексический).
• Ранжирование: выбор k лучших фрагментов под текущий вопрос.
• Сборка контекста: аккуратное форматирование (источник → цитата → тезисы), оглавление, «якоря» и краткое резюме в хвосте.
• Адаптация: размер чанка, перекрытие, фильтры дубликатов подбираются под задачу и модель.

Рекомендации по разбиению:

• Размер чанка: 400–1 200 токенов (в зависимости от плотности фактов);
• Перекрытие: 50–150 токенов (чтобы не рвать смысл);
• Формат: единый шаблон «Заголовок → Ключевые факты → Цитаты (с привязкой к источнику)».

«Контекстное окно» vs «память» модели

Частая путаница:

• Контекстное окно — оперативный вход на шаге генерации (то, что модель сейчас «видит»).
• KV-кэш — ускорение повторного обращения к уже пройденным токенам внутри текущего окна.
• Обучающие данные — то, на чём модель училась ранее; они не подмешиваются автоматически в ответ.
• Внешняя память/инструменты — базы знаний, веб-поиск, векторы, плагины — помогают подобрать и сжать нужные факты в окно.

Для пользователей это значит: если ассистент «забыл» вчерашние факты, их нужно снова передать или подключить механизм памяти/RAG, который будет это делать автоматически.

Практическая оценка объёма на русском

Примерный порядок:

• Страница A4 12 pt с межстрочным 1,15 — 350–500 слов ⇒ 500–800 токенов.
• Обзор на 1 500 слов ⇒ 2 000–2 400 токенов.
• Договор на 30 страниц (много пунктуации/нумераций) ⇒ 25–40 тыс. токенов.

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

Таблица: размеры окна и типовые сценарии

«Lost in the middle»: как бороться

• Сигнальные якоря: повторяйте в хвосте 3–7 ключевых тезисов (маркированный список).
• Оглавление/структура: явные заголовки «что в этом фрагменте» повышают извлекаемость фактов.
• Локальные резюме: после каждого большого куска — 3–5 строк «итога», затем следующий кусок.
• Устранение дубликатов: один и тот же факт, повторённый разными словами, «размывает» внимание.

Типовые ошибки при работе с окном

• Стратегия «всё и сразу». Заливка полных PDF без фильтрации; лучше извлечь текст, нормализовать, разбить на чанки.
• Отсутствие ранжирования. Вставка фрагментов «как попало», без учёта релевантности.
• Длинный системный промпт. Огромные инструкции вытесняют факты; держите «правила роли» компактными.
• Смешение форматов. Код, таблицы и «вода» в одной массе; приводите к единому шаблону.
• Без якорей. Нет явных заголовков/итогов; модель теряет ориентацию при длинных входах.

Чек-лист перед запуском в прод

1. Определено рабочее окно модели и бюджет токенов на каждый компонент (system/user/context/history).
2. Настроено разбиение источников (размер чанка/перекрытие) и дедупликация.
3. Есть ранжирование и лимит k фрагментов в сборке (под запрос).
4. Добавлены якоря (оглавление, тезисы в хвосте, ссылки на источник).
5. Промпты короткие, единый шаблон форматирования.
6. Включены метрики: доля успешных ответов, latency, токено-стоимость, «холостые» вставки.
7. Прописан план деградации: если контекст не помещается — компрессия/суммаризация, а не молчаливое усечение.

Вопросы стоимости: где «текут» токены

• Ввод: токены промпта + документы (вызов к модели).
• Вывод: токены ответа (чем длиннее — тем дороже).
• Повторы: при каждом шаге продолжающейся беседы часть истории снова «съедает» окно.

Оптимизация:

• выносите стабильные правила в компактный системный промпт;
• используйте ссылочную подачу (краткий тезис + ссылка на номер фрагмента), а не вставку «всего текста»;
• применяйте сжатие (extractive summary) для старых частей истории.

Проектирование промптов с учётом окна

Хороший промпт — это режиссёр контекста:

• Слоты: «Инструкции» → «Данные» → «Ожидаемый формат ответа». Не мешайте роли и факты.
• Ограничения: чётко задавайте рамки («используй только факты из контекста», «если нет факта — скажи об этом»).
• Прецеденты: пара малых примеров (few-shot) лучше одной огромной простыни.
• Идентификаторы: маркируйте источники ([A], [B], [C]), чтобы ссылка в ответе была однозначной.
• Хвост: краткий итог «что важно помнить» — уменьшает эффект «lost in the middle».

«Скользящее» окно и усечение истории

Большинство чатовых интерфейсов применяет скользящее окно: новые реплики добавляются в конец, а старые усекаются (удаляются из начала), чтобы вписаться в лимит. Если разговор «долгоиграющий», полезны:

• Периодическое сжатие истории (extractive/abstractive, лучше — первая ступень extractive → затем короткий абстракт);
• Пинning (закрепление) базовых фактов отдельно и инъекция их при каждом шаге;
• Вынос «вечных» фактов в внешнюю память (см. RAG), а не прокрутка их в каждой реплике.

Мини-глоссарий

• Токен — базовая единица текста для модели (часть слова/знак).
• Промпт — входные инструкции и данные пользователя.
• KV-кэш — кэш ключей/значений внимания для ускорения продолжения.
• Позиционное кодирование — способ учитывать «место» токена в последовательности.
• RAG — retrieval-augmented generation, генерация с извлечением релевантных фрагментов.
• Lost in the middle — феномен «потери» информации в середине длинного контекста.

См. также

• RAG: как подбирать контекст вместо «лить всё»
• AI: общий обзор