3,583 papers
arXiv:2507.10535 93 14 июля 2025 г. FREE

Модель-оценщик предвзята по умолчанию: она чаще выбирает вариант, который стоит в промпте последним.

КЛЮЧЕВАЯ СУТЬ
Модель-оценщик предвзята по умолчанию: она чаще выбирает вариант, который стоит в промпте последним. Это позиционное смещение — и оно тихо ломает любую попытку получить объективное суждение. Метод парного сравнения позволяет использовать LLM как надёжного судью при выборе лучшего варианта кода, текста или идеи — без шкал и без случайной погрешности. Фишка: вместо 'оцени от 1 до 10' — 'выбери лучшее из двух в одном промпте', плюс проверка смещения — поменяй варианты местами и запусти снова. Если модель изменила выбор — первый ответ был предвзятым, а не аналитическим.
Адаптировать под запрос

Исследование изучает, насколько хорошо LLM могут выступать в роли «судьи» для оценки и сравнения двух вариантов ответа (в данном случае, фрагментов кода). Было обнаружено, что модели подвержены «позиционному смещению» (результат зависит от порядка вариантов) и что прямое сравнение двух опций в одном промпте (парное сравнение) работает значительно лучше, чем оценка каждой по отдельности. Также выяснилось, что для более точной оценки модели нужен полный контекст, а не только «чистые» данные.

Ключевой результат: Для надежной оценки просите LLM сравнивать два варианта напрямую в одном запросе, но помните о возможном влиянии их порядка и предоставляйте максимум сопутствующей информации.

Суть метода, который можно извлечь из этого исследования, заключается в использовании LLM в роли «эксперта-оценщика» (LLM-as-a-Judge) с помощью специальной структуры промпта, которая повышает надежность и точность суждений модели.

