# ГЛАВА 5. ДЛИННЫЙ КОНТЕКСТ — ИЛЛЮЗИЯ, ЧТО МОДЕЛЬ «ВИДИТ ВСЁ»

---

## 5.1. Квадратичная сложность attention: фундаментальная стена

### Проблема коктейльной вечеринки

Представьте вечеринку. Каждый гость хочет поговорить с каждым другим гостем — хотя бы коротко. При 10 гостях это 45 разговоров (вполне реально). При 100 — уже 4 950. При 1 000 гостях — 499 500 разговоров. Это и есть квадратичная сложность: вечеринка, где количество рукопожатий растёт не пропорционально числу гостей, а *как квадрат* этого числа.

Self-attention работает именно так. Каждый токен — «гость», который должен обменяться информацией с каждым другим. Вот почему удвоение контекста — это не «в два раза дороже», а **в четыре**. А увеличение контекста в 10 раз — это **в 100 раз** больше вычислений.

### Математика проблемы

Наивный self-attention для последовательности длины $N$ с размерностью $d$:

- **Вычислительная сложность**: $O(N^2 \cdot d)$
- **Память**: $O(N^2)$ для хранения матрицы attention-весов

Конкретные числа:

| Context length ($N$) | Attention матрица ($N^2$) | Память (FP16) | Вычисления (относительно) |
|----------------------|--------------------------|---------------|--------------------------|
| 4K | 16M | ~32 МБ | 1× |
| 32K | 1B | ~2 ГБ | 64× |
| 128K | 16.4B | ~32 ГБ | 1024× |
| 1M | 1T | ~2 ТБ | 62500× |

Простыми словами: если обработка 4K токенов занимает 1 секунду, то 128K — уже ~17 минут при наивном подходе. А 1M токенов — больше 17 часов. Конечно, на практике оптимизации спасают, но порядок проблемы именно такой.

**Удвоение контекста → учетверение затрат.** Это не временная инженерная загвоздка, а фундаментальное свойство self-attention. Именно поэтому «просто увеличить контекст» — не решение.

### Почему нельзя просто использовать «длинный контекст»

Вендоры в 2025–2026 году предлагают впечатляющие окна контекста:

| Семейство | Заявляемое окно | Источник/период |
|-----------|-----------------|-----------------|
| Llama 4 Scout | до 10M токенов | Meta, 2025 |
| Grok 4.20 | 2M токенов | xAI, 2026 |
| GPT-5.4 | 1.05M токенов | OpenAI, 2026 |
| Claude Opus 4.6 | 1M токенов | Anthropic, 2026 |
| Gemini 3.1 Pro (Preview) | 1M токенов | Google, 2026 |
| Llama 4 Maverick | 1M токенов | Meta, 2025 |
| Qwen3.5 | 256K токенов | Alibaba, 2026 |
| Jamba2 | 256K токенов | AI21, 2026 |
| Gemma 4 (31B / 26B) | до 256K токенов | Google DeepMind, 2026 |
| DeepSeek-V3.2 | 128K токенов | DeepSeek, 2026 |

Формально — да, модель примет такой ввод. Но:

1. **Стоимость растёт суперлинейно** — даже при оптимизациях.
2. **Качество деградирует** — Lost in the Middle эффект (раздел 5.4).
3. **Латенси растёт** — time-to-first-token увеличивается пропорционально.
4. **Ошибки масштабируются** — одна ошибка в начале заражает весь длинный контекст (раздел 5.6).

---

## 5.2. Инженерные решения: как модели справляются с длинным контекстом

### Flash Attention (Dao et al., 2022–2024)

**Интуиция для начала.** Представьте, что вы читаете книгу в библиотеке. Книга лежит на стеллаже (медленная память GPU, HBM), а ваш стол — маленький, но близкий (быстрая память, SRAM). Наивный подход — ходить к стеллажу за каждой страницей, читать её, класть назад, идти за следующей. Умный подход (Flash Attention) — брать сразу пачку страниц, обрабатывать всю пачку на столе, не записывая промежуточные результаты обратно. Это как умное кэширование, которое избегает повторного чтения одной и той же страницы.

Flash Attention — не аппроксимация, а **точный** алгоритм с IO-оптимизацией. Он не изменяет математику attention; он изменяет порядок вычислений для оптимального использования GPU-памяти.

