# ГЛАВА 8. НЕСКОЛЬКО ГИПОТЕЗ ЛУЧШЕ ОДНОЙ

Вы когда-нибудь писали текст, потом стирали и переписывали с нуля — и второй вариант оказывался лучше? Или начинали решать задачу одним способом, заходили в тупик, пробовали иначе — и находили элегантное решение? Именно поэтому многогипотезная генерация работает: вместо того чтобы ставить всё на одну лошадь, мы просим модель сгенерировать несколько вариантов и выбираем лучший. Это одна из самых мощных идей в современной инженерии промптов.

---

## 8.1. Суперпозиция внутри модели

### Скрытые состояния содержат множество вариантов

Представьте струну гитары. Когда вы её дёргаете, она вибрирует не одной частотой — в ней одновременно звучат основной тон и множество обертонов. Все эти частоты **сосуществуют** в одной струне, пока вы не приложите фильтр и не выделите одну из них.

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

**Toy Models of Superposition** (Elhage et al., Anthropic, 2022) — фундаментальная работа, показывающая, что нейронные сети хранят больше «концептов», чем у них есть измерений. Иначе говоря, число различимых идей внутри скрытого пространства может быть больше, чем число самих нейронов. Это как хранить тысячу книг в комнате с сотней полок — просто кладёте несколько книг на каждую полку под разными углами.

### Как суперпозиция влияет на генерацию

На последнем слое модель превращает скрытое состояние в список оценок для всего словаря — это и есть logits. Затем эти оценки проходят через температуру и softmax, превращаясь в распределение вероятностей по токенам.

При генерации выбирается **один** токен из этого распределения. Все остальные варианты **схлопываются** — безвозвратно.

### Проблема жёсткого greedy decoding

**Greedy decoding** (температура стремится к нулю): всегда выбирает токен с максимальным logit.

Проблема: жадный выбор на каждом шаге не гарантирует глобально оптимальную последовательность. Пример:

```
Шаг 1: "Оптимальная структура для этой задачи — "
  Вариант A: "класс" (logit: 8.2)  → ведёт к OOP-решению
  Вариант B: "функция" (logit: 7.9) → ведёт к функциональному решению
  Greedy выбирает "класс"
  
Шаг 2-100: модель генерирует OOP-решение
```

Если функциональный подход был бы лучше для данной задачи, greedy decoding навсегда заблокировал этот путь на шаге 1.

---

## 8.2. Принцип «Superposition and Collapse»: не схлопывай рано

### Аналогия с квантовой механикой

До измерения (декодирования) — суперпозиция вариантов. После — один конкретный результат. Измерить нельзя откатить.

### Практический принцип

**Генерируйте несколько вариантов, затем выбирайте.** Это превращает декодирование из «одного броска кости» в «серию бросков с выбором лучшего результата».

```
[Промпт] → Генерация N вариантов → Оценка (человек / модель / метрика) → Финальный выбор
```

### Когда это оправдано

| Цена ошибки | Сложность задачи | N вариантов | Почему |
|-------------|------------------|-------------|--------|
| Низкая | Низкая | 1 | Один проход достаточен |
| Низкая | Высокая | 3–5 | Исследование пространства |
| Высокая | Низкая | 1–2 | Верификация > множество вариантов |
| Высокая | Высокая | 5–10 | Максимальное покрытие + выбор |

---

## 8.3. Self-Consistency: варианты → выбор согласованного

### Метод

Self-Consistency (Wang et al., ICLR 2023) — одна из самых эффективных и простых техник улучшения качества.

Аналогия: вы заболели и идёте к **десяти разным врачам**. Каждый обследует вас независимо, каждый рассуждает по-своему — но семь из десяти ставят один и тот же диагноз. Вы доверяете мнению большинства. Это и есть Self-Consistency.

Алгоритм:

1. **Сгенерировать** $n$ независимых CoT-цепочек (с температурой $T > 0$).
2. **Извлечь** финальный ответ из каждой цепочки.
3. **Голосовать**: выбрать ответ, который появился чаще всего (majority voting).

