Техники промптинга с нулём, одним и несколькими примерами — когда и как применять каждую
Три фундаментальных режима взаимодействия с LLM — от работы без примеров до тщательно подобранных демонстраций.
Zero-shot — самый простой подход: вы даёте модели только задачу, без каких-либо примеров.
Классифицируй тональность следующего отзыва как позитивный, негативный или нейтральный.
Отзыв: "Быстрая доставка, товар соответствует описанию."
Тональность:
Модель использует только то, что «знает» из предобучения. Это работает, потому что современные LLM обучены на огромных корпусах текста и могут выполнять многие задачи без примеров.
Когда zero-shot работает хорошо
Когда zero-shot недостаточно
One-shot — один пример input-output перед задачей. Иногда одного примера достаточно, чтобы показать паттерн:
Переведи техническую аббревиатуру в её расшифровку на русском.
Пример:
API → Интерфейс программирования приложений
Теперь переведи:
ORM → ?
One-shot полезен когда:
Few-shot — несколько примеров (обычно 3-8) перед задачей. Brown et al. (2020) показали в GPT-3 paper: few-shot сопоставим с fine-tuning для многих задач.
Классифицируй баг по приоритету. Используй: P0 (критично), P1 (высокий), P2 (средний), P3 (низкий).
Баг: "Приложение падает при попытке оплаты"
Приоритет: P0
Баг: "Неправильный перенос строк в PDF экспорте"
Приоритет: P2
Баг: "Кнопка 'Справка' не открывается в Chrome на Windows"
Приоритет: P2
Баг: "Опечатка в тексте подсказки в настройках"
Приоритет: P3
Баг: "Невозможно войти в систему через SSO для корпоративных пользователей"
Приоритет: ?
Модель видит паттерн и применяет его к новому примеру.
Качество few-shot примеров критически важно. Плохо подобранные примеры могут ухудшить результат по сравнению с zero-shot.
Разнообразие
Примеры должны покрывать разные части пространства задачи. Для классификации тональности не стоит давать только позитивные примеры — нужны все классы.
Плохо:
"Отлично!" → позитивный
"Супер продукт!" → позитивный
"Очень доволен" → позитивный
Хорошо:
"Отлично!" → позитивный
"Ужасно, не рекомендую" → негативный
"Обычный товар, ничего особенного" → нейтральный
Репрезентативность
Примеры должны быть похожи на реальные входные данные. Если вы будете классифицировать короткие твиты, не используйте длинные рецензии как примеры.
Формат
Все примеры должны следовать одному формату. Непоследовательный формат сбивает модель:
Плохо:
Input: "Привет" | Output: приветствие
"Пока" -> farewell
Q: "Как дела?" A: вопрос о состоянии
Хорошо:
Текст: "Привет" → Категория: приветствие
Текст: "Пока" → Категория: прощание
Текст: "Как дела?" → Категория: вопрос
Исследования показывают, что порядок few-shot примеров влияет на результат, особенно у малых моделей. Последний пример имеет наибольшее влияние на вывод (recency bias).
Практические рекомендации:
Calibration — проблема, когда few-shot примеры вводят bias: модель начинает предсказывать классы непропорционально часто.
Если в ваших 8 примерах 6 из класса A и 2 из класса B — модель будет предсказывать A намного чаще, даже когда это неправильно.
Решение: балансировать примеры по классам. Даже если в реальных данных дисбаланс — в промпте лучше давать равное количество примеров каждого класса.
Стоимость токенов
Каждый пример занимает место в контекстном окне. 10 примеров по 100 токенов = 1000 токенов дополнительных затрат на каждый запрос.
При 1000 запросов в день это существенно влияет на стоимость. Нужно балансировать: больше примеров → лучше качество, но выше стоимость.
Ограничение контекста
В контекстном окне 128k токенов кажется много, но при RAG + history + few-shot место заканчивается быстро.
Не работает для обучения
Few-shot НЕ обновляет веса модели. Это временный «намёк» — только в рамках одного запроса. Для устойчивого изменения поведения нужен fine-tuning.
Few-shot — хороший старт, но fine-tuning нужен когда:
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.