**Проблема**: GPU имеет иерархию памяти:
- **HBM** (High Bandwidth Memory): 40–80 ГБ, пропускная способность ~2 ТБ/с
- **SRAM** (on-chip): ~20 МБ, пропускная способность ~19 ТБ/с (в 10× быстрее)

Стандартный attention: вычисляет полную матрицу $N \times N$ → записывает в HBM → читает для softmax → записывает результат. Это **memory-bound**: узкое место — не вычисления, а чтение/запись.

**Решение Flash Attention:**
1. Разбить Q, K, V на блоки, помещающиеся в SRAM.
2. Вычислять attention по блокам, не материализуя полную $N \times N$ матрицу.
3. Использовать online softmax (Milakov & Gimelshein, 2018) для инкрементального обновления.
4. В backward pass пересчитывать attention вместо хранения — трейд-офф «память ↔ вычисления».

**Результаты:**

| Версия | Год | Ускорение | Утилизация GPU | Ключевое улучшение |
|--------|-----|-----------|-----------------|---------------------|
| FlashAttention-1 | 2022 | 3× (GPT-2, 1K) | 25–40% на A100 | IO-aware tiling |
| FlashAttention-2 | 2023 | 2× vs FA-1 | 50–73% на A100 | Параллелизация по головам, warp-оптимизация |
| FlashAttention-3 | 2024 | +1.5–2× vs FA-2 | ~75%+ на H100 | FP8 поддержка, асинхронные пайплайны |

FlashAttention-3 (2024) специально оптимизирован для архитектуры NVIDIA Hopper (H100/H200): использует асинхронные пайплайны Tensor Memory Accelerator (TMA), перекрывая копирование данных с вычислениями. Поддержка FP8 позволяет удвоить пропускную способность по сравнению с FP16 при минимальной потере качества.

**Сложность памяти:**
- Стандартный attention делает квадратичное число обращений к HBM: чем длиннее контекст, тем чаще приходится гонять большие промежуточные матрицы между медленной и быстрой памятью.
- FlashAttention оставляет ту же квадратичную математику, но резко сокращает число походов в HBM, потому что считает attention блоками в SRAM и не материализует полную матрицу целиком.

Flash Attention **не устраняет квадратичность** ($O(N^2)$ вычислений остаётся), но радикально снижает объём обращений к памяти, что на практике даёт 2–4× ускорение.

### Sparse Attention: разреженные паттерны

Вместо полного $N \times N$ attention используются разреженные паттерны:

**Longformer** (Beltagy et al., 2020):
- Sliding window attention: каждый токен «видит» $w$ ближайших соседей.
- Глобальные токены: специально отмеченные позиции видят весь контекст (например, `[CLS]`, начало секции).
- Сложность: $O(N \cdot w)$ — линейная.

**BigBird** (Zaheer et al., 2020):
- Sliding window + глобальные токены + **случайные связи**.
- Теоретически обосновано: разреженный attention + случайные рёбра → полная связность графа.
- Сложность: $O(N)$.

**Ограничение**: разреженные подходы теряют глобальные связи. Если ответ на вопрос требует сопоставления информации из начала и конца документа, а они разделены больше, чем окно, — модель «не увидит» связь.

### Sliding Window (Mistral, Phi)

Mistral использует фиксированное скользящее окно (4096 токенов по умолчанию) с каузальным сдвигом:

```
Позиция 8000: видит токены [3904..7999]
Позиция 12000: видит токены [7904..11999]
```

**Плюсы**: стабильный inference, фиксированный расход памяти.
**Минусы**: полная потеря контекста за пределами окна. Информация из начала длинного документа — недоступна.

### Глобальные якоря и рекурсивная компрессия

Продвинутые подходы (2024–2026):

1. **Hierarchical attention**: специальные summary-токены агрегируют информацию секций.
2. **Memory tokens**: выделенные позиции в KV-кэше для хранения глобальной информации.
3. **Recursive summarization**: длинный контекст сжимается в несколько итераций суммаризации.

### Ring Attention: распределённый инференс на нескольких GPU

**Ring Attention** (Liu et al., 2023) решает проблему памяти иначе: вместо того чтобы умещать весь KV-кэш на одном GPU, контекст разбивается на части между GPU. Каждый GPU хранит свой фрагмент, а KV-блоки передаются по кольцу: GPU 1 → GPU 2 → GPU 3 → ... → GPU 1.