```
Промпт → [CoT₁ → Ответ: 42]
       → [CoT₂ → Ответ: 42]
       → [CoT₃ → Ответ: 37]
       → [CoT₄ → Ответ: 42]
       → [CoT₅ → Ответ: 42]

Majority vote → 42 (4 из 5)
```

### Результаты

Self-Consistency vs стандартный CoT (одна цепочка):

| Бенчмарк | CoT (1 цепочка) | Self-Consistency (40 цепочек) | Улучшение |
|----------|------------------|-------------------------------|-----------|
| GSM8K | 56.5% | 74.4% | **+17.9 п.п.** |
| SVAMP | 79.0% | 90.0% | **+11.0 п.п.** |
| AQuA | 35.8% | 48.0% | **+12.2 п.п.** |
| StrategyQA | 73.4% | 79.8% | **+6.4 п.п.** |
| ARC-challenge | 85.2% | 89.1% | **+3.9 п.п.** |

**Модели**: PaLM 540B, Codex, UL2 — все показывают стабильное улучшение.

*Лучшие результаты из Wang et al. (2023); строки могут соответствовать разным моделям (PaLM 540B, Codex, UL2). Конкретная модель для каждого бенчмарка — в таблице 1 оригинальной статьи.*

### Почему это работает

1. **Разные цепочки исследуют разные пути**: температура $>0$ обеспечивает разнообразие промежуточных шагов.
2. **Правильный ответ робастнее**: к верному ответу ведёт больше рассуждений, чем к неверному. Множество разных путей сходятся к одной точке.
3. **Ошибки случайны, правильность системна**: каждая отдельная ошибка — случайное отклонение, а правильный ответ — аттрактор.

### Оптимальное N

- $n = 5$: уже значительное улучшение, хороший компромисс стоимость/качество.
- $n = 10–20$: оптимум для большинства задач.
- $n = 40+$: diminishing returns, оправдано только для критических задач.

> **Промпт для ИИ:** «Напиши Python-скрипт для реализации Self-Consistency с majority vote. Скрипт: принимает промпт и число сэмплов N (по умолчанию 5), делает N параллельных вызовов LLM (temp=0.7), извлекает финальный ответ из каждого сэмпла, применяет majority voting для выбора консенсусного ответа. Для числовых ответов — голосование по точному совпадению. Для текстовых — семантическая кластеризация (cosine similarity эмбеддингов, порог 0.85). Возвращает: консенсусный ответ, confidence score (доля согласных), список всех сэмплов. Используй OpenAI API или Anthropic API с asyncio для параллельных вызовов. Покажи пример на задаче с математическим рассуждением.»

### Анализ стоимости: сколько реально стоит Self-Consistency

Посчитаем на конкретном примере. Задача: математическая проблема, промпт ~500 токенов, ответ ~300 токенов. Цены на апрель 2026:

| Стратегия | Модель | N | Стоимость за запрос |
|-----------|--------|---|---------------------|
| Один вызов | Claude Opus 4.6 | 1 | ~$0.010 |
| Self-Consistency | Claude Opus 4.6 | 10 | ~$0.10 |
| Self-Consistency | Claude Haiku 4.5 | 5 | ~$0.010 |
| Self-Consistency | Claude Haiku 4.5 | 40 | ~$0.080 |
| Один вызов | GPT-5.4 | 1 | ~$0.006 |
| Self-Consistency | GPT-5.4-nano | 8 | ~$0.004 |

> *Цены рассчитаны для задачи ~500 входных + ~300 выходных токенов по тарифам апреля 2026: Opus 4.6 — $5/$25, Haiku 4.5 — $1/$5, GPT-5.4 — $2.50/$15, GPT-5.4-nano — $0.20/$1.25 за MTok (input/output). Проверяйте актуальные тарифы: anthropic.com/pricing, platform.openai.com/docs/pricing. Опубликованных бенчмарков Self-Consistency для этих конкретных моделей нет — качество зависит от задачи, числа цепочек и температуры.*

