TL;DR
Когда ты просишь ИИ ранжировать список — резюме кандидатов, тексты, товары, идеи — модель ставит оценку не только по смыслу, но и по месту элемента в списке. Если поставить один и тот же пункт на разные позиции, не меняя ни буквы в его содержании, он может подскочить с 5-го места на 1-е или наоборот.
Вот боль: у модели есть "сладкая зона" в середине списка — элементы там получают систематически лучшую оценку, чем в начале или в конце. Причина простая: модель читает список как последовательность слов слева-направо, и её внутренний "счётчик позиции" влияет на итоговую оценку так же сильно, как смысл текста. Исследователи показали: подбирая порядок из 50 вариантов, можно искусственно поднять в топ-5 почти 57% изначально нерелевантных элементов — просто переставляя их местами.
Спасение — не доверять одному прогону ранжирования. Нужно прогнать список 2-3 раза с разным порядком элементов и посмотреть, стабилен ли результат. Если топ меняется от перестановки — модель реагирует на позицию, а не на суть, и результату верить нельзя.
Схема метода
ШАГ 1: Дай модели список для ранжирования в исходном порядке → получи ранжирование A
ШАГ 2: Перемешай порядок элементов (сохраняя содержание) → получи ранжирование B
ШАГ 3: Сравни A и B → если топ совпадает — доверяй; если расходится — не доверяй одному прогону
Все три шага можно сделать в одном чате, тремя последовательными сообщениями.
Пример применения
Задача: HR-менеджер просит ChatGPT проранжировать 10 резюме кандидатов на позицию маркетолога и выбрать топ-3 для собеседования.
Промпт (прогон 1):
Вот 10 резюме кандидатов на позицию маркетолога (в порядке поступления заявок):
1. [резюме Анны]
2. [резюме Бориса]
3. [резюме Виктории]
...
10. [резюме Юрия]
Проранжируй их от лучшего к худшему по соответствию вакансии. Выведи топ-3.
Промпт (прогон 2 — тот же список, другой порядок):
Вот 10 резюме кандидатов на позицию маркетолога:
1. [резюме Юрия]
2. [резюме Виктории]
3. [резюме Анны]
...
10. [резюме Бориса]
Проранжируй их от лучшего к худшему по соответствию вакансии. Выведи топ-3.
Результат: Если топ-3 в обоих прогонах совпадает — ранжирование надёжное. Если состав топ-3 меняется хотя бы наполовину — модель ориентируется на позицию в списке, а не только на содержание резюме. В этом случае стоит либо усреднить несколько прогонов, либо явно попросить модель игнорировать порядок подачи.
Почему это работает
Модель читает список токен за токеном слева-направо. Из-за механизма внимания и позиционных кодировок (технических деталей вроде RoPE) оценка элемента частично зависит от того, где он стоит, даже если его смысл не меняется. Это не "мнение" модели — это побочный эффект того, как она обрабатывает последовательности.
При этом модель прекрасно умеет сравнивать элементы между собой в рамках одного прогона — в этом её сила. Проблема не в способности сравнивать, а в том, что позиция подмешивается к сравнению как лишний сигнал.
Рычаг управления: количество проверочных прогонов. Для важных решений (найм, выбор подрядчика, оценка юридического документа) — делай минимум 2-3 перестановки. Для рутинных задач с низкой ценой ошибки — один прогон достаточен. Другой рычаг — явная инструкция "не учитывай порядок подачи, оценивай только содержание" — это не устраняет проблему полностью, но снижает её (исследование показало, что подобные инструкции и переформулировки задачи уменьшают, но не убирают эффект).
Шаблон промпта
Вот список из {количество} элементов для сравнения: {список с описанием каждого}.
Задача: {что нужно оценить — выбрать лучший, ранжировать, отфильтровать топ-N}.
Проранжируй элементы и объясни коротко, почему каждый занял своё место.
Прогони этот промпт 2-3 раза, каждый раз меняя порядок элементов в списке (содержание не трогай). Сравни топ-N между прогонами.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для проверки ранжирования на устойчивость к порядку. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно ты ранжируешь и сколько элементов — потому что от этого зависит, сколько перестановок разумно проверить и как оформить список для сравнения.
Ограничения
⚠️ Требует нескольких прогонов: метод не даёт результат за один запрос — нужно минимум 2 прогона с разным порядком, это лишние токены и время.
⚠️ Не устраняет проблему, только обнаруживает: настоящее решение (переобучение модели, изменение архитектуры) недоступно в обычном чате. Ты можешь только диагностировать нестабильность, не вылечить её полностью.
⚠️ Работает для задач ранжирования и сравнения списка, а не для генерации текста или ответа на вопрос. Если ты просишь модель написать текст или ответить на вопрос без списка вариантов — эта техника не применима.
⚠️ Эффект сильнее, когда контента мало: исследование показало, что при слабых, скудных описаниях элементов (мало деталей) модель сильнее опирается на позицию. Чем подробнее описан каждый элемент списка, тем меньше влияет порядок.
Как исследовали
Исследователи проверяли LLM, которые ранжируют товары для рекомендаций (как в интернет-магазине или сервисе фильмов) — восемь разных моделей (от Qwen3 0.6B до 14B, Llama, Mistral) на трёх наборах данных: фильмы (MovieLens), книги и одежда с Amazon. Идея была простой: взять один и тот же список товаров-кандидатов, менять только порядок подачи и смотреть, можно ли искусственно "протолкнуть" заведомо нерелевантный товар в топ-5, просто переставляя порядок — без изменения содержания, оценок пользователей или самой модели.
Оказалось, что при 50 попытках перестановки почти 57% нерелевантных товаров можно искусственно затащить в топ-5 на "бедных" данных (Amazon), и заметно меньше — на "богатых" данных с подробными метаданными (MovieLens). Удивило то, что размер модели не спасает: крупные модели на 14 миллиардов параметров были не более устойчивы к этой атаке, чем маленькие на 0.6 миллиарда — уязвимость зависела больше от домена данных, чем от размера модели.
Ключевой практический вывод: стабильность ранжирования при случайных перестановках (насколько сильно меняется топ при разном порядке одного и того же списка) почти линейно предсказывает, насколько модель уязвима к этой атаке — даже без реальной попытки атаки. Это и даёт простой рецепт для пользователя: прогони список пару раз в разном порядке, и если результат шатается — не доверяй ранжированию.
Адаптации и экстраполяции
🔧 Техника: применение к LLM-as-judge → аудит любой оценки списка через модель
Тот же принцип работает не только для товаров, но и для любой задачи, где ты просишь LLM оценить или отранжировать несколько вариантов: сравнить черновики текста, выбрать лучший слоган из десяти, оценить питчи стартапов, отранжировать варианты дизайна.
Вот 5 вариантов слогана для бренда {название}: {список слоганов в порядке A}.
Выбери лучший и объясни почему.
Затем повтори с тем же списком в другом порядке. Если победитель меняется — значит, ты выбирал не лучший слоган, а тот, что просто оказался в удачной позиции.
Ресурсы
Ge Zhang, Jingru Cheng (Stanford University), Huiyuan Chen (Independent Researcher) — "Ranked by Position: Order Sensitivity as an Exploitable Attack Surface in LLM Listwise Recommenders". Код и данные: github.com/geoz-lab/position_bias_attack