LLM-оценщик может быть стабильным и всё равно ошибаться

Один и тот же LLM-оценщик может уверенно повторять ответ и всё же выбирать кандидата по его месту в паре, а не по качеству. Команда PayPal проверила это на моделях нескольких поставщиков; хотя препринт не рецензирован и числа в нём получили сами авторы, перестановка ответов меняла до 98% вердиктов. Для оценочных контуров это означает, что одной точности и одного прогона недостаточно для выбора модели или версии продукта.

Перестановка кандидатов ломает привычную проверку

В аудит вошли шесть моделей, включая GPT-5.2, Claude-Sonnet-4.6, Gemini-2.5-Pro и Llama-3.3-70B. Их проверяли на четырёх наборах задач: MT-Bench и AlpacaFarm с человеческими предпочтениями, JudgeBench с объективными ответами и LLMBar с примерами, специально составленными против моделей-оценщиков.

Для каждой пары ответов меняли порядок кандидатов, варьировали формат запроса и температуру выборки. Каждую комбинацию повторяли десять раз. Такой протокол разделяет три причины ошибки: случайную смену решения, зависимость от позиции и неспособность выбрать ответ с эталонной меткой.

Даже при нулевой температуре между одинаковыми запусками менялись 7–17% вердиктов. Нулевая температура снижает случайность генерации, но не превращает внешний API модели в полностью детерминированную функцию: на результат могут влиять серверная реализация, маршрутизация и особенности самой модели.

Повторяемость также не гарантирует правильность. В самой показательной конфигурации оценщик всегда возвращал одинаковый ответ на повторных запросах, но совпадал с эталонной меткой лишь в 51% случаев. Он выглядел стабильным, хотя фактически закреплял почти случайное решение.

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

Как посчитать долю действительно надёжных вердиктов

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

В работе предложен показатель надёжного вердикта T. Он объединяет повторяемость C, долю смены решения при перестановке φ и точность A:

T = C × (A − φ / 2)

Вычитание половины доли перестановок связано с устройством задачи. Если оценщик обязан выбрать одного из двух кандидатов и меняет выбор вместе с их местами, то из двух противоречащих друг другу решений правильным может быть только одно. Поэтому часть видимой точности возникает не из способности оценивать ответ, а из случайного совпадения с меткой.

Из той же логики следует верхняя граница точности:

A ≤ 1 − φ / 2

Пока сохраняется позиционное смещение, более способная базовая модель не сможет пересечь эту границу. Сначала нужно изменить протокол: показывать оба порядка, сравнивать решения и отдельно учитывать пары, для которых оценщик меняет мнение.

Формула опирается на допущение, что случайная повторяемость и устойчивость к порядку независимы. Проверка в приложении показывает, что при нарушении этого допущения T остаётся консервативной нижней оценкой. Для продуктового контура полезнее также хранить исходные три показателя: они объясняют, вызвана проблема шумом, позицией или слабой оценкой содержания.

Что менять в оценочном контуре

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

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

Формат оценки влияет сильнее, чем косметические изменения запроса. На JudgeBench переход к G-Eval, где модель выставляет оценки по нескольким критериям в одном вызове, повысил T у Gemini-2.5-Pro на 49 процентных пунктов. Разложение критериев по отдельным вызовам в стиле FLASK, напротив, снизило T у пяти из шести оценщиков: дополнительные решения накопили случайный шум.

Это не делает G-Eval универсальной заменой попарного сравнения. Практический вывод уже: перед выбором более дорогой или крупной модели стоит проверить порядок кандидатов и способ выставления оценки. Иначе команда может оптимизировать продукт под стабильную ошибку оценщика.

Источники

• All Verdicts are Not Equal: Rethinking LLM Judge Reliability