Обратите внимание: **5 вызовов Haiku стоят столько же, сколько один вызов Opus** (~$0.010), а Self-Consistency из 5 цепочек уже даёт существенный рост качества. Аналогично, ~8 вызовов GPT-5.4-nano обходятся дешевле одного вызова GPT-5.4. Это ключевая интуиция: можно обменять размер модели на количество попыток — об этом подробнее в разделе 8.8.

---

## 8.4. Best-of-N: генерация + оценка

### Развитие идеи

Self-Consistency работает через голосование по финальному ответу. **Best-of-N** идёт дальше — использует внешнюю функцию оценки.

Аналогия: вы пишете **пять черновиков** письма клиенту, потом даёте их коллеге и говорите: «Выбери лучший». Коллега (функция оценки) может быть кем угодно: другой моделью, набором тестов или обученной моделью предпочтений (reward model).

Алгоритм:

1. Сгенерировать $n$ вариантов.
2. Оценить каждый вариант функцией `score(output) → float`.
3. Выбрать вариант с максимальным score.

> **Промпт для генерации кода:** «Напиши функцию `best_of_n(prompt, n, scorer)` на Python. Функция должна: (1) сгенерировать n вариантов ответа через API модели с temperature=0.7, (2) оценить каждый вариант функцией scorer, (3) вернуть вариант с максимальным score. Используй OpenAI API или Anthropic SDK. Добавь параллельный запуск через asyncio для снижения latency.»

### Функции оценки

| Тип | Пример | Применение |
|-----|--------|------------|
| **Reward model** | Обученная модель предпочтений | Общее качество ответа |
| **Code execution** | `pytest` на сгенерированном коде | Кодогенерация |
| **Schema validation** | JSON Schema / Pydantic | Structured outputs |
| **Factual check** | RAG + сравнение с источником | Фактуальные задачи |
| **Self-evaluation** | LLM-as-Judge (вторая модель) | Универсально |
| **Heuristic** | Длина, наличие ключевых слов | Быстрая фильтрация |

### Best-of-N в продакшене (2025–2026)

Best-of-N с reward model scoring перешёл из исследований в промышленную практику. Вот где это стандарт сегодня:

- **Кодогенерация**: сгенерировать N вариантов кода → прогнать тесты → взять тот, который прошёл все тесты (sample-then-verify). Именно так работают AlphaCode 2, Cursor и другие продакшен-системы.
- **Математика**: сгенерировать N доказательств → проверить формальным верификатором (Lean, Isabelle). Используется в AlphaProof  и аналогичных системах.
- **Общий паттерн sample-then-verify**: сгенерировать много, верифицировать каждый вариант, взять лучший. Работает всюду, где есть автоматический верификатор (тесты, схемы, формальные проверки).

Новый практический вывод 2025 года: масштабировать число попыток имеет смысл только вместе с хорошим верификатором. Для кодовых задач это означает простое правило: не просите модель «подумать ещё» бесконечно; лучше сгенерируйте 3–5 патчей, прогоните `pytest`, `mypy`/`pyright`, `ruff` и проверку схемы, а затем возьмите минимальный дифф, который действительно прошёл проверки. Если внешнего верификатора нет, рост `N` быстро превращается в дорогой перебор с нестабильной отдачей.

### LLM-as-Judge

Используйте вторую модель (или тот же модель с другим промптом) для оценки:

```xml
<role>Expert evaluator</role>
<task>
  Rate the following code response on a scale 1-10.
  Criteria: correctness, efficiency, readability, error handling.
</task>
<response_to_evaluate>
  {candidate}
</response_to_evaluate>
<output_format>
  {"score": N, "reasoning": "...", "issues": [...]}
</output_format>
```

---

## 8.5. Брейншторм vs одношаговая генерация

### Два режима, два набора параметров

