Что такое preference data collection и как минимизировать bias в сравнениях?

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

Preference data collection — это процесс сбора данных о предпочтениях человека или модели между несколькими вариантами ответов (например, выходов LLM). Такие данные критически важны для методов выравнивания (alignment), таких как RLHF (Reinforcement Learning from Human Feedback) и DPO (Direct Preference Optimization). Основные источники bias (систематических ошибок) в сравнениях — это position bias (влияние порядка показа), fatigue (утомление аннотатора), anchoring (привязка к первому варианту) и contrast effect (влияние контекста). Минимизация bias достигается рандомизацией порядка, короткими сессиями, множественными аннотаторами, калибровкой и статистическими моделями вроде Bradley-Terry и Elo.

1. Что такое preference data и зачем она нужна

Preference data — это набор записей вида (запрос, ответ A, ответ B, метка предпочтения: A > B, B > A, или tie). Такие данные используются для обучения модели-вознаграждения (reward model) в RLHF или напрямую в DPO. В контексте Agentic RAG предпочтения могут собираться для оценки действий агента (какой документ выбрать, какой ответ сгенерировать). Без качественных данных о предпочтениях модель не сможет научиться генерировать полезные и безопасные ответы.

Зачем собирать Collection|data preference data

• Выравнивание LLM с человеческими ценностями (helpfulness, harmlessness, honesty).
• Улучшение качества ответов в RAG-системах (выбор лучшего чанка или рерайта).
• Обучение агентов выбирать оптимальные действия в многошаговых сценариях.

2. Методы сбора preference data

2.1 Парные сравнения (pairwise comparisons)

Аннотатору показывают два ответа на один запрос и просят выбрать лучший (или указать ничью). Это самый распространённый метод, так как он проще для человека, чем абсолютная оценка по шкале.

2.2 Рейтинги (ratings)

Аннотатор ставит каждому ответу оценку по шкале (например, 1–5). Затем предпочтения выводятся из разности оценок. Минус: разные аннотаторы по-разному используют шкалу (leniency/severity bias).

2.3 Турнирная система (Elo rating)

Каждый ответ участвует в серии парных сравнений. После каждого сравнения рейтинг Elo обновляется (победитель получает +k, проигравший -k). Итоговый рейтинг отражает относительное качество. Этот метод устойчив к шуму и позволяет ранжировать много вариантов.

2.4 Множественные аннотаторы

Одна пара ответов оценивается несколькими независимыми аннотаторами. Затем предпочтение определяется большинством голосов или усреднением. Это снижает влияние индивидуальных ошибок.

3. Основные виды bias в сравнениях

4. Стратегии минимизации bias

4.1 Рандомизация порядка (position bias)

Порядок показа ответов A и B должен быть случайным для каждого сравнения. Если ответы генерируются моделью, можно менять их местами и усреднять предпочтения.

4.2 Короткие сессии (fatigue bias)

Ограничить количество сравнений в одной сессии (например, не более 30–50). Ввести обязательные перерывы. Использовать прогресс-бар и предупреждения об усталости.

4.3 Калибровка аннотаторов

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

4.4 Множественные аннотаторы и агрегация

Каждое сравнение оценивают 3–5 аннотаторов. Итоговая метка определяется большинством или с помощью модели Bradley-Terry (см. раздел 5). Это снижает влияние случайных ошибок.

4.5 Использование статистических моделей

Вместо простого голосования применяют Bradley-Terry или Elo, которые учитывают силу каждого аннотатора и вероятность ничьей. Эти модели дают более робастные оценки предпочтений.

4.6 Контроль качества (inter-annotator agreement)

Регулярно вычислять Cohen's kappa (для двух аннотаторов) или Fleiss' kappa (для нескольких). Если согласованность низкая (< 0.6), нужно переобучить аннотаторов или уточнить инструкции.

5. Статистические модели для агрегации предпочтений

