Как работает LLM-as-judge и почему он biased?

Краткий тезис

LLM-as-judge — это парадигма, при которой большая языковая модель (LLM) используется для оценки ответов, сгенерированных другой LLM (или той же самой). Такой подход позволяет автоматизировать оценку качества генерации, но страдает от ряда систематических смещений (bias): position bias (предпочтение первого или второго ответа), self-enhancement bias (модель выше оценивает свои собственные ответы), verbosity bias (более длинные ответы кажутся лучше) и style bias (формальные ответы получают завышенные оценки). Понимание этих biases и методов их смягчения (random swap, калибровка, ансамблирование) критически важно для построения надёжных автоматических пайплайнов оценки в RAG и agentic системах.

1. Термин LLM-as-judge: зачем и как работает

LLM-as-judge — это использование LLM в роли судьи, который выставляет оценку (например, от 1 до 5) или выбирает лучший ответ из пары. Процесс обычно выглядит так:

1. Пользовательский запрос = вопрос, контекст (документы RAG) и несколько ответов (например, от двух разных моделей или параметров).
2. Специальный промпт-шаблон с инструкциями для судьи: «Оцени ответы по критериям: релевантность, полнота, безопасность. Выбери лучший».
3. LLM (судья) генерирует оценку и/или обоснование.

Зачем это нужно Людская оценка (human evaluation) дорога, медленна и субъективна. LLM-судья дешевле, быстрее, масштабируем. Используется в пайплайнах RAG evaluation (например, RAGAS, но RAGAS не требует LLM-судьи — там метрики на основе эмбеддингов), в обучении с подкреплением (RLHF) и в агентных системах для самооценки.

2. Основные biases LLM-as-judge и почему они возникают

2.1 Position bias (смещение по позиции)

Модель склонна предпочитать первый из двух ответов (или, реже, второй), независимо от их качества. В экспериментах с GPT-4 и Claude было замечено, что при простом A/B сравнении первый ответ выбирается в 65-80% случаев, если ответы эквивалентны по качеству.

Причина вероятно, из-за того, что в обучающих данных (предпочтения людей) часто первый ответ считается более релевантным; также влияние attention — первый токен получает больше «внимания» в авторегрессивных моделях.

2.2 Self-enhancement bias (самовосхваление)

Модель-судья оценивает ответы, которые она сама сгенерировала, значительно выше, чем ответы другой модели. Например, GPT-4 как судья оценивает ответ GPT-4 на 4.5, а ответ Llama-3 на 3.2, хотя люди оценивают их одинаково.

Причина модель «узнаёт свой стиль» и считает его эталонным — это форма калибровочной ошибки (calibration error). Также может быть связано с overfitting на собственные паттерны токенов.

2.3 Verbosity bias (многословность)

Длинные, развёрнутые ответы получают более высокие оценки, даже если они менее точны или содержат избыточную информацию. Это особенно опасно в RAG, где ответ должен быть кратким по факту.

Причина в обучающих данных аннотаторы часто ассоциировали длину с качеством («более подробный ответ лучше»). Модель усвоила это корреляцию, хотя она не всегда верна.

2.4 Style bias (стиль)

Модель предпочитает ответы, написанные в формальном, «академическом» стиле, с использованием маркдауна, списков и подчёркиваний. Ответы в разговорном или непоследовательном стиле оцениваются ниже, даже если они содержательно верны.

Причина обучающие данные (Reddit, Stack Overflow, научные статьи) перекошены в сторону структурированного, формального языка.

3. Почему biases опасны для RAG и agentic систем

В агентном RAG агент часто использует LLM-судью для самокритики (self-reflection) и выбора лучшего действия. Если судья biased, то:

• Агент может застрять в субоптимальных стратегиях (например, генерировать длинные ответы, потому что они получают высокую оценку).
• Оценка качества retrieval становится неточной — хорошие чанки могут быть отвергнуты из-за стиля.
• Сравнение разных LLM становится смещённым, что мешает HPO (hyperparameter optimization).

4. Методы смягчения biases (mitigation strategies)

4.1 Random swap (случайная перестановка)

Оценка пары ответов дважды: (A, B) и (B, A). Если судья последователен, итоговый выбор будет одинаковым; если biased, результаты разойдутся. Финальное решение принимается голосованием по двум раундам.