Методика для пользователя сводится к трем основным принципам:

  1. Используйте парное сравнение (Pair-wise Comparison): Вместо того чтобы просить LLM оценить один вариант по некой шкале (например, «Оцени этот текст от 1 до 10»), а затем другой, гораздо эффективнее подать оба варианта в одном промпте и попросить модель сравнить их и выбрать лучший. Этот подход заставляет LLM активировать механизмы сравнительного анализа, что приводит к более тонкому и обоснованному решению. Модели проще определить, что лучше, чем определить, насколько что-то хорошо в абсолюте.

  2. Помните о позиционном смещении (Positional Bias) и проверяйте его: Исследование доказывает, что LLM часто предпочитают вариант, который указан в промпте последним (recency bias). Чтобы не стать жертвой этого когнитивного искажения модели, используйте простой прием: если вы не уверены в объективности ответа, поменяйте варианты местами и задайте тот же вопрос. Если модель по-прежнему выбирает тот же вариант (независимо от его новой позиции), ее выбор, скорее всего, объективен. Если же она выбрала другой вариант (тот, что теперь стоит последним), значит, ее суждение ненадежно.

  • 3. Предоставляйте богатый контекст (Rich Context): Исследование показало, что оценки были точнее, когда модели получали не просто «чистый» код, а полный ответ с комментариями и рассуждениями. Для обычного пользователя это означает: не упрощайте входные данные чрезмерно. Если вы просите сравнить два варианта текста для письма, предоставьте также информацию о получателе, цели письма и т.д. Чем больше релевантного контекста, тем точнее будет «суждение» модели.
    • Прямая применимость: Чрезвычайно высокая. Любой пользователь может немедленно начать строить промпты по принципу «Сравни А и Б». Например: «Вот два варианта заголовка для статьи. Какой из них лучше и почему? Вариант А: [...]. Вариант Б: [...]». Техника проверки позиционного смещения (смена мест) также не требует никаких специальных навыков.

    • Концептуальная ценность: Огромная. Исследование дает пользователю интуитивное понимание того, что LLM — это не база знаний, а инструмент для рассуждений, который сильно зависит от «оправы» задачи. Ключевые концепции:

      • LLM лучше справляются со сравнительными, а не абсолютными задачами.
      • LLM подвержены когнитивным искажениям, аналогичным человеческим (например, влиянию порядка).
      • Контекст важнее лаконичности, когда речь идет о качестве суждений.
    • Потенциал для адаптации: Метод «LLM-как-судья» с парным сравнением универсален. Его можно адаптировать для любой сферы:

      • Маркетинг: Выбор лучшего рекламного объявления.
      • Юриспруденция: Сравнение двух формулировок в договоре.
      • Образование: Оценка двух вариантов ответа на экзаменационный вопрос.
      • Личная продуктивность: Выбор между двумя планами на день.
    🧠

    Механизм адаптации прост: определите два варианта для сравнения, задайте четкие критерии оценки и попросите модель сделать выбор с обоснованием.

    Практически пример применения:

    Ты — опытный HR-специалист и копирайтер. Твоя задача — помочь мне выбрать лучший вариант сопроводительного письма для отклика на вакансию "Менеджер по продукту".
    
    **# Контекст:**
    *   **Компания:** Инновационный стартап в сфере образовательных технологий.
    *   **Мой опыт:** 5 лет в маркетинге, последние 2 года управлял небольшими проектами, сильные аналитические навыки, есть опыт запуска двух успешных рекламных кампаний.
    *   **Цель письма:** Произвести впечатление, показать мотивацию и релевантность моего опыта, выделиться среди других кандидатов.
    
    **# Задание:**
    Проанализируй два варианта сопроводительного письма ниже. Сравни их по следующим критериям:
    1.  **Убедительность:** Насколько хорошо текст "продает" мой опыт для этой роли.
    2.  **Структура и ясность:** Легко ли читать и понимать основную мысль.
    3.  **Тон голоса (Tone of Voice):** Соответствует ли стиль письма культуре стартапа.
    
    Сделай окончательный выбор и подробно объясни, почему один вариант лучше другого.
    
    ---
    **ВАРИАНТ А**
    
    Уважаемый отдел кадров,
    
    Я пишу, чтобы выразить свою заинтересованность в вакансии менеджера по продукту, опубликованной на вашем сайте. Имея пятилетний опыт работы в маркетинге и управлении проектами, я уверен, что мои навыки хорошо подходят для вашей компании. Я успешно запустил несколько кампаний и обладаю сильными аналитическими способностями. Я был бы рад возможности обсудить, как мой опыт может быть полезен вашей команде.
    
    С уважением,
    [Мое Имя]
    ---
    **ВАРИАНТ Б**
    
    Уважаемая команда [Название Компании],
    
    Меня вдохновляет ваша миссия по трансформации образования, и я хочу стать частью этой истории в роли менеджера по продукту. Мой переход из маркетинга в управление проектами был продиктован желанием не просто продвигать продукты, а создавать их. За последние два года я руководил проектными группами и на практике понял, как превратить аналитические данные в успешный продукт — например, в ходе запуска кампании X, которая увеличила вовлеченность на 30%.
    
    Я уверен, что мой опыт в понимании пользователей и управлении жизненным циклом проекта поможет вам достичь новых высот. Буду рад обсудить, как я могу усилить вашу продуктовую команду.
    
    С уважением,
    [Мое Имя]
    ---

    Почему это работает:

    Этот промпт эффективен, потому что он напрямую использует выводы исследования:

    1. Парное сравнение (Pair-wise Comparison): Промпт не просит оценить каждое письмо по шкале, а заставляет модель напрямую сравнить «Вариант А» и «Вариант Б». Это активирует более глубокий анализ и выявление нюансов, так как модель ищет относительные преимущества и недостатки.
    2. Богатый контекст (Rich Context): Вместо того чтобы просто дать два текста, промпт предоставляет ключевую информацию (Контекст: о компании, моем опыте, цели). Это аналог «полного ответа с комментариями» из статьи. Этот контекст служит для LLM «мерилом», по которому она может объективнее судить о релевантности каждого письма.
    3. Четкие критерии оценки: Указание критериев («Убедительность», «Структура», «Тон голоса») направляет процесс «судейства» LLM, делая его менее случайным и более сфокусированным, что повышает надежность и стабильность ответа.
    4. 4. Осознание позиционного смещения: Хотя это не видно в самом промпте, пользователь, знакомый с исследованием, знает, что для 100% уверенности он может поменять местами Вариант А и Вариант Б и запустить промпт снова, чтобы проверить, останется ли выбор модели прежним.

    Другой пример практического применения

    Ты — эксперт по путешествиям, специализирующийся на семейном отдыхе.
    
    **# Контекст:**
    *   **Путешественники:** Семья с двумя детьми (6 и 11 лет).
    *   **Интересы:** Дети любят животных и интерактивные музеи. Родители — красивую природу и спокойные прогулки. Все не любят большие толпы и суету.
    *   **Бюджет:** Средний.
    *   **Задача:** Выбрать лучшее направление для недельного отпуска в августе.
    
    **# Задание:**
    Ниже представлены два варианта для отпуска. Проведи их сравнительный анализ по критериям:
    1.  **Интересы детей:** Насколько направление подходит для детей 6 и 11 лет.
    2.  **Интересы взрослых:** Есть ли что-то для родителей (природа, спокойствие).
    3.  **Логистика и бюджет:** Насколько удобно перемещаться и соответствует ли это среднему бюджету.
    
    В конце дай четкую рекомендацию, какой вариант ты считаешь оптимальным для этой семьи, и приведи развернутое обоснование.
    
    ---
    **НАПРАВЛЕНИЕ 1: Черногория (побережье Будвы и Котора)**
    
    *   **Активности:** Пляжный отдых, прогулки по старым городам Будвы и Котора, морская прогулка по Боко-Которскому заливу, посещение национального парка Ловчен.
    *   **Плюсы:** Красивое море, горы, историческая атмосфера.
    *   **Минусы:** В августе очень много туристов, пляжи переполнены, может быть шумно.
    ---
    **НАПРАВЛЕНИЕ 2: Словения (озера Блед и Бохинь)**
    
    *   **Активности:** Прогулки вокруг озер, посещение замка Блед, катание на лодках, поход в ущелье Винтгар, посещение интерактивного музея в Любляне (1 час езды). Рядом есть небольшой зоопарк.
    *   **Плюсы:** Потрясающая природа, меньше суеты, много активностей на свежем воздухе.
    *   **Минусы:** Море далеко, погода может быть переменчивой.
    ---

    Объяснение механизма почему этот пример работает.

    Этот промпт использует ту же доказанную методологию для получения качественного и надежного совета:

    1. LLM-as-a-Judge: Модель получает роль «эксперта по путешествиям», что настраивает ее на оценочный лад.
    2. Парное сравнение: Вместо абстрактного вопроса «Куда поехать с детьми?» промпт ставит конкретную задачу выбора между двумя четко описанными вариантами («Черногория» vs «Словения»). Это заставляет модель взвешивать конкретные плюсы и минусы каждого варианта относительно друг друга, а не генерировать общий список идей.
    3. Контекст и критерии: Указание состава семьи, их интересов и бюджета служит надежной основой для сравнения. Критерии («Интересы детей», «Интересы взрослых», «Логистика») структурируют анализ модели, заставляя ее последовательно рассматривать каждый аспект для обоих вариантов, что повышает качество и обоснованность финальной рекомендации.
    4. Снижение риска предвзятости: Пользователь, зная о «позиционном смещении», может легко поменять местами «Направление 1» и «Направление 2», чтобы убедиться, что рекомендация модели не случайна, а основана на анализе предоставленных фактов.

    Оценка полезности: 93

    📌

    Основные критерии оценки

    • A. Релевантность техникам промтинга: Да, исследование напрямую сравнивает эффективность разных подходов к промптингу для задач оценки (парное сравнение против оценки по шкале) и анализирует влияние структуры промпта (наличие/отсутствие комментариев и рассуждений).
    • B. Улучшение качества диалоговых ответов: Да, принципы, выявленные в исследовании, напрямую ведут к получению более надежных и последовательных ответов от LLM при решении задач, требующих оценки или выбора между вариантами.
    • C. Прямая практическая применимость: Абсолютно. Пользователь может немедленно применить выводы без какого-либо кода. Основные идеи — «сравнивай два варианта, а не оценивай по одному» и «остерегайся влияния порядка» — элементарны в реализации.
    • D. Концептуальная ценность: Очень высокая. Исследование наглядно демонстрирует фундаментальные поведенческие особенности LLM: позиционное смещение (positional bias) и превосходство сравнительного мышления над абсолютной оценкой. Это помогает пользователю понять, что LLM — не объективный логический калькулятор, а система, чувствительная к способу подачи информации.
    • E. Новая полезная практика (кластеризация): Работа попадает сразу в несколько ключевых кластеров:
      • 1. Техники формулирования промптов: Вводит и доказывает эффективность техники «парного сравнения» (pair-wise comparison) как части паттерна «LLM-as-a-Judge».
      • 2. Поведенческие закономерности LLM: Ключевое открытие — позиционное смещение (positional bias). Модели склонны предпочитать вариант, стоящий на втором месте (recency bias), что является критически важным знанием для любого пользователя.
      • 3. Оптимизация структуры промптов: Вывод о том, что полные, необработанные ответы с комментариями и рассуждениями (raw response) работают лучше, чем очищенный код, напрямую говорит о важности предоставления богатого контекста.
      • 7. Надежность и стабильность: Все исследование посвящено повышению надежности оценок. Оно показывает, как снизить случайность и предвзятость в суждениях LLM.
    • Чек-лист практичности (+15 баллов): Да, исследование дает готовые конструкции (парное сравнение), объясняет проблему с размещением информации (позиционное смещение), показывает, как структурировать сложные запросы на оценку и раскрывает неочевидные особенности поведения LLM.
    📌

    Цифровая оценка полезности

    Исследование получает высокую оценку, так как его выводы, несмотря на узкоспециализированный домен (оценка кода), являются универсальными и чрезвычайно полезными для любого пользователя, который использует LLM для задач выбора, сравнения или оценки.

    Аргументы в пользу оценки: * Универсальность выводов: Открытие «позиционного смещения» (когда модель предпочитает последний из предложенных вариантов) и доказанная эффективность «парного сравнения» применимы к любой задаче: от выбора лучшего маркетингового слогана до сравнения двух планов путешествия. * Прямое действие: Пользователь может немедленно улучшить свои промпты, просто изменив их структуру — вместо «Оцени вариант А. Теперь оцени вариант Б» использовать «Сравни вариант А и вариант Б и выбери лучший». * Концептуальный прорыв для пользователя: Работа разрушает наивное представление о LLM как об объективном эксперте и учит пользователя относиться к модели как к мощному, но предвзятому инструменту, который нужно правильно «калибровать» с помощью промптов.

    Контраргументы (почему оценка могла быть ниже): * Специфический домен: Вся терминология и примеры в статье относятся к программированию. Неподготовленному пользователю может быть сложно самостоятельно «перевести» выводы из контекста «оценки кода» в свою повседневную область (например, написание текстов или анализ данных). * Отсутствие готовых «магических фраз»: Исследование предлагает скорее методологию и указывает на поведенческие ловушки, а не дает конкретные фразы вроде «Думай шаг за шагом», которые можно просто скопировать. Требуется небольшое осмысление для применения.

    📌

    Несмотря на контраргументы, фундаментальная ценность и простота адаптации ключевых идей для общих задач перевешивают узкую специализацию исходного материала.

    📋 Дайджест исследования

    Ключевая суть

    Модель-оценщик предвзята по умолчанию: она чаще выбирает вариант, который стоит в промпте последним. Это позиционное смещение — и оно тихо ломает любую попытку получить объективное суждение. Метод парного сравнения позволяет использовать LLM как надёжного судью при выборе лучшего варианта кода, текста или идеи — без шкал и без случайной погрешности. Фишка: вместо 'оцени от 1 до 10' — 'выбери лучшее из двух в одном промпте', плюс проверка смещения — поменяй варианты местами и запусти снова. Если модель изменила выбор — первый ответ был предвзятым, а не аналитическим.

    Принцип работы

    LLM лучше справляется с относительными задачами, чем с абсолютными. Спросишь 'как хорош этот код по шкале от 1 до 10' — получишь размытое '7'. Спросишь 'что из двух лучше и почему' — получишь разбор с конкретными аргументами. Сравнительный анализ для модели проще, чем абстрактная оценка — она ищет относительные преимущества, а не придумывает universal score. Второй принцип: чем больше контекста — тем точнее суждение. Не урезай входные данные ради лаконичности.

    Почему работает

    LLM обучена на текстах, где люди сравнивают вещи относительно друг друга. Вопрос 'что лучше — А или Б?' встречается в обучающих данных куда чаще, чем 'оцени А по шкале'. Отсюда точность. Позиционное смещение — другая история: модель при генерации больше 'помнит' то, что читала недавно — поэтому последний вариант в промпте кажется ей свежее и убедительнее. Именно поэтому простой тест 'поменяй местами и запусти' работает как детектор ненадёжного ответа. Если выбор поменялся — модель реагировала на порядок, а не на качество.

    Когда применять

    Везде, где нужно выбрать лучшее из двух вариантов: код на ревью (какой фрагмент чище?), маркетинг (какой заголовок сильнее?), HR (какое сопроводительное письмо убедительнее?), продукт (какой сценарий использования понятнее?). Особенно полезно, когда критерии оценки размыты и хочется опереться на внешнее суждение, а не интуицию. НЕ подходит для оценки одиночного варианта — без второго для сравнения метод теряет главное преимущество.

    Мини-рецепт

    1. Собери оба варианта в одном промпте: Вариант А и Вариант Б — не отдельными запросами, а вместе. Модель должна видеть оба сразу.
    2. Дай роль и контекст: <роль>опытный разработчик с 10 годами опыта в Python — плюс опиши задачу, для которой написан код, требования и ограничения. Чем больше контекста — тем точнее суждение.
    3. Задай критерии: Не просто 'какой лучше', а 'сравни по читаемости, производительности и соответствию задаче'. Критерии убирают размытость ответа.
    4. Проверь смещение: Поменяй Вариант А и Вариант Б местами. Запусти тот же промпт снова. Если модель выбрала то же — ответ надёжен. Если выбор изменился — модель реагировала на порядок, а не на качество.

    Примеры

    [ПЛОХО] : Оцени этот код по шкале от 1 до 10 и скажи, хорош ли он
    [ХОРОШО] : Ты — опытный разработчик на Python. Ниже два варианта функции для парсинга JSON с обработкой ошибок. Задача: функция должна быть читаемой для джуна и не падать при пустых данных. Сравни варианты по трём критериям: 1. Читаемость — понятно ли джуну без комментариев 2. Надёжность — что произойдёт при пустом или битом JSON 3. Лаконичность — нет ли лишнего кода Вариант А: [код] Вариант Б: [код] Выбери лучший вариант и объясни конкретно, почему. После ответа — поменяй Вариант А и Вариант Б местами и запусти снова. Если выбор не изменился — суждение объективно.
    Источник: CodeJudgeBench: Benchmarking LLM-as-a-Judge for Coding Tasks
    ArXiv ID: 2507.10535 | Сгенерировано: 2026-03-02 17:59

    Проблемы LLM

    ПроблемаСутьКак обойти
    Модель выбирает вариант по позиции, не по качествуКогда даёшь два варианта на сравнение, модель часто выбирает тот что стоит последним. Не потому что он лучше. Просто он ближе к концу контекста. Это называют "смещением к последнему". Твой реально лучший вариант может проиграть только из-за порядкаПроверь своп-тестом: поменяй варианты местами и задай тот же вопрос. Модель снова выбрала то же? Значит выбор объективный. Выбрала другое (то, что теперь стоит последним)? Значит судила по позиции, а не по содержанию

    Методы

    МетодСуть
    Парное сравнение — точнее чем оценка по шкалеНе проси модель оценить каждый вариант отдельно (например, "дай 1-10"). Дай оба варианта сразу и попроси выбрать лучший с обоснованием. Шаблон: Вот два варианта. Вариант А: [...]. Вариант Б: [...]. Который лучше и почему? Почему работает: Сравнить А и Б проще чем оценить каждый в абсолюте. При раздельной оценке модель теряет точку отсчёта. При совместной — видит конкретные плюсы и минусы относительно друг друга. Когда применять: оцениваешь тексты, решения, варианты — любые два альтернативных ответа. Когда не работает: вариантов больше пяти — тогда разбивай на пары и сравнивай попарно
    Своп-тест — проверка объективности оценкиПолучил ответ от модели. Не уверен — объективно ли она выбрала? Поменяй Вариант А и Вариант Б местами. Запусти тот же запрос снова. Модель выбрала то же (независимо от новой позиции) оценка надёжная. Модель выбрала другое (то что теперь стоит последним) ответ зависит от порядка, а не от качества. В таком случае используй средний балл двух прогонов или переформулируй запрос с явными критериями

    Тезисы

    ТезисКомментарий
    Модели проще сравнить два варианта, чем оценить одинПри оценке одного варианта ("насколько это хорошо?") у модели нет точки отсчёта. Она выдаёт размытое 7 из 10. При сравнении двух вариантов она ищет конкретные отличия: здесь точнее, там логичнее. Это активирует другой тип рассуждений. Применяй: вместо "оцени этот текст" пиши "вот два варианта — выбери лучший и объясни почему"
    📖 Простыми словами

    CodeJudgeBench: бенчмаркинг LLM как судьи для задач кодирования

    arXiv: 2507.10535

    Суть проблемы в том, что мы привыкли доверять нейронкам проверку чужого кода, но до сих пор не понимали, насколько этот «судья» адекватен. CodeJudgeBench вскрыл фундаментальный баг: современные LLM оценивают код не по его логике или чистоте, а по поверхностному сходству с правильным ответом. Если код выглядит «правильно», модель ставит лайк, даже если внутри затаилась критическая ошибка, которая уронит весь продакшн. Это не полноценный аудит, а скорее визуальный техосмотр через грязное стекло.

    Это как нанять прораба, который проверяет качество фундамента по фотографии в Instagram. Он видит ровный бетон и говорит: «Красиво, принимаем», не замечая, что внутри вместо арматуры — гнилые палки. Модель ведет себя как ленивый отличник, который научился угадывать правильные ответы по интонации учителя, но совершенно не понимает физику процесса. В итоге мы получаем иллюзию контроля, где галлюцинации судьи становятся опаснее ошибок самого программиста.

    Исследование выделило конкретные методы, которые хоть как-то спасают ситуацию. Во-первых, это Chain-of-Thought (цепочка рассуждений) — когда мы заставляем модель сначала расписать логику работы кода, а только потом выносить вердикт. Во-вторых, Few-shot prompting с примерами плохих и хороших решений: без четких ориентиров модель начинает «плыть» и завышать оценки. Но главный вывод неутешителен: даже топовые модели типа GPT-4 лажают в 30% случаев, когда нужно найти тонкий логический изъян, а не просто синтаксическую опечатку.

    Хотя бенчмарк гоняли на Python и C++, принцип универсален для любой технической экспертизы через AI. Это касается и проверки смарт-контрактов, и анализа архитектурных схем, и даже юридических документов. Везде, где есть строгая логика, нейронка пытается подменить её вероятностным угадыванием. Если вы используете LLM для код-ревью в команде, знайте: она отлично ловит «очевидную фигню», но абсолютно слепа к сложным багам, которые не ломают структуру текста.

    Короче: CodeJudgeBench — это холодный душ для тех, кто решил полностью делегировать ревью нейронкам. Модели пока не умеют «думать» как компилятор, они лишь имитируют проверку. Использовать их как помощников можно, но оставлять за ними последнее слово — полный провал. Пока что лучший «судья» для кода — это всё ещё живой инженер с чашкой кофе, а AI — это просто продвинутая автопроверка орфографии, которая иногда воображает себя экспертом.

    Работа с исследованием

    Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

    0 / 2000
    ~0.5-2 N-токенов ~10-30с
    ~0.3-1 N-токенов ~5-15с