Почему примеры в промпте для рассуждающих моделей чаще мешают, чем помогают
Правило живёт в каждом втором гайде по промптингу: хочешь результат точнее — покажи модели пару примеров того, что тебе нужно. Этот приём называется few-shot prompting, и он реально работал на GPT-3 и его ровесниках. Проблема в том, что на современных рассуждающих моделях — тех, что сами «думают» перед ответом, — этот же приём часто делает результат хуже, а не лучше. И это не частное наблюдение одного пользователя, а задокументированный факт в исследованиях самих разработчиков моделей.
Откуда взялся миф о силе примеров
Few-shot prompting систематизировали ещё в статье про GPT-3 «Language Models are Few-Shot Learners» — модель показывали несколько пар «вход-выход», и она подхватывала паттерн без дополнительного обучения. Для классических языковых моделей это действительно был один из самых мощных приёмов: для обычных моделей few-shot prompting — это техника с самым высоким ROI в арсенале, четыре-восемь удачно подобранных примеров заметно улучшают формат, стиль и точность задачи. Отсюда и привычка тащить этот приём в любой новый промпт — для GPT-4o, для Gemini, а потом и для моделей с рассуждением.
Что пошло не так на новых моделях
Вот конкретные находки, которые ломают старое правило:
- DeepSeek прямо предупредил в своей научной статье. В материале, опубликованном в Nature, разработчики отметили, что few-shot prompting последовательно ухудшает производительность модели, и рекомендовали пользователям напрямую описывать задачу и указывать формат вывода в zero-shot режиме. Это не догадка блогера, а вывод из собственных экспериментов команды, которая обучала модель.
- OpenAI дал ту же рекомендацию для серии o. В официальной документации сказано: рассуждающим моделям часто не нужны few-shot примеры, чтобы выдать хороший результат, поэтому стоит сначала попробовать писать промпты без примеров.
- Исследования на o1-preview показали прямое ухудшение метрик. Исследование на o1-preview и o1-mini показало, что few-shot prompting стабильно ухудшал их результаты — даже тщательно подобранные примеры делали ответ хуже простого промпта, в том числе на медицинских бенчмарках.
- Механика проблемы — не баг, а особенность архитектуры. сильные модели не учатся на примерах так, как слабые — они по большей части игнорируют примеры и реагируют на описание задачи. Примеры в этом случае не подсказка, а лишний шум, который может даже сузить пространство для собственного рассуждения модели.
- Примеры тащат за собой классические искажения. Исследователи давно описали majority label bias — когда несбалансированный набор примеров искажает предсказания, и recency bias — когда промпт, заканчивающийся двумя негативными примерами, склоняет модель к негативному ответу. На рассуждающей модели эти искажения не компенсируются внутренним рассуждением, а прямо в него встраиваются.
- Рекомендации вендоров противоречат друг другу — и это важный сигнал. документация Gemini API рекомендует всегда включать few-shot примеры и предупреждает, что промпты без них будут менее эффективны, при этом документация Google Cloud предупреждает, что слишком много примеров может привести к переобучению модели. Иначе говоря, единого universal правила нет — многое зависит от конкретной модели и задачи.
- Примеры добавляют не только шум, но и риск для приватности. Свежее исследование показало, что вопросы вместе с few-shot примерами в промпте пропустили через анонимайзер на пяти моделях и более чем шести тысячах образцов — и обнаружили умеренные потери на задачах рассуждения и обвал на задачах поиска. Если примеры берутся из реальных данных клиентов, персональная информация попадает в каждый запрос.
Что делать вместо привычного «накинь пару примеров»
Правило не исчезло полностью — оно сместилось в зависимости от типа модели:
- Для рассуждающих моделей (GPT с режимом reasoning, Claude с extended thinking, Gemini с thinking-режимом) начинайте с zero-shot. Опишите задачу и формат вывода прямым текстом, без демонстраций. правильный подход — начинать с zero-shot и добавлять примеры только по необходимости; дизайн промпта — эмпирическая задача, нужно сначала смотреть на паттерны ошибок, а потом решать, добавлять ли примеры.
- Добавляйте примеры только если результат объективно не устраивает и вы это зафиксировали, а не угадали. Один-два чистых примера лучше пяти случайных — риск перекоса растёт с каждым лишним демонстрационным блоком.
- Для классических, нерассуждающих моделей старое правило всё ещё работает. В задачах с жёстким форматом или специфическим тоном примеры по-прежнему дают прирост — просто это уже не универсальный приём «для всех моделей сразу», а инструмент под конкретный тип модели.
- Если примеры всё же нужны, проверяйте их на однородность. Разный баланс положительных и отрицательных кейсов, порядок примеров — всё это влияет на ответ сильнее, чем кажется на первый взгляд.
Вместо вывода
Старое правило «чем больше примеров — тем лучше» перестало быть универсальным именно потому, что сами модели изменились: они научились рассуждать внутри себя, и внешние подсказки в виде примеров этому процессу иногда мешают. Разница между моделями теперь принципиальна: что спасало промпт для GPT-4o, может его же и испортить для модели с режимом рассуждения. Проверять это проще, чем кажется — достаточно прогнать один и тот же запрос в zero-shot и few-shot варианте и сравнить результат на своей задаче.
В GEMERA AI можно быстро сравнить, как одна и та же формулировка ведёт себя в GPT, Claude и Gemini — без переключения между разными сайтами и без необходимости разбираться в особенностях каждой модели заранее. Иногда самый быстрый способ понять, нужны ли примеры в промпте, — просто попробовать оба варианта и посмотреть на разницу.