| Параметр | Режим «Брейншторм» | Режим «Исполнение» |
|----------|--------------------|--------------------|
| **Цель** | Покрытие пространства решений | Стабильность и точность |
| **Temperature** | 0.7–0.9 | 0.0–0.3 |
| **Top-p** | 0.95 | 0.9 |
| **N вариантов** | 3–10 | 1 |
| **Формат** | Свободный | Строгий (JSON Schema) |
| **Верификация** | Не нужна на этом этапе | Обязательна |
| **Промпт** | «Предложи 5 разных подходов...» | «Реализуй вариант B...» |

### Трёхфазный workflow

```
Фаза 1: ИССЛЕДОВАНИЕ (Брейншторм)
├── temp=0.8, n=5
├── "Предложи 5 разных архитектурных подходов для..."
├── Результат: 5 вариантов с плюсами/минусами
│
Фаза 2: ВЫБОР (Критический анализ)
├── temp=0.2, n=1
├── "Из этих 5 вариантов выбери оптимальный по критериям: 
│    производительность, поддерживаемость, стоимость."
├── Результат: обоснованный выбор
│
Фаза 3: РЕАЛИЗАЦИЯ (Исполнение)
├── temp=0.1, n=1
├── "Реализуй вариант B: [детальная спецификация]"
├── Результат: код / документ / конфигурация
```

### Почему не объединять фазы

Объединение режимов в одном промпте создаёт conflict:
- Высокая температура для исследования → нестабильность реализации.
- Низкая температура для исполнения → узость исследования.
- Длинный контекст (все варианты + выбор + реализация) → Lost in the Middle.

**Изолируйте фазы**: отдельные вызовы, отдельные промпты, отдельные контексты.

---

## 8.6. Advanced: Tree of Thoughts и Graph of Thoughts

### Tree of Thoughts (Yao et al., NeurIPS 2023)

Представьте шахматиста, который думает на несколько ходов вперёд. Он не делает первый попавшийся ход — он мысленно проигрывает несколько вариантов, отсекает плохие ветки («тут я теряю ладью»), углубляется в перспективные — и только потом двигает фигуру. Tree of Thoughts работает точно так же.

Развитие CoT: вместо одной цепочки строится **дерево** рассуждений с возможностью backtracking:

```
Задача: "Game of 24: используя числа [1, 2, 3, 4] и операции +−×÷ получи 24"

         [1, 2, 3, 4]
        /     |      \
   1+2=3    1×2=2    1+3=4
   [3,3,4]  [2,3,4]  [4,2,4]
    /  \       |         \
  3+3=6  ...  2+3=5     4×4=16
  [6,4]       [5,4]     [16,2]
    |           |          \
  6×4=24 ✓   5×4=20       ...
```

**Результаты**: на Game of 24 CoT решает **4%** задач, Tree of Thoughts — **74%** (GPT-4).

Модель самостоятельно оценивает промежуточные состояния (self-evaluation) и выбирает, какие ветки исследовать (BFS/DFS).

### Graph of Thoughts (Besta et al., AAAI 2024)

Расширение ToT: рассуждения модели формируют **граф** с произвольными связями:

- Ветвление: одна мысль → несколько продолжений
- Объединение: несколько мыслей → одна агрегация
- Рефинирование: итеративное улучшение одной мысли

**Результаты**: ~62% улучшение качества по сравнению с ToT на задачах сортировки, >31% снижение стоимости.

### LATS (Language Agent Tree Search, Zhou et al., 2024)

Объединяет Tree of Thoughts с Monte Carlo Tree Search (MCTS) — тем самым алгоритмом, который стоит за AlphaGo. Если ToT — это шахматист-любитель, то LATS — шахматный движок, который систематически исследует дерево игры.

**Четыре фазы MCTS в LATS:**

