# ГЛАВА 4. КАУЗАЛЬНОЕ ЧТЕНИЕ И СИЛА ПЕРВОГО ФРЕЙМА

---

## 4.1. Что значит «каузальное чтение»: модель видит только прошлое

LLM — **авторегрессионные** модели. Их принцип работы — **каузальное чтение** (оно же каузальное декодирование): модель видит только предыдущие токены. Это не технический нюанс, а фундаментальное ограничение, из которого следуют все правила проектирования промптов.

Представьте, что вы читаете книгу строго слева направо, слово за словом, и при этом **физически не можете заглянуть вперёд** — страницы справа заклеены. Вы строите понимание предложения по мере чтения. Если в начале написано «банк», вы не знаете, речь о финансовом учреждении или берегу реки, пока не прочтёте следующие слова. Но вернуться и переосмыслить первое слово вы тоже не можете — оно уже «прочитано». Именно так работает LLM.

### Каузальная маска: как это устроено

Для тех, кто только начинает: **каузальная маска** — это механизм, который запрещает модели «подглядывать» за будущие токены. Простой пример:

> Допустим, модель генерирует предложение: **«Сегодня на улице идёт дождь».**
> Когда модель выбирает слово «идёт», она видит только «Сегодня на улице» — слова «дождь» для неё ещё не существует. Каждое следующее слово выбирается на основании только предыдущих.

Теперь формально. На каждом шаге генерации модель видит **только токены** слева от текущей позиции. Сам текущий токен и все будущие для неё ещё не существуют. Каузальная маска реализует это очень жёстко: токенам справа attention просто запрещён, поэтому после softmax они получают нулевой вес. Модель физически не может «заглянуть вперёд».

### Что это значит на практике

1. **Модель не может исправить начало, увидев конец.** Если в первом предложении промпта допущена ошибка, модель будет строить ответ на основе этой ошибки. Она не может «прочитать конец промпта» и скорректировать интерпретацию начала.

2. **Порядок информации критичен.** Один и тот же набор фактов, расположенный в разном порядке, даёт разные ответы — потому что ранние токены формируют контекст для интерпретации поздних, но не наоборот.

3. **Ошибки каскадируются.** Если модель сгенерировала неверный промежуточный шаг, все последующие шаги строятся на этой ошибке. Модель не может «откатиться» — она видит свой сгенерированный текст как часть контекста.

### Сравнение с двунаправленными моделями

| Свойство | Каузальная LLM (GPT, Claude, Llama) | Двунаправленная модель (BERT, RoBERTa) |
|----------|---------------------------------------|----------------------------------------|
| Маска attention | Треугольная (видит только прошлое) | Полная (видит всё) |
| Задача | Генерация текста | Понимание текста (классификация, NER) |
| Направление | Слева направо | Двунаправленно |
| Может генерировать? | Да | Нет (только MLM) |
| Может «передумать»? | Нет (без перезапуска) | Видит весь контекст сразу |

### Диффузионные LLM: важная ветка исследований, но не новый дефолт

В 2025–2026 годах усилился интерес к **диффузионным языковым моделям**. В отличие от авторегрессионных моделей, они генерируют текст **двунаправленно**: начинают с «шума» и постепенно уточняют всю последовательность сразу. Это исследовательская ветка, а не массовая замена autoregressive LLM.

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

**Почему это важно:**
- Диффузионные модели **могут «передумать»** — ранние токены изменяются с учётом поздних, что невозможно в каузальной модели
- Они могут генерировать все токены параллельно, что обещает значительное ускорение инференса
- **Траекторийная инерция** (описанная ниже в §4.4) в них значительно слабее — модель может корректировать начало текста на основании конца

К апрелю 2026 года диффузионные LLM перешли от чисто исследовательских демо к первым production-продуктам. **Mercury** (Inception Labs) стал первым коммерческим dLLM: компания предлагает API (≈$0.25/$0.75 за MTok input/output), обслуживает клиентов из Fortune 500 и фокусируется на задачах с высокой требовательностью к скорости генерации. **Gemini Diffusion** (Google DeepMind) демонстрирует значительное ускорение генерации в experimental demo (~1500 tok/s по данным демо-версии; точные характеристики не опубликованы официально). Тем не менее, для задач общего назначения авторегрессионные фронтирные модели остаются доминирующим выбором — dLLM пока не конкурируют с ними по качеству рассуждений и следования сложным инструкциям. Но подход активно развивается, и многие рекомендации этой главы (порядок информации, эффект прайминга, траекторийная инерция) специфичны именно для каузальных моделей.

