Продвинутый промптинг: ZS, FS, CoT, CoV, ToT

Фрагмент лекции: «Все что нужно знать про ИИ айтишнику», 53:53 — отсюда взято содержание этой главы.

В предыдущей главе мы разобрали, как устроен один хороший запрос: роль, контекст, задача, формат. Эта глава — про то, что делать, когда одного запроса не хватает.

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

Каждая техника промптинга — это способ обменять токены на надёжность. Обмен выгоден только тогда, когда вы знаете, сколько ошибок было до и сколько стало после.

Структура ответа: линия, цепочка, дерево

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

Слева — один проход: сколько токенов в ответе, столько и потратили. В середине — цепочка: промежуточные шаги тоже генерируются и тоже оплачиваются. Справа — дерево: ветки генерируются целиком, а в финальный ответ попадает одна, и отброшенные оплачены полностью.

Сквозной пример

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

<источники>
Релиз 4.2 от 12 марта: миграция на PostgreSQL 14.
Замер от 20 марта: сборка месячного отчёта — с 8 до 5 минут.
Регламент выгрузок от 1 февраля: лимит 20 000 строк.
</источники>
<текст>
Сервис отчётов с марта работает на PostgreSQL 14, сборка месячного
отчёта ускорилась вдвое, лимит выгрузки — 50 000 строк,
доступ выдаётся по заявке в ИТ.
</текст>

В тексте четыре утверждения: одно верное, одно преувеличенное, одно неверное и одно не подтверждается источниками вовсе. Хорошая проверка должна найти все три проблемы и не выдумать четвёртую.

Ступень 1. Zero-shot: задача без примеров

Что это. Вы формулируете задачу и не даёте ни одного образца желаемого результата — модель должна догадаться по самой формулировке. Автор лекции описывает типичный провал так: человек пишет «нарисуй котика», получает не то, что представлял, и тратит впустую и токены, и время. Механизм тут ровно тот, что мы разбирали в главе про большие языковые модели: неконкретный запрос не сужает множество правдоподобных продолжений, и модель выбирает самое частое. Не самое подходящее вам — самое частое в данных.

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

Тот же zero-shot, но с сужением — примеров по-прежнему нет:

Ты — технический редактор внутренней документации.
Задача: сверить каждое фактическое утверждение из блока <текст>
с блоком <источники> и найти расхождения.

Формат ответа: маркированный список; в каждом пункте цитата,
тире и причина расхождения со ссылкой на источник. Утверждения,
которые источники не подтверждают и не опровергают, вынеси
в отдельный список «нет данных». Сам текст не переписывай.

<источники>...</источники>
<текст>...</текст>

Когда применять. Всегда — как первую попытку. Огромная доля рабочих задач закрывается здесь, и подниматься выше без замера бессмысленно.

Чем платите. Базовая стоимость: длина промпта плюс длина ответа. Это единица измерения для всей остальной таблицы.

Ступень 2. Few-shot: несколько примеров прямо в промпте

Что это. Вы кладёте в промпт несколько пар «вход → желаемый выход», а затем даёте настоящий вход. Модель не дообучается: веса не меняются, ничего не запоминается между запросами. Она подстраивается под формат по образцам, которые видит прямо сейчас, в пределах одного контекста. Это явление называется обучением в контексте (in-context learning) и описано в исходной работе Brown et al., «Language Models are Few-Shot Learners», 2020.

Ты — технический редактор внутренней документации.
Сверяй утверждения текста с источниками. Отвечай строго
в формате примеров ниже.

Пример 1
Вход: «Сервис перешёл на Redis 7 в прошлом квартале.»
Выход:
- «Redis 7» — в источниках указана версия 6.2
- «в прошлом квартале» — относительной даты в источниках нет
Нет данных: —

Пример 2
Вход: «Доступ выдаётся автоматически всем сотрудникам.»
Выход:
- расхождений нет
Нет данных: «выдаётся автоматически всем сотрудникам»

Задача
<источники>...</источники>
Вход: «Сервис отчётов с марта работает на PostgreSQL 14, ...»
Выход:

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

Когда применять. Когда zero-shot даёт правильную суть, но не тот формат, не ту детализацию или разное оформление от запроса к запросу. Few-shot — самый дешёвый способ зафиксировать форму ответа.

Чем платите. Примеры уходят в промпт при каждом запросе. Три коротких примера — это ×1,5–3 к длине входа. Если формат стабилен, эту часть промпта имеет смысл кэшировать; продакшн-детали кэширования — в ИИ-инженерии.

Ступень 3. Chain-of-Thought: рассуждение по шагам

