BlackboxBook/book/05_long_context.md

ГЛАВА 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×

Простыми словами: при наивном attention обработка 4K токенов за 1 секунду означала бы ~17 минут для 128K и более 17 часов для 1M токенов. На практике оптимизации (Flash Attention, sparse attention, гибридные архитектуры) радикально снижают эти цифры — но порядок квадратичной проблемы показателен.

Удвоение контекста → учетверение затрат. Это не временная инженерная загвоздка, а фундаментальное свойство 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 архитектурой. Родственный подход демонстрирует Qwen3.5-397B-A17B: гибрид Gated DeltaNet (линейное внимание) + стандартный Attention + MoE — не 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 дешевле — они используют его только там, где он незаменим.

Ещё одно архитектурное направление — gated attention (2505.06708): добавление head-specific сигмоидного гейта после SDPA, которое, как показало исследование на моделях до 15B MoE и 3.5T токенов обучения, улучшает экстраполяцию на длину контекста и подавляет attention sink. Это не замена гибридам, а ортогональная оптимизация, совместимая с любой архитектурой.

---

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-кэш разбивается на страницы фиксированного размера. Это устраняет фрагментацию и, по данным vLLM, повышает утилизацию памяти GPU до near-zero waste.

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.

---

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 последующих токенов.

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

<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 входных токенов действуют повышенные тарифы (уточняйте на pricing page OpenAI — цены меняются).

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

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

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

---

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

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

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

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

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

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

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

<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.
• Ann, S., et al. (2025). "Gated Attention for Large Language Models: Non-linearity, Sparsity, and Attention-Sink-Free." arXiv:2505.06708.

---

Навигация:

• Назад: Глава 4. Каузальное чтение и сила первого фрейма
• Далее: Глава 6. Промпт — это протокол, а не просьба