Короткий ответ
Few-shot промптинг — это способ показать модели несколько коротких примеров формата вход → правильный выход, чтобы она воспроизвела тот же шаблон на новом запросе. Используйте его, когда задача повторяема, критерий качества понятен, а формат ответа нужно сделать стабильнее без дообучения модели. Метод плохо подходит, если правила длиннее самих примеров, данные быстро устаревают, нужна юридически или финансово значимая точность, контекстное окно ограничено, либо задача требует внешних источников, вычислений или скрытой бизнес-логики, которой нет в примерах.
Практически few-shot лучше всего работает на классификации, извлечении полей, нормализации текста, кратком редактировании, разметке по фиксированной схеме и преобразовании одного формата в другой. Если вы пытаетесь заменить им поиск по базе знаний, валидацию фактов, сложные вычисления или работу по десяткам страниц регламента, устойчивость быстро падает. В таких случаях нужен либо более жёсткий шаблон, либо retrieval, либо код, либо fine-tuning.
- Подходит: когда ответ должен следовать одному и тому же паттерну.
- Не подходит: когда каждый новый запрос радикально отличается от предыдущих или требует актуальных данных извне.
- Главное правило: примеры должны учить не теме, а способу ответа.
Что понадобится
Сначала подготовьте не модель, а саму задачу. Большинство проблем few-shot возникает не из-за качества модели, а из-за расплывчатой постановки: непонятно, что считать правильным выходом, какие случаи критичны и чем отличается хороший ответ от допустимого.
| Что нужно | Зачем | Минимум |
|---|---|---|
| LLM с управлением параметрами генерации | Нужна воспроизводимость и возможность снизить вариативность | Доступ к чат-интерфейсу или API |
| 3–10 качественных примеров | Они задают шаблон решения | Хотя бы по одному примеру на типичный и крайний случай |
| Фиксированный формат ответа | Иначе модель будет имитировать стиль, а не структуру | Список полей, меток или шаблон текста |
| Отложенный набор тестов | Нужен для проверки переноса на новые данные | 10–30 запросов, которых нет в примерах |
| Таблица ошибок | Помогает править примеры системно, а не наугад | Любой блокнот или таблица |
- Инструкция в одну фразу: что именно модель должна сделать.
- Правила: что запрещено, какие поля обязательны, какой язык и длина ответа нужны.
- Разделители: отдельные маркеры для инструкции, примеров и нового входа.
- Критерий успеха: например, точная метка класса, корректный JSON по схеме или отсутствие лишнего текста.
Если вы не можете сформулировать проверяемый критерий качества, few-shot почти наверняка будет нестабилен. Сначала зафиксируйте формат и правила, потом подбирайте примеры.
Пошаговый план
1. Определите задачу и критерий успеха
Сформулируйте задачу в операционном виде. Не проанализируй отзыв, а определи тональность: positive, neutral или negative; выведи только метку. Не сделай краткое резюме, а сократи до трёх пунктов без оценочных суждений. Few-shot хорошо переносится только тогда, когда выход можно сравнить с эталоном.
Полезный тест: сможет ли другой человек, не зная вашего контекста, проверить правильность ответа по одной инструкции и одному примеру. Если нет, задачу нужно ужесточить.
2. Подберите примеры, которые покрывают реальную вариативность
Не выбирайте только удобные случаи. Few-shot должен обучать модели границам решения: что считать нормой, что считать исключением и где не надо фантазировать. Обычно полезнее четыре разных примера, чем восемь почти одинаковых.
| Тип примера | Что показывает модели | Зачем нужен |
|---|---|---|
| Базовый | Стандартный шаблон ответа | Создаёт основную траекторию |
| Пограничный | Случай, где легко ошибиться | Снижает путаницу между близкими классами |
| Негативный | Когда данных недостаточно или ответ должен быть пустым | Учит не додумывать |
| Редкий, но важный | Исключение из общего правила | Повышает устойчивость на реальных данных |
- Держите единый стиль во всех примерах.
- Используйте ту же лексику и тот же язык, что и в рабочих запросах.
- Если есть классы, не оставляйте редкие классы без примеров.
- Не включайте в examples лишние объяснения, если в продакшене они не нужны.
3. Соберите шаблон промпта в одном порядке и не меняйте его без причины
Для практики удобен такой порядок: краткая инструкция, правила формата, примеры, затем новый вход. Если сначала дать примеры, а потом добавить новые ограничения, модель иногда будет следовать примерам, а не поздней инструкции. Поэтому критичные ограничения лучше ставить до few-shot блока.
Задача: определи категорию обращения пользователя.
Правила:
1) Выводи только одну метку: billing, technical, account, other.
2) Если данных недостаточно, выбирай other.
3) Не добавляй объяснений.
Пример 1
Вход: Не могу войти после смены телефона.
Выход: account
Пример 2
Вход: Почему списалась двойная оплата за месяц?
Выход: billing
Пример 3
Вход: Приложение вылетает при загрузке файла.
Выход: technical
Новый вход: {текст пользователя}
Выход:
Хороший шаблон обладает тремя свойствами: однозначность, одинаковая структура и минимум лишнего текста. Чем больше в примерах стилистического шума, тем выше шанс, что модель начнёт копировать его вместо нужного формата.
4. Настройте параметры генерации под задачу
Для извлечения, классификации и нормализации обычно полезна низкая вариативность. Это означает низкую температуру и достаточно жёсткое ограничение на длину ответа. Для переписывания текста или создания вариантов формулировки допустима более высокая вариативность, но даже там few-shot нужен скорее для контроля стиля и структуры, чем для творчества.
- Если нужен один точный формат: снижайте температуру и ограничивайте длину.
- Если нужна генерация по стилю: следите, чтобы примеры не были слишком узкими и не задавливали разнообразие.
- Если ответ обязан соответствовать схеме: проверяйте его кодом после генерации.
Не пытайтесь компенсировать плохие примеры настройками семплинга. Few-shot почти всегда ломается раньше из-за качества обучающих примеров, чем из-за температуры.
5. Проверяйте на отложенной выборке, а не на самих примерах
Частая ошибка — прогнать только те случаи, которые уже встроены в промпт, и решить, что всё работает. Это не проверка, а демонстрация. Нужны новые запросы, которые модель раньше не видела. Лучше разделить тесты как минимум на три группы: типовые, пограничные и шумные.
- Подготовьте 10–30 новых входов.
- Сравните ответы с эталоном или правилом валидации.
- Отметьте ошибки по типам: неверный класс, сломан формат, лишний текст, галлюцинация, пропуск данных.
- Проверьте, не ухудшились ли старые кейсы после правки few-shot блока.
Если улучшение видно только на одном классе, а на остальных качество падает, значит вы переобучили промпт под локальный паттерн. В few-shot это происходит очень быстро.
6. Правьте сначала примеры, потом инструкцию
Когда результат нестабилен, первая реакция — дописать ещё абзац правил. Обычно полезнее заменить слабые примеры. Если модель путает два близких класса, добавьте контрастную пару примеров. Если она слишком многословна, сократите examples до чистого формата без комментариев. Если она выдумывает недостающие поля, добавьте пример, где корректный ответ — пустое значение или специальная метка неизвестности.
Хороший цикл доработки выглядит так: одна гипотеза → одно изменение → повторная проверка на отложенном наборе. Не меняйте сразу и инструкцию, и порядок блоков, и примеры: вы потеряете понимание, что именно сработало.
7. Решите, когда few-shot уже не тянет задачу
Если промпт разрастается до десятков примеров, стоимость и латентность растут, а перенос всё равно слабый, это сигнал сменить подход. Для повторяющихся задач с жёсткой схемой может помочь fine-tuning. Для задач на фактах и документах — retrieval с короткими инструкциями. Для строгих преобразований — обычный код и валидаторы. Few-shot эффективен как лёгкий слой управления поведением модели, но не как универсальная замена архитектуре решения.
Типичные ошибки
- Противоречивые примеры. Один и тот же паттерн получает разные ответы. Модель не знает, какое правило важнее.
- Слишком похожие examples. Вы показываете только один подтип данных, поэтому перенос на новые случаи слабый.
- Смешение форматов. В одном примере ответ полным предложением, в другом — меткой, в третьем — списком.
- Скрытые правила вне промпта. Вы держите часть критериев в голове и удивляетесь, что модель их не соблюдает.
- Попытка через примеры передать объёмную предметную область. Few-shot не заменяет полноценную базу знаний.
- Слишком много текста вокруг примеров. Лишние пояснения размывают шаблон и расходуют контекст.
- Отсутствие негативных случаев. Если не показать, когда нужно отвечать unknown, empty или other, модель будет достраивать ответ.
- Проверка только на удобных кейсах. На продакшене ломаются именно пограничные и шумные входы.
- Избыточная длина промпта. Чем длиннее few-shot блок, тем выше цена и тем труднее поддерживать версию.
Ещё одна практическая ошибка — пытаться заставить модель повторять внутренние рассуждения из примеров. Если вам нужен контролируемый результат, лучше просить краткое структурированное объяснение или только итоговую метку. Чем меньше лишнего поведения встроено в демонстрации, тем надёжнее перенос.
Как проверить результат
Проверка должна ответить на два вопроса: стало ли лучше и сохранилась ли устойчивость. Без этого few-shot остаётся красивой демонстрацией, а не рабочим инструментом.
- Сравните с zero-shot. Прогоните одинаковый набор тестов без примеров и с примерами. Если разницы нет, few-shot только тратит контекст.
- Смотрите не только на средний результат, но и на типы ошибок. Иногда общая точность растёт, а число опасных галлюцинаций тоже растёт.
- Валидируйте формат автоматически. Если нужен строгий JSON, таблица или список полей, проверяйте это кодом.
- Проверяйте стабильность на повторных запусках. Если ответ меняется без причины, снизьте вариативность или упростите шаблон.
- Измеряйте стоимость контекста. Возможно, четвёртый и пятый примеры уже не дают пользы, но заметно увеличивают цену и задержку.
Минимальный рабочий стандарт для команды: хранить версии промпта, список примеров, отложенный набор тестов и журнал изменений. Тогда few-shot можно улучшать как инженерный артефакт, а не как магию.
Если после двух-трёх итераций вам приходится постоянно добавлять новые примеры под каждый сбой, задача, скорее всего, вышла за пределы уместного few-shot и требует другой архитектуры.
FAQ
Сколько примеров обычно нужно?
Начните с 3–5. Если этого мало, добавляйте только те примеры, которые закрывают новый тип ошибки. Большой набор похожих examples редко помогает лучше, чем несколько контрастных.
Куда ставить примеры: до инструкции или после?
Критичные правила и формат лучше ставить до примеров, а новый вход — после них. Так модель сначала получает рамку, а потом демонстрацию нужного поведения.
Можно ли использовать few-shot на русском, если модель лучше обучена на английском?
Да, но примеры должны быть на том же языке, что и рабочий запрос. Смешение языков допустимо только если это соответствует реальным данным и не ломает формат ответа.
Когда лучше перейти к fine-tuning?
Когда у вас много однотипных задач, стабильная разметка, длинный few-shot блок и понятная метрика качества. Fine-tuning имеет смысл, если вы постоянно возите в контексте одно и то же поведение.
Few-shot заменяет retrieval или базу знаний?
Нет. Few-shot задаёт способ ответа, но не подставляет свежие факты. Если ответ зависит от документов, каталога, базы или политики, сначала дайте модели доступ к этим данным, а уже потом управляйте форматом через few-shot.
Что делать, если модель начинает копировать текст примеров?
Сократите примеры, уберите лишние формулировки и сделайте входы менее похожими на рабочие кейсы. Иногда помогает более строгий разделитель между examples и новым запросом.