1. **Selection (выбор)**: используя UCT-score (Upper Confidence Bound for Trees), алгоритм выбирает, какую ветку исследовать дальше. На практике этот score складывает две вещи: среднюю оценку ветки и бонус за малоисследованные узлы. Поэтому поиск не залипает только в уже успешных направлениях и периодически проверяет новые.
2. **Expansion (расширение)**: LLM генерирует несколько продолжений выбранного узла — это как рассмотреть возможные ходы из текущей позиции.
3. **Simulation (моделирование)**: оценка каждого продолжения через LLM-self-evaluation или внешние инструменты (rollout). Например, для кода — запустить тесты; для веб-навигации — выполнить действие и посмотреть результат.
4. **Backpropagation (обратное распространение)**: оценка распространяется назад по дереву. Если rollout показал, что ветка успешна, все её родители получают повышенную оценку.

```
LATS на примере кодогенерации:

Итерация 1:
  Select: корень
  Expand: LLM генерирует 3 подхода (A, B, C)
  Simulate: запуск тестов → A: 2/5, B: 4/5, C: 1/5
  Backprop: обновить оценки

Итерация 2:
  Select: ветка B (лучший UCT)
  Expand: LLM дорабатывает B с учётом ошибки в тесте 5 → B1, B2
  Simulate: B1: 5/5 ✓, B2: 3/5
  Backprop: B1 — решение найдено!
```

Ключевое отличие от простого ToT: LATS **учится на ошибках в процессе поиска**. Обратная связь от симуляций направляет поиск в перспективные области. Это не просто «попробовать много вариантов» — это **направленный поиск** с накоплением знаний.

**Результаты**: HumanEval **92.7%** pass@1 (GPT-4), WebShop **75.9** average score (GPT-3.5).

---

## 8.7. Reasoning-модели и встроенное мышление (2025–2026)

### Встроенное мышление меняет правила игры

В 2025–2026 годах появился новый класс моделей: **reasoning models** (o3, Claude Opus 4.6 с adaptive thinking, Gemini reasoning-режимы, Qwen3 thinking mode). Эти модели имеют встроенное расширенное мышление — они тратят больше inference compute на сложные задачи, прежде чем выдать ответ. Claude 4.6 поддерживает два режима: adaptive thinking (`thinking: {type: "adaptive"}`), где модель сама определяет объём рассуждений, и extended thinking (`thinking: {type: "enabled", budget_tokens: N}`), где бюджет задаётся явно. Параметр `effort` (low/medium/high) передаётся в `output_config` и управляет адаптивным режимом. Важно: внешне это **похоже** на Tree of Thoughts, но внутренний механизм у закрытых моделей раскрыт лишь частично.

Что это меняет для нас?

**Явный ToT нужен реже.** Если вы используете o3 или Claude с adaptive thinking, модель уже делает часть работы по внутреннему поиску. Строить внешний ToT-оркестратор поверх такой модели стоит только там, где вам нужны явные ветки, тесты, инструменты или audit trail.

**Но Self-Consistency и Best-of-N по-прежнему актуальны.** Даже reasoning-модель может выдать разные ответы при разных запусках. Множественная генерация + голосование / оценка продолжает улучшать результат, потому что каждая «мысль» модели начинается с другого случайного seed.

### Когда что использовать с reasoning-моделями

| Ситуация | Подход |
|----------|--------|
| Reasoning-модель + простая задача | Один вызов, temp=0 (достаточно) |
| Reasoning-модель + сложная задача | Self-Consistency (n=3–5), модель «думает» при каждой попытке |
| Reasoning-модель + код | Best-of-N + тесты (sample-then-verify) |
| Обычная модель + сложная задача | Явный ToT или Self-Consistency (n=10+) |
| Обычная модель + комбинаторная задача | LATS с инструментами |

---

## 8.8. Test-Time Compute Scaling (T² scaling)

### Ключевая идея 2026 года

Классический подход к улучшению LLM: увеличить модель (больше параметров, больше данных). Это **train-time scaling** — масштабирование на этапе обучения.