---

## 4.2. Позиционные кодировки: как модель знает, что «где» стоит

### Зачем нужны позиционные кодировки?

Представьте коробку со словами на карточках. Вы засунули руку и достали слова «кот», «съел», «рыбу». Кто кого съел? Непонятно — порядок потерян. Именно так работает механизм attention без позиционных кодировок.

Transformer по природе — это **операция над множеством**: attention считает попарные связи между токенами, но **не знает, в каком порядке они стоят**. Без позиционных кодировок предложения `кот съел рыбу` и `рыбу съел кот` были бы для модели идентичны — как карточки в коробке.

Позиционные кодировки решают эту проблему: они **номеруют карточки**, чтобы каждое слово знало не только *что* оно означает, но и *где* оно стоит.

### Абсолютные позиционные эмбеддинги (оригинальный Transformer)

Vaswani et al. (2017) использовали синусоидальные кодировки: каждой позиции назначался набор волн разной частоты. Одни волны быстро меняются и помогают ловить локальный порядок, другие меняются медленно и помогают отличать дальние расстояния.

Проблема: плохая экстраполяция за пределы обученных длин. Модель, обученная на длине 2048, плохо работает на 4096.

### RoPE (Rotary Position Embeddings): стандарт 2024–2026

**RoPE** (Su et al., 2021) — позиционная кодировка, используемая в Llama, Mistral, Qwen, DeepSeek и большинстве современных моделей.

**Интуиция**: представьте, что каждое слово в предложении — это стрелка компаса. RoPE поворачивает эту стрелку на угол, пропорциональный позиции слова. Первое слово повёрнуто на 10°, второе на 20°, третье на 30°. Когда модель сравнивает два слова, она «видит» разницу углов — и таким образом понимает, насколько они далеко друг от друга. Это элегантно: каждое слово знает не только *что* оно означает, но и *где* оно стоит.

На практике RoPE делает следующее: берёт каждую пару координат вектора и поворачивает её на угол, зависящий от позиции токена. Важен не сам угол, а разница углов между двумя токенами. Поэтому модель лучше чувствует не абсолютный номер позиции, а **расстояние между токенами**. Это обеспечивает:
- Естественное затухание attention с расстоянием.
- Лучшую экстраполяцию на длины, не виденные при обучении.
- Инвариантность к абсолютной позиции одинаковых паттернов.

### Расширение контекста: YaRN и другие методы масштабирования RoPE

Модели обучаются на фиксированной длине (например, 8K токенов). Для работы с более длинными контекстами используются техники масштабирования позиционных кодировок. К апрелю 2026 года эти методы стали стандартом индустрии: вендоры уже публикуют окна от сотен тысяч до миллионов токенов. Например, Anthropic указывает **1M** для Claude Opus 4.6, Google в документации выводит в headline-линейку Gemini 3.x, а Meta для Llama 4 Scout заявляет до **10M** контекста. Но advertised window и эффективное извлечение фактов — не одно и то же.

**YaRN** (Yet another RoPE extensioN, Peng et al., 2023) — один из ключевых методов:
- Масштабирует позиционные частоты неравномерно по измерениям: низкочастотные компоненты (отвечающие за дальние связи) сжимаются сильнее, высокочастотные (локальные связи) — почти не меняются
- Позволяет расширить контекст в **10× и более** с минимальной потерей качества
- Варианты YaRN и его наследников используются во всех современных моделях с длинным контекстом

**NTK-aware scaling** (блочная интерполяция):
- Масштабирует температуру вращений, сохраняя корреляции токенов
- Требует минимального дообучения

**Важно понимать**: несмотря на рост контекстных окон до 1M–10M токенов, фундаментальные паттерны attention не изменились. Attention по-прежнему затухает с расстоянием, attention sinks никуда не делись, и Lost in the Middle ([Глава 5](05_long_context.md)) остаётся реальностью. Больше токенов — не значит лучшее понимание.

### ALiBi (Press et al., 2022)

Альтернативный подход: вместо позиционных эмбеддингов к attention score просто добавляется линейный штраф за расстояние. Чем дальше токен, тем ниже его исходный score. Подход простой, эффективный и хорошо экстраполирует. Используется в MPT, BLOOM.

---

## 4.3. Первый фрейм определяет траекторию ответа

### Эффект прайминга: «эффект первого впечатления» для модели

