TL;DR
Исследование показывает, что перестановка одних и тех же примеров в few-shot промпте даёт разброс точности, сопоставимый с заменой примеров на другие. Раньше считалось, что главное — выбрать хорошие примеры, а их порядок вторичен. Оказалось — нет: порядок влияет почти так же сильно.
Проблема в том, что LLM по-разному «весит» примеры в зависимости от их позиции. Пример в начале или конце промпта может доминировать над остальными. Это приводит к тому, что одни и те же примеры дают точность от почти случайной до близкой к оптимальной — просто в зависимости от того, в каком порядке они расположены.
Решение: тестировать несколько перестановок примеров на небольшом dev-сете (250+ примеров достаточно) и выбирать лучшую. 64-128 случайных перестановок достаточно, чтобы найти порядок, близкий к оптимальному. Важно: хороший порядок для одной задачи не переносится на другую — нужно тестировать заново для каждой новой задачи.
Схема метода
ШАГ 1: Подготовь несколько вариантов порядка примеров (8-16 перестановок для начала)
ШАГ 2: Протестируй каждую перестановку на 5-10 тестовых запросах
ШАГ 3: Выбери порядок с лучшими результатами → используй его для основной работы
Всё делается в одном чате, без кода. Просто копируешь промпт с разным порядком примеров и сравниваешь результаты.
Пример применения
Задача: Ты настраиваешь few-shot промпт для классификации отзывов клиентов на «жалоба», «вопрос», «благодарность» для службы поддержки.
Промпт (вариант 1 — порядок А):
Классифицируй отзыв клиента. Категории: жалоба, вопрос, благодарность.
Примеры:
"Спасибо, всё пришло вовремя!" → благодарность
"Когда будет доставка?" → вопрос
"Товар сломан, требую возврат" → жалоба
Отзыв: "Почему так долго ждать ответа?"
Категория:
Промпт (вариант 2 — порядок Б):
Классифицируй отзыв клиента. Категории: жалоба, вопрос, благодарность.
Примеры:
"Товар сломан, требую возврат" → жалоба
"Спасибо, всё пришло вовремя!" → благодарность
"Когда будет доставка?" → вопрос
Отзыв: "Почему так долго ждать ответа?"
Категория:
Результат: Ты получишь разные ответы или разную уверенность модели в зависимости от порядка. Протестируй оба варианта на 5-10 реальных отзывах. Тот порядок, который даёт больше правильных классификаций — используй для всех остальных запросов.
Почему это работает
LLM обрабатывает контекст не равномерно. Позиция примера в промпте влияет на его «вес» — примеры в начале и конце часто доминируют над средними. Это особенность архитектуры трансформеров: механизм внимания по-разному распределяет фокус по позициям.
Из-за этого один и тот же набор примеров может работать отлично или плохо — в зависимости от того, какой пример оказался «в фокусе». Исследование показало: разброс точности от перестановки примеров составляет ~2% в среднем — и это сопоставимо с разбросом от замены примеров на совсем другие.
Рычаги управления:
- Количество перестановок: 8-16 для быстрого теста, 64-128 для тщательного поиска
- Размер dev-сета: 250+ примеров достаточно, больше 1000 — уже overkill
- Тип задачи: для классификации эффект сильнее (~1.09x), для генерации слабее (~1.46x selection/ordering ratio)
Шаблон промпта
Универсального шаблона нет — метод применяется к твоим существующим few-shot промптам. Алгоритм:
1. Возьми свой few-shot промпт с N примерами
2. Создай 8-16 версий с разным порядком примеров
3. Протестируй каждую версию на 5-10 запросах из твоей реальной задачи
4. Выбери порядок с лучшими результатами
5. Используй этот порядок для всех остальных запросов
Быстрый способ создать перестановки:
Вот мой few-shot промпт:
[вставить промпт]
Создай 8 версий этого промпта с разным порядком примеров.
Сохрани все примеры, меняй только их последовательность.
🚀 Быстрый старт — вставь в чат:
У меня есть few-shot промпт с примерами. Помоги найти лучший порядок примеров:
1. Сгенерируй 8 перестановок порядка примеров
2. Я протестирую каждую на своих данных
3. Помоги проанализировать результаты
Мой промпт:
[вставить свой few-shot промпт]
LLM создаст варианты перестановок. Ты тестируешь их на реальных задачах и выбираешь лучший.
Ограничения
⚠️ Не переносится между задачами: Хороший порядок для классификации отзывов не сработает для классификации резюме. Каждая новая задача — новый поиск порядка.
⚠️ Эффект слабее для генеративных задач: В задачах типа «напиши текст» или «реши задачу» порядок влияет меньше, чем в классификации.
⚠️ Требует тестовых данных: Чтобы найти хороший порядок, нужно на чём-то тестировать. Если у тебя нет 5-10 примеров с известными правильными ответами — метод не применим.
⚠️ Время на тестирование: 8-16 перестановок × 5-10 тестов = 40-160 запросов. Для одноразовой задачи — overkill. Для постоянного use case (классификация сотен отзывов) — окупается.
Как исследовали
Команда из UC San Diego провела контролируемый эксперимент: фиксировали либо набор примеров (и меняли порядок), либо порядок (и меняли примеры). Это позволило изолировать эффект каждого фактора.
Тестировали на 13 моделях от 0.5B до 27B параметров (Qwen2.5, Gemma, Llama 3, DeepSeek) плюс GPT-5 Nano. Задачи: 5 датасетов классификации (AG News, DBPedia, MMLU, NYT-Topics, NYT-Locations) и 3 генеративных (GSM8K, MATH, MMLU-Pro).
Ключевая метрика — grouped standard deviation: разброс точности при изменении порядка vs разброс при изменении примеров. Результат: среднее отклонение от порядка — 0.0197, от выбора примеров — 0.0225. Разница всего 14%.
Неожиданный результат: GPT-5 Nano оказался самым чувствительным к порядку среди всех моделей (ratio 0.85 — порядок важнее выбора). Обычно ожидали бы, что большие модели стабильнее.
Попытка перенести «хороший» порядок с GSM8K на MATH дала точность на уровне случайного порядка (transfer ratio ~0.8). Это означает: оптимизировать порядок нужно для каждой задачи отдельно.
Ресурсы
Order Matters: Rethinking Prompt Construction in In-Context Learning
Warren Li, Yiqian Wang, Zihan Wang, Jingbo Shang — UC San Diego, Cushing Academy
Ключевые отсылки из статьи:
- Zhao et al. (2021) — первая работа о чувствительности к порядку в GPT-3
- Lu et al. (2022) — показали, что плохой порядок может снизить точность до случайного уровня
- Min et al. (2022), Rubin et al. (2022) — фокус на выборе примеров (эта работа оспаривает их приоритет)