Реализация для каждого запроса отправляем два запроса к LLM-судье с разным порядком. Флаг swap рандомизируется.

def compare_with_swap(question, answer_a, answer_b, judge_model):
    # раунд 1: сначала A, потом B
    response1 = judge_model.judge(question, answer_a, answer_b)
    # раунд 2: сначала B, потом A
    response2 = judge_model.judge(question, answer_b, answer_a)
    # логика: если оба раунда выбрали один и тот же ответ (учитывая swap) -> финал; иначе "disagree"
    final = "A" if response1.winner == "A" and response2.winner == "B" else (
               "B" if response1.winner == "B" and response2.winner == "A" else "disagree")
    return final

4.2 Калибровка на основе человеческих суждений (calibration)

Собираем датасет пар (запрос, ответ1, ответ2, выбор человека). Обучаем или настраиваем судью (fine-tune) с contrastive learning или preference tuning (DPO). Либо добавляем calibration prompt: «Ты склонен к position bias, постарайся быть объективным».

4.3 Ансамбль нескольких судей (ensemble)

Запускаем несколько разных LLM (GPT-4, Claude, Llama) и агрегируем их голоса (мажоритарное голосование). Это усредняет bias отдельных моделей. Метод дороже, но значительно надёжнее.

4.4 Использование метрик, не требующих LLM-судьи

Альтернативы: RAGAS (faithfulness, answer relevance считаются через эмбеддинги, без LLM), DeBERTa-v3 (обученная классификационная головка на 3 класса: лучший, ничья, худший). DeBERTa-v3 работает как маленькая (110М) модель, не имеет явных biases, но может быть менее гибкой.

5. Сравнение LLM-as-judge с альтернативами

6. Как измерить bias самого судьи: метрики согласованности

Чтобы оценить, насколько судья biased, используют:

• Self-consistency при swap: доля запросов, где судья выбрал один и тот же ответ в обоих раундах (A→B vs B→A). Идеал = 1.0, типичные значения для GPT-4 ~0.85-0.9.
• Agreement with human judges: корреляция (Cohen’s kappa, Spearman) между оценками судьи и усреднёнными оценками людей. Значение >0.6 считается приемлемым.
• Position bias metric: если в случае близких по качеству ответов судья чаще выбирает первый, это indicator.

7. Практические рекомендации для применения в RAG/agentic системах

1. Не доверяйте одному LLM-судье — всегда используйте рандомный swap и/или ансамбль.
2. Калибруйте судью на ваших данных — соберите хотя бы 50-100 человеческих оценок и настройте порог или prompt.
3. Для метрик faithfulness/relevance в RAG используйте RAGAS — он дешевле и лишён position bias.
4. Агентный self-reflection: лучше использовать маленькую модель (DeBERTa) для быстрой обратной связи, а LLM-судью — только для редких сложных случаев.
5. Периодически переоценивайте bias после обновления судьи (например, при переходе с GPT-4 на GPT-4o).

Пет-проект для закрепления

Задача Создать простой LLM-as-judge пайплайн и измерить position bias.

Инструменты Python, библиотека openai (для вызова GPT-4), datasets (сгенерировать пары ответов или взять из HaluBench), scikit-learn для метрик.

Шаги:

1. Выбрать 50 вопросов (например, из Natural Questions).
2. Для каждого вопроса сгенерировать два ответа: один с помощью GPT-4, другой с помощью Llama-3 (через API).
3. Написать функцию judge(question, answer_a, answer_b) с промптом: «Выбери лучший ответ, объясни выбор». Порядок ответов передаётся как (A, B).
4. Запустить оценку в двух режимах: (A,B) и (B,A) для каждого запроса.
5. Вычислить метрику position_bias_rate = (количество случаев, когда выбран первый ответ) / (всего случаев, где ответы не равны).
6. Повторить с random swap (усреднить результаты по двум порядкам). Сравнить bias до и после.

Ожидаемый результат Вы увидите, что без swap первый ответ выбирается в ~70% случаев. После усреднения bias снижается до 50-55% (остаточный шум). Отчёт с таблицей и гистограммой.

Связь с другими вопросами

Навигация

• Предыдущий: 869
• Следующий: 871
• Индекс: 00. Индекс разборов