5.1 Модель Bradley-Terry

Предполагает, что вероятность того, что ответ i лучше ответа j, равна:

P(i > j) = exp(θ_i) / (exp(θ_i) + exp(θ_j))

где θ_i — «сила» ответа. Параметры θ оцениваются методом максимального правдоподобия по всем парным сравнениям. Модель позволяет учесть ничьи (через порог).

5.2 Система Elo

Изначально разработана для шахмат. Каждый ответ имеет рейтинг R. После сравнения рейтинг обновляется:

R_new = R_old + K * (S - E)

где S — результат (1 — победа, 0 — поражение, 0.5 — ничья), E — ожидаемый результат (логистическая функция от разности рейтингов). K — коэффициент, регулирующий скорость обновления.

Пример кода на Python для симуляции Elo:

import math

def expected_score(rating_a, rating_b):
    return 1 / (1 + 10 ** ((rating_b - rating_a) / 400))

def update_elo(rating_a, rating_b, score_a, K=32):
    ea = expected_score(rating_a, rating_b)
    rating_a_new = rating_a + K * (score_a - ea)
    rating_b_new = rating_b + K * ((1 - score_a) - (1 - ea))
    return rating_a_new, rating_b_new

# Пример: ответ A (рейтинг 1500) побеждает ответ B (1500)
new_a, new_b = update_elo(1500, 1500, 1.0)
print(f"Новый рейтинг A: {new_a:.1f}, B: {new_b:.1f}")
# Вывод: A: 1516.0, B: 1484.0

Elo устойчив к временным изменениям и легко интерпретируется.

6. Инструменты для сбора preference data

7. Оценка качества собранных данных

После сбора необходимо проверить, насколько данные свободны от bias. Основные метрики:

• Inter-annotator agreement (Cohen's kappa, Fleiss' kappa) — показывает согласованность между аннотаторами. Значение > 0.8 считается отличным, 0.6–0.8 — хорошим.
• Position bias ratio — доля случаев, когда выбран первый вариант. Если близка к 0.5 — bias минимален.
• Fatigue curve — график зависимости качества (например, согласия с золотым стандартом) от номера сравнения в сессии. Если качество падает к концу — нужно сокращать сессии.

8. Практические рекомендации для минимизации bias

1. Всегда рандомизируйте порядок ответов в паре.
2. Ограничьте сессию 30–50 сравнениями, вставьте обязательный перерыв.
3. Используйте не менее 3 аннотаторов на каждое сравнение.
4. Проводите калибровку перед началом и периодически во время сбора.
5. Применяйте статистические модели (Bradley-Terry, Elo) вместо простого большинства.
6. Мониторьте метрики согласованности в реальном времени.
7. Включайте контрольные вопросы (gold standard) для выявления невнимательных аннотаторов.

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

Задача Разработать систему сбора preference data для оценки ответов RAG-агента с контролем bias.

Инструменты Python, Argilla (или Label Studio), библиотека elo (самописная), scikit-learn для метрик согласованности.

Шаги:

1. Сгенерировать 100 запросов и по 2 ответа от RAG-агента (с разными параметрами).
2. Настроить интерфейс парных сравнений в Argilla с рандомизацией порядка.
3. Привлечь 3 аннотаторов (можно себя в разные дни) для оценки всех 100 пар.
4. Собрать данные, вычислить Fleiss' kappa.
5. Агрегировать предпочтения с помощью Elo и Bradley-Terry.
6. Проанализировать position bias (доля выбора первого варианта) и построить fatigue curve.
7. Внести коррективы (например, отбросить данные от аннотатора с низкой согласованностью).

Ожидаемый результат Датасет предпочтений с метриками качества, показывающими низкий уровень bias (position bias ratio ~0.5, Fleiss' kappa > 0.7). Вывод о том, какой метод агрегации (Elo или Bradley-Terry) даёт более стабильные ранжирования.

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

Навигация

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