Few-shot и zero-shot — это подходы, при которых модель решает новую задачу без отдельного полного обучения на большом размеченном датасете: в zero-shot ей дают только формулировку задачи, а в few-shot — формулировку и несколько примеров. На практике это особенно важно для больших языковых моделей, но применимо и шире: к классификации, поиску, извлечению информации и мультимодальным системам. Метод не подходит как единственная основа для задач с высокой ценой ошибки, узкой терминологией, нестабильными метками или строгими требованиями к воспроизводимости.
Простыми словами
Если у вас нет времени и данных на полноценное дообучение модели, можно попробовать объяснить ей задачу прямо в запросе.
- Zero-shot: вы говорите, что нужно сделать, но не показываете примеры.
- Few-shot: вы показываете несколько правильных примеров входа и ожидаемого выхода.
Для языковых моделей разница выглядит так:
- Zero-shot:
Определи тональность отзыва: положительная, нейтральная или отрицательная. - Few-shot: та же инструкция плюс 2–5 пар вида
текст → метка.
Смысл в том, что современная модель уже знает общий язык, структуры текстов, типовые задачи и может перенести это знание на новый формат. В этом смысле few-shot и zero-shot — не столько «обучение» в классическом смысле, сколько адаптация поведения модели без обновления ее весов. Поэтому в русской практике корректнее говорить не только «обучение», но и «решение задачи по инструкции и примерам».
Как это работает
В языковых моделях
Модель получает контекстное окно: инструкцию, ограничения, иногда схему ответа и, при few-shot, несколько демонстрационных примеров. Дальше она предсказывает следующий токен, опираясь на закономерности в контексте. За счет этого она может временно подстроиться под нужный формат ответа, стиль или простое правило разметки.
Практически это означает:
- Вы задаете роль задачи: что именно нужно сделать.
- Фиксируете формат ответа: класс, JSON, краткое объяснение, таблица.
- При few-shot добавляете 2–10 примеров, желательно типичных и пограничных.
- Проверяете, не переобучили ли вы модель на слишком узкий шаблон.
Few-shot обычно помогает, когда задача чувствительна к формату, терминологии или редким классам. Но слишком много примеров может ухудшить результат: модель начинает копировать паттерн вместо обобщения, а полезный контекст вытесняется из окна.
В классическом машинном обучении
В более широком смысле few-shot learning — это методы, которые учатся по очень малому числу размеченных примеров на класс. Zero-shot learning — методы, которые распознают классы, которых не было в обучении, опираясь на их описание, атрибуты или связь с другими представлениями. Это встречается в компьютерном зрении, поиске по текстовым описаниям и мультимодальных моделях.
Здесь механика уже другая: модель обычно заранее обучают на большом количестве данных, чтобы она умела строить устойчивые представления. Затем новая задача решается через перенос в общее пространство признаков, сравнение эмбеддингов или использование текстового описания класса.
| Подход | Что получает модель | Когда уместен | Главный риск |
|---|---|---|---|
| Zero-shot | Только инструкция или описание классов | Быстрый старт, грубая оценка идеи | Низкая точность на доменных данных |
| Few-shot | Инструкция и несколько примеров | Нужно стабилизировать формат и метки | Чувствительность к качеству примеров |
| Дообучение | Существенный набор размеченных данных | Повторяемый production-сценарий | Стоимость и время на цикл обучения |
Зачем нужно
Для практики few-shot и zero-shot полезны не потому, что «заменяют обучение», а потому, что снижают стоимость проверки гипотезы. Они позволяют быстро понять, способна ли модель вообще решать задачу в вашем домене.
- Быстрый прототип: можно оценить задачу за часы, а не за недели подготовки датасета.
- Низкий порог входа: не нужен отдельный pipeline дообучения.
- Гибкость: формат ответа и критерии можно менять прямо в запросе.
- Работа с редкими кейсами: несколько хороших примеров иногда дают заметный прирост относительно одной инструкции.
- Поддержка длинного хвоста задач: когда задач много, а данных на каждую мало.
Но если задача повторяется в продакшене, имеет понятные метрики и на нее можно собрать стабильную разметку, few-shot часто становится только промежуточным этапом перед RAG, специализированным пайплайном или дообучением.
Пример
Предположим, службе поддержки нужно автоматически маршрутизировать входящие письма по трем очередям: billing, tech, legal.
Zero-shot вариант
Классифицируй обращение в один из классов: billing, tech, legal. Отвечай только именем класса.
На простых письмах это может сработать: запрос про счет пойдет в billing, жалоба на ошибку входа — в tech.
Few-shot вариант
Классифицируй обращение в один из классов: billing, tech, legal. Отвечай только именем класса.
Пример 1: "Не могу скачать счет за март" → billing
Пример 2: "После обновления приложение не запускается" → tech
Пример 3: "Нужна копия договора и условия обработки данных" → legal
После этого модель обычно лучше понимает границы классов. Особенно важно добавить пограничные кейсы. Например, письмо "Почему с меня списали деньги после сбоя в приложении?" может быть двусмысленным. Если бизнес-правило требует приоритета финансовых вопросов, это лучше показать в примере, а не надеяться на интуицию модели.
Практический вывод: few-shot здесь полезен, если классы похожи, а термины неоднозначны. Но если у вас десятки тысяч писем в день, строгие SLA и риск неправильной маршрутизации, одного few-shot мало. Нужны как минимум тестовый набор, мониторинг ошибок и, возможно, отдельная модель или правила поверх LLM.
Заблуждения и ограничения
Заблуждение 1: few-shot всегда лучше zero-shot. Не всегда. Плохие или нерепрезентативные примеры могут ухудшить результат сильнее, чем короткая точная инструкция.
Заблуждение 2: это и есть обучение модели. Для LLM обычно нет обновления весов. Модель не запоминает ваш few-shot как новый навык между запросами, если только система отдельно не сохраняет контекст, память или не запускает дообучение.
Заблуждение 3: несколько примеров решают доменную задачу. В медицине, праве, безопасности, финансах и промышленности few-shot без внешней валидации рискован. Модель может уверенно ошибаться.
Заблуждение 4: zero-shot годится для точной классификации. Он подходит для первичной оценки и для задач с понятной семантикой классов, но хуже работает, когда метки внутренние, искусственные или зависят от скрытых бизнес-правил.
Основные ограничения:
- Чувствительность к формулировке: небольшое изменение инструкции меняет результат.
- Зависимость от примеров: порядок, стиль и покрытие кейсов влияют на качество.
- Ограничение контекста: нельзя бесконечно добавлять примеры.
- Слабая воспроизводимость: ответы могут слегка плавать между запусками и версиями модели.
- Проблемы с редкими правилами: если правило не видно из примеров, модель может его игнорировать.
Метод плохо подходит, когда:
- нужна юридически значимая или клинически надежная автоматизация без человека в контуре;
- классы определяются не смыслом текста, а закрытой внутренней логикой процесса;
- ошибка дорого стоит, а тестового набора и контроля качества нет;
- задача требует доступа к фактам, которых нет в параметрах модели и контексте запроса.
Частые вопросы
Чем few-shot отличается от fine-tuning?
Few-shot меняет только контекст запроса, а fine-tuning меняет параметры модели на этапе обучения. Few-shot быстрее и дешевле для проверки гипотез, fine-tuning уместен для стабильных повторяемых задач.
Сколько примеров нужно для few-shot?
Универсального числа нет. Обычно начинают с 2–5 качественных примеров, затем добавляют пограничные случаи. Важнее покрытие сценариев, чем большое количество однотипных примеров.
Когда zero-shot достаточно?
Когда классы очевидны, формат ответа простой, а цена ошибки умеренная. Например, базовая тональность, извлечение сущностей по явному шаблону или первичная категоризация.
Можно ли использовать few-shot в продакшене?
Да, но только с тестовым набором, измерением качества, обработкой отказов и мониторингом. Для критичных сценариев его обычно комбинируют с правилами, RAG или специализированными моделями.
Связанные понятия
- In-context learning — способность модели подстраиваться под задачу по инструкции и примерам в контексте.
- Prompt engineering — практика проектирования инструкций, форматов и демонстраций для модели.
- Fine-tuning — дообучение модели на специализированных данных с обновлением весов.
- Transfer learning — перенос ранее выученных представлений на новую задачу.
- RAG — Retrieval-Augmented Generation, генерация с извлечением внешних документов; полезна, когда модели не хватает актуальных фактов.
- Классификация по эмбеддингам — альтернатива для задач, где лучше сравнивать представления текстов, чем полагаться только на генеративный ответ.
Короткое практическое правило такое: начинайте с zero-shot для оценки принципиальной решаемости, переходите к few-shot для стабилизации поведения, а затем решайте, нужен ли RAG, правила или дообучение. Это экономит время и помогает не строить тяжелый pipeline там, где задача вообще не проходит базовую проверку.