Как вы измеряете quality RLHF модели вне стандартных бенчмарков (MT-Bench)?

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

MT-Bench — полезный, но ограниченный бенчмарк, который не покрывает все аспекты качества RLHF-модели. Для полноценной оценки необходимо комбинировать offline-метрики (rate|win rate против baseline, согласие с человеческими предпочтениями, корреляция с reward model) и online-оценку (человеческие предпочтения в открытых задачах, анализ токсичности, разнообразия и устойчивости к reward hacking). Ключевой принцип — триангуляция: ни одна метрика не является достаточной, только их совокупность даёт надёжную картину.

1. Почему MT-Bench недостаточен

MT-Bench — это набор из 80 многошаговых вопросов, оцениваемых LLM-асессором (GPT-4). Он измеряет общую способность модели следовать инструкциям, но имеет ограничения:

• Узкий домен: вопросы не покрывают специализированные области (медицина, юриспруденция, код).
• Оценка одной моделью: GPT-4 может иметь собственные предубеждения (bias).
• Нет измерения alignment: MT-Bench не проверяет, насколько ответы соответствуют человеческим предпочтениям (helpfulness, harmlessness, honesty).
• Игнорирует долгосрочные эффекты: не выявляет reward hacking или деградацию разнообразия.

Поэтому для RLHF-моделей нужны дополнительные метрики, которые напрямую измеряют качество alignment.

2. Win rate против baseline

Win rate — доля случаев, когда ответ модели предпочтительнее ответа baseline (например, исходной SFT-модели или другой RLHF-модели) по мнению человека или автоматического judge.

Формула:

Win rate = (количество побед модели) / (общее количество сравнений)

Как измерять:

• Собирается набор промптов (100–500), репрезентативных для целевого использования.
• Для каждого промпта генерируются ответы от оцениваемой модели и baseline.
• Асессоры (люди или LLM) выбирают лучший ответ (или объявляют ничью).
• Win rate считается с учётом ничьих (обычно ничьи делятся поровну).

Интерпретация:

Преимущества: простая интерпретация, напрямую отражает улучшение alignment.

Недостатки: зависимость от выбора baseline и набора промптов; требует человеческой разметки (дорого) или автоматического judge (может быть смещён).

Инструменты: AlpacaEval (автоматический judge на GPT-4), Chatbot Arena (человеческие голоса в Elo-рейтинге).