**T² scaling** (test-time compute scaling) — другой подход: **увеличить количество вычислений на этапе инференса**. Вместо того чтобы тренировать бо́льшую модель, мы даём меньшей модели больше «времени на раздумье».

Аналогия: представьте двух студентов на экзамене. Один гениальный, но ему дали 5 минут. Другой хороший, но ему дали 2 часа. Кто сдаст лучше? Часто — второй.

### Формы T² scaling

Все техники этой главы — это формы test-time compute scaling:

| Техника | Как масштабирует compute |
|---------|------------------------|
| **Self-Consistency (n=10)** | 10× compute → majority vote |
| **Best-of-N + verifier** | N× generate + verify each |
| **Tree of Thoughts** | Exponential branching, но с pruning |
| **Adaptive / extended thinking** (o3, Claude, Gemini) | Модель сама решает, сколько «думать» |
| **LATS** | Итеративный поиск с rollouts |

### Почему это переворачивает экономику

Ключевое открытие: **маленькая модель + больше compute на инференсе может превзойти большую модель с меньшим compute**.

Конкретный пример (те же ~500 входных + ~300 выходных токенов):

```
Haiku 4.5 × Self-Consistency(n=5)    ≈ $0.010 за задачу
Claude Opus 4.6 × один вызов         ≈ $0.010 за задачу

GPT-5.4-nano × Self-Consistency(n=8) ≈ $0.004 за задачу
GPT-5.4 × один вызов                ≈ $0.006 за задачу
```

При одинаковом бюджете маленькая модель с Self-Consistency получает несколько независимых попыток; исследования (Snell et al., 2024; Brown et al., 2024) показывают, что это может давать качество, сопоставимое с более крупной моделью за один вызов. А параллельный запуск всех цепочек сохраняет latency на уровне одного вызова.

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

1. **Не переплачивайте за большую модель по умолчанию.** Сначала попробуйте дешёвую модель + Self-Consistency.
2. **Compute — это новый dial для настройки качества.** Не хватает качества? Увеличьте N, добавьте верификатор, дайте модели больше thinking budget.
3. **Latency vs quality trade-off.** Параллельные запуски не увеличивают latency, но увеличивают throughput cost. Последовательные (LATS, ToT) увеличивают latency, но дают более направленный поиск.

---

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

### Чек-лист многогипотезной генерации

| # | Правило | Когда применять |
|---|---------|-----------------|
| 1 | **Не генерируйте один ответ для сложных задач** | Задачи с >3 шагами, высокой ценой ошибки |
| 2 | **Self-Consistency (n=5–10)** | Математика, логика, планирование |
| 3 | **Best-of-N + scorer** | Кодогенерация (scorer = test execution) |
| 4 | **Трёхфазный workflow** | Архитектурные решения, дизайн систем |
| 5 | **Tree/Graph of Thoughts** | Сложные задачи с комбинаторным пространством |
| 6 | **Логируйте все ветки** | Для отладки и post-mortem анализа |
| 7 | **Используйте дешёвые модели + n** | n×cheap может быть лучше 1×expensive |
| 8 | **Учитывайте встроенное мышление** | Reasoning-модели уже тратят часть compute на внутреннюю декомпозицию |

### Дерево решений: какую технику выбрать

```
Задача имеет один правильный ответ? (математика, логика, факты)
│
├─ ДА → Есть автоматический верификатор? (тесты, схема, формальный чекер)
│   ├─ ДА → Best-of-N + верификатор (sample-then-verify)
│   └─ НЕТ → Self-Consistency (n=5–10)
│
└─ НЕТ (открытые задачи: текст, дизайн, архитектура)
    ├─ Нужно исследовать пространство? → Трёхфазный workflow (брейншторм → выбор → реализация)
    └─ Комбинаторная задача с обратной связью? → LATS

Используете reasoning-модель (o3, Claude Opus 4.6, Gemini reasoning-режимы, Qwen3 thinking mode)?
├─ ДА → Снизьте N вдвое, не стройте внешний ToT
└─ НЕТ → Используйте полные N и явные техники из этой главы

Бюджет ограничен?
├─ ДА → Дешёвая модель + большое N (T² scaling)
└─ НЕТ → Сильная модель + умеренное N
```