В психологии известен «эффект первого впечатления»: первые секунды знакомства формируют образ, который потом очень трудно изменить. У LLM работает точно такой же механизм — и он вытекает не из психологии, а из математики attention.

Первые 100–300 токенов промпта — **критическая зона**. Они формируют «аттрактор» в пространстве скрытых состояний модели: начальную точку, вокруг которой строится вся последующая генерация.

**Механизм:**

1. **Attention accumulation**: ранние токены проходят через все слои и накапливают attention-веса. К моменту генерации первого выходного токена ранние токены имеют наибольшее влияние на скрытые состояния.

2. **MLP activation pattern**: ранние токены определяют, какие ассоциации в MLP-слоях активируются. Это задаёт «тему» и «стиль» для всего ответа.

3. **Residual stream**: в Transformer информация передаётся через residual connections. Ранние токены формируют «baseline» residual stream, на который накладываются все последующие.

### Что определяет первый фрейм

| Аспект | Как задаётся | Пример |
|--------|-------------|--------|
| **Роль/персона** | Первое предложение | `Ты — старший Python-инженер с 10 годами опыта` |
| **Тон и стиль** | Лексика первых предложений | Формальный vs разговорный |
| **Уровень абстракции** | Контекстные маркеры | `На уровне архитектуры...` vs `В конкретном файле...` |
| **Домен знаний** | Ключевые термины | `В контексте HIPAA compliance...` → медицинский домен |
| **Формат вывода** | Структурные маркеры | `Ответь в формате JSON: {...}` |

### Экспериментальное подтверждение

Практический опыт и ряд исследований показывают:

1. **Порядок инструкций**: промпт «Сначала роль, потом задача, потом ограничения» стабильно лучше, чем «Сначала задача, потом роль, потом ограничения».

2. **Первые токены влияют непропорционально сильно**: ранняя часть промпта задаёт роль, тон и формат, а поздние уточнения нередко работают слабее, если противоречат уже сформированному фрейму.

3. **System prompt**: специальные «системные» токены получают повышенный attention-вес, потому что модель обучена на инструкциях, начинающихся с system prompt.

### Прайминг на практике: порядок в system prompt меняет поведение

Рассмотрим реальные сценарии:

**Сценарий 1: Роль в начале vs роль в конце**

✓ "Ты — опытный юрист. Проанализируй договор аренды."

✗ "Проанализируй договор аренды. Ты — опытный юрист."

В первом случае модель сначала активирует «юридические» нейроны, и весь анализ идёт через эту призму. Во втором — модель начинает «думать» о договоре без юридического фрейма, и роль, указанная после, влияет слабее.

**Сценарий 2: Первый пример задаёт паттерн**

Если в few-shot промпте первый пример ответа дан в формате JSON, а второй — в формате простого текста, модель с высокой вероятностью выберет JSON — потому что первый пример сформировал аттрактор.

**Сценарий 3: Негативный прайминг через описание ошибок**

Промпт «Не делай эти 10 ошибок: 1) не используй global variables...» парадоксально *повышает* вероятность этих ошибок. Почему? Потому что модель активировала нейроны, связанные с `global variables`, и этот паттерн «разогрет» в контексте. Лучше сформулировать позитивно: «Используй dependency injection и локальный scope».

**Сценарий 4: Языковой прайминг**

Если system prompt написан на английском, а пользовательский запрос на русском, модель может «колебаться» между языками в ответе — именно потому что первые токены активировали «англоязычный» режим.

## 4.4. Почему модели «трудно передумать»

### Траекторийная инерция

Представьте поезд, который выехал на рельсы в определённом направлении. Чем дальше он проехал, тем сложнее развернуться. LLM работает так же.

После генерации первых 50–100 токенов ответа модель «заякорена» на выбранной траектории. Изменение направления требует преодоления инерции скрытых состояний.

**Механизм:**

1. **Attention stabilization**: каждый сгенерированный токен добавляется в KV-кэш и учитывается всеми последующими токенами. Ранние сгенерированные токены накапливают attention вес.

2. **Commitment pattern**: если модель начала отвечать в определённом стиле (например, отказ: «Я не могу...»), паттерн самоподкрепляется — последующие токены более вероятны в контексте уже сгенерированного отказа.

3. **Residual accumulation**: каждый слой добавляет свой вклад в residual stream. К 40-му слою скрытые состояния настолько обусловлены ранними токенами, что «переключение» требует сильного сигнала.

### Когда модель может «передумать»

