TL;DR
Когда просишь LLM выбрать лучший из двух вариантов, она делает это с систематическими смещениями — не случайными, а предсказуемыми. Она выбирает вариант, который идёт первым в промпте. Она предпочитает длинные объяснения. Она ценит формальную корректность, но игнорирует читаемость и контекст задачи.
Это не баг конкретной модели. Исследователи Carnegie Mellon протестировали 13 разных систем — от GPT до специально обученных «судейских» моделей. Все уступили живому человеку на 12–23%. И дополнительное обучение не помогает: специализированные судьи не стабильно лучше обычного Claude или GPT-4o.
Решение простое: давай модели явный список критериев (рубрик) и спрашивай дважды с переставленными вариантами. Это устраняет позиционное смещение и направляет внимание туда, где LLM-судья слепа.
Схема метода
ШАГ 1: Составь рубрик → 3–5 конкретных критериев под свою задачу
ШАГ 2: Первый запрос → вариант A, затем вариант B → оценка по рубрику
ШАГ 3: Второй запрос → вариант B, затем вариант A (переставлены) → оценка
ШАГ 4: Сравни вердикты → если совпали — доверяй; если нет — смотри не на итог,
а на оценки по отдельным критериям
Все шаги — в обычном чате, никакого кода.
Пример применения
Задача: Выбираешь между двумя описаниями товара для Wildberries — один написал сам, второй сгенерила нейросеть. Хочешь спросить Claude, какой лучше.
Промпт (первый запрос):
Оцени два варианта описания товара для Wildberries по этим критериям:
1. Конкретность — есть ли реальные цифры, размеры, детали, или только общие слова
2. Краткость — нет ли лишнего, что не помогает покупателю принять решение
3. Понимание покупателя — учтены ли его реальные сомнения, а не абстрактные «преимущества»
4. Стиль под платформу — легко ли сканировать глазами при быстром просмотре
Оценивай каждый критерий отдельно для каждого варианта. Не давай одного общего вердикта без разбора по пунктам.
Вариант A:
[твой текст]
Вариант B:
[текст от нейросети]
Второй запрос (перестановка):
Теперь оцени снова по тем же четырём критериям, но в другом порядке:
Вариант A:
[текст от нейросети]
Вариант B:
[твой текст]
Результат: Получишь два оценочных листа по 4 критериям. Если итоговый победитель в обоих запросах один — это устойчивая оценка, ей можно доверять. Если модель переключилась — не смотри на общий вердикт, смотри на оценки по конкретным пунктам. Именно там реальная информация о том, чем варианты отличаются.
Почему это работает
LLM не читает два варианта «одновременно». Она генерирует ответ последовательно — и первый вариант в промпте сильнее влияет на то, что она «держит в голове» к моменту финального вывода. В исследовании модели меняли решение в 8–45% случаев только из-за перестановки — без изменения самих текстов.
Без рубрика у LLM нет якоря. Она опирается на то, что умеет проверять: длинный ли текст, правильная ли структура, много ли объяснений. Но не на то, что важно вам: подходит ли тон под аудиторию, учтены ли специфика ниши, не перегружен ли читатель. Явный список критериев — это якорь, который перенаправляет внимание туда, куда нужно тебе, а не туда, куда модель тянется по умолчанию.
Рычаги управления: - Количество критериев: 3–5 оптимально. Больше — модель начинает усреднять и конфликтовать между ними - Инструкция «оценивай каждый критерий отдельно» → убирает тенденцию давать один общий вердикт без обоснования - Числовая оценка по критериям (1–5) → легче сравнивать результаты двух запросов - Контр-инструкция против длины: добавь «длинный ответ с общими словами — это минус» → явно блокирует встроенное смещение модели к многословию
Шаблон промпта
Оцени два варианта {что оцениваем} по этим критериям:
1. {критерий 1} — {что это значит конкретно}
2. {критерий 2} — {что это значит конкретно}
3. {критерий 3} — {что это значит конкретно}
Оценивай каждый критерий отдельно.
Не давай одного общего вывода без разбора по пунктам.
{дополнительная контр-инструкция, если нужно: например, "краткость — плюс, а не минус"}
Вариант A:
{первый вариант}
Вариант B:
{второй вариант}
Затем повтори с переставленными A и B — тот же промпт, те же критерии, другой порядок.
Плейсхолдеры:
- {что оцениваем} — текст, план, решение, структура, идея, письмо клиенту
- {критерий N} — конкретный параметр, важный для твоей задачи
- {что это значит конкретно} — 3–7 слов, иначе модель интерпретирует по-своему
🚀 Быстрый старт — вставь в чат:
Вот шаблон для честной оценки двух вариантов с защитой от смещений LLM-судьи.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы понять что я сравниваю и какие критерии важны.
[вставить шаблон выше]
LLM спросит что именно ты сравниваешь и что важно при оценке — потому что без этого критерии получатся общими и бесполезными. Она возьмёт структуру из шаблона и сделает рубрик под твою задачу.
Ограничения
⚠️ Диагностирует, но не решает за тебя: Двойная проверка показывает, где судья нестабилен. Но если два запроса дают разные результаты — автоматического правильного ответа нет. Финальный выбор по критериям остаётся твоим.
⚠️ Неявный контекст не закрыть рубриком: LLM не знает историю твоего проекта, ожидания конкретного клиента, негласные стандарты команды. Рубрик помогает, но разрыв с живым экспертом, который «просто чувствует», остаётся.
⚠️ Длинные тексты — сильнее смещение: Чем длиннее варианты A и B, тем мощнее позиционный эффект. На больших текстах двойная проверка особенно важна.
⚠️ Не работает как «объективный арбитр»: Даже с рубриком LLM остаётся слабее человека-эксперта в той же области на 12–23%. Используй как инструмент структурирования мышления, не как финальный вердикт.
Как исследовали
Команда Carnegie Mellon взяла три реальных сценария взаимодействия разработчиков с AI: автодополнение кода в IDE (данные Copilot Arena), редактирование кода по инструкции (EDIT-Bench) и чат (Chatbot Arena, отфильтрованные примеры с кодом). Больше 500 примеров на каждый сценарий — не придуманные задачи, а реальные предпочтения реальных людей.
Идея была простой: сравнить что выбирают люди в реальной работе и что выбирают 13 разных моделей-судей. Чтобы понять почему расходятся — создали систему автоматической генерации рубриков: отдельная LLM смотрела на пары вариантов и выявляла, по каким критериям они отличаются. Потом обучили логистическую регрессию — она показала, какие критерии реально влияют на решение человека, а какие на решение LLM-судьи.
Самый неожиданный результат: специально обученные «судейские» модели (Prometheus, Atla Selene, Skywork Critic) не стабильно лучше обычных GPT-5 или Claude Sonnet. В чат-сценарии обычные модели оказались лучше специализированных. Это значит, что дообучение под задачу судьи не решает проблему — LLM просто не понимает неявный контекст так, как понимает человек с опытом в предметной области. Также выяснилось, что 11 из 16 выявленных тем оценки совпадают с классическими критериями качества кода из академических работ — и именно по ним LLM стабильно расходится с людьми.
Адаптации и экстраполяции
🔧 Техника: попросить объяснить расхождение → диагностика слепых пятен
Если при двойной проверке оценка изменилась, добавь в следующий запрос:
В первом запросе ты выбрал вариант A. Во втором (те же тексты, другой порядок) —
вариант B. По какому именно критерию из рубрика ты дал разный вес в двух случаях?
Модель пытается артикулировать своё смещение — и часто само это объяснение помогает тебе самому принять решение, не дожидаясь «правильного» вердикта.
🔧 Техника: добавить «антипредпочтения» в рубрик
Исследование показало, что LLM автоматически завышает оценку длинным объяснениям в чате. Если хочешь обратного — скажи явно:
При оценке: развёрнутый ответ с общими словами — это минус, не плюс.
Предпочитаю конкретику без воды, даже если текст короче.
🔧 Экстраполяция: применить принцип к нетехническим задачам
Исследование про код — но позиционное смещение универсально. Просишь LLM выбрать лучшую бизнес-идею, питч, заголовок, план проекта — то же правило: спрашивай дважды с переставленными вариантами. Смещение не зависит от домена, оно в архитектуре генерации.
Ресурсы
Comparing Developer and LLM Biases in Code Evaluation Aditya Mittal, Ryan Shar, Zichu Wu, Shyam Agarwal, Tongshuang Wu, Chris Donahue, Ameet Talwalkar, Wayne Chi, Valerie Chen Carnegie Mellon University GitHub: https://github.com/rShar01/TRACE