3. Preference agreement с людьми (Cohen's Kappa)

Cohen's Kappa — мера согласия между двумя оценщиками (например, человеком и автоматическим judge) с учётом случайного совпадения.

Формула:

κ = (p_o - p_e) / (1 - p_e)

где p_o — наблюдаемая доля согласия, p_e — ожидаемая доля случайного согласия.

Зачем: если мы используем LLM-асессор для оценки win rate, нужно убедиться, что его предпочтения совпадают с человеческими. Высокий κ (> 0.6) означает, что автоматическая оценка надёжна.

Как измерять:

• Берём подмножество сравнений (50–100 пар).
• Просим людей и автоматического judge оценить каждую пару.
• Считаем κ.

Интерпретация:

Преимущества: количественная оценка надёжности автоматической метрики.

Недостатки: требует человеческой разметки для калибровки; κ чувствителен к распределению классов.

4. Reward correlation (Spearman / Kendall)

Reward correlation — мера того, насколько хорошо обученная reward model (RM) предсказывает человеческие предпочтения. Используется Spearman's rank correlation или Kendall's τ.

Зачем: RLHF опирается на RM; если RM плохо коррелирует с людьми, то оптимизация policy будет неверной.

Как измерять:

• Берём набор пар ответов с человеческими предпочтениями (hold-out set).
• Для каждой пары RM вычисляет разницу reward.
• Считаем ранговую корреляцию между предсказанной разницей и человеческим выбором.

Формула Spearman:

ρ = 1 - (6 * Σ d_i²) / (n * (n² - 1))

где d_i — разность рангов для i-й пары.

Интерпретация:

Преимущества: прямая проверка alignment RM.

Недостатки: требует отдельного датасета с человеческими предпочтениями.

5. Open-ended task evaluation (человеческая оценка)

Open-ended task evaluation — оценка модели на задачах, где нет единственно правильного ответа: креативное письмо, диалог, генерация кода, суммаризация.

Метрики:

• Helpfulness (полезность): ответ решает задачу пользователя?
• Harmlessness (безвредность): нет токсичного, предвзятого или опасного контента.
• Honesty (честность): модель признаёт незнание, не галлюцинирует.
• Coherence (связность): логическая структура ответа.
• Fluency (беглость): грамматическая правильность.

Как проводить:

• Разрабатывается рубрика (scoring rubric) с 3–5 уровнями для каждого критерия.
• Привлекаются 3–5 аннотаторов на каждый ответ.
• Вычисляется средний балл и межаннотаторское согласие (ICC — intraclass correlation).

Преимущества: наиболее полная оценка alignment.

Недостатки: дорого, медленно, субъективно.

6. Дополнительные метрики

6.1 Diversity (разнообразие)

RLHF может привести к коллапсу разнообразия (mode collapse). Измеряется:

• Distinct-1 / Distinct-2 (доля уникальных униграмм/биграмм).
• Self-BLEU (среднее сходство между ответами на один промпт).
• Entropy (энтропия распределения токенов).

6.2 Toxicity и bias

• Perspective API для токсичности.
• BBQ (Bias Benchmark for QA) для стереотипов.
• WinoBias для гендерных предубеждений.

6.3 Reward hacking detection

Проверка, не «взломала» ли модель reward model, генерируя длинные, бессмысленные или повторяющиеся ответы. Метрики:

• Average response length.
• Repetition rate (доля повторяющихся n-грамм).
• Reward vs. length correlation (если высокая — возможен hacking).

7. Инструменты и фреймворки

8. Практические советы по организации evaluation pipeline

1. Определите целевой домен — подберите промпты, репрезентативные для продакшена.
2. Выберите baseline — обычно SFT-модель или предыдущая RLHF-версия.
3. Калибруйте автоматический judge — проверьте Cohen's Kappa на 50–100 парах.
4. Проводите человеческую оценку на 200–500 ответах для ключевых метрик.
5. Мониторьте diversity и toxicity — они могут ухудшиться при агрессивной оптимизации.
6. Используйте hold-out set для reward correlation — не пересекайте с тренировочными данными.
7. Повторяйте оценку после каждого раунда RLHF — alignment может деградировать.

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

Задача: Разработать пайплайн оценки RLHF-модели (например, fine-tuned LLaMA-3-8B) с использованием win rate, Cohen's Kappa и reward correlation.

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

• Python, Hugging Face Transformers, TRL (для RLHF).
• Датасет: Anthropic HH-RLHF (человеческие предпочтения).
• Judge: GPT-4 (через API) или открытая модель (например, Prometheus-2).
• Библиотеки: scipy (для корреляций), sklearn (для Cohen's Kappa).

Шаги:

1. Обучите SFT-модель на подмножестве HH-RLHF.
2. Обучите reward model на том же датасете (с человеческими предпочтениями).
3. Примените PPO для RLHF (используйте TRL).
4. Соберите 100 промптов из тестовой части HH-RLHF.
5. Сгенерируйте ответы от SFT, RLHF и baseline (например, оригинальная LLaMA).
6. Для каждой пары (RLHF vs SFT) получите предпочтения от GPT-4 и от человека (привлеките 2–3 друзей).
7. Посчитайте win rate RLHF vs SFT.
8. Вычислите Cohen's Kappa между GPT-4 и человеком.
9. На hold-out наборе пар посчитайте Spearman correlation между разницей reward (от RM) и человеческим выбором.
10. Дополнительно измерьте diversity (Distinct-1) и среднюю длину ответов.

Ожидаемый результат: Вы получите численные значения метрик и сможете интерпретировать, насколько RLHF улучшил модель, насколько можно доверять автоматическому judge и насколько reward model согласована с людьми.

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

Навигация

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