1. **Явный контраргумент с высоким attention-весом**: структурный маркер (`<override>`, `IMPORTANT:`, `IGNORE ABOVE`) может переключить attention.

2. **Многошаговая верификация**: если промпт явно просит «проверь свой ответ и исправь ошибки», модель может частично скорректировать генерацию.

3. **Контекстная перегрузка**: при очень длинном контексте attention может «переключиться» на новые якоря, забыв ранние — но это непредсказуемо.

4. **Extended thinking / test-time compute (2025–2026)**: современные модели вроде o3, Claude Opus 4.6 и Gemini reasoning-режимов умеют «думать дольше» перед ответом. Это **частично смягчает** траекторийную инерцию: модель может поймать часть ошибок до финального ответа. Но инерция никуда не исчезает — она просто частично сдвигается внутрь скрытого reasoning-процесса.

### Примеры траекторийной инерции на практике

**Пример 1: «Я не могу...» → отказ до конца**

Если модель начала ответ со слов «К сожалению, я не могу...», вероятность того, что она передумает и даст ответ, крайне низка. Паттерн отказа самоподкрепляется. Решение: переформулировать запрос, а не пытаться «уговорить» в том же диалоге.

**Пример 2: Выбор архитектуры на первом шаге**

Вы просите модель написать веб-приложение. Если она начнёт с `import flask`, то вся остальная архитектура будет Flask-style, даже если FastAPI подходил бы лучше. Если вам нужен FastAPI — укажите это *до* начала генерации.

**Пример 3: Зацикливание на неверном решении**

Модель решает математическую задачу. На шаге 3 допускает алгебраическую ошибку. Шаги 4–8 строятся на неверном результате, и просьба «проверь своё решение» часто приводит к тому, что модель «подтверждает» неверный ответ — потому что он уже в контексте.

### Стратегии смягчения инерции

| Стратегия | Как работает | Когда применять |
|----------|-------------|-------------------|
| **Перезапуск** | Новый чат / новый промпт — чистый контекст | Модель пошла не туда на раннем этапе |
| **Явный сброс** | «Забудь всё выше. Новая задача: ...» | Когда перезапуск дорог (длинный контекст) |
| **Пошаговая генерация** | Разбить задачу на маленькие шаги | Сложные многошаговые задачи |
| **Температура > 0** | Повышенная стохастичность ослабляет инерцию | Когда нужны разнообразные варианты |
| **Extended thinking** | Модель «думает» перед ответом | Логические и математические задачи |

### Когда перезапуск надёжнее

| Ситуация | Рекомендация |
|----------|-------------|
| Модель начала в неверном стиле | Перезапуск |
| Модель сделала фактическую ошибку на 5-м шаге из 10 | Перезапуск |
| Модель зациклилась (повторяет фразы) | Перезапуск |
| Модель правильно решила 8 из 10 шагов | Коррекция в диалоге |
| Нужно изменить тон, но не содержание | Попробуйте коррекцию, fallback — перезапуск |

**Правило**: перезапуск (новый чат / новая сессия / новый промпт) надёжнее, чем попытки «починить» сломавшуюся траекторию. Стоимость нового API-вызова < стоимость отладки неправильного ответа. (Исключение — модели с extended thinking: они могут частично корректировать себя внутри цепочки рассуждений.)

---

## 4.5. Attention Sinks: паразитные якоря

### Аналогия: закладка в книге

Представьте, что вы читаете длинную книгу и пользуетесь закладкой. Даже когда закладка лежит на неинтересной странице, вы всё равно к ней возвращаетесь — просто потому что она там есть. LLM делают то же самое с первыми токенами: они становятся «закладкой по умолчанию», куда модель направляет внимание, когда не знает, куда ещё его направить.

### Феномен

Xiao et al. (2023) обнаружили, что в авторегрессионных моделях **первые токены последовательности получают непропорционально высокий attention-вес** — независимо от их семантической релевантности.

**Количественные данные:**
- Средний attention к первому токену: **15–25%** по всем слоям
- Эффект усиливается в поздних слоях
- Наблюдается во всех протестированных моделях: Llama 2, MPT, Falcon, Pythia

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

В softmax attention, если ни один ключ не особенно релевантен запросу, модель всё равно должна распределить attention-веса (softmax суммирует до 1). Первый токен становится «закладкой-свалкой» — sink для неинформативного attention.

Это артефакт обучения, а не осознанная стратегия модели. Он имеет практические последствия:

