中文翻译暂不可用,显示俄语原文。

Что такое «оценка с подкреплением» (RLHF evaluation) и как она отличается от обычной?

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

RLHF evaluation — это метод оценки качества ответов языковых моделей, основанный на сравнении пар ответов людьми (chosen vs rejected), а не на абсолютных шкалах. В отличие от обычной оценки (например, Likert-шкалы или автоматических метрик), RLHF снижает субъективность и позволяет обучить reward model (модель вознаграждения]]), которая предсказывает человеческие предпочтения. Этот подход лежит в основе fine-tuning’а LLM с подкреплением (RLHF) и даёт более надёжную обратную связь, чем традиционные метрики.


1. Термин: RLHF (Reinforcement Learning from Human Feedback)

RLHF — это техника дообучения LLM, при которой модель учится генерировать ответы, максимизирующие вознаграждение от обученной на человеческих предпочтениях reward model. Ключевой этап — сбор данных: людям показывают несколько ответов модели на один запрос и просят выбрать лучший (chosen) и худший (rejected). Эти пары используются для обучения reward model, которая затем служит сигналом для алгоритма PPO (Policy Optimization|Proximal Policy Optimization]]).

RLHF evaluation — это процесс оценки качества ответов с помощью той же схемы: вместо абсолютных баллов (например, «поставьте оценку от 1 до 5») аннотаторы сравнивают пары ответов. Это даёт более согласованные и менее субъективные результаты.


2. Обычная оценка: проблемы и ограничения

Обычная оценка (conventional evaluation) включает:

  • Абсолютные шкалы (Likert: 1–5, 1–7).
  • Автоматические метрики (BLEU, ROUGE, METEOR, perplexity).
  • Парное сравнение (A/B testing) — но без обучения reward model.

Проблемы абсолютных шкал:

  • Субъективность: разные аннотаторы по-разному интерпретируют градации (что для одного «4», для другого «3»).
  • Калибровка: сложно обеспечить единый стандарт оценки.
  • Шум: разброс оценок высок, требуется много аннотаторов для усреднения.

Проблемы автоматических метрик:

  • Слабая корреляция с человеческим восприятием (особенно для генеративных задач).
  • Не учитывают контекст и семантику (BLEU считает совпадение n-грамм, но не смысл).

Обычная оценка полезна для быстрых итераций, но не даёт точного сигнала для обучения сложных моделей.


3. Как работает RLHF evaluation

3.1 Сбор предпочтений (preference collection)

  • На каждый prompt (запрос) генерируется несколько ответов (обычно 2–4).
  • Аннотатор (человек) выбирает лучший (chosen) и худший (rejected) ответ.
  • Результат: набор троек (prompt, chosen_response, rejected_response).

3.2 Обучение reward model

  • Reward model (обычно небольшая LLM, например, на базе GPT-2 или BERT) обучается предсказывать, какой ответ предпочтут люди.
  • Функция потерь — pairwise ranking loss (например, Bradley-Terry): [ \mathcal{L} = -\mathbb{E}_{(x, y_c, y_r) \sim D} \left[ \log \sigma (r(x, y_c) - r(x, y_r)) \right] ] где ( r(x, y) ) — скор (reward) для ответа ( y ) на запрос ( x ), ( \sigma ) — сигмоида.
  • Модель учится присваивать более высокий скор chosen-ответам.

3.3 Использование reward model для оценки

  • После обучения reward model можно использовать как автоматический evaluator: для нового ответа модель выдаёт скор, отражающий ожидаемое предпочтение человека.
  • Это позволяет оценивать ответы без привлечения людей на каждом шаге.

4. Отличия RLHF evaluation от обычной оценки

АспектОбычная оценкаRLHF evaluation
Формат данныхАбсолютные баллы (1–5) или автоматические метрикиПары (chosen vs rejected)
СубъективностьВысокая (разная интерпретация шкал)Низкая (сравнение проще и стабильнее)
Обучение моделиНе предусмотрено (только статистика)Обучается reward model для автоматизации
ЦельИзмерить качество в моментеПолучить сигнал для дообучения (RLHF)
СтоимостьДешевле (один ответ оценивается один раз)Дороже (нужно несколько ответов на запрос)
ПрименимостьБыстрые эксперименты, бенчмаркиFine-tuning, выравнивание (alignment)
ШумВысокий (разброс оценок)Низкий (сравнение даёт консистентность)

Ключевое отличие: относительность vs абсолютность

  • В обычной оценке аннотатор даёт абсолютную оценку каждому ответу.
  • В RLHF аннотатор сравнивает ответы, что психологически проще и даёт более надёжные данные (люди лучше ранжируют, чем ставят баллы).

5. Преимущества RLHF evaluation

  1. Снижение субъективности: сравнение пар менее зависимо от индивидуальных предпочтений.
  2. Возможность автоматизации: обученная reward model заменяет человека для массовой оценки.
  3. Прямая связь с fine-tuning: reward model используется в PPO для улучшения модели.
  4. Учёт тонких нюансов: модель учится различать ответы, которые почти одинаковы по качеству, но один чуть лучше.
  5. Масштабируемость: после обучения reward model можно оценивать миллионы ответов без людей.

6. Недостатки и ограничения

  1. Высокая стоимость сбора данных: нужно много пар ответов, каждая требует нескольких генераций и оценки человеком.
  2. Риск переобучения reward model: если данные однородны, модель может выучить артефакты.
  3. Ограниченность человеческих предпочтений: люди могут быть необъективны (например, предпочитать длинные ответы, даже если они менее точны).
  4. Сложность интерпретации: reward model — чёрный ящик, не всегда понятно, почему она дала низкий скор.
  5. Необходимость краудсорсинга: для больших датасетов нужны платформы вроде Amazon Mechanical Turk.