Что это. Вы просите модель не выдавать ответ сразу, а сначала расписать промежуточные шаги. Приём описан в работе Wei et al., «Chain-of-Thought Prompting Elicits Reasoning in Large Language Models», 2022. Почему это работает, если модель просто продолжает текст? Каждый сгенерированный токен возвращается на вход при генерации следующего, поэтому промежуточные шаги — это контекст, который модель создаёт сама себе: дальше она продолжает не голый вопрос, а вопрос вместе с частично проделанной работой. Ответ «сразу» и ответ «после трёх выписанных шагов» — буквально два разных вычисления.

Ты — технический редактор внутренней документации.
Разбери задачу по шагам и покажи каждый шаг:

Шаг 1. Выпиши все фактические утверждения из <текст>
       отдельными строками, по одному утверждению в строке.
Шаг 2. Для каждого утверждения укажи, какой фрагмент
       <источники> его подтверждает, или напиши «не найдено».
Шаг 3. Отметь утверждения, где источник и текст расходятся,
       и опиши расхождение числом или датой.
Шаг 4. Только после этого собери итоговый список расхождений
       и отдельный список «нет данных».

<источники>...</источники>
<текст>...</текст>

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

Важный нюанс: у рассуждающих моделей эта просьба часто лишняя. Работа Wei et al. вышла в 2022 году, когда модели по умолчанию отвечали сразу. С тех пор картина изменилась: на момент лекции, май 2026 года, у моделей со встроенным рассуждением просьба «думай по шагам» обычно избыточна, а иногда мешает. Такие модели сами выделяют внутренний бюджет на рассуждение, и явная инструкция может с этим конфликтовать: рассуждение дублируется в видимом ответе, ответ распухает, качество не растёт. Это наблюдение, привязанное к поколению моделей, а не универсальный закон. Практическое правило: если модель и без просьбы тратит рассуждение, не добавляйте CoT-инструкцию поверх — задавайте структуру результата, а не структуру размышления.

Когда применять. Задачи в несколько логических шагов: сверка, подсчёт, разбор условий, вывод из нескольких фактов сразу.

Чем платите. Промежуточные шаги — это выходные токены, а выход у всех провайдеров кратно дороже входа и генерируется последовательно. Порядок ×2–5 к стоимости и заметный рост задержки.

Ступень 4. Self-consistency: несколько прогонов и голосование

Этой техники в лекции нет, но по логике лестницы она встаёт ровно между CoT и самопроверкой.

Что это. Вы запускаете один и тот же CoT-промпт несколько раз независимо и берёте ответ, который встречается чаще. Метод описан в Wang et al., «Self-Consistency Improves Chain of Thought Reasoning in Language Models», 2022. Модель вероятностна, и на одном входе разные прогоны могут разойтись: если пять прогонов из пяти нашли одно и то же расхождение — оно, скорее всего, реальное; если его нашёл один прогон из пяти — скорее всего, выдумка.

Промпт остаётся тем же, что на ступени 3, меняется обвязка вокруг него:

from collections import Counter

def majority(runs: list[set[str]], k: int | None = None) -> list[str]:
    """Оставляем замечания, встретившиеся больше чем в половине прогонов.
    Каждый прогон — множество нормализованных замечаний, чтобы повтор
    внутри одного ответа не считался за два голоса."""
    votes: Counter[str] = Counter()
    for run in runs:
        votes.update(run)
    threshold = k if k is not None else len(runs) // 2 + 1
    return sorted(item for item, n in votes.items() if n >= threshold)

Сложность агрегации — O(n * m) по времени и O(m) по памяти, где n — число прогонов, m — среднее число замечаний в прогоне; сама агрегация бесплатна, платите вы за n вызовов модели. Самая тонкая часть — нормализация: «лимит 50 000 против 20 000» и «неверный лимит выгрузки» — одно замечание, но для Counter это две разные строки. Поэтому на практике просят структурированный ответ с фиксированными полями, а не свободный текст (структурированный вывод).

Когда применять. Когда ответы правдоподобны, но нестабильны: два запуска дают разный список, и непонятно, какому верить.

Чем платите. Во столько раз, сколько прогонов делаете: ×3, ×5, ×7. Прогоны независимы и запускаются параллельно, так что задержкой платить не приходится — только деньгами.

Ступень 5. Chain-of-Verification: модель проверяет сама себя

Что это. Модель сначала даёт черновой ответ, затем сама формулирует проверочные вопросы к своему ответу, отвечает на них отдельно — не глядя на черновик — и только потом собирает финальный ответ с учётом проверок. Метод описан в Dhuliawala et al., «Chain-of-Verification Reduces Hallucination in Large Language Models», 2023. Ключевая деталь, которую легко потерять: проверочные вопросы должны отвечаться изолированно. Если модель отвечает на них, видя перед собой черновик, она подтвердит собственную выдумку — правдоподобный текст в контексте работает как факт.