1. **Первые токены «поглощают»** attention, который мог бы быть направлен на релевантные токены в середине контекста.
2. **При потоковом инференсе** удаление первых токенов из KV-кэша катастрофически ухудшает качество.
3. **В длинных контекстах** sink-эффект усиливает Lost in the Middle ([Глава 5](05_long_context.md)).

### StreamingLLM: практическое решение

Xiao et al. предложили StreamingLLM:
- Сохранять первые несколько sink-токенов + скользящее окно последних токенов
- Это позволяет обрабатывать последовательности до **4M+ токенов** без дообучения
- До **22× ускорения** на длинных последовательностях по сравнению с пересчётом full attention

---

## 4.6. Как размер контекста влияет на паттерны attention

С ростом контекстных окон до 1M–10M токенов возникает соблазн думать: «больше контекста = лучше понимание». На практике это не так.

### Что происходит с attention при увеличении контекста

| Размер контекста | Поведение attention | Практический эффект |
|---------|-----------|---------------------|
| **< 4K токенов** | Attention распределяется относительно равномерно | Модель хорошо «видит» всё |
| **4K–32K** | Появляется эффект Lost in the Middle | Средняя часть контекста игнорируется |
| **32K–200K** | Attention sinks усиливаются, локальные паттерны доминируют | Нужно явно указывать, где искать ответ |
| **200K–1M+** | Attention становится «разреженным» — модель фокусируется на нескольких «островках» | Нужна специальная архитектура промпта с навигационными маркерами |

### Практические следствия

1. **Не заполняйте контекст «про запас».** 200K токенов нерелевантного контекста хуже, чем 2K релевантного.

2. **Дублируйте ключевую информацию.** В длинных контекстах (>32K) повторите ключевой вопрос или ограничения ближе к концу.

3. **Используйте структурные маркеры.** Теги `<important>`, заголовки, разделители помогают attention «найти» нужную информацию в море токенов. Подробнее — в [Главе 7](07_markup_tags_and_prompt_architecture.md).

---

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

### Чек-лист каузального проектирования промптов

| # | Правило | Обоснование |
|---|---------|-------------|
| 1 | **Ставь самое важное в начало** | Ранние токены формируют аттрактор для всей генерации |
| 2 | **Порядок: роль → цель → ограничения → контекст → формат → запуск** | Соответствует механике attention accumulation |
| 3 | **Чистый перезапуск** надёжнее попыток «починить» | Траекторийная инерция делает коррекцию ненадёжной |
| 4 | **Priming критически важен** | Первые 100–300 токенов определяют семантический коридор |
| 5 | **Не надейтесь на «саморегуляцию»** | Модель не может «одуматься» в середине генерации без явного сигнала |
| 6 | **Используйте system prompt** | Он получает повышенный attention-вес из-за RLHF-обучения |
| 7 | **Помните о sink-токенах** | Первые токены поглощают attention; размещайте инструкции после system prompt, а не вместо него |

### Шаблон оптимального промпта (каузальный порядок)

```xml
<system>
  [Роль: кто модель в этом контексте]
  [Режим: как модель должна действовать]
</system>

<goal>
  [Цель: что нужно получить]
  [Критерии качества: как оценивать результат]
</goal>

<constraints>
  [Ограничения: чего нельзя делать]
  [Формат: точная структура вывода]
</constraints>

<context>
  [Данные: то, с чем работать]
  [Примеры: входы → выходы]
</context>

<trigger>
  Начни.
</trigger>
```

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

---

### Эксперименты для читателя

Попробуйте эти эксперименты, чтобы почувствовать каузальную механику на практике:

**Эксперимент 1: Порядок имеет значение**

Возьмите одну и ту же задачу и отправьте её в двух вариантах:
- А: «Ты — опытный разработчик. Напиши функцию сортировки списка.»
- Б: «Напиши функцию сортировки списка. Ты — опытный разработчик.»

Сравните качество кода, комментарии, стиль. Вариант А обычно даёт более профессиональный результат.

**Эксперимент 2: Траекторийная инерция**

Попросите модель решить задачу по шагам. Затем в том же чате скажите: «Шаг 2 неверный. Переделай.» Затем отправьте ту же задачу в новом чате с подсказкой по шагу 2. Сравните, какой вариант даёт лучший результат.

**Эксперимент 3: Негативный vs позитивный прайминг**

Отправьте два промпта:
- А: «Не используй глобальные переменные, не делай функции длиннее 50 строк, не забывай обработку ошибок»
- Б: «Используй dependency injection, короткие функции до 50 строк, явную обработку исключений»

