TL;DR
Many-Shot Paradox — явление когда LLM показывает лучший результат при 5-25 примерах в промпте, а при увеличении до сотен примеров качество падает. Исследователи проверили это на переводе кода (90,000 тестов, модели Gemini), но принцип универсален для любых задач требующих точности.
Интуиция говорит: чем больше примеров даёшь модели, тем лучше она понимает задачу. Но для сложных задач это не так. При 5-25 примерах модель схватывает суть и даёт точные ответы. При 125-625 примерах начинает копировать поверхностные паттерны из примеров, игнорируя глубокую логику задачи. В переводе кода это выражается так: текст выглядит похоже на код (статические метрики растут), но не компилируется и не работает (функциональность падает на 5-10%).
Механика: модель с большим количеством примеров учится имитировать форму, а не воспроизводить суть. Слишком много контекста = слишком много шума и противоречащих сигналов. Модель теряет фокус на главном — правильности и точности.
Схема парадокса
ZERO-SHOT (0 примеров)
→ Базовый уровень: ~54-57% успеха
FEW-SHOT (5-25 примеров)
→ ПИК производительности: ~61-62% успеха
→ Модель схватывает суть задачи
MANY-SHOT (125-625 примеров)
→ ДЕГРАДАЦИЯ: возврат к ~54-58% успеха
→ Модель копирует поверхностные паттерны
→ Растут функциональные ошибкиКритическая точка: после 25 примеров каждые дополнительные 100 примеров снижают точность на 1-3%, хотя текст может выглядеть лучше.
Пример применения
Задача: Ты маркетолог в российском e-commerce. Пишешь карточки товаров в стиле Ozon — продающие, с эмоцией, но точные по характеристикам. Нужно описать новую коллекцию зимних курток (50 моделей).
⚠️ НЕ делай так: Скопируй 100 готовых описаний из каталога → "Вот примеры, теперь опиши новые куртки в том же стиле"
✅ Делай так:
Промпт:
Ты копирайтер для карточек Ozon. Вот 8 примеров описаний зимних курток из нашего каталога, которые хорошо продаются:
[Пример 1: Пуховик Alaska — акцент на морозостойкость]
Выдержит сибирские -40°C без шуток. Пух 90/10, ветрозащита, удлинённый крой — ты в тепле, даже если забыл шапку дома...
[Пример 2: Парка Urban — акцент на стиль + практичность]
Смотрится как миллион, стоит как... ну, явно дешевле. Мембрана 10K, съёмный мех, карманы под пауэрбанк...
[Примеры 3-8 с разными УТП: лёгкость, компактность, долговечность, etc.]
---
Теперь опиши новую модель:
- Название: Аляска Люкс
- Особенности: гусиный пух 95/5, водонепроницаемость 15K, карбоновые вставки на локтях, -50°C
- Целевая аудитория: мужчины 30-45, активный образ жизни, готовы платить за качество
Сохрани стиль Ozon (эмоция + точность), но адаптируй под характеристики этой модели.Результат: Модель выдаст описание которое сохранит ДНК стиля (эмоциональность, конкретные цифры, разговорные обороты), но точно отразит УТП новой модели. Если дать 100 примеров — модель начнёт микшировать фразы из разных карточек механически, потеряет фокус на уникальности товара.
Почему это работает
Слабость LLM: Модель не "понимает" задачу — она ищет паттерны в примерах. При 5-25 примерах паттерн чёткий и концентрированный. При 100+ примерах паттерны конфликтуют — одни примеры говорят "пиши коротко", другие "пиши длинно", третьи "будь серьёзным", четвёртые "будь эмоциональным".
Сильная сторона LLM: Модель отлично обобщает из небольшого набора качественных примеров. 5-8 примеров достаточно чтобы извлечь суть стиля, тона, структуры. Это как объяснить задачу человеку — достаточно 3-5 хороших примеров, а не 100 посредственных.
Механика парадокса: Много примеров = поверхностное копирование вместо глубокого понимания. Модель начинает имитировать форму (длину предложений, частоту слов, синтаксис), но теряет суть (логику, правильность, уникальность). В результате: текст выглядит правдоподобно, но работает плохо.
Рычаги управления:
- Количество примеров (5-25 оптимум) → меньше = экономия токенов, но может не схватить стиль; больше = шум и деградация
- Качество примеров → выбирай разнообразные, но все в рамках одного паттерна (разные УТП, но одинаковый тон)
- Явная инструкция ("сохрани стиль, но адаптируй под новый контекст") → помогает модели не копировать слепо
Шаблон промпта
Ты {роль}. Вот {5-25} примеров {типа контента}, которые работают хорошо:
[Пример 1: {контекст}]
{текст примера}
[Пример 2: {другой контекст}]
{текст примера}
...
[Пример {N}: {ещё один контекст}]
{текст примера}
---
Теперь создай {тип контента} для нового контекста:
- {ключевая информация 1}
- {ключевая информация 2}
- {ключевая информация 3}
Сохрани {что важно сохранить из примеров}, но адаптируй под {новый контекст}.Как заполнять:
{роль}— кто ты для модели (копирайтер, аналитик, переводчик){5-25}— держи в диапазоне 5-25 примеров, не больше{тип контента}— что создаёшь (описание товара, письмо клиенту, анализ данных){контекст}для каждого примера — покажи разнообразие сценариев{что важно сохранить}— явно укажи что модель должна взять из примеров (стиль, структуру, тон)
🚀 Быстрый старт — вставь в чат:
Вот шаблон Few-Shot оптимального размера. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]LLM спросит какие примеры у тебя есть, какой результат нужен, какой стиль сохранить — потому что ей нужно понять что извлекать из примеров и как применять к новому контексту. Она возьмёт структуру промпта и соберёт рабочий вариант под твою задачу.
Ограничения
⚠️ Простые задачи: Для очевидных задач (перевод слова, столица страны) даже 5 примеров — лишнее. Zero-shot работает отлично.
⚠️ Слишком разные примеры: Если твои 10 примеров в разных стилях/тонах/форматах — модель запутается. Лучше 5 примеров в едином стиле, чем 20 разношёрстных.
⚠️ Субъективные критерии: Если задача про "креативность" или "оригинальность" — примеры могут ограничить фантазию модели. Для креатива лучше zero-shot или 2-3 примера "для вдохновения".
⚠️ Токены и деньги: 625 примеров = в 20-30 раз дороже чем 25 примеров. Если результат хуже, а цена выше — это просто невыгодно.
Как исследовали
Команда взяла 90,000 переводов кода между 6 языками программирования (C, C++, C#, Java, Go, Python) и прогнала через 3 модели Gemini с разным количеством примеров: 0 (zero-shot), 5, 25, 125, 625. Главная фишка — они мерили не только "похожесть текста" (BLEU, CodeBLEU), но и функциональную корректность: компилируется ли код, запускается ли, даёт ли правильный результат.
И вот что выяснилось: статические метрики (похожесть текста) росли или оставались стабильными при увеличении примеров, но функциональность падала. При 25 примерах 61.8% кода компилировался успешно, при 625 примерах — только 56-58%, почти как в zero-shot. Больше того, с ростом примеров выросли функциональные и runtime ошибки — код выглядел правильно, но работал неправильно.
Почему так? Модель с 625 примерами научилась копировать синтаксические паттерны (структуру кода, ключевые слова), но потеряла семантическое понимание (логику, правильность работы). Это как школьник который заучил 100 примеров решений задач наизусть, но не понял принцип — на новой задаче применит не ту формулу.
Экономика вопроса: Промпт с 625 примерами стоил в 21 раз дороже чем с 25 примерами (по токенам), но давал хуже результат. Это не просто академический парадокс — это конкретная потеря денег и качества.
Робастность находки: Парадокс проявился во всех 30 языковых парах, включая лёгкие (Java → C#) и сложные (Python → Go). Независимо от сложности перевода, пик всегда был в зоне 5-25 примеров.
Ресурсы
When Many-Shot Prompting Fails: An Empirical Study of LLM Code Translation — Amirkia Rafiei Oskooei, Kaan Baturalp Cosdan, Husamettin Isiktas, Mehmet S. Aktas (Yildiz Technical University, Intellica Business Intelligence, 2025)