Контекстне вікно (Context Window)(Архітектура та фізика контекстного вікна)

1. Огляд концепції та системна проблема

Розробники-початківці часто сприймають контекстне вікно як аналог жорсткого диска: місце, куди можна скинути будь-яку кількість документації, щоб модель «просто знала її».

Проте в реальній фізиці нейромереж контекстне вікно — це оперативна пам'ять графічного процесора (GPU VRAM), задіяна в інтенсивних матричних обчисленнях:

1. Квадратична складність уваги: У класичному механізмі Attention зв'язок розраховується між кожною парою токенів ($O(N^2)$). Збільшення довжини входу в 10 разів вимагає в 100 разів більше обчислювальних ресурсів на етапі префіксу (Prefill).
2. Апаратні обмеження пам'яті: Коли довжина діалогу сягає сотень тисяч токенів, розмір KV-кешу переростає ємність відеопам'яті відеокарти (Out of Memory - OOM).
3. Ліміт екстраполяції позицій: Модель не може адекватно сприймати позиції токенів, що виходять за межі її навчання, без спеціальних методів інтерполяції (RoPE / YaRN).

Контекстне вікно (Context Window) визначає горизонт активної робочої пам'яті системи: усе, що потрапляє всередину вікна, бере участь у розрахунку ймовірностей; усе, що залишається за його межами, для моделі фізично не існує.

2. Архітектурна таксономія та ментальна модель

Робота з контекстним вікном розділяється на дві фази обчислень та відповідні оптимізації:

• 1. Фаза префіксу (Prefill Phase): Паралельна обробка всього вхідного запиту користувача. Обчислювально обмежена фаза (Compute-bound), оптимізується технологіями на зразок FlashAttention-2/3, які усувають зайві звернення до глобальної пам'яті GPU.
• 2. Фаза декодування (Decode Phase): Послідовна генерація нових токенів по одному за крок. Обмежена пропускною здатністю пам'яті (Memory-bandwidth bound), де швидкість залежить від вибірки векторів із KV-кешу.
• 3. Архітектури довгого контексту:
  • RoPE (Rotary Position Embeddings): поворотні позиційні ембеддінги, що дозволяють масштабувати вікно з 8K до 1M токенів через частотне масштабування.
  • Ring Attention: розподіл обчислення механізму уваги по кільцю з десятків серверів GPU для опрацювання мільйонних послідовностей.
• 4. Структура бюджету вікна: Total Window = System Prompt + Long-term Memory + Ingestion Files + History + Tools Output + Max Generation Tokens.

3. Технічний пайплайн та внутрішня механіка

Життєвий цикл проходження контексту крізь трансформер:

1. Tokenization & BPE Mapping (Токенізація): Сирий рядок коду чи тексту транслюється у числовий вектор ID токенів через словник BPE/Tiktoken.
2. Positional Encoding Injection (Впровадження координат): Кожен токен отримує вектор позиції в послідовності (через матриці обертання RoPE).
3. Multi-Head Self-Attention & KV Cache Allocation (Розрахунок уваги): Обчислюються матриці Query, Key, Value. Вектори $K$ та $V$ записуються у VRAM-буфер KV-кешу для запобігання повторним розрахункам на наступних кроках.
4. Context Length Enforcement (Контроль лімітів): Якщо сумарна кількість токенів перевищує max_context_length, рантайм або скидає помилку 400 BadRequest: context_length_exceeded, або автоматично зрізає найстаріші повідомлення (Sliding Window Truncation).

4. Практичні інженерні сценарії в продакшені

01. In-Context Learning над усім репозиторієм проєкту

Завантаження 200 000 токенів кодової бази безпосередньо у вікно моделі (Cursor / Claude Code). Модель бачить усі типи, імпорти та архітектурні патерни одночасно, генеруючи новий модуль з ідеальним збереженням конвенцій проєкту.

02. Аналіз юридичних пакетів M&A та аудитів

Передача 500-сторінкового пакета контрактів у вікно Gemini 2.5/3 Pro (1M токенів) для пошуку взаємних суперечностей, неузгоджених фінансових умов та прихованих зобов'язань без втрати контексту між документами.

03. Економічна оптимізація через Prompt Caching

У довгоживучих асистентах системний промпт і документація API (наприклад, 40 000 токенів) кешуються провайдером (Anthropic/OpenAI). Завдяки цьому кожен наступний запит обробляється в 4 рази швидше і коштує на 90% дешевше.

5. Підводні камені, типові помилки та безпека

• Тихе обрізання контексту (Silent Truncation): Деякі наївні клієнти автоматично викидають початок діалогу при наближенні до ліміту. Якщо там містилися важливі системні правила безпеки, модель стає незахищеною.
• Out of Memory (OOM) на self-hosted серверах: Запуск Llama 3 70B на власній ноді з 80GB VRAM працює чудово на коротких тестах, але падає з критичною помилкою пам'яті, коли користувач надсилає запит на 64K токенів через роздування KV-кешу. Завжди обмежуйте max_model_len у vLLM.
• Експоненційне зростання рахунку: Неконтрольоване надсилання історії з кожним повідомленням призводить до того, що простий чат на 20 реплік генерує сотні тисяч оплачуваних вхідних токенів.