Попросите модель написать один и тот же модуль с каждым промптом. Вариант Б (позитивный) обычно даёт более чистый код.

**Эксперимент 4: Эффект размера контекста**

Возьмите длинный документ (например, 10 страниц текста). Вставьте факт (например, «кодовое слово — банан») в начало, в середину, и в конец. Спросите модель: «Какое кодовое слово?» Вы увидите Lost in the Middle в действии.

### Задания

1. **Переупорядочение production-промпта.** Возьмите реальный промпт из вашего проекта (system + user). Переставьте секции в каузальном порядке: роль → цель → ограничения → контекст → формат → триггер. Прогоните обе версии (оригинальную и переупорядоченную) на 20–30 тестовых входах, сравните результаты по целевой метрике (accuracy, adherence to format, длина ответа). Ожидаемый результат: таблица «метрика → до / после», демонстрирующая влияние порядка секций. Альтернативно, используйте скрипт из промпта для ИИ ниже, который автоматизирует такой A/B-тест.

**Промпт для ИИ:** «Напиши Python-скрипт для A/B-тестирования порядка секций промпта. Скрипт принимает: (1) базовый промпт с секциями в каузальном порядке (роль → цель → ограничения → данные), (2) тот же промпт с переставленными секциями. Для каждого варианта делает 10 прогонов (temp=0.3) на 5+ тестовых запросах. Измеряет: parse rate (доля валидных ответов), семантическую стабильность (косинусное сходство между прогонами), качество по LLM-judge рубрике. Используй OpenAI API или Anthropic API. Результат — сводная таблица A vs B с p-value (Mann-Whitney U).»

2. **A/B-тест primacy vs recency.** Подготовьте задачу с 5–7 релевантными фактами. Создайте два варианта промпта: в одном ключевой факт размещён в первых 200 токенах, в другом — в последних 200. Запустите по 20 запросов каждого варианта и подсчитайте, в каком случае модель чаще использует этот факт. Ожидаемый результат: количественное подтверждение primacy/recency bias для конкретной модели.

3. **Аудит attention sinks.** Возьмите длинный контекстный промпт (>4K токенов) из вашей системы. Определите, какие токены занимают sink-позиции (первые 4–8 токенов системного промпта). Убедитесь, что эти позиции не заняты бессмысленным контентом (пустые теги, boilerplate). Если заняты — перепишите начало промпта так, чтобы sink-позиции содержали семантически значимый сигнал (роль, ключевое ограничение). Ожидаемый результат: оптимизированный промпт с осмысленным использованием ранних позиций.

4. **Протестируйте primacy/recency эффект.** Используйте промпт для ИИ ниже, чтобы автоматически провести количественный тест: насколько положение критической инструкции в промпте влияет на точность выполнения задачи.

**Промпт для ИИ:** «Напиши Python-скрипт для тестирования primacy/recency эффекта в промпте. Скрипт размещает критическую инструкцию в разных позициях (первые 10%, середина, последние 10% промпта) и измеряет, насколько модель следует инструкции. Тест-кейс: задача классификации или extraction с известным ground truth. Используй OpenAI API (можно любую модель), 20 тестовых примеров на каждую позицию. Вывод: таблица позиция → accuracy → вывод о primacy/recency. Добавь визуализацию через matplotlib (bar chart).»

---

## Источники
- Vaswani, A., et al. (2017). "Attention Is All You Need." NeurIPS.
- Su, J., et al. (2021). "RoFormer: Enhanced Transformer with Rotary Position Embedding."
- Press, O., et al. (2022). "Train Short, Test Long: Attention with Linear Biases Enables Input Length Generalization."
- Peng, B., et al. (2023). "YaRN: Efficient Context Window Extension of Large Language Models."
- Xiao, G., et al. (2023). "Efficient Streaming Language Models with Attention Sinks." ICLR 2024.
- Liu, N., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." TACL.
- Nie, S., et al. (2025). "Large Language Diffusion Models." arXiv:2502.09992. (LLaDA)
- Google DeepMind (2025). *Gemini Diffusion* — experimental text diffusion model demo.
- Inception Labs (2025). *Mercury* — production diffusion language model. https://inceptionlabs.ai/
---

**Навигация:**
- Назад: [Глава 3. Галлюцинации — не поломка, а режим работы](03_hallucinations.md)
- Далее: [Глава 5. Длинный контекст — иллюзия, что модель «видит всё»](05_long_context.md)