Пока GPU обрабатывает текущий KV-блок, следующий уже передаётся по сети — вычисления перекрывают коммуникацию. Это позволяет масштабировать контекст практически линейно с числом GPU: 8 GPU с 80 ГБ каждый могут обработать контекст, который не влез бы ни на один из них.

### Гибридные архитектуры: обход квадратичной стены

К 2025–2026 году появилось решение, которое не просто оптимизирует, а **обходит** квадратичную проблему: гибридные архитектуры, сочетающие attention с SSM-слоями (State Space Models, например Mamba). Архитектурные основы гибридов — в Главе 2.

**Идея**: SSM-слои обрабатывают последовательность за $O(N)$ — линейно. Они отлично справляются с дальними зависимостями, но плохо — с точным извлечением конкретного факта из середины. Attention-слои — наоборот: точный поиск, но $O(N^2)$. Гибрид чередует оба типа.

**Подтверждённые гибриды Transformer + SSM:**

| Модель | Архитектура | Контекст | Ключевая особенность |
|--------|-------------|---------|---------------------|
| **Jamba** (AI21, 2024) | Mamba + Attention + MoE | 256K | Первый публично описанный production-гибрид |
| **Jamba2** (AI21, янв. 2026) | SSM-Transformer + MoE | 256K | Параметры семейства не полностью раскрыты; state passing для обобщения контекста; Apache 2.0 |

По состоянию на апрель 2026 года Jamba/Jamba2 — единственные подтверждённые production-модели с гибридной Transformer + SSM архитектурой. Архитектуры закрытых фронтирных моделей (GPT-5.x, Claude, Gemini, Grok) не раскрываются.

**Llama 4 и MoE — другой путь.** Llama 4 Scout (10M контекст) и Maverick (1M контекст) используют стандартный self-attention + MoE, а не SSM-гибридизацию. MoE снижает вычислительную стоимость за счёт активации лишь части экспертов (17B из 109–400B), но **не обходит $O(N^2)$ self-attention** — модель по-прежнему платит квадратичную цену за длину последовательности. Длинный контекст Llama 4 достигается через RoPE-масштабирование и параметрическую эффективность MoE, а не через линейный SSM.

Гибридные архитектуры Transformer + SSM — наиболее перспективный путь к действительно эффективным миллионным контекстам, потому что они не пытаются сделать attention дешевле — они используют его только там, где он незаменим.

---

## 5.3. KV-кэш: почему память важнее вычислений

### Что такое KV-кэш

При генерации каждого нового токена модель должна «посмотреть» на все предыдущие токены. Чтобы не пересчитывать их каждый раз, векторы Key и Value сохраняются в **KV-кэше** (кэш ключей-значений). KV-кэш, впервые упомянутый в контексте GQA (Глава 2), в длинных контекстах становится основным узким местом инференса.

Аналогия: представьте, что вы пишете сочинение, постоянно сверяясь с исходным текстом. KV-кэш — это ваши закладки и выписки на полях, чтобы не перечитывать всё с начала.

**Проблема масштаба:** для модели с 70B параметрами KV-кэш на 128K токенов занимает ~40 ГБ памяти GPU — зачастую больше, чем сами веса модели. При 1M токенов — сотни гигабайт. В 2025–2026 году управление KV-кэшем стало приоритетом № 1 для оптимизации инференса.

### PagedAttention и vLLM

**PagedAttention** (Kwon et al., 2023) применяет идею из операционных систем — страничную память — к KV-кэшу. Вместо выделения непрерывного блока памяти (где часть пустует, как фрагментация диска), KV-кэш разбивается на маленькие страницы фиксированного размера. Это устраняет фрагментацию и повышает утилизацию памяти GPU с ~50% до ~95%.

**vLLM** — открытый inference-фреймворк, построенный на PagedAttention. В 2025–2026 году стал стандартом для сервинга LLM.

### Продвинутые методы оптимизации KV-кэша

