Этап 2 — Базовые паттерны промптов

Здесь ты переходишь от «написал текст» к воспроизводимому инженерному шаблону.

Темы этапа

• Zero-shot / One-shot / Few-shot
• Role prompting
• Output format prompting
• Step-by-step / Chain of Thought (контролируемо)
• Constraints prompting

Zero-shot, One-shot, Few-shot

• Zero-shot: только инструкция.
• One-shot: один эталонный пример.
• Few-shot: несколько примеров нужного поведения.

Few-shot обычно сильно повышает качество, потому что модель видит целевой паттерн ответа.

Role prompting

Роль задаёт рамку поведения: «ты senior reviewer», «ты data analyst».
Это не магия, а способ сместить распределение ответов к нужному стилю и уровню детализации.

Format prompting

Всегда явно задавай формат:

• JSON,
• таблица,
• список,
• фиксированные поля.

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

Step-by-step и Chain of Thought

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

Constraints prompting

Хорошие ограничения:

• проверяемые,
• конкретные,
• не противоречат друг другу.

Примеры: длина, структура, запрещённые действия, допустимые источники.

Как выбрать подходящий паттерн

Выбор паттерна зависит от того, насколько очевидно нужное поведение. Zero-shot подходит, когда нужно проверить базовую инструкцию и увидеть, как модель сама понимает задачу. One-shot полезен, когда один пример снимает ключевую неоднозначность. Few-shot становится важным, когда у задачи есть узнаваемый стиль, повторяемая структура или доменная оценка, которую модель должна воспроизвести.

Объяснение для новичка

Zero-shot означает, что ты не показываешь модели пример ответа. Ты просто даёшь инструкцию: «Составь описание товара в 3 предложениях». Это нормально, если задача простая и критерии очевидны. Например, если нужно перевести короткий текст или сжато объяснить термин, zero-shot часто достаточно. Но если у команды есть особый стиль, фиксированная структура или правила оценки, одной инструкции часто мало.

One-shot означает, что ты даёшь один пример. Пример работает как образец: модель видит, какой длины должен быть ответ, какие слова допустимы, как выглядят поля и какой уровень детализации нужен. Few-shot — это несколько примеров. Он полезен, когда одного примера недостаточно, потому что задача имеет разные варианты входа. Например, классификация support-запросов может включать billing, bug, feature request и security. Один пример покажет только один случай, а несколько примеров покажут паттерн.

Важно понимать: examples — это не просто подсказки, а обучающие образцы внутри prompt-а. Если пример плохой, модель будет копировать плохой стиль. Если пример слишком длинный, ответы станут длиннее. Если пример не показывает edge case, модель может ошибиться на похожем edge case. Поэтому examples нужно ревьюить как тестовые данные.

Пример few-shot:

Классифицируй запрос как billing, bug или feature_request.

Пример 1:
Запрос: "После оплаты тариф не обновился"
Ответ: billing

Пример 2:
Запрос: "Кнопка сохранить не работает"
Ответ: bug

Пример 3:
Запрос: "Добавьте экспорт в PDF"
Ответ: feature_request

Запрос: "С карты списали деньги дважды"
Ответ:

В production few-shot особенно полезен там, где важно повторять judgment команды: tone of voice, разметку обращений, классификацию, оценку качества, форматирование данных. Но few-shot увеличивает размер prompt-а, поэтому примеры должны быть короткими и репрезентативными.

Главный риск — использовать примеры, которые не являются эталонными. Модель воспринимает примеры как доказательство нужного паттерна вместе с их слабостями. Если пример слишком многословный, ответ тоже станет многословным. Если пример пропускает edge cases, модель может повторить этот пробел. В production примеры нужно воспринимать как тестовые фикстуры: ревьюить, версионировать и заменять при изменении продуктового поведения.

Что нужно уметь объяснить

• Почему few-shot радикально повышает качество на реальных кейсах.
• Почему формат ответа нужно задавать почти всегда.
• Почему «свободный текст без рамок» плохо масштабируется.

Мини-сценарии из практики

• Zero-shot даёт общий ответ без бизнес-контекста: добавление 1-2 релевантных примеров резко повышает точность.
• Few-shot ухудшает результат: примеры противоречат желаемому стилю или содержат плохие паттерны.
• Роль задана формально, но не влияет на ответ: в роли нет конкретной ответственности и критериев качества.

Быстрые правила принятия решений

• Если задача шаблонная и формат важен, начинай с few-shot.
• Если задача новая и нужно проверить базовое понимание, сначала zero-shot, затем итерация.
• Каждый пример в few-shot должен быть эталоном, а не «как получилось».

Вопросы для самопроверки

1. Почему few-shot часто даёт качественный скачок по сравнению с zero-shot?
2. Как понять, что примеры в few-shot вредят, а не помогают?
3. Что важнее: роль или формат, если нужен предсказуемый машинно-читаемый вывод?