7. Практические аспекты

7.1 Как собирать данные

  • Используйте платформы: Scale AI, Surge AI, Labelbox.
  • Инструкции для аннотаторов: чёткие критерии (полезность, безопасность, честность).
  • Контроль качества: золотые вопросы (known pairs), межаннотаторское согласие (Cohen’s kappa).

7.2 Обучение reward model

  • Архитектура: обычно transformer с головой регрессии (один выход — reward).
  • Размер: от 1B до 7B параметров (меньше, чем основная LLM).
  • Гиперпараметры: learning rate ~1e-5, batch size 64–256, эпохи 1–3 (чтобы не переобучить).

7.3 Использование в PPO

  • Reward model выдаёт reward для каждого токена (или для всего ответа).
  • PPO обновляет политику (LLM) так, чтобы увеличить ожидаемый reward.
  • Дополнительно добавляют KL-дивергенцию с исходной моделью, чтобы не уйти далеко.

8. RLHF evaluation vs LLM-as-a-Judge

LLM-as-a-Judge — это подход, где сама LLM (например, GPT-4) оценивает ответы, часто используя ту же схему парного сравнения. Отличия:

  • RLHF evaluation использует человека для сбора данных, а затем обучает reward model.
  • LLM-as-a-Judge полностью автоматизирован, но может наследовать bias’ы LLM.
  • RLHF даёт более надёжный сигнал для fine-tuning, а LLM-as-a-Judge — для быстрой оценки.

Оба подхода могут комбинироваться: reward model можно обучать на данных, размеченных LLM (LLM-as-a-Judge), но это менее надёжно.


9. Альтернатива: DPO (Direct Preference Optimization)

DPO — метод, который обходит обучение отдельной reward model. Вместо этого он напрямую оптимизирует политику (LLM) на парах предпочтений, используя аналитическое выражение для оптимальной политики. DPO проще, дешевле и часто даёт сопоставимые результаты с RLHF. Однако в контексте оценки DPO не даёт отдельной reward model — оценка остаётся на уровне пар.


10. Пример кода (Python, PyTorch-like)

# Псевдокод для обучения reward model
import torch
import torch.nn as nn

class RewardModel(nn.Module):
    def __init__(self, base_model, hidden_size=768):
        super().__init__()
        self.base_model = base_model  # например, BERT
        self.reward_head = nn.Linear(hidden_size, 1)

    def forward(self, input_ids, attention_mask):
        outputs = self.base_model(input_ids, attention_mask=attention_mask)
        # Используем [CLS] токен
        cls_embedding = outputs.last_hidden_state[:, 0, :]
        reward = self.reward_head(cls_embedding).squeeze(-1)
        return reward

# Функция потерь Bradley-Terry
def bradley_terry_loss(chosen_rewards, rejected_rewards):
    # chosen_rewards, rejected_rewards: (batch_size,)
    logits = chosen_rewards - rejected_rewards
    loss = -torch.log(torch.sigmoid(logits))
    return loss.mean()

# Пример батча
batch = {
    'prompt': ['Как дела?', 'Что такое RLHF?'],
    'chosen': ['Хорошо, спасибо!', 'RLHF — это...'],
    'rejected': ['Плохо.', 'Не знаю.']
}
# Токенизация, forward, loss...

11. Когда использовать RLHF evaluation, а когда обычную

СитуацияРекомендуемый подход
Быстрый прототип, baselineОбычная оценка (Likert, BLEU)
Fine-tuning LLM с выравниваниемRLHF evaluation + reward model
Оценка безопасности (harmlessness)RLHF (парное сравнение)
Масштабная автоматическая оценкаRLHF reward model (после обучения)
Сравнение двух моделейA/B тест (можно и обычный, и RLHF)

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

Задача: Создать датасет предпочтений для чат-бота на русском языке, обучить reward model и сравнить её оценку с обычной Likert-оценкой.

Инструменты:

  • Python, Hugging Face Transformers, PyTorch.
  • Датасет: 500 запросов из открытых источников (например, Dolly, Alpaca).
  • LLM для генерации ответов: GPT-2 или небольшая русскоязычная модель (ruGPT-3.5).
  • Платформа для сбора оценок: Google Forms или собственный веб-интерфейс.

Шаги:

  1. Сгенерировать для каждого запроса 2 ответа (разные temperature).
  2. Привлечь 3–5 друзей/коллег для парного сравнения (chosen/rejected).
  3. Обучить reward model (например, на базе ruBERT).
  4. Для тех же запросов попросить оценить каждый ответ по шкале 1–5.
  5. Сравнить корреляцию reward model с человеческими предпочтениями и корреляцию Likert-оценок.

Ожидаемый результат:

  • Reward model покажет более высокую согласованность с человеческими предпочтениями (Cohen’s kappa > 0.6), чем усреднённые Likert-оценки.
  • Вы увидите, что парное сравнение даёт меньше шума.

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

ВопросТема
137LLM-as-a-Judge: автоматическая оценка
139Reward model: архитектура и обучение
140PPO для fine-tuning LLM
141DPO: альтернатива RLHF
142Метрики качества генерации (BLEU, ROUGE, METEOR)
143Оценка безопасности (red teaming)

Навигация