- **Multi-head Latent Attention (MLA)**: инновация DeepSeek-V2/V3 — вместо хранения полных K и V для каждой головы, MLA проецирует их в латентное пространство меньшей размерности. Это радикально сжимает KV-кэш без потери качества. DeepSeek открыл реализацию FlashMLA (github.com/deepseek-ai/FlashMLA). На апрель 2026 года MLA — наиболее значимая архитектурная инновация для длинных контекстов на уровне механизма attention.
- **KV-кэш компрессия**: квантизация KV-кэша до INT4/INT8 сокращает расход памяти в 2–4× с небольшой потерей качества.
- **Дизагрегированный сервинг (llm-d)**: разделение prefill (обработка входного контекста) и decode (генерация токенов) на разные GPU. Prefill — compute-bound (нужна грубая сила), decode — memory-bound (нужна пропускная способность памяти). Разделение позволяет оптимизировать каждый этап независимо.
- **Prefix caching**: если много запросов начинаются одинаково (общий system prompt), KV-кэш общего префикса переиспользуется между запросами.

Подробнее о KV-кэше в контексте serving и GPU capacity planning — в [Главе 21](21_serving_and_runtime_of_llm_systems.md).

---

## 5.4. Lost in the Middle: начало и конец сильнее середины

### Эмпирическое открытие

Вспомните последнюю книгу, которую вы читали. Вы помните, как она начиналась. Помните, чем закончилась. Но середина — главы 7–12 из 20 — сливаются в туманное «там что-то происходило». LLM страдают той же болезнью — только в гораздо предсказуемой, измеримой форме.

Liu et al. (2023, TACL) — одна из самых цитируемых работ по длинным контекстам. Ключевое открытие:

> Модели значительно лучше извлекают информацию из **начала** и **конца** контекста. Информация в **середине** систематически игнорируется.

### U-образная кривая

Если разместить ответ на вопрос в разных позициях длинного контекста (10–20 документов) и измерить точность:

```
Точность
100% |*                              *
     | *                           *
 80% |  *                        *
     |   *                     *
 60% |    *                  *
     |      *             *
 40% |        *  *  *  *
     |
  0% +--+--+--+--+--+--+--+--+--+--→ Позиция документа
     1  2  3  4  5  6  7  8  9  10
     начало     середина        конец
```

**Конкретные числа** (из экспериментов Liu et al.):
- Документ на позиции 1 (начало): ~85–90% accuracy
- Документ на позиции 5 (середина): ~40–55% accuracy
- Документ на позиции 10 (конец): ~75–85% accuracy

Это **U-образная кривая**: сильная деградация в середине.

### Почему это происходит

1. **Attention concentration**: из-за каузальной маски и attention sinks, ранние токены получают стабильно высокие attention-веса. Токены в конце — последние сгенерированные, они «свежие» в KV-кэше.

2. **Recency bias**: модель оптимизирована предсказывать **следующий** токен. Ближайшие предшествующие токены статистически наиболее релевантны.

3. **Primacy bias**: первые токены формируют «каркас» residual stream (см. Главу 4). Их влияние стабильно по всем слоям.

4. **Attention dilution**: при $N$ = 50000 токенов каждый query должен распределить attention по 50000 keys. Информация в середине «тонет» в шуме.

### Влияние на RAG-системы

Lost in the Middle непосредственно влияет на RAG:
- Если retriever возвращает 10 документов, отсортированных по релевантности, документ №5 (середина) будет плохо использован моделью.
- **Решение**: размещайте самый релевантный документ **первым и последним** (дублирование или reranking). Или ограничивайте количество документов до 3–5.

### Смягчают ли reasoning-модели этот эффект?

Да, частично. Модели с extended thinking и test-time compute нередко лучше справляются со сложными задачами поверх длинного контекста: дополнительное рассуждение помогает повторно обратиться к важным фрагментам и снизить часть ошибок извлечения.

Однако эффект **не исчезает полностью**: на сложных задачах с контекстом 100K+ токенов reasoning-режим не отменяет Lost in the Middle. Структурные митигации (XML-теги, позиционирование, retrieval, pre-extraction) остаются важными.

**Промпт для ИИ:** «Напиши Python-скрипт для проведения теста "Lost in the Middle" на выбранной модели. Скрипт: генерирует контекст из N документов (N=20, каждый ~500 токенов), прячет ключевой факт в одном из документов на позиции p (0% = начало, 50% = середина, 100% = конец). Для каждой позиции задаёт вопрос, ответ на который требует этого факта. Прогоняет 3 раза для каждой позиции. Строит график: позиция → accuracy retrieval. Используй OpenAI API или Anthropic API с длинным контекстом (32K+). Результат — CSV + график (matplotlib). Покажи пример для N=20.»

