Zero-shot Prompting

Суть в двух словах

Zero-shot — это "объясни задачу без образца". Модель не видит примеров, а опирается на свои общие способности и вашу инструкцию.

Лучше всего работает там, где:

• задача стандартная;
• формат ответа не критичен до символа;
• не нужен специфический tone of voice;
• важнее скорость, чем максимальная стабильность.

Классифицируй обращение клиента как billing, technical или general. Верни только метку.

Обращение: «С карты списали оплату дважды за один месяц»

Почему zero-shot по-прежнему важен

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

Практическое правило:

1. Сначала замерьте zero-shot baseline.
2. Потом добавляйте only-if-needed few-shot или structured outputs.
3. Только после этого думайте о fine-tuning.

Zero-shot как production baseline

На практике zero-shot полезен не только в чате, но и как первый слой в реальных системах. Его часто ставят:

• в дешёвый initial route;
• в triage-поток;
• в eval baseline;
• в режим быстрого запуска нового сценария до появления curated examples.

Это хороший operational default, потому что он показывает реальную "естественную" способность модели решать задачу без костылей. Если хороший zero-shot уже работает, команда не тратит время на лишние demonstrations и более тяжёлый orchestration.

Когда zero-shot подходит

Что делает zero-shot сильнее

Даже без примеров качество заметно растёт, если в промпте есть четыре слоя:

Как выглядит сильный zero-shot prompt

Проблема zero-shot редко в том, что "нет примеров". Гораздо чаще проблема в том, что запрос не задаёт нормальный task contract.

Рабочий шаблон обычно такой:

• что сделать;
• над чем именно это сделать;
• в каком виде вернуть результат;
• что делать при неопределённости.

Слабый prompt:

Проанализируй сообщение клиента

Сильнее:

Классифицируй сообщение как billing, technical или general. Ориентируйся только на текст сообщения. Если данных недостаточно, верни general. Ответ: только одна метка.

Это всё ещё zero-shot, но уже достаточно определённый, чтобы модель не гадала, что вы хотели.

Примеры

Хороший zero-shot для extraction

Извлеки из текста только компанию, город и год основания. Если поля нет, верни null. Ответ дай в одной JSON-строке.

Текст: «Компания ООО Прогресс основана в 2019 году в Москве и делает мобильные приложения для медицины.»

Хороший zero-shot для rewrite

Перепиши текст в деловом стиле. Сохрани смысл, убери разговорные формулировки, сократи до 3 предложений.

Текст: «Мы тут немного затянули с релизом, но уже почти всё допилили и скоро выкатим обновление»

Когда zero-shot уже не хватает

Если zero-shot даёт нестабильность, следующий шаг обычно такой:

• few-shot, если надо откалибровать паттерн;
• structured outputs, если нужен строгий schema-ответ;
• routing, если часть задач простая, а часть требует reasoning;
• fine-tuning, если нужно стабильно менять поведение, а не просто формат.

Лестница эскалации после zero-shot

Полезно думать не в бинарной логике "работает / не работает", а по ступеням:

1. Zero-shot
2. Zero-shot + жёсткий формат
3. Few-shot
4. Structured outputs / tool use
5. Routing
6. Fine-tuning

Во многих случаях оказывается, что проблема решается не примерами, а более чёткими ограничениями:

• перечислить допустимые классы;
• запретить домысливание;
• отделить final answer;
• ограничить длину ответа.

Частые anti-patterns

Ещё типичные ошибки:

• не перечислять варианты ответа;
• просить "ответить как эксперт" вместо описания задачи;
• смешивать creative tone и строгую extraction-задачу;
• считать, что короткий prompt автоматически лучше длинного.

Где zero-shot особенно силён

Практически это хороший default для:

• routing и triage;
• кратких summary;
• rewrite-задач;
• очевидной field extraction;
• первого прохода по support-обращениям;
• ad hoc аналитики по короткому контексту.

Он заметно слабее там, где:

• нужен точный internal style;
• важен строгий машинно-валидируемый формат;
• много пограничных случаев;
• домен требует устойчивого узкого поведения.

Техническая реализация

OpenAI Responses API

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5-mini",
    input=(
        "Классифицируй обращение как billing, technical или general. "
        "Верни только метку.\n\n"
        "Обращение: «Не приходит письмо для сброса пароля»"
    ),
)

print(response.output_text)

Anthropic Messages API

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-sonnet-4-0",
    max_tokens=32,
    messages=[
        {
            "role": "user",
            "content": (
                "Классифицируй обращение как billing, technical или general. "
                "Верни только метку.\n\n"
                "Обращение: «Не приходит письмо для сброса пароля»"
            ),
        }
    ],
)

print(message.content[0].text)

Production-правило

Zero-shot особенно полезен как baseline в eval-пайплайне:

• сначала измеряете zero-shot;
• затем сравниваете с few-shot;
• если прирост marginal, оставляете zero-shot и экономите токены.

Что логировать в production

Если zero-shot стоит в живом маршруте, полезно хранить:

• prompt version;
• model route;
• input length;
• success/fail label;
• причину, по которой запрос эскалировался в few-shot или более сильный route.

Тогда видно, где zero-shot реально экономит деньги и latency, а где его уже пора заменять более контролируемым подходом.