Разделение на отдельные вызовы, как на диаграмме, — то, ради чего техника и придумана. Упрощённый шаблон в один вызов дешевле, но слабее, потому что черновик остаётся в контексте на шаге 3:

Ты — технический редактор внутренней документации.
Шаг 1. Составь черновой список расхождений между <текст> и <источники>.
Шаг 2. Сформулируй 5 проверочных вопросов к своему черновику. Каждый
       вопрос проверяет ровно одно число, дату или название версии
       и формулируется так, чтобы на него можно было ответить,
       не видя черновика.
Шаг 3. Ответь на каждый вопрос отдельно, опираясь только на <источники>.
Шаг 4. Перепиши список: убери пункты, не подтвердившиеся на шаге 3,
       и добавь то, что нашлось при проверке.

<источники>...</источники>
<текст>...</текст>

Когда применять. Когда ответы стабильны от прогона к прогону (self-consistency не помогает — все прогоны согласованно ошибаются), но содержат уверенные выдумки: несуществующие пункты регламента, придуманные номера версий, правдоподобные, но не встречающиеся в источниках числа.

Чем платите. Три-четыре вызова вместо одного, причём каждый следующий тащит контекст предыдущих. Порядок ×4–8 к стоимости и, в отличие от self-consistency, шаги строго последовательны — задержка растёт вместе с ценой.

Ступень 6. Tree of Thoughts: ветвление и отбор

Сначала терминология, потому что здесь легко унаследовать ошибку. Tree of Thoughts по-русски — дерево мыслей, а не «дерево решений». Дерево решений (decision tree) — это совершенно другой алгоритм машинного обучения, который строится по обучающей выборке и разбивает пространство признаков; он разобран в отдельной главе соседнего трека: деревья решений. Путать их нельзя: у них нет ничего общего, кроме слова «дерево».

Что это. Модель порождает несколько разных вариантов рассуждения (веток), каждая развивается на шаг-два, затем варианты оцениваются — самой моделью или внешним критерием, — слабые отбрасываются, перспективные развиваются дальше. Метод описан в Yao et al., «Tree of Thoughts: Deliberate Problem Solving with Large Language Models», 2023. Отличие от CoT в одном слове: возврат. Цепочка идёт вперёд и, свернув не туда, доводит ошибку до конца; дерево может отбросить неудачную ветку и продолжить с развилки.

Ты — технический редактор внутренней документации.
Шаг 1. Предложи три независимых подхода к проверке текста: сверка
       по источникам; проверка внутренней непротиворечивости;
       проверка всех чисел и дат по отдельности.
Шаг 2. Пройди каждый подход отдельно и выпиши, что находит именно он.
Шаг 3. Оцени каждый разбор от 1 до 5 по двум критериям: доказуемость
       каждого пункта ссылкой на источник и полнота охвата.
Шаг 4. Возьми разбор с лучшей суммой оценок, дополни пунктами,
       которые он пропустил, и выдай итоговый список.

<источники>...</источники>
<текст>...</текст>

Когда применять. Когда задача допускает несколько разных способов решения и заранее неясно, какой сработает: планирование, поиск, перебор вариантов. Для сверки текста с источниками это уже избыточно — пример выше нужен, чтобы показать структуру, а не чтобы рекомендовать ToT для такой задачи.

Чем платите. Дороже всех: генерируются все ветки, а в ответ идёт одна, и отброшенные оплачены полностью. Порядок ×5–20 в зависимости от ширины и глубины дерева.

Мультиролевой приём — это не ToT

Автор лекции описывает рядом с деревом другой приём: «представь, что ты одна из трёх ролей; вторая и третья всегда критикуют первую». Приём рабочий, но это не Tree of Thoughts:

• ToT ветвит способ рассуждения над одной задачей и отбирает лучшую ветку по оценке. Роли и критика не нужны — нужен критерий отбора.
• Мультиролевая дискуссия ветвит точки зрения: несколько ролей с разными приоритетами спорят о результате. Это ближе к мультиагентным системам, где роли исполняются отдельными вызовами со своими промптами и своей памятью.

Обе конструкции повышают шанс заметить ошибку, но по разным причинам: дерево — за счёт перебора и отбора, дискуссия — за счёт того, что критик не заинтересован защищать чужой ответ.

Сводная таблица

Кратность здесь — порядок величины, а не измерение. Реальные числа зависят от длины промпта, длины ответа, числа примеров и ширины дерева, и считать их нужно на своей задаче — как, разобрано в главе про токены и контекстное окно.

Почему в этой главе нет процентов точности

В лекции звучат конкретные цифры: у дерева точность «больше 90 %», у самопроверки «больше 85 %», у цепочки рассуждений «больше 80 %», у few-shot «около 70 %», и добавлено, что «где-то были публикации».