---

## 5.5. Attention Sinks в длинных контекстах

Механизм attention sinks и практическое решение StreamingLLM подробно разобраны в Главе 4.5. Здесь — только то, что меняется в масштабе длинного контекста.

**Что усиливается с ростом контекста:**

1. **Масштаб потерь.** При 4K токенов sink-позиции «забирают» 15–25% attention — заметно, но терпимо. При 128K+ тот же процент означает, что тысячи информативных токенов в середине теряют внимание в пользу семантически пустых позиций.
2. **Двойной удар по середине.** Attention sinks усиливают U-образную деградацию Lost in the Middle (раздел 5.4): середина контекста теряет attention и из-за dilution (больше токенов — тоньше распределение), и из-за стока в sink-позиции.
3. **KV-кэш при стриминге.** В streaming-сценариях (чат-боты, непрерывный анализ логов) нельзя выбрасывать sink-токены из KV-кэша — без них качество катастрофически падает. StreamingLLM решает это фиксацией первых 4–8 sink-позиций + скользящего окна последних токенов (детали алгоритма — в Главе 4.5).

---

## 5.6. Как длинный контекст замораживает ошибки

### Простой пример «заморозки ошибки»

Представьте игру «испорченный телефон». Первый игрок неточно передал слово, и теперь каждый следующий игрок опирается на ошибочную версию. Чем длиннее цепочка, тем невозможнее исправиться. В LLM это работает именно так: ошибка на позиции 100 оказывается «видна» всем 127 900 последующим токенам, и каждый из них строит свои выводы на неверном фундаменте.

### Каскад ошибок в длинном контексте

Этот эффект — следствие каузальной механики (Глава 4) в масштабе:

1. **Вводная ошибка**: неверное допущение в начале промпта или ранней генерации.
2. **Attention reinforcement**: все последующие токены «видят» ошибку и строят на ней.
3. **MLP activation lock**: ошибочная ассоциация активируется раз за разом.
4. **Масштаб**: в 128K-токенном контексте ошибка из позиции 100 влияет на 127.9K последующих токенов.

### Пример из практики

```xml
<system>
  Ты — юридический аналитик. Анализируй договоры по российскому праву.
</system>

<document>
  [128 страниц договора, ~50K токенов]
  ...
  Пункт 4.2: "Срок действия — 24 месяца с даты подписания (01.01.2024)"
  ...
  Пункт 7.3: "Штрафные санкции начисляются после 12 месяцев действия"
  ...
</document>

<task>
  Когда наступает срок начисления штрафных санкций?
</task>
```

Если модель неверно извлечёт дату из пункта 4.2 (например, `01.01.2025` вместо `01.01.2024`), весь расчёт штрафных санкций будет неверным. А пункт 4.2 находится в середине документа — именно в зоне Lost in the Middle.

### Контрмеры

1. **Pre-extraction**: извлеките ключевые факты из документа отдельным вызовом, передайте только их.
2. **Chunking + References**: разбейте документ на секции, обрабатывайте каждую отдельно с перекрёстными ссылками.
3. **Validation pass**: после генерации запустите отдельный промпт для проверки извлечённых фактов.

---

## 5.7. Стоимость длинного контекста: почему прайс-лист быстро устаревает

Миллионные контексты — это не только инженерная, но и экономическая проблема. Конкретные цены меняются быстрее, чем выходят печатные книги, но инварианты остаются:

1. **Очень длинный prompt почти всегда дороже, чем несколько коротких запросов с retrieval.**
2. **Даже при падении цен prefill большого контекста остаётся дорогим по latency и memory.**
3. **Self-hosting переносит расход из API-счёта в GPU-часы, но не отменяет стоимость префилла, KV-кэша и batching.**
4. **Провайдеры вводят ступенчатое ценообразование:** например, у GPT-5.4 свыше 272K входной токен стоит вдвое, а выходной — в полтора раза дороже стандартных тарифов. Это экономический сигнал: модель принимает 1M, но провайдер мотивирует использовать меньше.

### Когда что выбрать

