467 lines
38 KiB
Markdown
467 lines
38 KiB
Markdown
# ГЛАВА 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)
|