### Формула выбора стратегии

```
Если задача_простая AND цена_ошибки_низкая:
    → 1 вариант, temp=0.1
    
Если задача_сложная AND цена_ошибки_низкая:
    → 3–5 вариантов, temp=0.7, majority vote
    
Если задача_простая AND цена_ошибки_высокая:
    → 1 вариант, temp=0, + верификация
    
Если задача_сложная AND цена_ошибки_высокая:
    → 5–10 вариантов, temp=0.5, Best-of-N + верификация каждого

Если используете reasoning-модель:
    → Уменьшите N вдвое, увеличьте thinking budget
    → Не стройте внешний ToT — модель делает это внутри
```

### Задания

1. **Сравнение Self-Consistency vs одиночного вызова.** Возьмите набор из 20 задач (математика, логика или классификация), релевантных для вашего проекта. Сгенерируйте ответы двумя способами: (a) один вызов сильной модели с temp=0, (b) 5 вызовов дешёвой модели с temp=0.7 + majority vote. Сравните accuracy и суммарную стоимость. **Ожидаемый результат:** таблица с метриками качества и стоимости для каждой стратегии; решение, какой подход оптимален для вашей задачи.

2. **Best-of-N с автоматическим верификатором.** Выберите задачу кодогенерации из вашей практики. Настройте пайплайн: генерация N=5 вариантов кода → запуск тестов на каждом → выбор варианта, прошедшего все тесты. Используйте AI-промпт из §8.4 как отправную точку. **Ожидаемый результат:** работающий sample-then-verify пайплайн; оценка, при каком N достигается стабильный pass rate.

3. **Трёхфазный workflow на реальной задаче.** Примените трёхфазный подход (брейншторм → выбор → реализация) к архитектурному решению в вашем проекте. Зафиксируйте промпты для каждой фазы, параметры temperature и количество вариантов. **Ожидаемый результат:** документированный процесс с артефактами каждой фазы; сравнение с тем, что вы получили бы за один вызов.

Методы этой главы — горизонтальное исследование пространства решений: мы генерируем много вариантов на одном уровне и выбираем лучший. В следующей главе мы перейдём к **вертикальной** декомпозиции: разрезанию сложной задачи на подзадачи с последовательным углублением.

---

## Источники
- Elhage, N., et al. (2022). "Toy Models of Superposition." Anthropic.
- Wang, X., et al. (2023). "Self-Consistency Improves Chain of Thought Reasoning in Language Models." ICLR.
- Yao, S., et al. (2023). "Tree of Thoughts: Deliberate Problem Solving with Large Language Models." NeurIPS.
- Besta, M., et al. (2024). "Graph of Thoughts: Solving Elaborate Problems with Large Language Models." AAAI.
- Zhou, A., et al. (2024). "Language Agent Tree Search Unifies Reasoning, Acting and Planning in Language Models." arXiv:2310.04406.
- Snell, C., et al. (2025). "Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters." arXiv:2408.03314.
- Setlur, A., et al. (2025). "Scaling Test-Time Compute Without Verification or RL is Suboptimal." arXiv:2506.14495.
- Swamy, G., et al. (2025). "All Roads Lead to Likelihood: The Value of Reinforcement Learning in Fine-Tuning." arXiv:2505.14864.
- Brown, B., et al. (2024). “Large Language Monkeys: Scaling Inference Compute with Repeated Sampling.”
- OpenAI (2025). “o3 System Card.”
- Anthropic Docs (2026). *Claude models overview* and adaptive thinking documentation. https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking
---

**Навигация:**
- Назад: [Глава 7. Разметка, теги и архитектура сложного промпта](07_markup_tags_and_prompt_architecture.md)
- Далее: [Глава 9. Многошаговое мышление и разрезание задач](09_multistep_reasoning.md)