| Сценарий | Рекомендуемый подход | Почему |
|----------|---------------------|--------|
| Вопросы по одному большому документу (>50K токенов) | Pre-extraction → верификация | Дешевле по токенам, выше точность извлечения фактов из середины |
| Вопросы по коллекции документов | RAG + reranking | Масштабируется на сотни документов; retriever фокусирует контекст |
| Анализ связей между частями одного контекста (код, лог, стенограмма) | Полный контекст + структурные маркеры | Связи между частями теряются при нарезке |
| Многошаговый агент с инструментами | Средний контекст + tool use | Агент запрашивает данные по мере необходимости, а не грузит всё заранее |

Практический вывод: прежде чем «заливать всё в 1M токенов», сравните это с двумя альтернативами — RAG + reranking и pre-extraction + verification. Во многих production-системах они дешевле и надёжнее.

---

## 5.8. Практические стратегии работы с длинным контекстом

### Стратегия 1: Структурируй контекст XML-тегами

```xml
<document section="4.2" topic="срок действия">
  Срок действия — 24 месяца с даты подписания (01.01.2024).
</document>

<document section="7.3" topic="штрафные санкции">
  Штрафные санкции начисляются после 12 месяцев действия.
</document>
```

Парные теги каждые ~200 токенов создают «якоря» для attention — модель распознаёт XML-паттерны и направляет attention к нужным секциям.

### Стратегия 2: Секционируй длинные промпты

Правило: **не более 1000 токенов на секцию** с явными заголовками.

```xml
<section id="1" title="Входные данные">
  [До 1000 токенов]
</section>

<section id="2" title="Требования">
  [До 1000 токенов]
</section>

<section id="3" title="Ожидаемый формат">
  [До 1000 токенов]
</section>
```

### Стратегия 3: Грузи ключевую информацию в начало

Пока работает full attention (первые 1–4K токенов), модель наиболее «внимательна». Размещайте:
- Системные инструкции
- Ключевые ограничения
- Формат вывода
- Самые важные данные

### Стратегия 4: Брейншторм — в отдельном чате

Не смешивайте исследовательские запросы (высокая энтропия, много вариантов) с исполнительными (низкая энтропия, точность). Загрязнение контекста брейнштормом ухудшает точность исполнения.

### Стратегия 5: Отключай неиспользуемые MCP-серверы

Каждый подключённый MCP/tool-сервер добавляет описания инструментов в контекст (часто 500–2000 токенов на сервер). 10 неиспользуемых серверов = 5000–20000 токенов шума.

### Стратегия 6: Как эффективно использовать 1M токенов

Миллионный контекст — не повод забрасывать всё подряд. Вот когда он действительно оправдан:

1. **Анализ целой кодовой базы**: загрузите все файлы проекта, но добавьте карту файлов в начало (`## Структура проекта: ...`).
2. **Многодокументный анализ**: перекрёстный анализ нескольких документов, где важен контекст между ними.
3. **Длинные расшифровки/логи**: когда нужно найти паттерн во всём массиве данных.

**Принципы эффективного использования:**

- **Оглавление в начале**: первые 500–1000 токенов — краткое описание структуры того, что загружено.
- **Разделители между документами**: чёткие XML-теги или маркеры (`<file path="...">...</file>`).
- **Задачу — в конец**: вопрос или инструкция в последних токенах, где attention максимален.
- **Не дублируйте информацию**: избыточность расходует токены и размывает attention.

---

## Практический вывод

### Чек-лист для длинных контекстов

| # | Правило | Метрика |
|---|---------|--------|
| 1 | **Структурируйте XML-тегами** | Каждые ~200 токенов — парный тег |
| 2 | **Секционируйте** | До 1000 токенов на секцию |
| 3 | **Критичное — в начало** | Первые 1–4K токенов — зона максимального attention |
| 4 | **Задачу — в конец** | Вопрос в последних токенах входа |
| 5 | **Измеряйте accuracy по позициям** | Тестируйте: находит ли модель факт из середины? |
| 6 | **Используйте RAG вместо stuffing** | Лучше 3 релевантных фрагмента, чем весь документ |
| 7 | **Брейншторм ≠ исполнение** | Отдельные чаты для разных режимов |
| 8 | **Минимизируйте noise** | Отключите ненужные MCP/tools |
| 9 | **Валидируйте извлечённые факты** | Отдельный verification pass |
| 10 | **Считайте стоимость** | Сверяйте текущие прайсы провайдера и сравнивайте с RAG/pre-extraction |

### Задания

