Примеры в промте: zero-shot и few-shot

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

Термины#

• Zero-shot — промт без примеров: только инструкция и входные данные.
• One-shot / few-shot (multishot) — в промт добавлены один или несколько образцов «вход → правильный ответ».
• Шаблон ответа — заготовка формата, которую модель должна заполнить.

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

Когда хватает инструкции#

Начинайте без примеров. Это короче, дешевле и не навязывает модели лишних шаблонов. Zero-shot обычно достаточно, когда:

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

Когда нужны примеры#

Google в руководстве по Gemini, наоборот, советует добавлять примеры в большинство промтов: без них результат менее предсказуем. Противоречия здесь нет — всё зависит от задачи. Примеры особенно нужны, когда:

• формат нестандартный — особая структура JSON, порядок полей, единицы измерения;
• важен стиль — тон ответов поддержки, длина описаний товаров, принятая в команде формулировка коммитов;
• граница категорий размыта — «это жалоба или вопрос?», «это баг или пожелание?»;
• словами объяснять дольше, чем показать.

Пример классификации обращений:

Определи тип обращения: bug, question или feature.
Ответ — одно слово.

<examples>
<example>
Обращение: После обновления не открывается страница заказа, белый экран.
Тип: bug
</example>
<example>
Обращение: Можно ли выгрузить отчёт сразу в Excel?
Тип: question
</example>
<example>
Обращение: Хорошо бы добавить тёмную тему в личный кабинет.
Тип: feature
</example>
</examples>

Обращение: {текст}
Тип:

Сколько примеров давать#

Anthropic рекомендует для лучшего результата 3–5 примеров. Google отмечает, что модели часто схватывают закономерность уже по нескольким образцам, а слишком много примеров приводит к переобучению: модель начинает копировать их слишком буквально. Точное число подбирается опытом:

1. Начните с одного-двух примеров.
2. Прогоните 10–20 реальных входов и посмотрите, где модель ошибается.
3. Добавьте пример именно на тот случай, где она ошиблась, а не ещё один «типичный».

Какими должны быть примеры#

Последний пункт особенно важен. Anthropic советует оборачивать примеры в теги <example>, а набор — в <examples>; подойдут и другие явные разделители — заголовки, линии. Google обращает внимание на мелочи: одинаковые теги, пробелы, переносы строк и разделители между примерами — модель повторяет их так же старательно, как содержание.

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

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

Инструкция и примеры вместе#

Пример показывает формат, но не объясняет, почему ответ именно такой. Поэтому оставляйте и инструкцию: правила дают модели принцип, примеры — образец. Google допускает, что при очень ясных примерах инструкции можно убрать, но в документации Vertex AI тот же Google советует всегда сопровождать примеры чёткими указаниями — так надёжнее.

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

<example>
Было: Потрясающая кружка из качественной керамики объёмом 350 мл,
идеально подойдёт для утреннего кофе и станет лучшим подарком!
Стало: Керамическая кружка на 350 мл.
</example>

Было: {описание}
Стало:

Строгий формат ответа#

Если ответ разбирает программа, «почти JSON» — это ошибка. Что помогает, по возрастанию надёжности:

1. Описать формат словами и показать пример — как выше. Работает в чате и в простых сценариях.
2. Попросить ответ внутри тегов — например, <answer>…</answer>. Тогда текст до и после легко отрезать.
3. Структурированный вывод в API. У OpenAI, Anthropic и Google есть режимы, где ответ ограничен JSON Schema: модель физически не может вернуть невалидную структуру. Для классификации подойдёт поле с перечнем допустимых значений (enum).
4. Проверить кодом в любом случае. Валидируйте ответ своей схемой и при ошибке повторяйте запрос с текстом ошибки.

Раньше популярным трюком был prefill — начать ответ модели за неё, например с символа {, чтобы она продолжила JSON. У новых моделей Anthropic (начиная с поколения 4.6) prefill последнего ответа не поддерживается: запрос вернёт ошибку. Вместо него используйте структурированный вывод или прямую инструкцию «отвечай без вступления».

Пример схемы для извлечения данных из письма:

{
  "type": "object",
  "properties": {
    "order_id": { "type": "string" },
    "issue": { "type": "string", "enum": ["delivery", "payment", "quality", "other"] },
    "refund_requested": { "type": "boolean" }
  },
  "required": ["order_id", "issue", "refund_requested"],
  "additionalProperties": false
}

И проверка на стороне приложения — обязательна, даже если API обещает соответствие схеме: бизнес-правила (существует ли такой заказ) схема не проверит.

import json

ALLOWED_ISSUES = {"delivery", "payment", "quality", "other"}


def parse_answer(raw: str) -> dict:
    data = json.loads(raw)
    if data.get("issue") not in ALLOWED_ISSUES:
        raise ValueError(f"Неизвестный тип проблемы: {data.get('issue')!r}")
    if not isinstance(data.get("refund_requested"), bool):
        raise ValueError("refund_requested должен быть true или false")
    return data

Шпаргалка#

Источники#

• Prompting best practices: Use examples effectively — Anthropic.
• Prompt design strategies — Google, Gemini API.
• Reasoning best practices — OpenAI.
• Structured outputs — Anthropic.