TL;DR
Если дать LLM пачку независимых элементов (отзывы, посты, заявки) и спросить «каких больше?», ответ зависит от порядка элементов. Хотя по смыслу порядок не должен ничего менять. Модель лучше всего учитывает начало набора, середину хуже всех, конец чуть лучше середины. Исследователи не предлагают метод, а показывают, где ломается привычная практика «загрузил всё и спросил».
Проблема в том, что одни и те же 2000 отзывов с одной и той же правдой дают то «в основном позитивные», то «в основном негативные», если переставить их местами. Разрыв между лучшим и худшим порядком доходил до 40–90 процентных пунктов, у всех протестированных моделей, включая свежие флагманы. Причина: модель не перебирает все элементы по очереди. В её рассуждениях упоминается в основном первая сотня-другая элементов, остальное она «пролистывает». Если большинство лежит в середине, она его просто не замечает.
Дополнение «учти ВСЕ элементы», подсказка «считай группами и суммируй» и самостоятельное составление инструкции моделью не дали стабильного улучшения. Вывод для практики: не доверяй агрегацию по большому набору одному запросу, а точность проверяй перестановкой порядка.
Схема метода
В статье нет метода-лекарства. Есть диагностический тест, и его удобно повторить у себя:
ШАГ 1: Берёшь набор элементов + две метки → стандартный промпт «найди преобладающую метку»
ШАГ 2: Тот же набор в 2–3 разных порядках → отдельные запросы (новые чаты)
ШАГ 3: Сравниваешь ответы → совпали = можно осторожно доверять; разошлись = агрегация ненадёжна
Порядки в исследовании: случайный; большинство в начале, в конце, в середине, по краям; мягкие варианты с чередованием.
Пример применения
Задача: Селлер на Wildberries выгрузил 400 отзывов на термокружку за квартал. Он хочет понять, чего больше, хвалят или ругают, чтобы решить, переделывать ли крышку. Выгрузка отсортирована по дате, свежие отзывы сверху.
Промпт (стандартный тип промпта из статьи, запускается три раза с разным порядком отзывов):
Ниже 400 отзывов на термокружку, пронумерованных от 1 до 400.
Для каждого отзыва определи тональность: положительная или отрицательная.
Затем скажи, какая тональность преобладает среди ВСЕХ отзывов.
Ответь одним словом: «положительная» или «отрицательная».
Отзывы:
1. Крышка течёт, возвращаю.
2. Держит тепло 12 часов, доволен.
...
400. {последний_отзыв}
Запуск:
- Запуск 1: отзывы как есть (по дате).
- Запуск 2: отзывы в случайном порядке (перемешай в Google Таблицах функцией СОРТПО / RAND).
- Запуск 3: отзывы в обратном порядке.
- Каждый раз в новом чате.
Результат: Модель выдаст одно слово в каждом запуске. Если все три ответа совпали, вывод пока устойчив. Если ответы разошлись, ответ зависит от порядка и ему нельзя верить. Тогда разметь отзывы по пакетам (например, по 40 штук в запросе, с выводом номер | метка) и посчитай итог формулой в таблице. Этот обходной путь в статье напрямую не проверяли, он следует из её выводов.
Почему это работает (почему ломается)
Слабость модели. Ей кажется, что она читает и учитывает весь набор. На деле она не ведёт честный счётчик: рассуждения упоминают лишь небольшую долю элементов, в основном ранние. Чем длиннее набор, тем меньше покрытие. На 100–200 элементах она почти всё упоминает, на 2000 меньше пятой части.
Что модель умеет хорошо. Классифицировать один элемент: после фильтрации все модели справлялись с каждым отдельным примером почти идеально. Ошибка возникает не в понимании, а в сборке итога из сотен кусков.
Что из этого следует. Отдельную разметку надо отделять от подсчёта. Модель размечает небольшие порции, а итог считает таблица или скрипт. Раз порядок так влияет, его стоит перемешивать и повторять, чтобы увидеть нестабильность.
Рычаги проверки: - Число перестановок (2–3 → быстрый тест, 5+ → надёжнее). - Размер набора: чем он меньше, тем слабее эффект, но даже при 100 элементах он заметен. - Баланс классов: чем ближе 50/50, тем сильнее разброс. Когда одна сторона явно доминирует (90/10), модели легче.
Шаблон промпта
Ниже {число} {элементов}, пронумерованных от 1 до {число}.
Для каждого определи: {метка_A} или {метка_B}.
Затем скажи, какая метка преобладает среди ВСЕХ элементов.
Ответь одним словом: «{метка_A}» или «{метка_B}».
{элементы}
Подставляй:
- {элементы} — отзывы, посты, заявки, комментарии;
- {метка_A} и {метка_B} — две взаимоисключающие категории («жалоба / не жалоба», «лид / не лид»);
- {число} — сколько элементов в наборе.
Запускай шаблон 2–3 раза с разным порядком элементов, каждый раз в новом чате. Это протокол проверки, а не промпт-лекарство.
Ограничения
⚠️ Лечение не найдено: подсказка «обрабатывай все элементы», подсказка «считай группами и суммируй» и самостоятельная инструкция от модели не дали стабильного улучшения. Разрыв между лучшим и худшим порядком остался большим.
⚠️ Простая модельная задача: искали преобладающую из двух меток. Как порядок влияет на более сложные итоги (темы, резюме, выводы), в статье не проверяли.
⚠️ Способы обхода не проверены: разбиение на пакеты, перемешивание с голосованием, подсчёт в таблице напрямую не тестировали. Это логичный вывод, но не результат эксперимента.
⚠️ Подсказки проверяли на узком наборе: только три модели. Две другие модели вообще почти не давали ответа: исчерпывали лимит токенов, и их исключили из анализа.
⚠️ Наборы очищены: оставили только «лёгкие» примеры, которые модели размечают верно по одному. Реальные отзывы сложнее, так что ошибка в жизни может быть ещё больше.
⚠️ Эффект не только про середину: хуже всего чаще было, когда большинство лежало в середине, но не у всех моделей. Универсального «худшего порядка» нет.
Как исследовали
Идея была простой: ответ не должен зависеть от порядка, значит любую зависимость можно считать ошибкой. Команда из Кардиффа взяла пять простых задач на бинарную классификацию: чётное/нечётное число в задаче по математике, имя человека или место, слово «the» один раз или больше, позитивный или негативный отзыв, «java» как язык программирования или остров. Из каждого набора оставили только те примеры, которые две модели размечают верно поодиночке: чтобы ошибки шли от сборки итога, а не от трудных примеров.
Затем собирали наборы по 2000 элементов с долей 55/45: на 200 штук больше у одной метки. Даже при 90% точности на элемент шанс перевернуть итог ничтожен, порядка одного на миллиард. Один и тот же набор подавали в семи порядках: случайном, с большинством в начале, в конце, в середине, по краям и двух мягких вариантах. Тестировали 15 моделей.
Итог: все модели показали разрыв минимум 40 процентных пунктов, а некоторые (Gemma 4 26B, Llama 4 Maverick) около 90. Лучше всего шёл порядок «большинство в начале», хуже — «в середине». Более половины моделей показали самые плохие результаты именно в «середине».
Потом выяснили почему. Вручную разобрали 222 рассуждения моделей с неверными ответами: в 72% случаев модель упоминала только подряд идущие элементы с начала, обычно в пределах первых 200. Если большинство лежало в конце или середине, в рассуждениях упоминались только меньшинство. Автоматический подсчёт показал, что в большинстве запусков упоминалось меньше 25% номеров. А анализ градиентов (какие части входа влияют на ответ) на трёх открытых моделях подтвердил: влияние ниже в середине, чем в начале и в конце.
Удивило, что промпты не помогли вообще. Три подсказки на трёх моделях в целом не улучшили точность и не уменьшили разрыв. Для практики это означает: проблема в способе обработки, а не в формулировке запроса.
Адаптации и экстраполяции
Это мои выводы из результатов, в статье они не проверялись.
🔧 Техника: перемешать и проголосовать → сглаживает влияние порядка
Я пришлю один и тот же набор отзывов в {число_порядков} разных порядках, каждый раз в новом чате.
Для каждого запуска запиши ответ: преобладающая метка.
Если ответы совпали — принимаем. Если нет — размечаем по пакетам.
🔧 Техника: разметка пакетами + подсчёт вне модели → убирает «сборку итога»
Вот пакет из {20–50} отзывов.
Для каждого выведи строку в формате: номер | метка_A или метка_B.
Ничего не считай и не обобщай. Только строки.
Склей результаты пакетов в таблицу и посчитай СЧЁТЕСЛИ. Так модель делает то, что умеет (классифицировать по одному), а итог считает таблица.
Экстраполяция на агентов: если агент читает много файлов, тикетов или логов, в CLAUDE.md или AGENTS.md можно добавить правило:
Если нужно посчитать или определить, чего больше среди более чем {N} элементов, не делай вывод «в уме».
Сначала размечай элементы по одному (или пакетами) в файл, потом считай скриптом или формулой.
Не опирайся на то, что запомнил из начала списка.
Ресурсы
- Название работы: Does Every Instance Count Equally? Order Effects in LLM Multi-Instance Processing
- Авторы: Jingxuan Chen, Mohammad Taher Pilehvar, Jose Camacho-Collados, School of Computer Science and Informatics, Cardiff University
- Данные и код: https://github.com/jingxuanchen916/mip-order
- Связанная работа: Liu et al., 2024 («lost in the middle»); Bertsch et al., 2026 и Chen et al., 2026 (деградация при росте числа элементов)