1. **Тест Lost in the Middle на вашем use case.** Возьмите 10 тестовых вопросов, ответы на которые содержатся в разных частях длинного документа (>20K токенов). Разместите каждый ответ поочерёдно в начале, середине и конце контекста. Измерьте accuracy по позициям. Ожидаемый результат: U-образная кривая и конкретные цифры деградации для вашей модели и задачи — база для решения о RAG vs full context.

2. **Сравнение RAG vs context stuffing.** Подготовьте 50 вопросов по корпусу из 5–10 документов (суммарно 50K+ токенов). Сравните два подхода: (а) загрузка всех документов в один запрос; (б) RAG-пайплайн с top-3 чанками. Измерьте accuracy, latency и стоимость. Ожидаемый результат: количественные данные для решения, какой подход экономически и качественно оправдан в вашем сценарии.

3. **Оценка эффекта структурных маркеров.** Возьмите длинный промпт (10K+ токенов) без разметки. Добавьте XML-теги, секционирование и оглавление по стратегиям из раздела 5.8. Проведите A/B-тест на 20+ запросах. Ожидаемый результат: измеримое улучшение accuracy на фактах из середины контекста.

4. **Посчитайте стоимость длинного контекста.** Используйте промпт для ИИ ниже, чтобы построить собственный калькулятор с актуальными ценами на момент запуска. Это поможет принимать экономически обоснованные решения: загружать ли всё в контекст или использовать RAG.

**Промпт для ИИ:** «Напиши калькулятор стоимости длинного контекста для разных моделей. Принимает: список контекстных окон (8K, 32K, 128K, 256K, 1M токенов), среднее число токенов в ответе, число запросов в день. Для каждой модели (GPT-5.4, Claude Opus 4.6, Claude Sonnet 4.6, GPT-5.4-mini, Gemini 3.1 Pro, self-hosted Llama 4 Scout) считает: стоимость одного запроса, стоимость в день, стоимость в месяц. Учитывает prompt caching для кэшируемых частей (системный промпт 2000 токенов). Self-hosted считает через стоимость GPU-часа / пропускную способность. Вывод — сортируемая таблица в терминале. Используй актуальные цены (встрой в константы с комментарием "проверить актуальность").»

### Ментальная модель

> **Длинный контекст — как длинный коридор с плохим освещением.** У входа (начало) и у выхода (конец) — яркие лампы. В середине — полумрак. Модель «видит» всё, но **различает** — только то, что хорошо освещено. Ваша задача — расставить дополнительные «лампы» (структурные маркеры, якоря) там, где нужна точность.

---

## Источники
- Dao, T., et al. (2022). "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness." NeurIPS.
- Dao, T. (2023). "FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning."
- Shah, J., et al. (2024). "FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision."
- Beltagy, I., et al. (2020). "Longformer: The Long-Document Transformer." arXiv:2004.05150.
- Zaheer, M., et al. (2020). "Big Bird: Transformers for Longer Sequences." NeurIPS.
- Liu, N., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." TACL.
- Xiao, G., et al. (2024). "Efficient Streaming Language Models with Attention Sinks." ICLR 2024.
- Liu, H., et al. (2023). "Ring Attention with Blockwise Transformers for Near-Infinite Context."
- Peng, B., et al. (2023). "YaRN: Efficient Context Window Extension of Large Language Models."
- Kwon, W., et al. (2023). "Efficient Memory Management for Large Language Model Serving with PagedAttention." SOSP.
- Lieber, O., et al. (2024). "Jamba: A Hybrid Transformer-Mamba Language Model." arXiv:2403.19887.
- AI21 (2026). "Introducing Jamba2." ai21.com/blog/introducing-jamba2.
- DeepSeek-AI (2024). "DeepSeek-V3 Technical Report." arXiv:2412.19437.
- Gu, A. & Dao, T. (2023). "Mamba: Linear-Time Sequence Modeling with Selective State Spaces." arXiv:2312.00752.
- OpenAI (2026). "Models — API Reference." developers.openai.com/docs/models.
- xAI (2026). "Models." docs.x.ai/docs/models.

---

**Навигация:**
- Назад: [Глава 4. Каузальное чтение и сила первого фрейма](04_causal_reading_and_the_power_of_the_first_frame.md)
- Далее: [Глава 6. Промпт — это протокол, а не просьба](06_prompt_is_a_protocol.md)