Этих чисел в тексте главы нет и не будет. Источник не назван, а сами по себе они не соответствуют ничему проверяемому: точность промпт-техники — свойство не техники, а тройки «техника + задача + модель». На арифметике для младших классов CoT даёт огромный прирост, на извлечении поля из письма — ноль или минус, а на модели со встроенным рассуждением может не изменить вообще ничего. Что можно утверждать честно:

• Порядок техник по надёжности на задачах с многошаговым рассуждением обычно такой, как в таблице выше — это и показывают работы Wei et al., Wang et al., Dhuliawala et al. и Yao et al., каждая на своём наборе задач.
• Величина выигрыша в каждой из работ измерена на конкретных бенчмарках конкретными моделями своего времени. Переносить её на вашу задачу нельзя.
• Универсального числа «точность техники X» не существует. Источник, называющий одно число без указания задачи, набора и модели, называет его зря.

Правило подъёма: не выше, чем измерено

Каждая ступень отделена от следующей замером, а не ощущением:

Не переходите на следующую ступень, пока не измерили провал текущей.

«Измерили» означает конкретное: взяли 20–50 реальных запросов вашей задачи, зафиксировали правильные ответы, прогнали текущий промпт, посчитали долю ошибок и посмотрели глазами, какие именно ошибки случились. Тип ошибки прямо указывает, куда подниматься: путаница в формате — к few-shot; сбой на многошаговом выводе — к CoT; расхождения между прогонами — к self-consistency; уверенные выдумки — к CoV. Без такого набора вы не разрабатываете промпт, а гадаете: сравниваете два ответа на одном запросе и делаете вывод о всей системе. Как собрать минимальный набор и что мерить кроме среднего — в главе про оценку и бенчмарки.

Типичные ошибки

Начинать сверху. Многоролевой промпт на две страницы для задачи, которая решается одним точным предложением: стоимость выросла в разы, качество — нет, а отладить такой промпт невозможно, потому что непонятно, какая его часть работает.

Ставить «думай по шагам» везде. На простых задачах это добавляет выходные токены и задержку без выигрыша, а на моделях со встроенным рассуждением может ухудшить ответ. Инструкция уместна там, где шаги названы и осмысленны.

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

Копить примеры и смешивать техники. Три примера, включая один граничный, почти всегда лучше двадцати однотипных: примеры уходят в промпт при каждом запросе, а лишние ещё и тянут ответ к себе. Дерево внутри самопроверки поверх few-shot — не «максимальная надёжность», а неотлаживаемая конструкция с непредсказуемой ценой; каждая техника добавляется отдельно и после замера.

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

Источники

• Brown et al., Language Models are Few-Shot Learners, 2020 — обучение в контексте, исходная работа по few-shot
• Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, 2022
• Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, 2022
• Dhuliawala et al., Chain-of-Verification Reduces Hallucination in Large Language Models, 2023
• Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, 2023 — и Building Effective Agents от Anthropic о том, почему простая композиция обычно выигрывает у сложной

Мини-итог

• Пять техник промптинга — не список равноправных приёмов, а лестница: каждая ступень надёжнее и дороже предыдущей, и подниматься на неё нужно только после измеренного провала текущей.
• Zero-shot проваливается не из-за «глупости» модели, а из-за неконкретности запроса: не сузив множество правдоподобных продолжений, вы получаете самое частое, а не самое нужное.
• Few-shot не дообучает модель — веса не меняются; примеры подстраивают формат в пределах одного контекста, и три примера с граничным случаем обычно лучше двадцати однотипных.
• Chain-of-Thought работает потому, что сгенерированные шаги возвращаются на вход и становятся контекстом для следующих; на моделях со встроенным рассуждением, по наблюдению на момент лекции (май 2026), эта просьба часто избыточна.
• Self-consistency ловит нестабильность, Chain-of-Verification — стабильные выдумки; это разные болезни, и лечатся они разными техниками.
• Tree of Thoughts — это дерево мыслей, а не «дерево решений»: последнее — самостоятельный алгоритм машинного обучения. Мультиролевая дискуссия из лекции — тоже не ToT, а ближе к мультиагентной системе.
• Универсального числа «точность техники X» не существует: выигрыш зависит от задачи и модели, поэтому единственный ориентир — замер на своих 20–50 реальных запросах, а кратность расхода токенов из таблицы нужно пересчитывать под свою задачу.

Что дальше

До сих пор мы говорили о моделях, которые продолжают текст токен за токеном: и промптинг, и все пять техник из этой главы работают именно с этим механизмом. Но изображения так не генерируются — картинка не рисуется слева направо и не собирается по пикселю. Следующая глава разбирает совсем другую механику: почему изображение рождается из случайного шума, что такое seed и почему один и тот же запрос дважды даёт разные картинки.

Диффузионные модели: как генерируются изображения