TL;DR
Когда просишь LLM сравнить два варианта («что лучше — вариант A или B?»), результат зависит не только от качества самих вариантов, но и от того, как ты сформулировал запрос. Порядок вариантов, упоминание авторитета, наличие «цепочки рассуждений», эмоциональная окраска — всё это систематически сдвигает вердикт, даже если сами тексты не изменились ни на букву.
Исследователи нашли 12 типов искажений, которые ломают оценку через LLM. Некоторые из них ты, вероятно, используешь ненамеренно прямо сейчас: называешь один вариант «улучшенным», просишь «подумать шаг за шагом», ставишь нужный вариант первым. В худшем случае эти приёмы меняют итог оценки на противоположный — даже при закрытых, «надёжных» моделях вроде GPT.
Выход — тест A/B-свопа: попросить оценить дважды, поменяв варианты местами. Если вердикт изменился — оценка ненадёжна. Второй инструмент — «слепая» подача: убрать из промпта всё, что намекает на происхождение, статус или историю вариантов. Третий — несколько независимых прогонов с одним и тем же промптом: если ответ меняется, это шум, не суждение.
Схема метода
ШАГ 1: Оценка в прямом порядке (A → B)
→ вердикт 1
ШАГ 2: Оценка в обратном порядке (B → A) [отдельный запрос]
→ вердикт 2
ШАГ 3: Сравнение вердиктов
→ совпали? → оценка надёжна
→ расходятся? → результат ненадёжен, нужны доп. прогоны
Все три шага выполняются как отдельные запросы. ШАГ 3 можно попросить выполнить саму модель в том же чате.
Пример применения
Задача: Ты написал два варианта оффера для менеджера по продажам. Просишь Claude выбрать лучший.
Промпт — Прогон 1:
Оцени два варианта оффера для менеджера по продажам.
Критерии: мотивирует кандидата, звучит честно, конкретно по условиям.
ВАРИАНТ A:
Предлагаем позицию менеджера по продажам. Оклад 90 000 ₽ + KPI до 50%.
Команда 5 человек, продукт — B2B SaaS. Старт через две недели.
ВАРИАНТ B:
Мы ищем сильного менеджера, который готов строить продажи с нами.
Оклад от 80 000 ₽, бонусы без потолка, гибкий график, крутая команда.
Оцени каждый вариант по каждому критерию. Скажи, какой лучше и почему.
Промпт — Прогон 2 (свопинг):
Оцени два варианта оффера для менеджера по продажам.
Критерии: мотивирует кандидата, звучит честно, конкретно по условиям.
ВАРИАНТ A:
Мы ищем сильного менеджера, который готов строить продажи с нами.
Оклад от 80 000 ₽, бонусы без потолка, гибкий график, крутая команда.
ВАРИАНТ B:
Предлагаем позицию менеджера по продажам. Оклад 90 000 ₽ + KPI до 50%.
Команда 5 человек, продукт — B2B SaaS. Старт через две недели.
Оцени каждый вариант по каждому критерию. Скажи, какой лучше и почему.
Затем сравни этот вердикт с обратным порядком — и скажи, насколько оценка стабильна.
Результат: Модель выдаст оценку по каждому критерию для каждого варианта и итоговый вердикт. При сравнении прогонов будет видно: изменился ли победитель при смене порядка. Если изменился — у модели не было надёжного основания, она реагировала на позицию, а не на качество текста.
Почему это работает
LLM не «читает» два варианта нейтрально. Она генерирует текст слева направо, и первый вариант формирует якорь — контекст, относительно которого оценивается второй. Это не баг конкретной модели, это структурная особенность того, как работает генерация.
Кроме позиции, модель реагирует на социальные сигналы в промпте. Фраза «это улучшенная версия» работает как инструкция: модель начинает искать подтверждение, что вариант лучше. «Большинство экспертов предпочитают A» — то же самое. «Обоснуй подробно» (Chain-of-Thought) не делает оценку точнее — оно меняет направление, и куда именно, зависит от того, какой вариант стоит первым.
Антидот — убрать все подсказки о происхождении, порядке и статусе вариантов. И проверить вердикт свопом: если оценка надёжна, она должна выдержать смену позиций.
Рычаги управления: - Количество прогонов → больше прогонов = больше уверенности. Для важных решений — минимум 3–5 - Нейтральность формулировок → убери слова «улучшенный», «финальный», «рекомендован экспертом» - Слепая подача → не говори, кто написал вариант, из какого источника, какой был «первым» - Критерии явно → без критериев модель сама придумает веса — и это источник дополнительного смещения
Шаблон промпта
Оцени два варианта {объект_оценки}.
Критерии оценки:
— {критерий_1}
— {критерий_2}
— {критерий_3}
ВАРИАНТ A:
{текст_A}
ВАРИАНТ B:
{текст_B}
Оцени каждый вариант отдельно по каждому критерию (1–5).
Затем дай итоговый вердикт: какой вариант лучше и почему.
Не делай предположений об авторе, источнике или истории вариантов.
---
[ПРОГОН 2 — для проверки надёжности:]
Теперь повтори ту же оценку, поменяв варианты местами:
ВАРИАНТ A:
{текст_B}
ВАРИАНТ B:
{текст_A}
После оценки: сравни оба вердикта.
Если победитель изменился — напиши прямо: «Оценка позиционно нестабильна».
Если совпал — напиши: «Оценка устойчива к смене порядка».
Плейсхолдеры:
- {объект_оценки} — что сравниваем: «оффер», «питч для инвестора», «landing page», «версия текста»
- {критерий_1-3} — конкретные, измеримые: «звучит честно», «понятна целевая аудитория», «есть конкретный призыв к действию»
- {текст_A} и {текст_B} — сами варианты без подписей «улучшенный», «финальный», «от автора X»
🚀 Быстрый старт — вставь в чат:
Вот шаблон для надёжной оценки вариантов через A/B-своп.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про объект оценки и критерии — потому что без явных критериев она сама выберет веса, что и есть один из источников искажений.
Ограничения
⚠️ Субъективные задачи: Чем более «вкусовой» задача (оцени, что красивее / эмоциональнее), тем сильнее все 12 искажений. Для таких задач A/B-своп особенно важен.
⚠️ Маленькие модели: Компактные модели хуже держат формат ответа при свопе — могут съехать в «свободный пересказ» вместо структурированного вердикта. На GPT-4/Claude Sonnet работает надёжнее.
⚠️ Chain-of-Thought — не панацея: Просьба «подумай шаг за шагом» не делает оценку честнее. Она меняет направление рассуждений, и при позиционном смещении может усилить ошибку, а не исправить её.
⚠️ Эффект сохраняется при высокой сложности задачи: Чем сложнее и неоднозначнее объект оценки — тем больше влияние промпт-сигналов. Это не «ошибка новичков» — это системная уязвимость даже при грамотно написанных промптах.
Как исследовали
Команда Университета Британской Колумбии взяла три типичные задачи: генерация кода, починка кода и генерация тестов. Для каждой задачи — датасет пар «хороший вариант vs плохой вариант» с заранее известным правильным ответом. LLM-судья должен выбрать: вариант A или B?
Дальше — один фактор за раз. Взяли базовый нейтральный промпт, проверили точность. Потом добавили ровно одно искажение — например, написали «вариант A написан senior-инженером» — и снова замерили точность. 12 искажений × 3 задачи × несколько моделей (включая GPT и open-source Qwen).
Самый неожиданный результат: Chain-of-Thought снизил точность на некоторых задачах. Интуитивно ожидаешь обратного — «больше рассуждений = точнее». Оказалось, CoT усиливает позиционный якорь: модель подробно обосновывает то, что уже «решила» из-за порядка вариантов.
Также проверили воспроизводимость — один и тот же промпт, одна и та же пара вариантов, два независимых прогона. Совпадение ответов было высоким (~90%+), но не 100% — это значит, что даже без искажений часть результатов меняется между запросами из-за случайности генерации.
Для практики вывод неприятный: если ты не контролируешь порядок, формулировки и контекст, ты получаешь не оценку, а отражение своего промпта.
Оригинал из исследования
Исследователи проверяли 12 конкретных типов искажений. Вот их классификация (Table 1 из оригинала):
ЯВНЫЕ ИСКАЖЕНИЯ (explicit):
1. Position bias — какой вариант стоит первым (A или B)
2. Verbosity bias — более длинный/подробный вариант получает преимущество
3. Authority bias — «написано senior-инженером» / «из документации»
4. Distraction — добавление нерелевантного контекста в промпт
5. Chain-of-Thought — просьба «подумай шаг за шагом» перед оценкой
6. Self-enhancement — модель оценивает свой собственный вывод
НЕЯВНЫЕ ИСКАЖЕНИЯ (implicit):
7. Refined-version cue — «это улучшенная/финальная версия»
8. Bandwagon — «большинство предпочитают вариант A»
9. Sentiment — эмоциональная/позитивная окраска описания варианта
10. Model-name visibility — подсказка что написала конкретная модель (GPT/Claude)
11. Provenance cue — намёк на источник (опенсорс vs проприетарный)
12. Conformity pressure — «предыдущий эксперт оценил A выше»
Контекст: Это систематическая таксономия, которую исследователи использовали чтобы изолировать каждое искажение по одному. Можно использовать как чеклист при подготовке промпта для оценки: убедиться что ни один из этих сигналов не присутствует непреднамеренно.
Адаптации и экстраполяции
💡 Адаптация: «Слепой питч» для оценки бизнес-идей
Применение: просишь LLM оценить две стратегии, два лендинга, два варианта позиционирования.
У меня две концепции для {продукт/проект}.
Оцени каждую по критериям: {критерий_1}, {критерий_2}, {критерий_3}.
Не спрашивай и не предполагай, какая «основная», «новая» или «рекомендованная».
Treat both as equal candidates.
КОНЦЕПЦИЯ 1:
{текст}
КОНЦЕПЦИЯ 2:
{текст}
Оценка по критериям → итоговый вердикт → уверенность в вердикте (высокая / средняя / низкая).
После — попроси то же самое с заменой порядка. Если уверенность «высокая» в обоих прогонах и победитель тот же — можно доверять.
🔧 Техника: «Аудит промпта перед оценкой»
Перед тем как отправить запрос на сравнение — попроси модель сначала проверить сам промпт:
Прочитай следующий промпт для сравнительной оценки.
Найди в нём слова или фразы, которые намекают на то,
что один вариант лучше другого до начала оценки.
Перепиши промпт так, чтобы убрать все такие намёки.
[Промпт для оценки]
Это «мета-слой» защиты: модель убирает собственные триггеры до того, как начинает судить.
🔧 Техника: несколько независимых прогонов → консенсус
Для важных решений — три прогона с лёгким перефразированием промпта:
Прогон 1: стандартный промпт
Прогон 2: поменяй A и B местами
Прогон 3: попроси сначала оценить каждый вариант по шкале 1-10 отдельно, потом сравнить
→ Победитель в 2 из 3 прогонов = надёжный результат
→ Все три дали разный ответ = задача слишком субъективна, нужна другая методика
Ресурсы
Название работы: Bias in the Loop: Auditing LLM-as-a-Judge for Software Engineering
Ключевые ссылки из исследования: - CALM (Ye et al.) — базовый фреймворк 12 искажений в NLP оценке, на который опираются авторы - CodeJudgeBench (Jiang et al.) — датасет пар хороший/плохой код для тестирования судей - MT-Bench — оригинальный бенчмарк LLM-as-a-Judge парадигмы
Авторы: Zixiao Zhao, Amirreza Esmaeili, Fatemeh Fard Университет: University of British Columbia, Kelowna, Canada Контакт: zixiaosh@student.ubc.ca