Сначала проверю актуальные исследования и данные по этой теме.
Вы когда-нибудь писали модели подробнейшую инструкцию на полстраницы — перечисляли все правила, форматы, граничные случаи, а она всё равно делала по-своему? А потом добавили два примера — и всё заработало. Почему так происходит? Разберёмся.
Модель учится на паттернах, а не на правилах
Когда вы пишете длинную инструкцию, вы пытаетесь формализовать задачу. Вы говорите: «делай так, потому что...», «не делай так, потому что...». Но большие языковые модели — это не программы. Они не читают инструкции как исполняемый код. Они ищут паттерны.
Few-shot prompting эксплуатирует именно эту особенность. Вместо описания правила вы даёте модели готовый образец: показали ей, как выглядит вход и ожидаемый выход — и она подхватывает формат, логику, стиль. Без解释нений. Без «в случае, если...».
В исследовании 2022 года эта техника была представлена как основной способ заставить GPT-3 решать задачи, которые не поддавались прямым инструкциям. Модели оказались способны экстраполировать правила из двух-трёх примеров точнее, чем из десятка правил.
Длинные инструкции создают шум
Вот типичная ошибка: разработчик думает, что чем подробнее напишешь, тем лучше результат. Ой.
Проблема в том, что модель начинает «теряться» в деталях. Если вы напишете три страницы правил, между важными Constraints и второстепенными уточнениями модель не видит разницы. Всё сливается в один массив текста. Она пытается следовать каждому пункту, но пункты противоречат друг другу — и в итоге вы получаете что-то среднее, размытое, часто неправильное.
Плюс длинные промпты жгут токенны быстрее. Особенно если вы работаете с контекстом на оплате за каждый символ.
А ещё длинные инструкции часто страдают от «эффекта белой вороны»: вы случайно упоминаете что-то, что слегка отличается от остальных примеров — и модель хватается именно за это, игнорируя общую логику.
Что именно делает примеры сильными
Не каждый набор примеров одинаково полезен. Вот на что стоит обращать внимание.
Репрезентативность. Примеры должны покрывать основные типы входных данных, с которыми модель столкнётся. Если задача — классификация обращений, а вы даёте примеры только нейтральных, а потом просите классифицировать негативные — не удивляйтесь.
Разнообразие. Три-четыре примера — это хорошо. Но если все они слишком похожи друг на друга, модель может решить, что паттерн узкий. Лучше показать разные варианты, включая граничные случаи.
Формат вывода. Это вообще главное, ради чего стоит использовать few-shot. Если вам нужен JSON определённой структуры — просто покажите пример JSON. Одно упоминание формата в тексте инструкции не даёт такого эффекта, как живой пример с правильными ключами и вложенностью.
Негативные примеры. Помогают не меньше позитивных. Показать, как выглядит неправильный ответ, — это мощный сигнал для модели.
Два подхода: когда что выбирать
Zero-shot — это когда вы просто описываете задачу без примеров. Иногда это работает отлично, особенно на простых, хорошо определённых задачах. Но на сложных, нетипичных, требующих нюансов — регулярно проваливается.
Few-shot — это примеры. Работает лучше, когда задача неформализуема. Или когда формат важен. Или когда вам нужен стабильный, предсказуемый результат.
Chain-of-thought — это уже совсем другая история. Там примеры включают не только вход и выход, но и рассуждения между ними. Модель видит логику и начинает рассуждать сама. Это резко повышает качество на задачах с многошаговыми вычислениями или логикой.
Я часто комбинирую подходы: сначала даю примеры для формата, потом добавляю цепочку рассуждений для сложных случаев. Получается гибрид, который закрывает больше краев.
Практический пример
Допустим, вы делаете бота, который отвечает на вопросы по документации компании. Плохой промпт выглядит так: «Отвечай вежливо, используй только информацию из документации, не придумывай, если информации нет — скажи, что не знаешь, не давай юридических советов, будь кратким, но информативным...» — и так десять пунктов.
Хороший промпт: два-три примера диалогов. Один, где ответ можно найти в документации. Один, где информации недостаточно. Один с двусмысленным вопросом. Модель сама поймёт, как себя вести.
Подвох: иногда длинные инструкции нужны
Не всё сводится к few-shot. Есть случаи, когда без подробной инструкции не обойтись.
Политики безопасности. Примеры не заменяют чёткое «не делай X» — особенно если X может причинить вред.
Специфичный контекст, который нельзя показать в примерах. Скажем, правила вашей компании по обработке персональных данных — это не паттерн, а набор требований.
Задачи, где важна точность воспроизведения. Если вам нужен ответ строго по шаблону — иногда проще написать инструкцию, чем подбирать идеальные примеры.
Итог
Few-shot работает лучше длинных инструкций, потому что модели — это не исполнители правил. Это системы, которые видят паттерны. Покажите им образец — они поймут задачу быстрее, чем если вы будете объяснять её на пальцах десятью абзацами.
Но few-shot — не серебряная пуля. Комбинируйте с инструкциями, где нужно. Добавляйте CoT, где логика важна. И главное — тестируйте на реальных данных, а не наSynthetic-примерах, которые вы придумали сами.
